Об DevOps и архитектуру

Святослав Котусев небезызвестный в кругах Enterprise Architecture своими исследованиями EA, выпустил новую версию своего легковесного фреймворка по Enterprise Architecture: https://eaonapage.com/ 4 больших одностраничных карты вместо 1.5 тыс страниц TOGAF (в прошлой версии было 2 одностраничника): Из изменений: - Добавилась модель зрелости EA - Добавились полтора десятка вариантов функциональной оргструктуры архитектуры (в зависимости от размера и типа организации), в т.ч. небольшой бенчмарк по количеству архитекторов в организации - Расширилась карта практик EA (добавились связи с артефактами ЕА, появились примеры, карта стала более практической) - Уточнены формулировке на карте артефактов Рекомендую как минимум полистать всем, кто так или иначе сталкивается со следующими темами или интересуется ими: - Lifecycle объектов уровня солюшена и масштабнее - Опермодель архитектурной функции и взаимодействие между отделами и проектами - Виды архитектурной документации (обоснования, governance, портфолио и архрепозитории)

The Kubernetes design is based on choreography, but can incorporate orchestration benefits. Пояснительная бригада: choreography и orchestration это два подхода композиции микросервисов (паттерна saga). В случае orchestration есть отдельный микросервис, который оркестрирует процесс, проходящий через несколько микросервисов. В случае choreography микросервисы обмениваются событиями напрямую. Так вот, операторы в Kubernetes в общем случае работают в соответствии с подходом Choreography, а не Orchestration как мы могли бы подумать. Что с этим делать? Ничего, просто забавное наблюдение 😃

Мне кажется, половина восторгов вокруг LLM связаны с тем что они постоянно исподволь и умело хвалят человека у клавиатуры, даже если он пишет полнейшую хрень. В обычном цикле работы «гипотеза - реализация - оценка» напрочь ломается последний шаг, если его явно не выносить за рамки чата с LLM. При этом, не важно занимаешься ли ты оценкой своей работы по факту — ты так или иначе ее получаешь в любом случае, и она в любом случае будет носить некоторый объективный характер. В случае с LLM положительное подкрепление получаешь сразу же, при этом независимо от того что вы оба написали — если не развита саморефлексия, получится «я герой, и гитхаб не пустой, но время потрачено, а результата нет»

С этими LLM одни проблемы — количество идей увеличилось в несколько раз. Когда их воплощать то? Вторая проблема (связанная с первой), о которой мало говорят — как и многие современные технологии LLM вторгаются в стандартный культурно-обусловленный дофаминовый цикл. Если раньше в процессе работы над проблемой радость от решения проблем была размазана на длительность работы, то теперь за час разговора можно получить подробный план решения, и пачку тикетов в персональную (или не обязательно персональную) тикетницу на довольно рутинную реализацию. У меня получилась такая эвристика: «если после разговора с LLM ты не почуствовал себя дураком, или не ушел из разговора с вооот такенным списком задач — ты поговорил зря» — знай эти задачи как-то приоритезируй и разгребай. Но в разгребании радости гораздо меньше чем собственно в поиске решения. Навык «разбивать большую задачу на много маленьких, каждая из которых приносит пользу» становится еще более актуальным чем во времена пост-ватерфола: сейчас становится супер легко попасть в ловушку over-engeneering, причем сразу на множестве уровней одновременно: уровне описания проблемы, уровне описания концепции решения, уровне постановки задач, уровне проработки архитектуры решения, уровне определения и проработки границ между компонентами, уровне определения качества этих компонентов. Чуть промахнулся — получил тонны нейрослопа, который еще не сразу заметишь. На уровне реализации все наоборот, хорошо — написал задание, модель тебе написала ответ. Но попутно тут же наплодила долга на всех перечисленных уровнях (и нескольких не перечисленных). А если делать интероп LLM с человеком — чтобы по-очередно могли писать код и люди и LLM получается все еще более интересно, но об этом в другой раз. Что любопытно, практики Devops описанные отцами-основателнями и далее превратившиеся в DX, Evolutionary Architecture, и частично Platform Engineering на концептуально-методическом уровне вполне неплохо помогут справиться с возросшей сложностью

Как я написал в прошлом посте, меня как и во многих других вещах, в контексте LLM интересует в первую очередь методологический аспект: как работать с ними эффективно? При этом я намеренно не задаю определение слова «эффективно», чтобы можно было применять этот подход в разных контекстах. В этот раз я не буду писать долго и много, и просто порекомендую посмотреть на https://github.com/Fission-AI/OpenSpec/ Это одновременно метод и инструмент для построения coding workflow вида «планируем фичу -> проектируем архитектуру -> пишем тесты -> пишем код». На базе него эту эффективность собрать кажется достаточно несложно независимо от того что вы понимаете под «эффективностью»: - если вам дела нет до документации можно ее оставить только как опору для агентов - если вам техническая документации нужна, здесь уже есть готовый каркас на базе которого можно строить и не выдумывать его самому - каркас довольно легковесный, при этом его можно дорабатывать (например корректировать какая именно документация вам нужна) (уточнение: я пока не могу сказать насколько он сочетается с полностью автономными coding agents) Похожие инструменты/подходы, но менее удобные для старта по тем или иным причинам: - https://promptdriven.ai/ — кажется, один из первых подходов «спеки -> доки», который так и не выстрелил, да и помер. Смотреть на него не рекомендую. - https://github.com/github/spec-kit — более детальный по сравнению с OpenSpec и кажется более тяжеловесный подход от Microsoft - https://github.com/bmad-code-org/BMAD-METHOD — на мой взгляд чрезмерно формализованный - Plan & Act — самый простой, но и наименее мощный из всех Как и с изучением всего нового, рекомендую взять какой-то подход и сделать на базе него десяток итераций (реализовать десяток решений любого размера начиная от простейшего скрипта). Мои первые опыты генерировали гигантское количество документации которая не нужна, но теперь я понимаю что именно из нее нужно. Следующая итерация видимо будет обкатка этих подходов в к

Если DevOps был «технологизацией» Agile, то что будет технологизацией AI-gile?

Про доработку и расширение классической сервисной модели расскажу в ближайшее воскресенье на конференции “Современная системная инженерия и менеджмент-2026”

Интересный момент, что с появлением coding agents автоматизация SDLC (т.е. в частности CI/CD, вот это наше всё) стала ещё более важной чем была до этого. Люди более детерминированные чем LLM тупо в силу того что у них есть привычки, и в силу того что постоянно общаются друг с другом вне кода и тикетов. А LLM это бывалый сыч, который всё умеет, но сидит где-то в углу, кодит что-то в одиночку, что-то там бормочет, иногда вскрикивает, и ни с кем не общается. Задачи закрывает быстро, но его лапшу никто кроме него понять не может, да ещё и душнит как только какой-то косяк ему предъявишь. И с одной стороны, для организации такой ситуации нужен нормально работающий SDLC, а с другой — часть его переедет из собственно CI-сервера в AGENTS.md, openscpec workflows и подобные промпт-компоненты

Попросили меня сегодня прокомментировать модель зрелости для внедрения AI в devops, и у меня получились такие интересные результаты, что чем выше уровень зрелости по условному CMMI тем меньше в нем места для AI в принципе. (на примере только CI/CD, не рассматривал другие поднаправления) UPD: кажется можно и в принципе для разработки эту шкалу применять L0 (нулевой). AI не используется для CI/CD. L1 (стихийный). AI для написания и исправления кода пайплайнов по месту. L2 (повторяемый). AI используется для написания сквозных пайплайнов на местах. Задан набор правил и code style для агентов. L3 (управляемый). Заданы критерии качества к коду пайплайнов написанного AI. Построен процесс для контролируемой доставки инкрементов пайплайнов, реализованных агентами. Результаты работы пайплайнов (результаты и логи сборок и т.д.) доступны агентам для анализа. Задана и выполняется политика безопасности для доступа агентов к исходному коду приложений L4 (оптимизируемый). Заданы характеристики качества самих пайплайнов, реализовано измерение качества, эти характеристики качества используются в качестве цели для постановки задач для AI. Заданы и выполняются политики по выполнению операций не связанных с управлением кодом пайплайнов и приложений -- запуск пайплайнов, создание тикетов, создание архитектурных RFC для пайплайнов, работа с секретами (например, создание плейсхолдеров) L5 (инновационный). Выбран портфель характеристик элементов ИТ-ландшафта; характеристики пайплайнов входят в состав этих элементов. Выполняется управление портфелем характеристик, задания на изменение набора характеристик ставятся в качестве задач для AI. Заданы, контролируются и улучшаются правила и полномочия действий конкретных ролей агентов на уровне организации, а не только на уровне технологических элементов. А вы что думаете?