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

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

DevOps-трансформация вкратце: что меняется, а что остается прежним

DevOps-трансформация эффективна тогда, когда команда, написавшая сервис, сама доставляет его в продакшен и обслуживает через единый автоматизированный CI/CD-пайплайн. Сами по себе инструменты не сократят время выполнения, если релизы по-прежнему простаивают в очереди тикетов или зависят от передачи задач отдельному операционному отделу.

Netguru строит облачную инфраструктуру, CI/CD-пайплайны и платформенные инструменты для продуктовых команд и рекомендует определять базовые метрики DORA перед покупкой любых решений, поскольку именно они показывают, что является узким местом: согласования, время тестирования или риск развертывания. Организациям с обязательными комитетами по изменениям следует сначала пересмотреть процесс согласования.

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

Что меняется в структуре команд и операционной модели

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

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

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

Для разного масштаба организаций подходят три модели. Указанное ниже количество команд является нашим субъективным мнением, а не эталоном:

По нашему мнению, при наличии примерно 15 и более команд лучше всего работает комбинация двух последних моделей: центральная платформенная команда строит дорогу, в то время как небольшая группа SRE консультирует, внедряет практики SLO и временно подключается к сервисам, которые исчерпывают свой бюджет ошибок.

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

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

Дорожная карта DevOps-трансформации: этапы, ответственные и критерии завершения

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

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

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

Каждый этап с указанием ответственного и критерия завершения:

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

Если логи неполные, сделайте ручную выборку релизов за последние 90 дней и считайте базовые показатели приближенными. Организации с числом инженеров примерно до 50 часто могут объединить этапы 4 и 5, так как один платформенный инженер может справиться с обеими задачами.

С чего начать и какие команды идут первыми

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

Три критерия для сужения круга кандидатов:

Реальная проблема с релизами. Картирование потока создания ценности показывает длинную очередь между слиянием кода (merge) и продакшеном, например ручное согласование или еженедельное релизное окно. Пилотный проект существует для того, чтобы убрать это ожидание.
Высокий объем изменений. Команда объединяет код достаточно часто, чтобы в течение квартала прослеживался тренд. Сервис, развертываемый два раза в год, не дает достаточного количества сигналов.
Готовый к сотрудничеству владелец. Один инженерный менеджер соглашается изменить привычки ветвления и ревью. Разработка на основе ветки trunk-based обычно является первым из таких изменений и терпит неудачу, если навязывается команде, которая ее не выбирала.

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

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

Метрики DORA для измерения DevOps-трансформации

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

В отчете State of DevOps за 2023 год время восстановления сервиса было переименовано во время восстановления после неудачного развертывания (failed deployment recovery time), что сузило его до сбоев, вызванных развертыванием. В отчет за 2024 год наряду с процентом неудачных развертываний был добавлен показатель уровня доработок (rework rate) в качестве второй меры стабильности.

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

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

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

Что может помешать прогрессу DevOps-трансформации

DevOps-трансформация буксует, когда инструменты поставляются, но результаты поставки остаются прежними. Стоит в первую очередь проверить пять режимов сбоев, каждый из которых рано проявляется в метриках DORA или данных об использовании платформы. Исправления в основном сводятся к тому, чтобы относиться к платформам как к продукту, с «золотой дорожкой» (golden path), которую команды выбирают, потому что она быстрее их собственного пайплайна.

Каждый режим сбоя с его ранним сигналом и способом устранения:

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

Чтобы перезапустить буксующую программу, сначала соберите базовые показатели (baseline), затем сопоставьте ваши сигналы с таблицей и исправляйте по одной строке за раз. Командам численностью примерно до 50 инженеров обычно можно обойтись без выделенной команды платформы, разделив небольшой набор шаблонов.

Платформенная инженерия: Конечное состояние DevOps-трансформации

Платформенная инженерия — это конечное состояние DevOps-трансформации: команда платформы управляет внутренней платформой разработчика (IDP), которая предоставляет продуктовым командам возможность самостоятельной доставки через «золотую дорожку». В Белой книге CNCF по платформам эта платформа описывается как продукт, клиентами которого являются использующие ее разработчики.

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

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

Измеряйте платформу с помощью метрик внедрения, как это делает продуктовая команда:

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

Если внедрение становится обязательным для выполнения первого показателя, метрика перестает нести какой-либо смысл. Низкое добровольное использование означает, что этот путь медленнее, чем собственные пайплайны команд.

Увязывайте платформу и с результатами доставки: отслеживайте частоту сбоев изменений и время выполнения для команд, которые ее используют, поскольку платформа, выпущенная без продуктовых практик, может ухудшить оба показателя.

Как построить DevOps-культуру без лозунгов

DevOps-культура проистекает из трех механизмов, которые меняют то, кто носит пейджер, как анализируются сбои и за какие показатели отвечают разработчики и операционисты: общие дежурства, бессрочные разборы полетов (blameless postmortems) и общий целевой уровень обслуживания (SLO) с бюджетом ошибок.

Общие дежурства. Разработчики присоединяются к ротации для сервисов, которые они выпускают, начиная со второй линии рядом с инженерами по эксплуатации или надежности (SRE). Предоставьте им инструкции (runbooks) и полномочия изменять пороги оповещений. Оповещения, на которые никто из команды-владельца не может отреагировать, возвращаются этой команде.
Бессрочные разборы полетов (Blameless postmortems). Проводите их для каждого инцидента, нарушающего SLO. Используйте фиксированный формат: хронология, сопутствующие факторы, что было упущено при обнаружении, а также задачи с ответственным лицом и сроком выполнения. В книге по SRE от Google бессрочные разборы полетов преподносятся как предположение, что все участники действовали добросовестно, основываясь на имеющейся у них информации.
Общий SLO и бюджет ошибок. Продукт, разработчики и операция согласуют один SLO для каждого сервиса. Бюджет ошибок — это допустимая ненадежность, поэтому условный ежемесячный целевой показатель в 99,9% оставляет примерно 43 минуты простоя. Политика бюджета ошибок определяет, что происходит, когда бюджет исчерпан: обычно это приостановка выпуска новых функций в пользу работ по надежности.

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

Где должны находиться проверки DevSecOps: Коммит, сборка и развертывание

Проверки DevSecOps должны выполняться в трех точках CI/CD-пайплайна: обнаружение секретов и быстрый SAST на этапе коммита, SCA и генерация SBOM на этапе сборки, а также политика как код (policy as code) при развертывании. Каждая проверка располагается там, где ее время выполнения соответствует ожиданиям разработчика на данном этапе.

Где мы рекомендуем выполнять каждую проверку:

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

Этап сборки — это то место, где артефакты подтверждения дешевле всего произвести. Национальное управление по кибербезопасности США (CISA){{ называют SBOM одним из способов хранения данных о происхождении для каждого релиза, а спецификация SLSA определяет, что должно фиксироваться в отношении происхождения сборки. Политика как код на этапе развертывания с помощью OPA Gatekeeper или Kyverno затем отклоняет несоответствующие манифесты до того, как они попадут в кластер.

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

Как выбрать инструменты в зависимости от этапа пайплайна

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

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

Практический пример делает стоимость наглядной. Предположим, есть 12 сервисов и два кандидата на роль флажков функций (feature flags). Кандидат А имеет собственный каталог пользователей, не имеет провайдера инфраструктуры как кода (IaC) и не поддерживает экспорт аудита. Кандидат Б поддерживает OIDC и имеет провайдер Terraform.

Для варианта А заложите 2 недели на мост SSO, 3 недели на написание скриптов для определений флагов, чтобы они не расходились с репозиторием, и 1 неделю на экспорт аудита: 6 инженер-недель, причем поддерживать мост после этого вам. Для варианта Б заложите 1 неделю. Все это — иллюстративные предположения, а не ориентиры.

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

Бизнес-результаты, факторы затрат и то, что искать в партнере

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

Ежегодный отчет State of DevOps от DORA связывает эти метрики с организационной эффективностью. Для бизнес-обоснования это делает частоту сбоев изменений самой простой для оценки цифрой: каждый неудачный сбой влечет за собой переделку, время на устранение инцидентов и задержку работы над дорожной картой.

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

Мы рекомендуем проверить партнера по трем пунктам:

Базовые показатели в первую очередь: они измеряют ваши текущие метрики DORA и картируют поток создания ценности перед предложением инструментов.
Передача возможностей: ваши инженеры управляют конвейером и платформой к назначенной дате передачи.
Метрики результатов: в контракте отчитываются по частоте сбоев изменений и времени выполнения, а не по количеству установленных инструментов.

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

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

Что такое DevOps-трансформация?

DevOps-трансформация изменяет структуру команды, конвейер поставки, операционную модель и систему измерений так, чтобы одни и тем же команды создавали, выпускали и запускали программное обеспечение. Платформенная инженерия — это ее современная форма, где внутренняя платформа разработчика предоставляет золотые пути самообслуживания. Судите о ней по метрикам DORA, так как само по себе внедрение инструментов ничего не доказывает.

Какова главная цель DevOps-трансформации?

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

Что больше всего мешает прогрессу DevOps-трансформации?

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

Как DevOps ускоряет цифровую трансформацию?

DevOps ускоряет цифровую трансформацию за счет сокращения цикла обратной связи между идеей продукта и ее использованием в производстве. Небольшие и частые релизы через автоматизированный CI/CD-конвейер позволяют командам быстро проверять бизнес-гипотезы. Выгода зависит от архитектуры: тесно связанные системы с общими циклами релизов ограничивают частоту развертываний независимо от качества конвейера.

Кто предлагает консалтинг по DevOps-трансформации?

Профессиональные сервисы облачных провайдеров (AWS, Microsoft, Google Cloud), системные интеграторы и специализированные инженерные компании, такие как Netguru, — все они предлагают консалтинг по DevOps-трансформации. Составляйте шорт-лист на основе того, измеряют ли они сначала базовые метрики DORA и передают ли платформу, которой ваша команда сможет управлять. Избегайте проектов, результатом которых является установка инструментов.

Заменит ли ИИ DevOps?

Нет. ИИ меняет работу в DevOps, но не отменяет необходимость владения конвейером, инженерии надежности и проверок безопасности. В отчете DORA State of DevOps за 2024 год более высокое внедрение ИИ было связано с ростом производительности, но с более низким уровнем стабильности поставок и пропускной способности. Поэтому командам, добавляющим код, созданный ИИ, требуются более надежные автоматизированные тесты и шлюзы, что повышает спрос на навыки работы с платформами.

Каковы 5 главных навыков в DevOps?

Пять главных навыков в DevOps: проектирование CI/CD-конвейеров, инфраструктура как код, наблюдаемость с помощью SLO и бюджетов ошибок, практики DevSecOps, такие как создание SBOM и политики как кода, а также межкомандное сотрудничество. Роли в платформ-инженерии добавляют продуктовое мышление для внутренних платформ разработчиков. Какой навык нанимать в первую очередь, зависит от узкого места, выявленного вашими базовыми показателями: медленные ручные релизы указывают на навыки CI/CD и инфраструктуры как кода, а частые инциденты — на навыки наблюдаемости и SRE.

Начните с базовых показателей производительности поставки

DevOps-трансформация начинается с базовых значений метрик DORA: частоты развертываний, времени выполнения изменений, частоты сбоев изменений и времени восстановления после сбоя развертывания, а также показателя надежности, такого как достижение SLO.

Извлеките их из данных, которые у вас уже есть: истории Git, CI/CD-конвейера и трекера инцидентов. Мы предлагаем взять последние 90 дней для двух или трех пилотных сервисов-кандидатов с картой потока создания ценности для каждого из них, чтобы показать, где ожидаются изменения, и записать показатели по каждому сервису, так как среднее значение по всей организации скрывает медленные участки.

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