Очень оперативно @codetalkskz опубликовали видео моего всё того же выступления о каскадном снижении связанности! 🔥
Подписывайтесь и ставьте 👍 ))
🍿 Ютуб
🍿 Рутуб

Слайды можно найти постом выше, а описание — ещё чуть повыше

upd: статья на Хабре: https://habr.com/ru/articles/894766/

Про документацию или вопросы от подписчиков.

Руслан, привет!) а подскажи пож-та, может есть у тебя ссылочки на
шаблоны/примеры/лучшие практики по документированию архитектуры и инфраструктуры системы

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

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й-то год существования канала со словом "архитектура" в названии 😅😆 ).

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

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

А теперь обещанные ссылки на мои инструменты, если кто ещё не видел.
Разделы Open-Source репозитория с инструментами и примерами:
- автогенерация архитектуры
- тесты на актуальность архитектуры

Статья про покрытие тестами: https://habr.com/ru/articles/800205/
Общий доклад про все инструменты: https://rutube.ru/video/8ed42e502d514675cbc057c5a6d7b765/

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

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

В последние годы достаточно много езжу по различным ИТ-конференциям и в качестве участника, и спикера, и члена программных комитетов. Это и профильные конференции и митапы для ИТ-архитекторов (например, @archdays_conf), и более широкие, но с обязательными архитектурными докладами или даже целой секцией (например, @cdfst, @TechLeadConfChannel, @HighLoadChannel).

И даже вроде бы находясь в плотном информационно конференческо-архитектурном поле, умудряешься каким-то образом пропустить/не знать про все важные и крутые события 🙃
К примеру, я узнал про Arch.Conf только благодаря приглашению на эту конференцию от одного из организаторов, являющегося подписчиком этого канала 🐱. К сожалению, в этом году не смогу посетить конференцию очно, но в любом случае я теперь про неё знаю, и постараюсь посмотреть доклады в записи.

У нас в компании мы даже пару раз составляли документы со списком, датами и ссылкой на записи на разные полезные конференции, но каждый раз не взлетало — актуальность такой "документации" терялась (т.к. дока не генерировалась автоматом по сайтам конференций и/или не было на неё тестов 😀 [отсылка к прошлому посту]).

Сейчас хочу попробовать воспользоваться одним из новых агрегаторов конференций — https://tg-me.sbs/conference_ru. Помимо всех анонсов парни заявляют, что будут публиковать промокоды, ссылки на открытые записи и (что для меня важно) напоминать про важные даты — начало и окончание приема заявок на доклады, ну и, собственно, сами даты мероприятий 📆

Главное, конечно, не утонуть нам с вами в обилии контента, но это уже тема отдельного разговора 🐱🌚

Весь год фабрика мысли нашей компании😎️ работала на полную мощность. Мы глубоко ныряем в смыслы, чтобы потом было легко на уровне тактики.

Каждый из основателей развивал методы и сообщества в своём направлении:
1. Александр Бындю https://tg-me.sbs/byndyufeed/444
2. Андрей Шапиро https://tg-me.sbs/how2scheme/309
3. Руслан Сафин https://tg-me.sbs/rsa_enc/356

♦️Самый большим общим шагом стало описание фреймворка для проектирования социо-технических систем https://byndyusoft.com/productanalysis. Что из четырех частей этого Фреймворка уже используется в вашей компании?

🤩От всей компании Byndyusoft😎️ желаем вам вкладывать время и жизненную энергию только в что-то действительно стоящее! С наступающим Новым годом 🎄

Денис Бесков сделал подробный разбор моего канала, за что ему огромное спасибо! Было очень приятно читать теплые слова, а практичным советам Дениса я обязательно последую в новом году! 🎄

Читать разбор

А какие у вас, как подписчиков, есть пожелания и рекомендации по моему каналу? Чего бы хотелось, каких тем? Что уже хорошо, а на что обратить внимание?

Всех ещё раз с наступающим! 🥂 ❤️

Приветствую всех в новом году! 🎁

Ещё перед самым новым годом обновили описание нашего фреймворка, которым мы в Бындюсофт 😎️ проектируем и в последствии реализуем сложные ИТ-продукты или даже социо-технические системы.
А именно — добавили описание 4️⃣-го этапа — проектирования архитектуры.

Связующим и необходимым шагом между анализом ИТ-продукта и этапом реализации является проектирование ИТ-архитектуры. Проектируем на основе выявленных целей, приоритизированных гипотез, зафиксированной в виде историй функциональности продукта и подсчитанных нефункциональных требований. Кроме того, грамотно спроектированная архитектура обеспечивает высокую скорость и надёжность внесения изменений в автоматизируемые бизнес-процессы на протяжении всего жизненного цикла продукта.

Обычно я выделяю 5 основных разрезов ИТ-архитектуры и её реализации при проектировании продуктов:
1. Архитектура ИТ-инфраструктуры
2. Схемы информационных потоков
3. Оркестрация бизнес-процессов
4. Микросервисная архитектура решения
5. Дорожная карта встраивания архитектуры решения в текущий ландшафт архитектуры предприятия

Чуть нагляднее — по ссылке.

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

Всех ещё раз с наступившим! ❤️

В этом году я состою в командах организаторов нескольких ИТ-конференций и почти во всех из них в том числе отвечаю за архитектурные доклады — приглашаю спикеров, отсматриваю заявки, помогаю с подготовкой докладов. Буду рад вашим заявочкам 😊
А если хотите, но не знаете с чем податься — помогу с идеями и выбором темы, пишите!

Кроме того, можно присоединиться на открытые встречи спикеров (я как раз и буду на них представлять программный комитет (ПК)), послушать чего мы ждем, обсудить или спросить про свои идеи:
📆 28 января 18:00 — онлайн-встреча с ПК CTO Conf, встреча открытая по предварительной регистрации
📆 29 января 18:00 — онлайн-встреча с ПК TechLead Conf, встреча открытая по предварительной регистрации

CTO Conf — абсолютно новая конференция для технических директоров, в которой я отвечаю за секцию технологий.

Про родные края я тоже стараюсь не забывать — мы начали подготовку к UWDC 25! 🏔

И с особой любовью и гордостью расскажу про свою новую позицию в CodeFest 🎙☺️. Нет-нет, я все так же занимаюсь архитектурными докладами для Кодфеста, но теперь не только!
На юбилейный 15й CodeFest мы готовим что-то по истине грандиозное — что-то, чем хотим на самом деле бустануть индустрию, насколько это возможно с позиции организаторов конференций. Это секция Будущего!

Понимание будущего теперь в том, что нет никакой границы между сегодня и завтра, что будущее уже здесь, что мы в него вступили и в нём живём. Действительный прорыв в понимании и концепциях в том, чтобы признаться себе и уже начать жить в новом. Сделать смелый переход: от отложенной жизни и взгляда вперёд к жизни в моменте и взгляду вокруг. У нас всё для этого есть. Итак, добро пожаловать — Будущее! Устраивайтесь поудобнее.

Полный вижн секции: https://15.codefest.ru/themes#future

Если вы проектируете и создаёте архитектуры проектов, меняющих мир — срочно подавайтесь с докладами и/или пишите мне! 🚀🚀
Ведь прямо сейчас мы создаём будущее и меняем настоящее 🧑‍🚀

15 февраля впервые в России (😅) представлю выведенный мной Принцип каскадного снижения связанности! 🚀

Описание и тезисы первой версии доклада (в 🇰🇿) публиковал ранее.

Сейчас добавил в доклад пример использования принципа для проектирования новых интеграций: рассмотрим пример, когда новая планируемая "в лоб" интеграция приводит к нарушению принципа (поговорим чем это плохо помимо формального нарушения правила), и обсудим как запроектировать интеграцию с соблюдением принципа (и чем это поможет избежать реальных проблем в будущем).

Обновлённую версию доклада расскажу 15 февраля в рамках онлайн-конференции Analyst Marathon #12:
https://tg-me.sbs/Analyst_maraphon/323
(кому нужны промокоды и скидочки (их ограниченное количество) — пишите в комментарии или в личку)

🌌🌌🌌🧑‍🚀

Очередное сообщение в корпоративном чатике о том, что "* * * прилёг" и теперь у нас не работает часть систем, застало меня за чтением советского (⭐️!) ГОСТа 27.002-89 "НАДЕЖНОСТЬ В ТЕХНИКЕ".

1.1. Надежность
Reliability, dependability
1.2. Безотказность
Reliability, failure-free operation
1.3. Долговечность
Durability, longevity
1.4. Ремонтопригодность
Maintainability
1.5. Сохраняемость
Storability

ничего не напоминает? 😏

Видимо верно говорят, что сейчас нет ничего нового, а есть только советские разработки на бумаге, до которых сейчас наконец-то дошли руки 😉

ГОСТ предлагает чёткие определения понятий и классификацию состояний объектов и видов отказов, а также конкретные формулы расчета вероятности отказов.
В ГОСТе говорится о сложных технических объектах, которым свойственен износ и срок наработки. В этом плане, наверное нельзя один к одному перенести методики расчета на программные компоненты распределенных систем (наверное вы уже догадались, что я к этому клоню), т.к. те же наши всеми любимые микросервисы падают скорее не из-за временно́го износа, а по причине внесения изменений или внешних факторов (хотя наверное это всё тоже можно как-то наложить на шкалу времени и придумать формулы — было бы интересно попробовать 🤔).

Но всё чаще в публичных постмортемах ⚰️ крупных сбоев первопричиной становится выход из строя как раз физического оборудования (недавно где-то было про выгоревший порт коммутатора), что как раз поддаётся прогнозированию и расчётом по формулам из прошлого тысячелетия 📜

Т.е. в пресловутый расчёт количества девяток после запятой можно попробовать включить давно известную теорию, правда при этом придётся уже на уровне архитектуры железа стрясти с производителей необходимые параметры, либо проводить испытания самим 😅.

Не факт, что на практике это было бы целесообразно для большинства проектов, но если от отказа вашей программно-аппаратной системы много чего критичного зависит.. хотя наверное вы уже и так тогда знакомы с данным ГОСТом (собственно почему я его и изучал 🙃).

В целом, возвращаясь к отказоустойчивости именно софта: если у вас достаточно много статистических данных по различного рода отказам — ради интереса можно попробовать применить ГОСТовские формулы для расчета различных показателей отказоустойчивости (и наложить потом результаты расчетов на реальные факты и время отказов 👩‍🎓).

И в любом случае, независимо от накопленной статистики, я советую всем проводить учения и тесты своих систем на отказоустойчивость и восстановления после сбоев. У меня есть отдельная статья про проектирование отказоустойчивости и её измерении: https://habr.com/ru/articles/764904/

ГОСТ

Всем стабильных систем 🌀, и всех с наступающим 💗!

[пятничный пост]

Вчера в беседе внезапно вывели метрику стабильности и отказоустойчивости систем ))

Суть в том, что у меня в холодильнике достаточно долго лежала баночка брендированного подарочного энергетика с одного из давних Хайлоадов. Лежала она на случай внезапного падения прода в разгар ночи — точнее на случай необходимости взбодриться и оперативно тушить пожары и поднимать всё упавшее.

Так вот, эту баночку пришлось выкинуть, т.к. у энергетика вышел срок годности 📆
И на неделе я купил новую и положил в холодильник на тот же случай.

Получилась вот такая метрика стабильности наших систем, и хороший показатель этой метрики 🕶

Принял участие в записи аудио-подкаста Цифровые голоса, побеседовали про мою любимую тему — Архитектуру как код 😊
https://rutube.ru/video/a0948a611c85b4f284f8e1695099815c/

Тайминг и этапы беседы по мнению YaGPT 🤖:

00:00:05 — Введение в архитектуру как код
00:00:39 — Что такое архитектура как код
00:02:49 — Преимущества архитектуры как код
00:04:48 — Инструменты для архитектуры как код
00:06:07 — Тестирование архитектуры
00:08:06 — Документирование и создание новых архитектур
00:09:15 — Примеры тестов
00:11:10 — Проектирование нового проекта
00:12:09 — Архитектуры и итерации
00:12:59 — Повторное использование элементов
00:15:29 — Нотации и инструменты
00:17:03 — Языки и инструменты
00:20:31 — Применение AaC в проектах
00:22:59 — Проблемы с асинхронной связью
00:23:58 — Внедрение автоматизации
00:25:09 — Рекомендации для начинающих
00:25:47 — Тестирование архитектуры
00:26:47 — Заключение

🎧🎧🎧

В очередной раз размышляя о настоящем и будущем программирования, я решил подумать об этом через метадоксы.
Это такая техника описания сложного.

В целом, термин "метадокс" уже хорошо гуглится, к примеру краткое видео с его определением от одного из авторов: https://www.youtube.com/watch?v=b9Nt_Ipo230

Если вкратце, суть метадокса насколько я его понимаю — в переходе от бинарного противоречия к тернарному и в описании неких промежуточных состояний, уходящих во фрактальную бесконечность.

Думаю, всё будет ясно на примере.

В вершины базового метадокса (треугольника) поместим 3 основных разных подхода к программированию на текущий момент (всё сугубо только на мой субъективный взгляд):
Классическое программирование — Искусственный Интеллект (ИИ) — Low Code.

Далее в каждой из вершин составляем свой треугольник и пытаемся понять, чем является каждая из вершин более мелкого треугольника.
Начнем с классического программирования:  у треугольника этой вершины будут три своих вершины:
- классическое программирование с оттенком ИИ,
- классическое программирование с оттенком Low Code,
- классическое программирование с оттенком классического программирования.

Теперь подумаем, что есть что в современном многообразном ландшафте нашей айтишечки. Я предложу свои варианты (с разной степенью субъективной уверенности в них) и буду рад услышать альтернативные предложения и рассуждения.

🔼Классическое программирование с оттенком ИИ — имхо, это таблицы решений, которые с одной стороны максимально чёткие в плане классического программистского если-то, с другой — чуть приближены к математической магии машинного обучения (к примеру, к тем же деревьям решений)

Идём дальше.

🔼Классическое программирование с оттенком Low Code — это различные DSL, т.е. языки программирования приближенные и заточенные под конкретную доменную область. Этакий промежуток между универсальным языком программирования и LowCode'ом )

🔼И наконец, классическое программирование с оттенком классического программирования — на мой взгляд, это функциональщина ) Оргазм любого тру хардкор олдскул программиста )
〰️〰️〰️〰️

Думаю, логика понятна. Попробуем заполнить и следующие вершины.

🔼ИИ с оттенком ИИ — это наш всеми ожидаемый AGI: сильный (или общий) ИИ. Технологическая сингулярность, точка невозврата и вот это вот всё 👁

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

🔼ИИ с оттенком Low Code — тут пока сложно, возможно соответствующих ярких представителей категории пока ещё и не изобрели (как и рядом стоящих Low Code с оттенком ИИ).. Я бы сюда отнёс в целом программирование с помощью LLM-моделей (всякие копилоты): ты ей промт на белковом человечьем, а она тебе в ответ код. В таком подходе программировать можно и не уметь, но чуть-чуть (Low) придётся.
〰️〰️〰️〰️

И последний треугольник второго уровня (коих может быть сколько угодно) — Low Code.

🔼Начнём с трудного: Low Code с оттенком ИИ — как и писал выше, с одной стороны я не вижу тут одного яркого представителя или технологии (возможно это значит что ниша ещё не до конца сформирована). С другой — в свои Low Code платформы не пытается встроить ИИ сейчас только ленивый: мы установили одну хайповую технологию в другую хайповую технологию 🏎. Пусть тут будут эти многочисленные ИИ-конструкторы, якобы создающие прототипы CRM-систем по экспорту задач из трелло.

🔼Low Code с оттенком Low Code — ещё одна недостижимая точка, мечта всех маркетологов — No Code 🤤

🔼Low Code с оттенком классического программирования — различные BPMN-движки, прокидывающие мостик между наглядностью визуализации и суровыми энтерпрайзными json'о-перекладывателями микросервисами.
〰️〰️〰️〰️

Вывода не будет (пока). Предлагаю вместе порассуждать над вариантами вершин всех треугольников, покидать альтернативы.

Прежде чем продать понять что-то ненужное сложное, нужно сначала купить описать что-то сложное
🧠