The State of DevOps Modernization 2026 (Рубрика #Devops)

Изучил недавно вышедший отчет "The State of DevOps Modernization 2026" от Harness. Отчет основан на опросе ~700 инженеров и руководителе, что был проведен в феврале 2026 года компанией Coleman Parkes. Основной вывод отчета в том, что AI резко ускорил локальный цикл кодирования, а остальная часть delivery контура во многих командах внутри корпораций не успевает его переварить.

Основная аналитическая модель отчета очень простая: почти все выводы построены через cross-tab по вопросу "как часто вы используете AI инструменты для кодирования" - от нескольких раз в день до более редкого использования. То есть это не анализ телеметрии и не каузальный инференс как в DORA, а срез восприятия и самооценок респондентов.

Авторы выделил следующие ключевые результаты

1️⃣ Скорость действительно выросла. 45% very frequent AI пользователей говорят о ежедневных или чаще развертывания против 32% у frequent и 15% у occasional users. Но рядом с этим идет налог на стабильность: 69% very frequent users говорят, что AI-generated code приводит к проблемам с развертыванием как минимум в половине случаев; 22% deployments в этой когорте заканчиваются rollback, hotfix или customer-impacting incident; MTTR по таким инцидентам у них выше - 7.6 часа против 6.0 и 6.3 часа в соседних когортах.

2️⃣ Но это напряжение распространяется далеко за пределы инцидентов. Среди very frequent AI users 50% говорят о росте vulnerabilities/security инцидентов и 50% - о росте non-compliance issues; 49% видят больше проблемы с производительностью; 51% - больше code quality/efficiency problems. При этом сами авторы специально оговаривают: явной причинно-следственной связи между AI coding и этими проблемами отчет не доказывает (такой дизайн эксперимента может показать только корреляции)

3️⃣ Coding автоматизируется быстрее, чем остальной SDLC. 84% респондентов используют AI ежедневно для coding, но для QA testing этот показатель 68%, для performance/cost optimization 63%, для refactoring 62%. 47% very frequent users говорят, что ручная работа дальше по пайплайну после кода стала проблемнее (это QA, code review, remediation); 69% теряют время из-за медленных и ненадженых CI/CD; 70% считают, что их pipelines страдают от flaky тестов and неуспешных развертываний; 75% связывают давление на шиппинг с выгоранием; 73% говорят, что у них почти нет стандартных темплейтов и golden paths

В итоге, видно, что проблема в том, что AI усиливает throughput там, где платформа, CI/CD, гейты контроля и координация остались на старой скорости. Авторы сами это почти проговаривают: у них есть гипотеза, что heavy AI users просто пытаются доставлять больше кода и поэтому острее чувствуют flaky tests и deployment failures; их pipelines не обязательно хуже, просто потребности уже выше. Это сильный инсайт, но как доказательств причинности отчет не дает:)

Примерно эти же мысли я писал в статье "От классического PDLC к AI-native разработке", но в основном опирался на другие исследования типа DORA или нашего AI4SDLC, который мы проводили от "Т-Технологий" в конце прошлого года и проведем еще раз в этом году

#Engineering #AI #Metrics #Software #DevEx #Productivity #DevOps #Architecture #Culture #Engineering #ML #SystemDesign

[1/2] The State of DevOps Report 2026 от Perforce (Рубрика #DevOps)

Изучил новый "State of DevOps 2026" от Perforce, который фокусировался на вопросе: что на самом деле определяет успех AI в системе поставки ценности - сами AI-инструменты или зрелость инженерной системы. Этот вопрос обусловлен вендорской спецификой, так как Perforce - это вендор Devops стека, поэтому авторы исследовали связь между зрелостью DevOps процессов, глубиной внедрения AI, ролью платформенной инженерии и IDP, а также пробелами в измерениях и экономическим эффектом AI относительно стоимости. Ну и ребята пришли к логичному выводу, что для масштабирования AI нужны зрелые DevOps практики и процессы.

Методология выглядела как опрос 820 респондентов из глобального собщества, которые принимают IT решения, влияют на IT закупки, выбор инфраструктурных и платформеннных инструментов, а также на mission-critical приложения. С учетом такой выборки это скорее менеджерский взгляд на связь зрелости DevOps практик и AI, а не взгляд с позиции инженеров. Забавно, что авторы отфильтровывали из отчета менеджеров, которые не смогли бы объяснить коллегам термин "Agentic AI". А зрелость DevOps процессов авторы определяли операционно: через степень стандартизации delivery, качество работы с инцидентами, а также долю автоматизации деплоев, наличие автоматических rollback. В общем, авторы не претендуют на репрезентативность и выявление причинно-следственных связей, но дают интересную описательную статистику.

В основу исследования легли четыре ключевых вопроса
1) Влияет ли зрелость DevOps на успех AI?
2) Что нужно, чтобы AI масштабировался между командами - локальные инструменты или централизованные системы, IDP (внутренние платформы разрботки) и control planes?
3) Умеют ли компании измерять и аудировать AI, или пока просто "верят", что он помогает?
4) Есть ли экономический эффект, и не съедают ли его cloud/compute затраты?
Собственно, поэтому сам отчет и состоит из четырех частей:)

В следующем посте я расскажу подробнее про полученные авторами результаты по итогам этого опроса

#Engineering #AI #Metrics #Software #DevEx #Productivity #DevOps #Architecture #Culture #Engineering #ML #SystemDesign

[2/2] The State of DevOps Report 2026 от Perforce (Рубрика #DevOps)

Продолжая рассказ про новый отчет "State of DevOps 2026" от Perforce, поделюсь основными результатами, которые представляют менеджерский взгляд на связь зрелости DevOps практик и AI (ребята так подбирали респондентов, чтобы это были в основном менеджеры, что принимают решения по инфраструктурным и платформенным решениям в своих компаниях).

1️⃣ 70% респондентов говорят, что зрелость DevOps заметно повлияла на успех AI
При этом только 38% организаций реально встроили AI глубоко в несколько стадий SDLC, еще 38% используют его часто, но без стандартизации, а 17% остаются на уровне ограниченных пилотов. Разрыв по зрелости огромный: в high-maturity организациях 72% лидеров говорят о deeply embedded AI, в mid - 43%, в low - 18%. В итоге, видно, что для масштабирования AI инициатив важна не покупка AI инструментов, а скорее подготовленная почва в виде зрелых инженерных процессов

2️⃣ AI наследует операционную модель работы, а не чинит ее
В отчете 32% организаций описаны как highly standardized, 35% - mostly standardized, а 34% продолжают жить в частичной или хаотичном деливери. То есть примерно треть рынка по‑прежнему находится в зоне, где результат зависит от конкретной команды. Perforce называет это проблемой вариантивности: пока рабочие процессы, окружения и governance отличаются от команды к команде, AI будет давать столь же неравномерный результат. Отсюда и акцент на control plane: не "еще один инструмент", а шаренные шаблоны, шаренные стандарты, шаренные пайплайны и управляемые окружения.

3️⃣ На рынка уже есть разрыв в уверенности между доверием к AI и реальной интеграцией AI инструментов в процессы
77% респондентов говорят, что доверяют AI outputs, но только 38% действительно глубоко встроили AI в delivery, и лишь 39% имеют полностью автоматизированные данные для аудита. В части про измерения авторы формулируют риск прямо: организации доверяют AI быстрее, чем успевают построить проверяемость, auditability и согласованную измеримость. Это важный антидот против иллюзии, что рост локальной продуктивности в IDE уже означает зрелый AI-native delivery.

4️⃣ Экономический эффект есть, но он не возникает автоматически
74% опрошенных считают, что AI встречается с завышенными ожиданиями. Отдельно Perforce показывает, что ROI сильнее у тех, у кого зрелая система поставки: high-maturity организации на 36% чаще автоматизируют 61%+ деплоев от коммита до прода и на 66% чаще "very effectively" отвечают на продовые инциденты. У low-maturity организаций, наоборот, 78% delivery не стандартизованы а только 19% очень эффективно реагируют на инциденты. Если на пальцах, то без зрелого DevOps AI может ускорить работу, но одновременно увеличить долю переделок, вариативность результатов, время downtime и затраты.

На мой взгляд, отчет Perforce очень хорошо подтверждает базовый тезис из моей статьи "От классического PDLC к AI-native разработке", что AI-native - это не еще один умный инструмент, а перестройка всей системы создания, проверки и поставки изменений. Только я иду еще дальше и размышляю про отдельные роли в этом новом процессе:)

#Engineering #AI #Metrics #Software #DevEx #Productivity #DevOps #Architecture #Culture #Engineering #ML #SystemDesign

State of AI4SDLC на DevOpsConf 2026 (Рубрика #DevOps)

Завтра я открываю конференцию DevOpsConf первым докладом в главном зале и расскажу про наше исследование AI4SDLC, а также что это значит для нас как инженеров, занимающихся разработкой и поставкой софта в продакшен. Я расскажу про то, как выглядят новые процессы разработки, а также про то, как их внедряют в зарубежных бигтехах, а также как действуем мы в Т-Банке.

Вообще мое выступление будет состоять из следующих частей

1️⃣ Как себя чувствует индустрия
Здесь я расскажу про наше исследование AI4SDLC, которое мы проводили в конце прошлого года и которое состояло из мета-исследования и опроса в котором поучаствовала примерно тысяча респондентов со всей России. Мы хотели ответить на вопросы
- В каких задачах разработки AI используется чаще всего, а где остаётся редким?
- Как соотносятся изменения продуктивности и качества (опросы, телеметрия, эксперименты)?
- Как доверие к AI-коду связано с практиками проверки (ревью, тесты, quality gates)?
- Какие элементы процесса превращают индивидуальный эффект в командный?
Сами результаты доступны здесь

2️⃣ От классического PDLC к AI-native-разработке
Здесь я расскажу про сдвиг индустрии от классических процессов к AI-native, как это выглядит и почему происходит. Здесь я поделюсь сигналами от западных бигтех компаний, а также расскажу как мы идем примерно в эту же сторону. На эту тему у меня есть подробная статья на моем сайте tellmeabout.tech.

3️⃣ От AI-native-разработки к AI-native-организации
Здесь я расскажу о том, как вслед за процессами разработки начинает меняться и огрдизайн компаний. Тут опять будут сигналы от западных бигтех компаний + размышления о том, почему так происходит, какие преимущества дает и какие вопросы при этом требуется решить. На эту тему у меня есть подробная статья на моем сайте tellmeabout.tech.

4️⃣ От классического task management к AI-native: как меняется сама единица работы. Тут я расскажу про подходы Atlassian и Linear, которые практикуют разные подходы к управлению задачами и являются лидерами рынка для корпораций и стартапов соответственно. На эту тему у меня есть подробная статья на моем сайте tellmeabout.tech.

5️⃣ Как бигтехи планируют внедрять AI-native разработку у себя в 2026 году. Тут я расскажу про то, как бигтехи подходят к организации этого перехода и постановке целей внутри организации, а также как они планируют измерять результат. На эту тему у меня есть подробная статья на моем сайте tellmeabout.tech.

P.S.
У нас есть отдельный сайт ai4sdlc.tbank.ru про наши AI решения для разработки. И мы их не только используем внутри, но и продаем крупным компаниям.

P.P.S.
Если будете очно на кофне, то можете поймать меня и пообщаться.

#AI #Management #Future #Software #Engineering #Productivity #Agents #Processes

State of AI4SDLC (Рубрика #AI4SDLC)

Появилась запись моего апрельского выступления на DevOps Conf с докладом про "State of AI4SDLC" или что сейчас реально происходит с AI в разработке и почему история уже давно не только про генерацию кода.

Про само исследование я уже рассказывал много раз, поэтому коротко. AI уже стал повседневным инструментом для кодогенерации. По нашим данным, 58% часто или всегда используют AI для генерации кода, 64% видят рост продуктивности. Но дальше картинка сложнее: доверие к AI-коду остается низким, а качество не улучшается автоматически. Главный вывод для меня такой: AI ускоряет не весь SDLC, а отдельные его участки. Если ничего не менять в инженерной системе, bottleneck просто переезжает из написания кода в review, тесты, CI/CD, интеграцию, безопасность, релизы и управление контекстом.

И вот здесь начинается самое интересное: мы движемся от Software Engineering 1.0 к Software Engineering 2.0.

В классическом Software Engineering 1.0 разработка часто выглядит как цепочка стадий и handoff’ов: требования, дизайн, реализация, review, тестирование, релиз. Даже в agile-командах эта логика никуда полностью не исчезла: есть тикет, есть исполнитель, есть diff, есть ревью, есть pipeline. В AI-native варианте часть работы начинают делать ассистенты и агенты. Они могут писать код, предлагать тесты, читать документацию, анализировать баги, готовить PR, помогать с миграциями. Но человек при этом не исчезает. Скорее меняется его позиция.

Разработчик становится не только автором кода, но и навигатором: задает intent, собирает context, формулирует ограничения, декомпозирует work graph, делегирует задачи агентам, проверяет результат и принимает инженерное решение.

Мне все больше нравится описывать это как цепочку: intent -> context -> plan -> tasks -> implementation -> verification.

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

Отсюда следующий важный сдвиг: классический ticket tracker начинает трещать. Тикет как “описание задачи + статус + комментарии” был нормальной единицей координации для людей. Но агенту этого мало. Агенту нужен связанный контекст: цель, ограничения, зависимости, решения из прошлого, права доступа, кодовая база, тесты, логи, критерии приемки, доступные инструменты и границы того, что можно менять. Новая единица работы - не тикет, а context-rich work graph, в котором человек и агент могут безопасно довести задачу до результата.

Это влияет и на оргдизайн. AI-native организация - это не просто “меньше людей”. Скорее это меньше лишних handoff’ов, сильнее роль senior и staff engineers, больше self-service, сильнее platform engineering, больше automation и guardrails. То есть организация должна не только генерировать больше output’а, но и уметь безопасно его переваривать.

Именно поэтому метрики usage почти ничего не говорят. Количество запросов к AI, включенных лицензий или сгенерированных строк кода - это vanity metrics. Смотреть надо на всю цепочку: adoption -> throughput -> quality/risk -> economics. То есть: используют ли инструмент; ускорились ли PR, review, time to merge и cycle time; не выросли ли дефекты, инциденты, security-риск и технический долг; какая экономика у этой новой скорости.

Для разработчиков вывод в том, что надо уметь работать с AI как с инженерным контуром: декомпозировать задачи, писать хорошие acceptance критерии, проверять диффы, сгенерированные AI, понимать архитектурные последствия и держать в голове эксплуатацию.

Для тимлидов, EM и CTO вывод еще жестче: AI-внедрение нельзя вести как закупку инструмента. Это изменение production-системы разработки. Нужны правила, доступ к контексту, безопасные контуры, CI/CD, тесты, ownership, platform engineering, evals, observability и метрики результата.

#AI #AI4SDLC #Engineering #DevOps #Management #Architecture

[1/2] GitLab Act 2: зачем GitLab перестраивает разработку под агентов (Рубрика #AI4SDLC)

Разбирался с GitLab Act 2. Формально это письмо CEO про новый этап компании: фокус, реструктуризацию, AI и DevSecOps. Но важнее другое: GitLab описывает не набор AI-фичей, а смену производственной модели разработки. Если коротко, GitLab больше не хочет быть DevSecOps-платформой, к которой прикрутили AI. Он хочет стать control plane для SDLC, где работают не только люди, но и агенты.

В этом документе видно несколько продуктовых сдвигов

1️⃣ Git и платформа должны выдерживать нагрузку от машин
Если агенты параллельно открывают MR (merge request), запускают пайплайны и возвращаются с правками быстрее любой человеческой команды, инфраструктура разработки становится бутылочным горлышком. Поэтому GitLab говорит не только про AI-помощника, а про API-first сервисы и Git под машинные нагрузки.

2️⃣ Нужна оркестрация всего жизненного цикла
Агент, который написал код, сам по себе не решает enterprise-задачу. Нужно связать issue, код, review, безопасность, CI/CD, развертывание, инциденты, approvals и политики. Иначе получится много быстрых действий, но не управляемая поставка изменений.

3️⃣ Главным активом становится контекст
Кодогенерация быстро становится commodity: хорошие модели будут у всех. Разница будет в том, какой контекст получает агент: задачи, архитектура, история MR, уязвимости, ownership, deploy-история, инциденты, решения прошлых команд. GitLab называет это connected data model across the lifecycle, что является графом инженерного контекста.

4️⃣ Governance должен быть встроен в ядро, а не добавлен сбоку
В агентной разработке скорость без аудита, identity, политик и контролей развертывания быстро превращается в риск. Нужно понимать, кто или что изменило код, по каким правилам, с какими правами и где человек обязан остаться в контуре.

5️⃣ GitLab честно описывает гибридный режим
Не "завтра все автономно", а сосуществование работы людей, агентов-ассистентов и автономных агентов. Это достаточно трезвая картина: большие компании будут двигаться к агентности не одним прыжком, а через слои контроля и доверия.


Организационная часть здесь не менее важна, чем продуктовая. GitLab делает более плоским менеджмент, говорит примерно о 60 автономных R&D-командах, требует ежедневного использования AI и меняет старый ценностный фреймворк CREDIT (Collaboration, Results, Efficiency, Diversity & Inclusion, Iteration, and Transparency) на Speed with Quality, Ownership Mindset и Customer Outcomes. В отчете от 2 июня 2026 компания также описала реструктуризацию: сокращение примерно 14% штата, около 350 человек, выход из 22 стран и уменьшение footprint примерно на 37%. Кажется, что это попытка перестроить саму компанию под новую скорость разработки.

Для меня важно не только то, что GitLab говорит про агентов. Важно, что он связывает их с Git, CI/CD, governance, моделями данных, прайсингом и организационной структурой. Это уже не инструмент продуктивности для разработчика, а новая производственная система для разработки софта. В следующей части посмотрим, насколько GitLab тут одинок. Спойлер: почти не одинок. GitHub, Atlassian, Cursor, JetBrains и OpenAI/Codex идут в ту же сторону, но каждый заходит со своей точки силы.

#AI #AI4SDLC #Engineering #DevSecOps #Management #Architecture #DevOps #PlatformEngineering #Agents #DevEx #Strategy

What if the network was the sandbox? — Remy Guercio, Tailscale (Рубрика #AI4SDLC)

Посмотрел этот доклад Remy Guercio из Tailscale с конфы AI Engineer, 1 июня 2026, где разговор шел про то, как запускать AI агентовв организацию, если им нужны ключи, доступы, MCP tools и иногда production-данные. Сам Remy Guercio занимается стратегическими проектам в Tailscale, который многие знают как "удобный VPN на WireGuard". Но сама компания давно позиционирует себя шире - как платформа для связи с нулевым доверием (zero trust) и основанная на identity. То есть сеть, где устройство, пользователь, workload или CI job подключаются не как безымянный IP, а как сущность с identity, группами, тегами и политиками доступа.

На этом фоне Tailscale теперь заходит в AI governance через Aperture. Это продукт, сейчас в beta, который работает как AI gateway: стоит между вашими агентами/LLM-клиентами и провайдерами моделей вроде OpenAI, Anthropic, Google или самостоятельно развернутых OpenAI-совместимых решений. И главная идея доклада такая: если сеть на базе WireGuard уже умеет надёжно понимать, кто именно делает запрос, зачем класть настоящий API key внутрь sandbox'а с агентом?

Обычная модель выглядит так. Мы запускаем агента в контейнере, VM, GitHub Actions runner или другом sandbox. Вроде бы он изолирован. Но чтобы он был полезным, мы кладем внутрь разрешения: API key к Anthropic/OpenAI, OAuth token, доступ к tool'ам, иногда секреты к внутренним сервисам. Получается странная конструкция: sandbox ограничивает среду исполнения кода, но access control живет внутри этой же среды. Если агент работает долго, утащит ключ, обойдет обертку или начнет ходить напрямую, sandbox уже мало помогает.

Guercio предлагает инверсию: вынести AuthN/AuthZ на сетевой слой. Агенту не дают настоящий ключ. Ему дают только base_url на Aperture и, по сути, пустую заглушку вместо provider API key, чтобы существующий LLM-клиент продолжил работать. Сам Aperture живет в tailnet (Tailscale network), хранит ключи провайдерову себя, видит identity входящего соединения и решает: этому пользователю, устройству, CI job или tagged agent можно идти к такой модели, с таким лимитом и такими правилами. Если доступ запрещен или quota исчерпана, агенту нечего "попробовать в другом месте": ключа у него никогда не было.

Это и есть "network as sandbox" в практическом смысле. Не "контейнеры больше не нужны", конечно. Контейнер или VM все еще нужны для filesystem, process isolation и выполнения кода. Но сетевой слой становится границей разрешений: кто может вызвать модель, какой агент может ходить к какому endpoint'у, сколько он может потратить, какие tool calls видны в аудите.

Что Tailscale предлагает из коробки.

1️⃣ Aperture как продукт: единый AI gateway для организации. Он убирает раздачу API keys по ноутбукам, devcontainer'ам и CI; маршрутизирует запросы к разным провайдерам по model name; логирует запросы, ответы, tool use, bash-команды, MCP-вызовы, токены и стоимость; позволяет задавать budgets, quotas, ограничения по пользователям, группам, агентам и моделям; умеет отправлять события во внешние системы через webhooks для security, audit и compliance.
2️⃣ Aperture CLI как open source tooling: launcher для coding agents, который конфигурирует Claude Code, Codex, Gemini CLI, OpenCode, GitHub Copilot CLI и другие инструменты на работу через Aperture. Важная деталь: это не новый coding agent, а слой настройки и подключения к gateway. Репозиторий открыт, но сам проект помечен как alpha.
3️⃣ tsnet как open source библиотека: Go-библиотека, позволяющая встроить Tailscale прямо в программу. То есть ваш внутренний MCP server, proxy, admin endpoint или собственный agent gateway может сам стать node'ой в tailnet и читать identity вызывающего клиента без отдельной OAuth-интеграции. Это сильная часть истории: Aperture — продукт, но underlying pattern можно повторять внутри своих платформенных сервисов.

Плюс у Tailscale открыт значительный кусок клиентского кода: tailscaled и tailscale CLI живут в GitHub-репозитории. Это не значит, что весь Tailscale как SaaS лежит open source, но для платформенных команд важно другое: примитивы вокруг клиента и tsnet можно изучать, расширять и использовать в своей инфраструктуре.

Почему это важно для production AI.

1) Это убирает проблему утекания ключей. Пока AI в компании живет как набор личных токенов в IDE, CI secrets и локальных конфигов, никакого production governance нет.
2) Это дает нормальную атрибуцию и наблюдаемость без переписывания агента. Для production мало знать, что "Claude что-то сделал". Нужно знать, какой пользователь, какой agent, какой CI workflow, какая модель, какой function call, какой MCP-запрос, какая bash-команда, сколько токенов, какая стоимость и какой результат.
3) Это делает AI rollout управляемым для security, platform и finance. Можно разрешить дешевую модель всем, дорогую — отдельным группам, background agents — с жесткими лимитами, PR review bot — только в конкретном repo scope, а подозрительные tool calls отправлять webhook'ом в security-систему.
4) Это показывает, куда движется инфраструктура агентов. Production AI — это не только evals, prompts и RAG. Это еще и identity, policy, audit, cost control, routing, secrets management и observability.

Главный вывод для меня: sandbox для агента — это не только место, где он запускается. Это еще и место, где живут его разрешения. Если разрешения лежат внутри sandbox'а, агент потенциально владеет собственными ключами. Если разрешения вынесены в identity-aware network и gateway, агент становится гораздо менее опасным: он может действовать, но не может унести с собой право действовать.

#AI #AI4SDLC #Security #PlatformEngineering #DevOps #Architecture

SDLC с AI взгляд через метрики - Анна Громова @ AI Dev Conf (Рубрика #AI4SDLC)

Посмотрел майское выступление Анны Громовой из Т-Банка с конференции AI Dev Conf. Мы с Аней часто обсуждаем метрики эффективности AI по работе, поэтому мне особенно полезно, что появилась запись, на которую теперь можно давать ссылку: это актуальный и глубокий разбор того, как мы подходим к этой теме у себя в компании.

Главная мысль там очень практичная: AI в разработке нельзя нормально оценить, если вы не понимаете сам процесс поставки кода. Количество лицензий, MAU, запросов к ассистенту или сгенерированных строк может быть полезным сигналом adoption, но не отвечает на главный вопрос: стал ли SDLC быстрее, надежнее и дешевле для реального production-результата.

Аня начинает с фреймворков, которые многие знают по отдельности, но редко собирают вместе
- DORA - это метрики конвейера: lead time for changes, deployment frequency, recovery time, change failure rate; в докладе рядом с ними обсуждается и unplanned work. То есть как быстро и насколько стабильно команда довозит изменения до production.
- SPACE и DevEx добавляют человеческую сторону: удовлетворенность, коммуникации, flow, cognitive load, feedback loops. Потому что разработка - это не только pipeline, но и люди внутри него: ждут review, переключают контексты, ходят на встречи, разбираются с новым проектом и ищут доступы.
Кстати, я раньше уже подробно рассказывал про все эти подходы DORA, SPACE, DevEx.

Мне нравится, что в выступлении Аня не остановилась на теории, а показала реальные метрики: onboarding time, время до первого MR, pipeline time, testing time, review time, rework, размер MR, доля падающих pipeline, incident recovery, опросы разработчиков. То есть не у нас нет единой магической метрики продуктивности, а карта процесса, по которой можно искать узкие места.

Например, если вырос lead time, причина может быть не в том, что разработчики стали медленнее. Может оказаться, что у людей слишком долго оформляются доступы, документация плохо помогает при onboarding, новые end-to-end тесты замедлили pipeline или MR стали слишком большими и зависают на review.

И вот здесь AI становится интересным не как “ускоритель кодинга”, а как вмешательство в конкретные участки SDLC.

AI review может сократить ожидание первой реакции и часть рутинных итераций по стилю, опечаткам и простым багам. AI в дебаге проблем может быстрее сводить логи, код и симптомы к гипотезе о ключевой причине. Генерация юнит тестов закрывает скучную, но важную работу, до которой часто не доходят руки, и через это влияет на качество pipeline и change failure rate.

Но важная оговорка: если ускорить только написание кода, бутылочное горлышко просто переедет дальше. Сначала senior не успевает проверять сгенерированный код. Потом упираемся в флакающие тесты и CI/CD. Потом в тестовые окружения, релизный процесс или платформенные лимиты. AI не чинит слабую инженерную систему сам по себе, он часто просто ярче подсвечивает ее ограничения.

По словам Анны, в Т-Банке у AI-амбассадоров увидели снижение median merge time на 12% и lead time на 30%. Это не универсальный бенч и не обещание “просто добавьте воды AI и получите минус 30%”: в докладе отдельно проговаривается, что за скобками остаются особенности репозиториев, связность и сложность кода. Но как пример правильного разговора про эффект AI это ценно: не “люди стали чаще нажимать кнопку”, а “что произошло с delivery-процессом”.

Из доклада ясно, что для осмысленного внедрения AI нужен baseline до старта, регулярный сбор метрик, связь количественных данных с опытом разработчиков и понимание, какую часть процесса мы действительно хотим улучшить. И еще важнее - не влюбляться в одну метрику. Adoption нужен, но сам по себе он ничего не доказывает. Throughput нужен, но без quality/risk можно просто быстрее производить проблемы. Экономика нужна, но без инженерного контекста легко начать оптимизировать стоимость токенов вместо стоимости результата.

Практически это означает: прежде чем спорить, какой AI-инструмент лучше, стоит честно описать свой SDLC. Где у вас теряется время? Где ломается feedback loop? Где review превращается в очередь? Где CI/CD съедает выигрыш от генерации кода? Где разработчики чувствуют cognitive load, а граф метрик показывает то же самое? Тогда разговор про AI становится взрослым. Не “магия ускорила разработку”, а “мы изменили конкретный участок инженерной системы, увидели такой эффект, проверили риски и поняли, где следующий bottleneck”.

#AI #AI4SDLC #Engineering #DevOps #Management #Metrics #Software #Processes

AIDev: Studying AI Coding Agents on GitHub (Рубрика #AI4SDLC)

Прочитал короткую статью от 9 февраля 2026 года о том, как изучать coding agents по реальным PR, а не по демкам. В ней представлен публичный датасет, по которому agentic software engineering можно изучать не по демкам, а по следам реальных pull request'ов. Авторы - Hao Li, Haoxiang Zhang и Ahmed E. Hassan из Queen's University. Это хороший сигнал доверия: группа Hassan давно работает в empirical software engineering и mining software repositories. Paper подана на arXiv 9 февраля 2026 года и связана с MSR 2026 Mining Challenge; данные выложены на Hugging Face и Zenodo, код и ноутбуки - на GitHub.

Набор данных AIDev агрегирует 932 791 pull request, которые авторы относят к Agentic-PR: PR, созданным coding agents. В выборке пять инструментов: OpenAI Codex, Devin, GitHub Copilot, Cursor и Claude Code. Эти PR распределены по 116 211 репозиториям и связаны с 72 189 разработчиками; cutoff - 1 августа 2025 года. Для глубокого анализа есть поднабор: 33 596 PR из 2 807 репозиториев с более чем 100 звездами. Там уже есть review comments, review verdicts, commit-level diffs, связанные issues, timeline событий и автоматическая классификация типа задачи по Conventional Commits.

Методологически это dataset paper с главным результатом в виде инфраструктуры для интересных вопросов вида:
- Кто использует агентов (джуны, мидлы, сеньоры)
- Какие PR проходят review и merge
- Совпадает ли описание PR с diff
- Lобавляют ли агенты тесты
- Какие security/quality-паттерны всплывают в agent-authored code

Для меня здесь самый интересный сдвиг в единице измерения. В AI4SDLC долго мерили либо completion в IDE, либо synthetic benchmark вроде «реши issue». AIDev предлагает смотреть на весь lifecycle: issue -» PR -» commits -» review -» comments -» CI/merge/close -» дальнейшая судьба изменения. Это гораздо ближе к реальной инженерной системе. Практическое применение тут довольно прямое. Если компания внедряет кодинговых агентов, то ей стоит строить похожую внутреннюю телеметрию. Не «сколько строк сгенерировано» и не «сколько лицензий активировано», а что происходит с agent-authored PR: размер diff, доля тестов, время до review, число замечаний, merge rate, rollback/hotfix, security findings, соответствие conventions и CI.

Отдельно отмечу, что у исследования есть несколько оговорок:
- Датасет построен по публичному GitHub, поэтому enterprise-разработка и закрытые репозитории почти наверняка выглядят иначе
- Качество выводов зависит от того, насколько надежно определены agent-authored PR для каждого инструмента; в короткой версии paper этот слой описан недостаточно подробно (надо будет копнуть вглубь)
- Поднабор PR из репозиториев с 100+ звездочек смещает картину в сторону заметных open-source проектов.

P.S.
Дальше расскажу про несколько интересных статей, что опираются на инсайты, что были добыты из этого датасета.

#AI #AI4SDLC #Engineering #Research #Agents #Software #DevOps #Processes

State of AI4SDLC на HighLoad++: материалы к докладу (Рубрика #AI4SDLC)

Сегодня выступил на Saint HighLoad++ 2026 с докладом “State of AI4SDLC: как AI меняет процессы разработки в крупных компаниях”. Главная мысль у меня была про то, что AI4SDLC сейчас это про перестройку инженерной системы: платформу, процессы, метрики, безопасность, экономику и саму роль инженера.

1️⃣ В первой части я показывал, что внедрение AI уже случилось, но доверие и командный эффект за ним не успевают. Кодинг ускоряется быстрее, чем поставка изменений (delivery), поэтому старые узкие места просто становятся заметнее: постановка задач, ревью, тесты, CI/CD, безопасность, релизы и работа с контекстом.
2️⃣ Во второй части разбирал, как это выглядит на масштабе крупного финтеха на 10 000+ инженеров. Тут уже не работает логика “разрешим всем хороший AI-редактор”. Нужна платформа, рассчитанная на агентов (agent-first): модельный шлюз, инструментальный MCP-шлюз, реестр возможностей, уровни доверия read -> recommend -> act, проверки качества (evals), телеметрия и модель угроз.
3️⃣ Дальше я показывал, какие блоки уже появляются в реальной инженерной среде: единый доступ к моделям, управляемый доступ агентов к внутренним инструментам, внутренний ассистент с контекстом компании, агентный режим (agent mode) на платформе разработки и доменные агенты по всему SDLC: тестирование, ревью, дизайн, безопасность, эксплуатация, миграции, data/DS и инфраструктура.
4️⃣ Отдельный был был про измерения. Считать долю AI-кода почти бесполезно: эту метрику легко раздуть, и она плохо отвечает на вопрос, стала ли инженерная система сильнее. Смотреть нужно на цепочку внедрение -> throughput -> качество/риск -> экономика: DORA, SPACE, DevEx, переделки (rework), время ревью, неудачные прогоны pipeline, время восстановления (recovery time), стоимость токенов и человеческого времени.

Основной вывод в том, что выигрывает не команда, у которой самый модный инструмент, а команда, которая умеет превращать AI в управляемую производственную систему. С понятным базовым уровнем (baseline), владельцами, контекстом, ограничениями, проверками, наблюдаемостью и честным разговором про стоимость.

Ниже я привожу доп. материалы к этому докладу (мои статьи)
- Слайды HighLoad++
- AI4SDLC Research 2025
- From classic PDLC to AI-native
- IDP is Dead? Нет, умирает монополия GUI
- Agent-first IDP playbook
- Tg пост про spec-driven development
- Tg пост с разбором доклада Анны Громовой про метрики AI4SDLC

Подробнее про измерения (DORA / SPACE / DevEx):
- DORA ROI: как посчитать эффект AI-assisted разработки без магии
- DORA 2025 - State of AI-assisted Software Development
- DORA AI Capabilities Model
- Как незаметно DORA метрик стало не четыре, а пять
- The SPACE of Developer Productivity
- DevEx: What Actually Drives Productivity

#AI #AI4SDLC #Engineering #PlatformEngineering #DevOps #Management #Conference

Как я с агентами запил сегодня себе прямые эфиры на статический сайт без обычного бэкенда (Рубрика #Architecture)

На этой неделе у меня четыре разговора с экспертами в прямом эфире: два уже прошли, два ещё впереди. Формат общения в реальном времени перестал быть для меня разовым экспериментом, и в какой-то момент стало странно, что мой сайт polomodov.tech об этом ничего не знает. Я хотел простое поведение: если в ближайшие семь дней запланирован эфир, сайт сам показывает анонс. Когда трансляция начинается, блок переключается в состояние live. Если эфира нет, ничего не нужно править руками, пересобирать или выкладывать специально ради одной плашки.

Здесь было интересное ограничение. Сайт статический, собран на GitHub Pages и работает на собственном домене. Обычного бэкенда у него нет, и заводить отдельный сервис с сервером и базой данных ради статуса трансляции мне не хотелось. Но совсем без серверной части не обойтись: YouTube API требует OAuth, а значит, где-то должны безопасно жить client secret и refresh token.

В итоге, я сегодня утром пообщался с Codex и мы спроектировали такую схему
- Добавили не полноценный бэкенд, а один узкий динамический слой - Cloudflare Worker.
- Раз в две минуты Worker через OAuth запрашивает у YouTube списки active и upcoming трансляций;
- Отбрасывает непубличные эфиры и эфиры другого канала, затем выбирает текущий либо ближайший запланированный;
- Сохраняет в Workers KV нормализованный снимок из трёх состояний - offline, upcoming, live - и отдельно кэширует access token;
- Наружу отдаёт только публичный read-only endpoint /status, без OAuth-данных и лишних деталей YouTube API;
- Браузер опрашивает этот endpoint раз в минуту, но только пока вкладка видима.

Отдельно предусмотрено не только как показать эфир, но и как безопасно перестать его показывать. Клиент проверяет версию схемы и все поля ответа. Если снимок старше десяти минут, он считается устаревшим и интерфейс возвращается в offline. Так же скрывается анонс, если трансляция запланирована дальше чем на семь дней. Ошибка YouTube или Worker не превращается в вечную плашку «мы в эфире».

Сам плеер тоже не загружается заранее. Для активной трансляции iframe появляется только после клика. Если я впаду в маразм и запрещу встраивание Youtube-фрейма, то сайт покажет превью и ссылку на страницу YouTube. А в навигации индикатор появляется только для состояния live. Операционную часть я тоже не оставил «на потом»: изменения Worker выкладываются отдельным сценарием GitHub Actions, а ещё один сценарий раз в час проверяет схему /status и свежесть данных. При этом посещения сайта не увеличивают число запросов к YouTube - к API обращается только Worker по расписанию.

Круто, что все это от начала и до релиза заняло меньше дня:
- Сегодня утром с агентом мы договорились об архитектуре
- Основной PR открылся в 12:46
- В 15:48 ветка синхронизировалась с main (я поревьювил и принял измения)
- Дальше я настроил все токены и доступы по инструкции агента между Google Cloud Console, Cloudflare, Github
- А в 17:09 изменения были смержены и дальше раскатаны
- К 18:00 на сайте уже отображался завтрашний стрим с Женей Сергеевым про whitepaper Anthropic

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

#Architecture #Engineering #Web #Cloudflare #DevOps #YouTube

Граф зависимостей как фильтр перед хаос инженерией (Рубрика #SRE)

Прочитал пятистраничную работу Анатолия Красновского "Model Discovery and Graph Simulation: A Lightweight Gateway to Chaos Engineering". Главная идея простая: перед дорогими экспериментами со сбоями можно автоматически собрать из распределенных трасс граф зависимостей, добавить число реплик и дешево прогнать по нему Monte Carlo.

Практическая проблема таких моделей - ручное описание архитектуры, которое быстро устаревает. Здесь граф извлекается из Jaeger; в перспективе источниками могут быть телеметрия service mesh, манифесты Kubernetes/Terraform, API-контракты и SLO-as-Code. Получается не еще одна диаграмма, а исполняемая модель доступности, которую можно обновлять в CI/CD.

Проверяли подход на DeathStarBench Social Network: два режима развертывания, пять долей отказавших экземпляров, сравнение симуляции с реальным внедрением сбоев (fault injection). Общая корреляция между моделью и живым экспериментом составила около 0,992. При репликации и доле отказов 0,3 оценки практически совпали: 0,3054 против 0,3054. Но без реплик отклонение было систематическим: от -24,4% при 0,1 до +20,7% при 0,5.

Отдельно надо отметить, что модель видит только обязательные синхронные вызовы и независимые fail-stop отказы. Она не учитывает частичные и серые отказы (gray failures), коррелированные сбои, очереди, повторные попытки, сброс нагрузки и асинхронные потоки. А опытные архитекторы знают, что реальный радиус поражения (blast radius) часто определяется не числом сервисов или кластеров, а общими коррелированными слоями - образом ОС, CNI, системой доставки или цепочкой поставки.

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

Работа вошла в ICSE-NIER 2026 и получила отметку Distinguished Paper Award (кстати код к статье опубликован). Но пока это проверка на одном примере (proof by instance) и одном бенчмарке. Практический первый шаг для платформенной команды: связать трассы, граф зависимостей, SLO и число реплик в проверяемый артефакт - а уже из него формировать короткий список chaos-сценариев с наибольшим риском.

P.S.
Возможно, запишем с автором статьи ее разбор и обсуждение инежнерного продукта, что сделал автор на базе этой идеи. Если вам нравится эта идея, то поставьте 👌

#Software #Engineering #Architecture #DevOps #PlatformEngineering #RnD

ingress-nginx: как маленький API оброс собственным языком (Рубрика #PlatformEngineering)

Разбирался с закрытием ingress-nginx. Эту историю можно пересказать как драму open source: компонент примерно для половины cloud-native окружений, по внутренним данным Datadog, годами поддерживали один-два человека в свободное время. Но мне интереснее механизм, сделавший его несопровождаемым.

Ingress API намеренно оставили маленьким: host, path, backend, TLS. В production быстро понадобились таймауты, повторные попытки, canary, внешняя авторизация, заголовки и WAF. ingress-nginx добавлял всё это аннотациями - к июлю 2026 года документация насчитывала около 130 уникальных ключей. Snippet-аннотации позволяли вставлять произвольные фрагменты NGINX-конфига.

Так обходной путь превратился в неформальный DSL. API выглядел простым, но реальный контракт жил в строках metadata, зависел от контроллера, плохо валидировался и расширял поверхность атаки. В 2025 году Wiz раскрыл IngressNightmare - цепочку уязвимостей с неаутентифицированным RCE.

В марте 2026 года поддержка ingress-nginx закончилась: больше нет релизов, исправлений ошибок и security-патчей. Существующие установки продолжают работать - просто без будущих исправлений. Сам Ingress API не закрыт и не deprecated: он заморожен, а развитие ушло в Gateway API.

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

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

#PlatformEngineering #Kubernetes #Architecture #DevOps #Security

Research Insights Made Simple #25: Моделируем надёжность по графу зависимостей (Рубрика #SRE)

Можно ли понять, где распределённая система сломается, ещё до дорогого эксперимента со сбоями? В этом выпуске сегодня в 17:00 мы вместе с Анатолием Красновским разберём его работу "Model Discovery and Graph Simulation: A Lightweight Gateway to Chaos Engineering", отмеченную Distinguished Paper Award на ICSE-NIER 2026 (кстати, я разбирал ее раньше).

Анатолий - инженер, который пошёл в науку, чтобы спасти IT от шаманства. За 10+ лет в разработке он устал от того, что сложные системы строятся на интуиции и слепом копировании «лучших практик». Сейчас он пишет кандидатскую по матмоделированию в Иннополисе, чтобы научиться доказывать их устойчивость математически, а не надеяться на эмпирический авось, а также ведет свой канал о том, как на самом деле работают сложные системы: @mb3rlab

Идея подхода Анатолия из этой статьи проста: автоматически извлечь из распределённых трасс граф обязательных вызовов, добавить число реплик и с помощью Monte Carlo оценить доступность системы при отказах. Получается не замена chaos engineering, а дешёвый фильтр перед ним: модель помогает найти подозрительные цепочки, единичные точки отказа и сценарии, которые стоит проверить на живой системе в первую очередь.

С автором обсудим:

- Почему для первого приближения может хватить топологии и числа реплик;
- Как автоматически обнаруживать модель из Jaeger и поддерживать её актуальной вместе с системой;
- Что означает высокая корреляция с живым fault injection и почему один benchmark ещё не доказывает универсальность метода;
- Где заканчиваются возможности модели: gray failures, коррелированные сбои, очереди, retries и асинхронные потоки;
- Как встроить такой анализ в CI/CD, связать его с SLO и превратить в приоритизацию chaos-экспериментов;
- Где проходит граница между полезным упрощением и опасной ложной уверенностью.

Для меня главный вопрос выпуска практический: можем ли мы превратить наблюдаемость из способа расследовать уже случившийся инцидент в исполняемую модель надёжности - и использовать её, чтобы ломать систему реже, но точнее?

#Software #Engineering #Architecture #DevOps #Reliability #Research

Research Insights Made Simple #29 про «The AI-Native SDLC playbook» с Антоном Костериным (Рубрика #AI4SDLC)

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

27 августа в 14:00 в прямом эфире Research Insights Made Simple вместе с Антоном Костериным, principal engineer RnD-центра Т-Банка, разберём свежий материал Anthropic — The AI-Native SDLC playbook. С Антоном мы уже говорили об architecture governance, RFC/ADR и архитектурных ревью. Теперь вопрос шире: как перестроить под агентов не только написание кода, но весь SDLC.

Тезис playbook: после ускорения Build bottleneck смещается в Plan, Test/Review и Deploy. Anthropic предлагает замкнуть шесть стадий, от Plan до Maintain, в цикл. intent.md, spec.md, plan.md, diff с тестами, результаты review и записи об инцидентах образуют цепочку версионируемых артефактов и одновременно audit trail. Человек остаётся ответственным, но подключается в точках, где действительно требуется суждение.

Обсудим:

- Действительно ли код перестал быть узким местом и где теперь скапливается очередь;
- Зачем нужны markdown-артефакты, если уже есть Jira, wiki и архитектурные процессы;
- Как превратить знания компании в CLAUDE.md, skills и проверяемые политики, не законсервировав ошибки;
- Как связать continuous evals, hooks, агентное и человеческое review с production monitoring;
- С какого участка SDLC начинать и какими метриками доказывать эффект.

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

Подключайтесь 27 августа в 14:00 и приносите свои кейсы и вопросы. Особенно если coding agents уже ускорились, а delivery почему-то нет.

#AI4SDLC #AI #Agents #Engineering #Architecture #DevOps #Research

Research Insights Made Simple #29 про «The AI-Native SDLC playbook» с Антоном Костериным (Рубрика #AI4SDLC)

Через 5 минут стартанет прямой эфир Research Insights Made Simple, где мы вместе с Антоном Костериным, principal engineer RnD-центра Т-Банка, разберём свежий материал Anthropic — The AI-Native SDLC playbook. С Антоном мы уже говорили об architecture governance, RFC/ADR и архитектурных ревью. Теперь вопрос шире: как перестроить под агентов не только написание кода, но весь SDLC.

#AI4SDLC #AI #Agents #Engineering #Architecture #DevOps #Research

Материалы выпуска с Антоном Костериным: как замкнуть AI-native SDLC? (Рубрика #AI4SDLC)

Готовы материалы 29-го выпуска Research Insights Made Simple, который прошёл 27 августа. Вместе с Антоном Костериным — principal engineer RnD-центра Т-Банка — разбирали "The AI-Native SDLC Playbook" от Anthropic: что должно измениться вокруг кодинга, чтобы скорость агентов превратилась в скорость поставки.

Обсудили:
- Почему playbook ценен не принципиально новыми практиками, а тем, что собирает их в последовательность с примерами и шаблонами, — и почему это руководство поставщика нужно проверять в собственном контексте;
- Как intent.md, spec.md и проверенный человеком plan.md превращают замысел в версионируемую цепочку артефактов и одновременно audit trail;
- Зачем команде CLAUDE.md, skills, команды, hooks и специализированные агенты — и каких начальных вложений и организационного доверия требует такой контур;
- Почему после ускорения Build ограничение переезжает в постановку, review, тесты или выпуск, а детерминированные проверки в CI/CD и continuous evals должны независимо ловить нарушения и повторные ошибки;
- Где проходит граница автоматизации: hooks закрепляют проверяемые запреты, но review, инженерное суждение и принятие остаточного риска остаются за человеком;
- Как Maintain замыкает цикл: инцидент может породить новый intent, а runbook — превратиться в ограниченный политиками агентный self-healing; экономику при этом полезнее считать по принятым задачам и предотвращённым переделкам, а не только по токенам.

Все материалы выпуска:

- Страница выпуска и слайды
- Видео: YouTube, VK Видео
- Аудио: Podster, Яндекс Музыка, Apple Podcasts
- Текст: краткая расшифровка

Спасибо Антону за разговор. Если после просмотра появятся вопросы — пишите в комментариях: соберу их для продолжения темы о том, как переносить AI-native практики в большие инженерные организации.

#AI4SDLC #AI #Agents #Engineering #Architecture #DevOps #Research

Randy Shoup про eBay: инженерия ускорилась, а система — нет (Рубрика #Management)

Супер-крутой доклад — прямо много попаданий в реальность. Пока слушал, то и дело ловил дежавю. И у этой истории есть первый акт: в 2023 году я уже разбирал, как Randy Shoup с командой удвоил engineering productivity в eBay. Новый доклад — неприятный второй акт. Техническая трансформация сработала, а траектория бизнеса и культура руководящего слоя, по оценке Шоупа, почти не изменились.

Шоуп был Chief Architect и VP of Platform Engineering в eBay в 2020–2022 годах. По его данным, инициатива Velocity дала 2× по числу features и bug fixes на единицу времени. Deployment frequency выросла в 10 раз, lead time сократился с 10 до 2 дней, change failure rate и time to recover улучшились втрое. Это цифры из доклада и слайдов, а не независимый аудит. Но масштаб всё равно впечатляет: около 5000 инженеров в компании; Velocity со временем охватила 400 продуктовых команд и 4500 приложений и сервисов.

Секретного фреймворка не было. Команды спрашивали: если завтра придётся выкатываться ежедневно, что именно вам помешает? Ответы становились бэклогом Platform Engineering. Дальше — сокращение build, test и PR validation time, автоматизация deployment и обновлений, общая staging-среда, DORA как outcome-метрики и developer friction как входной сигнал.

Но важнее инструментов была механика взаимодействия. Сильных IC из платформы встраивали в продуктовые команды, руководители синхронизировались ежедневно, команды делились локальными автоматизациями, а Security, Compliance, Accessibility и Localization переставали быть внешними «воротами» и становились участниками улучшения потока. Начали с пилотов, затем расширялись квартальными когортами и повторяли цикл: нашли bottleneck, сняли, посмотрели, кто теперь получил повышение.

А затем Шоуп задаёт неприятный вопрос: если инженерная продуктивность выросла вдвое, почему это не развернуло бизнес? Его ответ состоит из трёх слоёв.

1️⃣ Стратегия и планирование
Годовой план собирался централизованно и надолго. Работа получала деньги, только если была достаточно большой для executive-level инициативы; небольшие изменения выживали как «прицеп» к гигантским программам. Новые знания появлялись, а курс уже нельзя было менять.

2️⃣ Execution
Нормой оставались релизы на десятки команд и годы работы. Вознаграждалось выполнение обещанного списка, а не изменение клиентской или бизнес-метрики. То есть feature factory стала выпускать больше features — ровно как и было заказано.

3️⃣ Культура
Используя типологию Ron Westrum, Шоуп описывает её как pathological: страх ошибок, поиск виноватого, zero-sum борьба руководителей за scope и headcount, Not Invented Here. В такой системе осторожность — не дефект отдельных людей, а рациональная стратегия выживания. Вот здесь дежавю становится особенно сильным. Ускорить CI/CD политически проще, чем изменить бюджетный процесс, права на решения и систему стимулов. Можно дать командам прекрасную дорогу, но если маршрут определён 18 месяцев назад, они просто быстрее приедут не туда.

В ретроспективе Шоуп считает, что поддержки CEO сверху и энтузиазма команд снизу оказалось недостаточно: трансформации нужен ещё middle-out — союз с peer-руководителями, чьи границы и стимулы она неизбежно затрагивает. Его рассказ об увольнении и культуре — личная версия событий, не независимое расследование. Но именно поэтому доклад хорош: автор не продаёт очередной transformation playbook, а честно показывает предел уже успешного.

И да, в 2026 году невозможно не увидеть продолжение про AI. Если агенты ускорят производство кода, но не выбор задач, обратную связь и принятие решений, feature factory просто получит двигатель помощнее. Поэтому до вопроса «насколько мы ускорились?» стоит задать другой: «а инженерная скорость вообще ограничивает результат всей системы?»

#Management #Leadership #Culture #DevOps #PlatformEngineering #Engineering #Metrics

Kubernetes: слишком сложно? Материалы DevOps Deflope №62 (Рубрика #PlatformEngineering)

Сходил в гости к DevOps Deflope — вместе с Александром Качмашевым из «Точка Банк». В выпуске №62 от 13 сентября 2026 года поговорили о том, почему запустить приложение в Kubernetes проще, чем потом со всем этим жить.

Обсудили:
- Сложность Kubernetes. Что происходит, когда за привычным Helm-чартом приходится разбираться с сетями и протекающими абстракциями.
- Внутренние платформы. Какую работу они снимают с разработчиков и кто берёт её на себя. Число подключённых команд ещё не говорит, насколько им удобно.
- AI-агентов в кластере. Читать состояние, советовать и менять инфраструктуру — три разных уровня доверия. Обсудили проверки, ограниченные права и изменения через GitOps.

Материалы выпуска:
🎧 Apple Podcasts , Яндекс Музыка, Spotify
📌 Страница выпуска у меня на сайте и текстовый конспект
📖 Лонгрид моей подготовки: куда переезжает сложность Kubernetes

А у вас какая часть сложности осталась у разработчиков, а какая переехала в платформенную команду?

#PlatformEngineering #Kubernetes #DevOps #AI #Engineering