Вы сделали заказ в интернет-магазине, а он внезапно завис в самый разгар скидок. За кулисами этого сервиса работают сотни строк кода и ещё больше человеческой поддержки. DevOps — это способ организовать эту работу так, чтобы новые функции доходили до вас быстрее и без сбоев. Он объединяет разработчиков, тестировщиков и операторов, автоматизируя рутинные шаги и следя за сервисом в режиме реального времени. Звучит хорошо, но на практике автоматизация закрывает далеко не всё.
В статье рассмотрим, что за зверь такой DevOps. Когда работает, а когда спотыкается и где автоматизация работает, а где нужна платформа и процессы. Даже если вы не айтишник — переходите под кат.
Что такое DevOps
DevOps (от англ. «Development Operations») — это не просто набор инструментов, а методология и операционная дисциплина. Она переводит ответственность за качество и доставку из отдельных силосов в общий поток. Команда не делит работу на «я сделал код — дальше пусть ops сам разбирается». Команда продукта и платформа совместно несут ответственность за сервис в продакшене. Главная цель — уменьшить lead time for changes и одновременно удерживать или улучшать стабильность и безопасность. Специалиста по этой методологии называют DevOps-инженером, или девопсом.
Цели DevOps понятны: чтобы идея или новый код быстрее попадали в продакшен при низком уровне ошибок, а ещё максимально быстро можно было восстановить систему после инцидентов (mean time to recovery, MTTR). Чтобы всё это как-то оценить, используют DORA-метрики.
Показатели DORA включают:
Частоту развёртываний (deployment frequency), то есть насколько часто команда выпускает новые изменения;
Время цикла (Cycle Time) — сколько времени проходит от коммита до доставки кода в прод;
Процент отказов изменений (change failure rate) — доля изменений, которые приводят к сбою или исправлению;
Среднее время восстановления после сбоев — MTTR.
Эти метрики — своеобразные якоря для принятия решений. Например, если команда увеличивает частоту релизов, но MTTR не уменьшается и пользователи не получают лучшего опыта, это сигнал. Значит проблема в контроле качества и мониторинге, а не в скорости выпуска.
Практики DevOps
Сами по себе CI, IaC или мониторинг мало что меняют. Но вместе они образуют замкнутый цикл. Ниже — практики, которые используются в проектах.
CI/CD даёт быструю обратную связь команде, ускоряя исправления и снижая риски выпуска и делает сборку и базовые проверки повторяемыми. Infrastructure as Code (IaC) с версионированием — это не просто воспроизводимость окружений, но и возможность масштабировать их, управлять изменениями декларативно и надёжно. GitOps переносит изменения инфраструктуры в pull-request-процесс и даёт трассировку изменений.
Отдельная история — работа с данными. Schema change — это изменение модели данных, а не просто деплой кода. Для автоматизации миграций, мониторинга и т.п. нужны разработчики или администраторы БД. Ведь неправильный откат, часто невозможен без потери данных. Инструменты для online schema change сокращают простой, но без надёжного бэкапа и контроля они могут привести к серьёзным проблемам.
Тестирование должно покрывать уровни: unit, integration, contract, e2e. А вот, Contract testing (Pact) и Testcontainers позволяют прогонять интеграции в CI без ложного ощущения безопасности. Наличие dedicated test environments или infra-as-a-product, где команды получают стабильную песочницу с реалистичными данными, резко снижает риск «зелёного» билда, падающего в проде.
Observability — связь релизов и их последствий. Метрики, распределённые трассы и коррелированные логи на базе OpenTelemetry и Prometheus формируют единое окно видимости процессов. Настроенные SLO и error budget позволяют управлять автоматическими откатами и продвижением релизов на основе объективных данных, без участия человека.
Безопасность и качество поставки — это тоже непрерывный процесс со встроенными проверками SCA, сканированием IaC-конфигураций, управлением секретами и подписью артефактов. Что помогает сохранять скорость релизов и при этом соответствовать требованиям compliance.
Так что в итоге? В итоге всё происходит так: когда разработчик заканчивает работу над кодом, он отправляет его в систему, которая автоматически собирает программу и запускает тесты, чтобы проверить, что всё работает правильно. После этого подготовленный образ программы подписывается для безопасности, а система GitOps создаёт запрос на запуск новой версии. Сам процесс обновления проходит постепенно — сначала новая версия доступна небольшой части пользователей, а система внимательно следит за состоянием и производительностью.
Если всё хорошо, новая версия появляется у всех, но если что-то идёт не так и появляются ошибки, система делает откат к предыдущей стабильной версии. После успешного обновления делаются проверки и обновляются инструкции. Важно, чтобы в таком процессе были чёткие зоны ответственности, возможность повторного безопасного выполнения действий и хорошая система мониторинга — без этого даже самая автоматизированная система не будет работать эффективно и безопасно.
Где мы сейчас
Судите сами: по данным АО «Флант» доля компаний, которые вовсе не пользуются CI/CD, сократилась с 17,2% до 13,3%. Можно подумать, что это плановое, логичное развитие. Но примерно 30–40% релизов в организациях по-прежнему требуют ручек кожаных человеческого вмешательства, особенно там, где дело касается stateful-сервисов и миграций баз данных. Эта статистика объясняет, почему у многих команд «быстро собрать образ», не равно «безопасно доставить изменение в продакшен».
DORA-исследования показывают, что успешные команды рекомендуют частоту релизов более одного раза в день и низкий Change Failure Rate (менее 15%). Но многие команды сталкиваются с ростом ручных экстренных патчей и инцидент-расследований.
Речь не только про инструменты. По данным McKinsey на 2023 год, технически CI/CD экономит 20% операционных расходов. У компаний, внедривших непрерывную доставку, меньше простоев, быстрее фидбек. Достигается это распределением ответственности, внедрением платформенной инженерии. Когда CI/CD превращается в привычный рабочий поток, разработчики тратят меньше времени на рутину, меньше выгорают и успевают создавать фичи.
Инструменты для CI/CD
Среди CI/CD-систем лидер по-прежнему GitLab CI. С прошлого года он снова подрос, теперь его доля составляет ~56,7%. Чуть-чуть увеличился и процент пользователей GitHub Actions, несмотря на риски блокировки.
В целом инструменты для CI/CD используют 86,7% респондентов. Практики непрерывной поставки распространяются медленно, но верно. В 2021 и 2023 годах их использовали чуть больше 82% участников исследования.
Снижается популярность к инструментам GitOps. Использование ArgoCD упало до 14%, а FluxCD — до 2,8%. Возможно, это связано с тем, что среди опрошенных появилась большая доля специалистов из компаний, которые пока не интегрировали GitOps в свои процессы. Таким образом, внимание концентрируется вокруг нескольких ключевых инструментов, задающих темп развития автоматизации CI/CD.
Узкие места DevOps
Организации, внедряющие DevOps, в среднем автоматизировали чуть более половины (56%) всего сквозного жизненного цикла. И это, вероятно, одна из основных причин возникновения узких мест. Проблема в том, что многие организации оказались между молотом и наковальней.
Stateful-сервисы и миграции данных. Это согласованный деплой приложений, где изменения касаются не только кода, но и схем баз данных. Например, миграция схемы — это отдельный процесс, который часто невозможно откатить без потерь данных и нарушения целостности. Используйте паттерны blue/green и canary deployment, feature flags, чтобы минимизировать влияние на пользователей. А также инструменты онлайн-миграции. Они обеспечивают минимальные простои и позволяют плавно переключаться между версиями базы данных.
Наследие и смешанная инфраструктура. Легаси-системы и устройства с проприетарным ПО, как-то не вписываются в современные DevOps-процессы. Отсутствуют стандартные API и ограничения на модификации. Поэтому, применяют подходы типа strangler pattern (постепенное замещение устаревших компонентов новыми), ещё используют фасады (facade) для создания единых интерфейсов взаимодействия с legacy-моделями. Ну и поэтапный рефакторинг с минимизацией рисков простоев. Примеры — обновление бронирования в Marriott без остановки системы или перенос данных с мейнфреймов в микросервисную архитектуру в крупных банках.
Мало хорошего тестирования. Многие CI/CD процессы не имеют достаточного покрытия интеграционными и контрактными тестами. ОТ этого риск на релизе. Баги могут всплыть в продакшене, если нет выделенного стабильного тестового окружения. Решают это через IaaS — создание устойчивых тестовых платформ. Команды воспроизводят реальную работу сервисов, сокращая вероятность неудачных деплоев.
Фрагментация и нестабильные скрипты. Во многих компаниях инфраструктура управляется сотнями ad-hoc скриптов. Это всё нужно поддерживать, масштабировать и повторно использовать. Решением становится переход к идемпотентным модулям и библиотекам, использование модульного Terraform, Kustomize, Helm charts и развитие PaaS.
Пробелы в наблюдаемости (observability gap). Для поддержки необходимы метрики, распределённые трассы (distributed tracing) и корреляция логов. С помощью Prometheus, OpenTelemetry и систем корреляции выявляют аномалии. А потом уже можно принять решение, откатывать или нет.
Роль ИИ в DevOps
Рассмотрим типичный процесс развертывания веб-приложения. Разработчики пишут код и вносят изменения в контроль версий. Проводятся авто-тесты для проверки функциональности. Если тесты проходят, код развёртывается в промежуточных средах для дальнейшего тестирования. После проверки код перемещается на производственные серверы, где реальные пользователи получают к нему доступ. Каждый шаг включает в себя несколько систем, зависимостей и потенциальных точек отказа.
Традиционный DevOps опирается на заранее определённые правила и скрипты для управления этой сложностью. Если загрузка процессора превышает 80% — масштабируйте серверы. Если уровень ошибок увеличивается — запускайте оповещения. Если определённые тесты не проходят — блокируйте развёртывание. Эти основанные на правилах подходы хорошо работают для предсказуемых сценариев, но не подходят для современных, динамичных приложений.
Современные приложения состоят из десятков или сотен микросервисов, работающих на нескольких облаках. Каждая служба имеет собственный график развёртывания, зависимости и характеристики производительности. Модели трафика пользователей варьируются в течение дня и в разных регионах. Новые функции возможно повлияют на производительность системы неожиданными способами. Эта сложность превышает то, чем могут эффективно управлять операторы-люди, используя традиционные подходы.
Инструменты автоматизации
Первый инструмент, автоматизация рабочих процессов разработки. Выполняется анализ качества кода и безопасности. Могут выявляться потенциальные уязвимости безопасности, узкие места в производительности и проблемы с «ремонтоспособностью» при написании кода. На больших кодовых базах эти системы учатся распознавать шаблоны, которые указывают на проблемы.
Например, GitHub Copilot. Он понимает контекст из окружающего кода и может рекомендовать подходы, которые позволят избежать распространённых ошибок безопасности. Эти предложения выполняются в реальном времени.
Есть и инструменты, с машинным обучением (ML), такие как Snyk и Veracode. Они анализируют, как шаблоны кода соотносятся с известными проблемами безопасности, и предсказажут, где могут возникнуть новые уязвимости.
Интеллектуальное масштабирование
Вторая крупная трансформация включает в себя то, как ИИ управляет ресурсами инфраструктуры и реагирует на меняющиеся требования. Это когда инфраструктура сама понимает, сколько ей нужно ресурсов и когда эти ресурсы лучше добавить или убрать. Не ручками по тикету утром, а по истории поведения сервиса, внешним событиям и текущим метрикам.
Простой пример: как Netflix предсказывает, что в определённый вечер у конкретного шоу вырастет аудитория. Так и система масштабирования может заранее поднять потоки или ноды там, где ожидается всплеск нагрузки. Облачные провайдеры уже предлагают похожие механизмы: они учитывают время суток, сезонность и реальные метрики приложения и со временем «обучаются» под конкретные паттерны нагрузки. Это делает масштабирование плавным и экономичным — лучше, чем жёсткие правила «CPU > 70% → добавить инстанс».
Шаг дальше — интеллектуальное балансирование нагрузки и маршрутизация. Балансировщик на базе ML распределяет запросы поровну. Но помимо этого, он смотрит на скорость отклика конкретного сервера, местоположение пользователя и SLA сервиса. И перенаправляет трафик с уменьшением задержек и экономя ресурсы. CDN-провайдеры (например, Cloudflare) используют похожие приёмы: анализируют трафик и заранее кэшируют контент в нужных регионах. Даже обнаруживают аномалии вроде DDoS-атак.
Это касается и микросервисов. Сервис-меши и платформы оркестрации (Kubernetes, Istio и им подобные) получают фидбек о связях между сервисами. А дальше, находят узкие места и подправляют политику ретраев и маршрутизации. ИИ может формировать инфраструктуру по описанию требований. Он подберёт и развернёт нужные базы, ноды и сети.
Мониторинг, оповещение и реагирование на инциденты
Третья область трансформации заключается в том, как ИИ меняет мониторинг и инцидент-менеджмент. Традиционный мониторинг генерирует оповещения на основе заранее определённых пороговых значений и правил.
Инструменты мониторинга ИИ узнают, как выглядит нормальное поведение приложения, и предупреждают команды, когда шаблоны значительно отклоняются от ожиданий. Этот подход уменьшает ложноположительные оповещения при выявлении проблем, которые могут не вызвать традиционный мониторинг на основе правил.
Например, если приложение обычно обрабатывает 1000 запросов в минуту со средним временем отклика 200 миллисекунд, традиционный мониторинг может предупреждать, когда время ответа превышает 500 миллисекунд или объём запросов падает ниже 500 в минуту. Мониторинг ИИ учитывает взаимосвязь между этими показателями и понимает, что время отклика 300 миллисекунд может быть нормальным в периоды пикового использования, но тревожным в периоды низкого уровня трафика.
Платформы мониторинга, такие как New Relic, используют ML для установления динамических базовых линий для метрик приложений. Для обнаружения тонких изменений в поведении, которые указывают на развитие проблем. Прежде чем они существенно повлияют на пользователей.
Интеллектуальный анализ первопричин: при возникновении проблем инструменты ИИ анализируют журналы, метрики и поведение системы, чтобы выявить первопричины, быстрее ручного расследования. Эти системы понимают взаимосвязи между различными компонентами системы и могут отслеживать проблемы через сложные цепочки зависимостей.
ИИ может оптимизировать графики дежурных, анализируя схемы инцидентов, опыт членов команды и распределение рабочей нагрузки. Системы учатся направлять оповещения членам команды, которые, скорее всего, быстро решат конкретные типы проблем.
Они также могут предоставить контекст и предлагаемые шаги по исправлению, основанные на аналогичных предыдущих инцидентах, помогая дежурным инженерам реагировать более эффективно на незнакомые проблемы.
А что в итоге
Сложности не останавливают бизнес. Компании продолжают постепенно углубляться в инструменты методологии. А фактор импортозамещения делает ИТ-продукты подхода DevOps популярными среди предприятий самых разных направлений деятельности и размеров.
Вероятнее всего, в 2026 году тренд лишь усилится, организации будут интенсивнее внедрять инструменты методологии. В бизнес-сообществе станут больше говорить об использовании DevOps-решений за пределами ИТ-индустрии. Ожидается рост рынка DevOps в ближайшие несколько лет. В 2029 году он вырастет до 37,33 млрд. долларов США при темпах роста (CAGR) 25,7%. Такой рост связан с расширением мультиоблачных и гибридных стратегий, а также с увеличением инвестиций в автоматизацию, CI/CD и платформенную инженерию.
Что ждёт DevOps в будущем, увидим ли мы автоматизацию хотя бы на 90%, пишите в комментариях.
© 2025 ООО «МТ ФИНАНС»