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

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

Agile и DevOps 10-15 лет назад позволили выпускать прототип приложения за месяц, за 3 месяца первую версию, за год полноценный продукт, который генерирует доход.
Если продукт успешен и у основателей есть видение совпадающее с будущей реальностью (и/или влияние на массы), следом за ним выпускались другие продукты и через несколько лет получалась «экосистема продуктов» или «платформа» (as in boundaryless.io, а не team topologies, не перепутайте) — Hashicorp, Ruby on Rails, Kubernetes, Shopify.

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

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

Фактическое воплощение решений — это не писать код или тексты, не рисовать картинки, не строить модели, а вписывать их в реальность.

За этим стоит достаточно большая и непростая работа:
• выстраивание уже существующих систем, людей, и организаций вокруг новой реальности (которой еще нет)
• визионерство того какая это новая реальность в принципе это должна быть
• построение циклов обратной связи для поддержки этой новой реальности (не loop engineering, а построение именно физических циклов в реальности — обмен сообщениями, документами, артефактами и физическими предметами, и конкретные действия сотрудников и систем)
• непрерывная поддержка и корректировка этой картины (continuous vision)
• ну и естественно, создание всех необходимых инструментов, программ и подобных инструментальных объектов — с этим агенты нам помогут

Что-то типа «стартап теперь запустить может каждый», но ограничение теперь не в реализации (она перестала быть ограничением лет пятнадцать назад) и не в стоимости реализации (она перестала быть ограничением сейчас), а в собственно том чтобы брать и делать.

Попросили меня сегодня прокомментировать модель зрелости для внедрения AI в devops, и у меня получились такие интересные результаты, что чем выше уровень зрелости по условному CMMI тем меньше в нем места для AI в принципе.

(на примере только CI/CD, не рассматривал другие поднаправления)
UPD: кажется можно и в принципе для разработки эту шкалу применять

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

А вы что думаете?

Если кого-то из вас shieldybot незаслуженно кикнул из чата — напишите мне (@TimurBatyrshin), я вас разбаню

Недавно Онтико (организаторы крупнейших технологических конференций) сделали публикацию про новую систему разделения труда, которая у нас на подходе с появлением ИИ: https://t.me/onticochannel/60

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

Давайте рассмотрим слайд «Матрица четырёх промышленных революций» (с ним я согласен только отчасти) и проследим как собственно происходила эволюция через революции.

У тебя есть цепочка добавления ценности (совпадает с разделением труда).
Во время промышленной революции №0 (нумерация со слайдов) разделение труда начало проявляться в обществе, а не только в общине: не человек пришел к соседу за луковицей/тканью, а человек пришел к мастеру, который именно этим и занимается профессионально, и занимается не по запросу (ты попросил я сделал), а под постоянный сбыт.
Этот ремесленник, или может быть купец (но еще не предприниматель).

Следующей промышленной революцией обычно считается изобретение паровой машина и механизация силы.
Но вот с промышленными революциями 20 века не все так однозначно.

Если говорить о конвейере как центральном элементе промышленных революций 20в, то до собственно прохождения детали по конвейеру у тебя должна появиться стандартизация изделий и деталей (19в), и дальше декомпозиция техпроцесса на стадии (операции) и их регламентация. Их сборка в поток это и есть конвейер.
Первое — это инженерия, второе — технология.
Работа с временами производства в потоке это менеджмент, но менеджмент процессный, который весьма сильно отличается от например менеджмента проектного и продуктового. И до второй половины 20 века еще не считалось зазорным производить продукцию «на склад», т.е. и процессный менеджмент был в довольно зачаточном состоянии.

Если более пристально посмотреть на изменения цепочки добавленной ценности («горизонтальный сдвиг»), то увидим, что происходили переходы:
• Обособление торгово-сбытовой функции: от «стихийного взаимодействия между ремесленниками» к установившимся цепочкам добавленной ценности (каналам спроса и поставки)
• Появление управленческого учета и здесь же стандартизация выпускаемой продукции (т.е. появление функции проектирование изделий): от простых и локальных цепочек к длинным, сложным и географически распределенным, где нужна спецификация на продукцию
• Становление операционной декомпозиции и регламентации: деление на операции в производстве, конвейер
• Появление процессного управления: оптимизация потока в производстве (TPS, Lean, вот это все), глобализация производств
• Формализация и инструментализация проектирования и перепроектирования систем и организаций <— ИТ здесь
В параллель с этим еще идут сильные линии маркетинговая и предпринимательская (как у Шумпетера) с начала 20в, которые я сейчас не рассматриваю.

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

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

В управление кубером, облаком и инфрой вообще через агентов + MCP есть интересный и тонкий момент.
Это уход от configuration management в «deployless» (шуточный термин): «ща емана тут на проде один параметр поправлю падажжи нах»
Т.е. это шаг назад.

Подобный уход уже был некоторое время назад через Operator Pattern, и к нему до сих пор довольно неоднозначное отношение в сообществе — хорошие операторы писать сложно, пользоваться ими тоже сложно, супер важен API/DX для них и т.д.

Так вот, с агентами и MCP похоже будет продолжение этой истории по одному из направлений (или сразу по всем трем):
• трэш и содомия «deployless и правим на проде» (и все откатится обратно)
• агенты будут не править кубера/облака, а будут коммитить в гит — благо что они это умеют, и дальше все катится обычными пайпами
• либо будет дальнейшее развитие Operator Pattern и пока неясно в какую сторону (замену софта на агента умеет делать мало кто, и плюсы от этого довольно узкие)

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

Рост из миддла в сеньора это не «изучить больше инструментов» или «изучить какие-то инструмент глубоко», а научиться декомпозировать задачу на составляющие, контролировать насколько качественно эти составляющие реализованы.
«Глубокое знание инструментов» (или навык быстро набирать эту глубину) это просто необходимая база для того чтобы выполнять эту самую декомпозицию.
Рядом органично вырастают архитектурные паттерны — если мы можем разрезать задачу на структурные части, то дальше логичным образом мы перестаем оперировать деталями и начинаем оперировать этими самими структурными частями, связями между ними, их характеристиками и т.д.

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

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

И с одной стороны, для организации такой ситуации нужен нормально работающий SDLC, а с другой — часть его переедет из собственно CI-сервера в AGENTS.md, openscpec workflows и подобные промпт-компоненты

Слайды: https://systemschool2026.timurb.ru

Название моего доклада: «Расширение онтологии сервисного запроса при помощи LLM+FPF».
Подключайтесь по этой ссылке (откроется Zoom, сейчас там идут другие доклады):
https://systemschool2026-zoom.timurb.ru
Слайды соедующим сообщением.

Мой слот по расписанию: 13:30-14:00

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

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

Почему это открытие оказалось таким легким и одновременно таким сложным.

Все знают что «классический DevOps» это про ускорять поставку, разработку и т.д.
При этом само понятие давно выродилось, и от devops-инженеров уже давно не ждут «построения DevOps» или чего-то такого, а ждут всяких инфраструктурных задач и кодинга в команде разработки.
И не совсем понятно чем это отличается от сисадминства.

Так вот, отличие в цели этих операций, а не в содержании.

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

Кажется, отличие в цели не очень-то существенно или материально.
Но на деле оно влечет за собой разницу в подходе:
- «Как вы хотите кафку использовать? В каких задачах, какие нагрузки и т.д.?»
против
- «Сколько ей сделать нод, сколько выдать памяти и диска? А авторестарт вам нужен?»

К сожалению, выгружать в человекочитаемом виде наработки по ходу довольно накладно, видимо выгрузку про сервисную модель сделаю уже только когда все закончу.

Но если взглянуть на operations в принципе через призму ITSM/сервисной модели, обнаружилась просто замечательная разница между «devops-инженерами» и «сисадминами».
Над этой разницей мы в программном комитете DevOpsConf (кстати, в апреле уже конференция) мы уже бьемся лет пять, и никак не можем ее ухватить.

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

Подсказка, попробуйте подумать об этом в следующем ключе: какой сервис (as in ITSM) они предоставляют заказчику?

Дальше цитата близко к оригиналу.

Самый простой способ увидеть разницу между Devops и Sysadmin: взять один и тот же технический кейс и посмотреть, какой consumer-facing результат обещаем.

Установить базовые пакеты на все Linux-хосты через Ansible
Devops: Обычно не самостоятельный DevOps service; может быть внутренним carrier для platform/runtime outcome
Sysadmin: Прямой предмет работы: привести хосты к нужному baseline

Написать playbook для развертывания PostgreSQL
Devops: Часть обещания “дать проекту готовый infra component/platform foundation”
Sysadmin: Часть администрирования серверов и сервиса БД

Развернуть кластер Kubernetes
Devops: Дать командам platform foundation: кластер, tenancy, baseline policies, operating model
Sysadmin: Поднять и администрировать кластер как инфраструктурную систему

Настроить ArgoCD
Devops: Дать воспроизводимый deployment/platform contour для проектных команд
Sysadmin: Установить и сопровождать еще один инфраструктурный инструмент

Выдать VPN/доступ в прод
Devops: Если это часть developer enablement к runtime/platform contour
Sysadmin: Прямой предмет работы: доступы, сеть, эксплуатационные правила

Поставить SSL-сертификат в shared Nginx
Devops: Если это часть platform/runtime outcome для команд
Sysadmin: Если это просто администрирование ingress/веб-сервера как инфраструктуры

Разобрать, почему упал deploy
Devops: В этом репозитории это чаще support поверх DevOps service surface
Sysadmin: В sysadmin-модели это обычная эксплуатационная диагностика системы

Если в одной фразе:
DevOps здесь = “обещаем команде воспроизводимый путь поставки или использования платформы”.
Sysadmin = “обещаем корректное состояние инфраструктуры, хостов, доступов и сервисов как таковых”.
SRE = держим сервис надежным по эксплуатационным целям: SLO/SLA, error budget, incident response, capacity, toil reduction, safe change.

(в конце я добавил еще SRE, но с ним и так более-менее понятно
И дополнительно про то, как они друг с другом соотносятся:

sysadmin это набор capability/навыков про инфраструктуру, хосты, доступы, базовые сервисы и их эксплуатацию.
DevOps и SRE могут использовать часть этих capability, но сами они шире и собраны вокруг другой цели.
sysadmin — это общий технический слой, который часто используется внутри DevOps и SRE, но не совпадает с ними.

sysadmin = capability/domain layer
devops = delivery/platform operating model
sre = reliability operating model

На всякий случай уточню, что в данном случае «методом» я называю то, что люди в команде выполняют в рамках своих задач, а не какие-то универсальные способы действовать описанные в книжках или статьях.

Проверочное утверждение: сотрудники работают по некоему методу и получают некий рабочий продукт.
Например:
- разработчики пишут на java::метод и получают модуль аутентификации::рабочий продукт.
- devops-инженеры готовят воспроизводимое изменение IaC::метод и получают скрипты для развертывания БД PostgreSQL::рабочий продукт.

Это примеры методов блока Ядро (K) — для одного и того же сервиса (например, написание IaC) они одинаковы для всех контекстов.

Контекстно-зависимым (S) же методом будет, например Выбрать режим поставки и границы интеграции (выбор режима managed/self-hosted, cloud/on-prem, интеграций и границ ответственности) и при выполнении получиим уточненная спецификация::рабочий продукт.

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

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

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

Если вам интересна эта тема — предложите про что из этого написать более развернуто.

В целом, с LLM удобно и вести исследования различных предметных областей как таковых.

К примеру, в процессе данной работы обнаружилось, что любой метод работы (компетенцию) можно разложить на:
- Ядро метода (K), которое не меняется от проекта к проекту. Пример: «Разворачиваем Gitlab-CI в общем», «знание Ansible»
- Контекстно-зависимые методы (S) — то же самое с репликацией, отказоустойчивостью и резервными копиями. Здесь можно много развивать в любую сторону — это по своей сути system analysis + system design. Написать пайплайн легко — берешь, читаешь туториал и пишешь. А вот вписать его в контекст проекта (количество команд, отзывчивость пайплайна, его надежность, комплаенс по секретам, мониторинг пайплайнов) — это уже совсем другое.
- Внесервисные методы — заказчик часто не может качественно сформулировать запрос на услугу. Например, сколько ему времени хранить резервные копии, или сколько ему нужно диска под данные. Нужно ему в этом помочь, а может быть и убедить что нужно сделать так, а не иначе, т.е. транслировать потребности в требования.

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

По аналогии можно декомпозировать и другие объекты

Конкретно в одной из последних задач LLM мне помогает смоделировать операционную модель команды в проектной организации.

А точнее как более эффективно интегрировать между собой:
- Сервисы/услуги, предоставляемые проектной командой внутри проекта
- Методы работы команды: ядро, контекстно-зависимые методы, внесервисные методы.
- Состав команды
- Грейды (в т.ч. разделение на «базу» и «точки роста» в рамках одного грейда), и назначение грейдов на методы работы
- Предъявляемые артефакты работы для упрощения принятия решения промо/не промо
- Трансформеры для того, чтобы люди двигались на следующий грейд (был человек грейда «джуниор», после участия в некоторой деятельности стал «миддл»).

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

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

В случае работы с LLM при изменении вводных в одном месте все остальное автоматом пересчитывается (возможно нужно дать модели пинок, но это происходит).
По сути у нас получается что-то типа пайплайна CI/CD для текстов, только на базе LLM, а не yaml.

Гипотезы у меня сейчас следующие:
- Насколько хорошо оцифрованная модель команды срисованная с реального мира будет работать и заведется ли вообще? Надеюсь узнаю за 1-2 месяца работы уже «в реальном мире» после того как ее доработаю.
- Автоматический пересчет всех текстов когда я на вход подаю новые вводные: например, если в реальном мире работает все не так как у меня описано, я даю новую вводную и все обновляется само
- Генератор аналогичных описаний для команд другой предметной области. Например, я описываю это все для команды Devops, потом подставляю на вход набор вводных для команды DBA, и он сам генерирует все эти документы по заданному шаблону для новой предметной области.

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