Руслан Сафин ♟️

Архитектор распределённых систем. Автор курса и тг-канала:
| CTO и соучредитель @byndyusoft
| ПК #CodeFest и #TechLeadConf
| КМС по ♟️

[Руслан Сафин ♟️ @razonrus]

Твит для закрепа. Несмотря на то, что мой курс по проектированию микросервисной архитектуре теперь можно купить отдельно (https://t.co/W5V5HNtaMF), почти все теоретические материалы есть и будут в открытом доступе. Ссылки в треде:

[Руслан Сафин ♟️ @razonrus]

Ссылки на опубликованные в общем доступы материалы, на которых основан мой авторский курс по проектированию микросервисной архитектуре.
Тред ⏬

[Руслан Сафин ♟️ @razonrus]

@tatarmagister У меня тоже 2 из 3 заграниц в этом году – нерабочие )

[Руслан Сафин ♟️ @razonrus]

Горы 2024.
Питер → Стамбул → Питер → Челябинск → Питер → Москва → Питер → Сколково → Питер → Москва → Питер → Казань → Иннополис → Казань → Питер → Новосибирск → Екатеринбург → Питер → Челябинск → Питер → Москва → Питер → Терскол (Эльбрус) → Питер → Выборг → Питер → Тбилиси → Питер → Москва → Питер → Челябинск (Таганай) → Питер → Москва → Питер → Алматы → Питер → Сколково → Питер → Пермь → Питер → Челябинск (Тургояк) → Питер

перелетов: 25
поездов: 12

А следующий перелёт уже послезавтра 🛫 – и снова горы

[Руслан Сафин ♟️ @razonrus]

Спасибо вам! За все сердечки и огонёчки и слова 🥰
Это меня драйвит и заряжает энергией двигаться дальше! 💙

[Руслан Сафин ♟️ @razonrus]

Поздравление Сергея Борисовича Переслегина с новым годом.
Вдвойне приятно, что я лично присутствовал на упоминаемой деньрожденческой лекции "Россия. Предрассветные годы"
https://t.co/4Io2rxW9rx

Рутуб: https://t.co/U5u9NEb3yj

[Руслан Сафин ♟️ @razonrus]

Подвёл (😉) итоги года! 🥂
https://t.co/FCKxr56OE2

[Руслан Сафин ♟️ @razonrus]

Всех с наступающим! Всех жду 31 мая в Новосибе! Мы готовим нечто воистину особенное! 🚀 #codefest

[Руслан Сафин ♟️ @razonrus]

@sharslammer хахах, получается надо сюда перестать публиковать то же самое, что и в канал, чтобы там нарастить подписчиков? )))

[Руслан Сафин ♟️ @razonrus]

Разбор моего телеграм-канала "Архитектура распределённых систем" (https://t.co/x0OBiPqBDC) от Дениса Бескова: https://t.co/cGKLzknemC ❤️

[Руслан Сафин ♟️ @razonrus]

@gaxeliy Просто дублирую туда некоторые записи из канала про ит-архитектуру и некоторые твиты ))

[Руслан Сафин ♟️ @razonrus]

@gaxeliy ахах, я выбрал самый непопулярный вариант ))

[Руслан Сафин ♟️ @razonrus]

В Питер пришел снег

[Руслан Сафин ♟️ @razonrus]

Как бы мы не были завалены работой, мы всегда сможем её развалить

[Руслан Сафин ♟️ @razonrus]

Отчётный ролик CodeTalks 2024: https://t.co/Pu4Nz1xeLZ

[Руслан Сафин ♟️ @razonrus]

А теперь и в виде статьи на Хабре: https://t.co/zbIfZKUOcB
➕'аните, если считаете полезным/интересным 😊

[Руслан Сафин ♟️ @razonrus]

Про документацию, неоднозначность термина "as Code" или вопросы от подписчиков.
> Руслан, привет!) а подскажи пож-та, может есть у тебя ссылочки на шаблоны/примеры/лучшие практики по документированию архитектуры и инфраструктуры системы

Вопросы документирования и особенно актуальности документации — на мой взгляд, одни из самых больных в нашей с вами айтишечке. Но, если дело касается сущностей, которые мы можем описать кодом (или как код) — всё становится сильно проще.

1️⃣ Лучшая документация — это всегда актуальная документация. Такой вариант возможен только в двух случаях:
🌹 при автоматической генерации документации (описания) из реального положения дел (для исполняемого кода API таким примером будет Swagger)
🌹 или же наоборот — генерации "реальности" из описания (в случае Infrastructure as Code примером может быть разворачивание инфраструктуры из её описания в yaml-формате).

2️⃣ Если лучший вариант нам недоступен, то хорошо бы нам хотя бы иметь автоматический сигнал о том, что наша документация разъехалась с реальностью (или наоборот). 🚨
Источником такого сигнала должны стать тесты — мы их можем и будем запускать при любом изменении и системы (реальности), и её описания. И в случае расхождения тесты должны падать (блокируя тем самым дальнейшее попадание порождающих несоответствие изменений в основную ветку/новый релиз и т.д.).
Базовое свойство тестов — они должны быть воспроизводимы и независимы от внешних условий. Именно поэтому ручные проверки не попадают в эту категорию (регламентированная ручная проверка на актуальность документации при каждом тестировании не работает, т.к. имеет в основе своей человеческий фактор).

3️⃣ а вот третьего, на мой взгляд, не дано. Либо у вас есть автодокументация, либо есть автоматизированные тесты, проверяющие актуальность. В противном случае — всё, ваша документация рано или поздно в бо́льшей или меньшей степени, но станет неактуальной. Без вариантов. И никакими оффлайн-процессами или регламентами это не решить.
Есть, конечно, ещё один граничный случай — это когда в проект никаких изменений не вносится.. Но это означает, что проект мёртв, и этот случай нам неинтересен ⚰️

Итак, возвращаясь к архитектуре и инфраструктуре.

🌺 Начнём с инфры. Если у вас реализован подход Infrastructure as Code (IaC) и всё разворачивается из кода (описания) инфры — то уже всё хорошо. По сути ваши yaml или другие файлы и являются документацией (сюда попадает не только статичная инфра, но и различная инфраструктурная логика: мониторинг и правила алертинга, например). А если хочется иметь документацию по инфраструктуре в более удобном и наглядном виде — всегда можно написать различные генерилки/визуализаторы из yaml и json в красивый текст и схемки (или даже интерактивный, как у Swagger). А возможно, такие инструменты уже и существуют (накидайте, плиз, если да).

🌺 С архитектурой всё чуть сложнее. Подход Architecture as Code (AaC) в отличие от IaC не предполагает, что по описанной в коде архитектуре всё будет разворачиваться и работать согласно ей. В большинстве случаев предполагается лишь описание архитектурных схем кодом из которого генерируется картинка, а не просто картинкой. В таком случае Architecture as Code на самом деле всего-то навсего Architecture Scheme as Code ☹️. Т.е. не сама ИТ-архитектура, а лишь опять же её документация в виде схемки или нескольких.

Тут некоторые читатели могут задаться вопросом — а что же такое ИТ-архитектура, если не просто схемка или набор схемок?

Готовясь к одному из своих докладов, я гуглил разные определения ИТ-архитектуры. И к своему удивлению нашел одно из лучших, на мой взгляд, в стандарте (ANSI/IEEE Std 1471-2000):

«Фундаментальная организация системы, реализованная в её компонентах, их взаимоотношениях друг с другом и средой и принципах, определяющих её конструкцию и развитие»

Т.е. архитектура — это даже больше чем просто "описание реальности" как IaC, но и принципы, определяющие в том числе и её развитие (т.е. будущее). Но сейчас не об этом... Про то, что такое архитектура надо будет как-нибудь отдельный пост написать 🙂 (и это на 4й-то год существования моего тг-канала (https://t.co/rl1jh1QwtB) со словом "архитектура" в названии 😅😆 ).

Скрепя сердце приравняв архитектуру к документации, вернемся к вопросу актуальности этой документации. Описав архитектурные схемки кодом (т.е. применив AaC) мы можем пойти описанными выше путями в плане автодокументации или тестов на актуальность, но для этого нужны ещё инструменты над AaC (см. ниже). Т.е. всё-таки as Code нам помогает, хоть и в меньшей степени, чем в IaC, где as Code уже гарантирует соответствие реальности и описанию (коду).

Вот так, размышляя о документации, мы пришли к выводу о различии подходов, называемых as Code в инфраструктуре и архитектуре 🥲.

А теперь обещанные ссылки на мои инструменты, если кто ещё не видел.
Разделы Open-Source репозитория (https://t.co/JAzHwBptxs) с инструментами и примерами:
- автогенерация архитектуры: https://t.co/8L8MDxvx5c
- тесты на актуальность архитектуры: https://t.co/tfbugmP2c7

Статья про покрытие тестами: https://t.co/0VgdAUWrwR
Общий доклад про все инструменты: https://t.co/ClPFAdnSHf

Оффтоп. И всё-таки, согласно в том числе и определению из стандарта, архитектура — это в том числе и принципы на которых она построена, а один из способов описания таких принципов (ещё и сразу же автоматизирующий проверку их выполнения) — это тесты на соблюдение архитектурных принципов: https://t.co/tfbugmP2c7

Всё. Теперь точно всё )
❤️

[Руслан Сафин ♟️ @razonrus]

ахахах )

[Руслан Сафин ♟️ @razonrus]

@oldValkyrie А в один твит при купленном премиуме влезло! 😂
https://t.co/8LsN0a2O5n

[Руслан Сафин ♟️ @razonrus]

Про документацию, неоднозначность термина "as Code" или вопросы от подписчиков.
> Руслан, привет!) а подскажи пож-та, может есть у тебя ссылочки на шаблоны/примеры/лучшие практики по документированию архитектуры и инфраструктуры системы

Вопросы документирования и особенно актуальности документации — на мой взгляд, одни из самых больных в нашей с вами айтишечке. Но, если дело касается сущностей, которые мы можем описать кодом (или как код) — всё становится сильно проще.

1️⃣ Лучшая документация — это всегда актуальная документация. Такой вариант возможен только в двух случаях:
🌹 при автоматической генерации документации (описания) из реального положения дел (для исполняемого кода API таким примером будет Swagger)
🌹 или же наоборот — генерации "реальности" из описания (в случае Infrastructure as Code примером может быть разворачивание инфраструктуры из её описания в yaml-формате).

2️⃣ Если лучший вариант нам недоступен, то хорошо бы нам хотя бы иметь автоматический сигнал о том, что наша документация разъехалась с реальностью (или наоборот). 🚨
Источником такого сигнала должны стать тесты — мы их можем и будем запускать при любом изменении и системы (реальности), и её описания. И в случае расхождения тесты должны падать (блокируя тем самым дальнейшее попадание порождающих несоответствие изменений в основную ветку/новый релиз и т.д.).
Базовое свойство тестов — они должны быть воспроизводимы и независимы от внешних условий. Именно поэтому ручные проверки не попадают в эту категорию (регламентированная ручная проверка на актуальность документации при каждом тестировании не работает, т.к. имеет в основе своей человеческий фактор).

3️⃣ а вот третьего, на мой взгляд, не дано. Либо у вас есть автодокументация, либо есть автоматизированные тесты, проверяющие актуальность. В противном случае — всё, ваша документация рано или поздно в бо́льшей или меньшей степени, но станет неактуальной. Без вариантов. И никакими оффлайн-процессами или регламентами это не решить.
Есть, конечно, ещё один граничный случай — это когда в проект никаких изменений не вносится.. Но это означает, что проект мёртв, и этот случай нам неинтересен ⚰️

Итак, возвращаясь к архитектуре и инфраструктуре.

🌺 Начнём с инфры. Если у вас реализован подход Infrastructure as Code (IaC) и всё разворачивается из кода (описания) инфры — то уже всё хорошо. По сути ваши yaml или другие файлы и являются документацией (сюда попадает не только статичная инфра, но и различная инфраструктурная логика: мониторинг и правила алертинга, например). А если хочется иметь документацию по инфраструктуре в более удобном и наглядном виде — всегда можно написать различные генерилки/визуализаторы из yaml и json в красивый текст и схемки (или даже интерактивный, как у Swagger). А возможно, такие инструменты уже и существуют (накидайте, плиз, если да).

🌺 С архитектурой всё чуть сложнее. Подход Architecture as Code (AaC) в отличие от IaC не предполагает, что по описанной в коде архитектуре всё будет разворачиваться и работать согласно ей. В большинстве случаев предполагается лишь описание архитектурных схем кодом из которого генерируется картинка, а не просто картинкой. В таком случае Architecture as Code на самом деле всего-то навсего Architecture Scheme as Code ☹️. Т.е. не сама ИТ-архитектура, а лишь опять же её документация в виде схемки или нескольких.

Тут некоторые читатели могут задаться вопросом — а что же такое ИТ-архитектура, если не просто схемка или набор схемок?

Готовясь к одному из своих докладов, я гуглил разные определения ИТ-архитектуры. И к своему удивлению нашел одно из лучших, на мой взгляд, в стандарте (ANSI/IEEE Std 1471-2000):

«Фундаментальная организация системы, реализованная в её компонентах, их взаимоотношениях друг с другом и средой и принципах, определяющих её конструкцию и развитие»

Т.е. архитектура — это даже больше чем просто "описание реальности" как IaC, но и принципы, определяющие в том числе и её развитие (т.е. будущее). Но сейчас не об этом... Про то, что такое архитектура надо будет как-нибудь отдельный пост написать 🙂 (и это на 4й-то год существования моего тг-канала (https://t.co/rl1jh1QwtB) со словом "архитектура" в названии 😅😆 ).

Скрепя сердце приравняв архитектуру к документации, вернемся к вопросу актуальности этой документации. Описав архитектурные схемки кодом (т.е. применив AaC) мы можем пойти описанными выше путями в плане автодокументации или тестов на актуальность, но для этого нужны ещё инструменты над AaC (см. ниже). Т.е. всё-таки as Code нам помогает, хоть и в меньшей степени, чем в IaC, где as Code уже гарантирует соответствие реальности и описанию (коду).

Вот так, размышляя о документации, мы пришли к выводу о различии подходов, называемых as Code в инфраструктуре и архитектуре 🥲.

А теперь обещанные ссылки на мои инструменты, если кто ещё не видел.
Разделы Open-Source репозитория (https://t.co/JAzHwBptxs) с инструментами и примерами:
- автогенерация архитектуры: https://t.co/8L8MDxvx5c
- тесты на актуальность архитектуры: https://t.co/tfbugmP2c7

Статья про покрытие тестами: https://t.co/0VgdAUWrwR
Общий доклад про все инструменты: https://t.co/ClPFAdnSHf

Оффтоп. И всё-таки, согласно в том числе и определению из стандарта, архитектура — это в том числе и принципы на которых она построена, а один из способов описания таких принципов (ещё и сразу же автоматизирующий проверку их выполнения) — это тесты на соблюдение архитектурных принципов: https://t.co/tfbugmP2c7

Всё. Теперь точно всё )
❤️

[Руслан Сафин ♟️ @razonrus]

@oldValkyrie хахах, это не я ))
хотя как раз в итоге вчера этот пост в дзен и засунул 😅
https://t.co/rAqKtqz9Zg

[Руслан Сафин ♟️ @razonrus]

о, у меня про это есть на одном из слайдов из доклада выше. Сейчас замыслы описываю в ADR, и если удается — в виде теста.
И в посте годичной давности:
> ...Суть в первичности инженерного решения, а не в его проверке на последнем этапе зацикливания обратной связи. Суть в автоматической генерации реализации принятого решения, уничтожения самой возможности совершить ошибку, т.е. хрупкости, а не в проверке на хрупкость путём краштеста с находящимся за лобовым стеклом манекеном из времени разработчика и денег заказчика.
https://t.co/v591jKEm7v