DevOps как методология в 2025 году — что уже устарело, что становится must-have, какие инструменты и подходы реально работают в продакшене

Главная / Статьи / Интервью / DevOps как методология в 2025 году — что уже устарело, что становится must-have, какие инструменты и подходы реально работают в продакшене

28-летний DevOps-инженер Владимир Фролкин за пять лет прошел путь от системного инженера до DevOps-специалиста в крупной IT-компании и основателя собственного аутсорс-агентства. В интервью журналу «БИТ» он рассказывает, как изменилась методология DevOps, какие инструменты устарели, а без чего невозможно выжить в 2025 году.

- Владимир, Вы начинали системным инженером в 2020 году, а сейчас отвечаете за всю инфраструктуру компании Digital Wave Technology. Как изменился DevOps за эти пять лет?

- Кардинально. То, что мы считали передовым в 2020-м, сегодня может серьезно навредить проекту. Взять те же монолитные CI/CD-пайплайны — длинные последовательности сборки, которые выполняются часами. Дело в сложности. Условно до 2021 разработка инфраструктуры всё чаще и чаще включала в себя новые модные инструменты, компании хотели kubernetes, много цифр и букв, что создавало овер-инжиниринг. Но бизнесу нравилось. Было вдохновение для гонки в использовании технологий, и в том, насколько новый и крутой инструмент используется у вас в продукте (или инфраструктуре). Был своеобразный “понт”, как для привлечения сотрудников, так и для репутации бизнеса (смотрите, мы передовые). Когда на рынок залетел ИИ со своими клиентами, цикл дизайна архитектуры в IT свернул в стадию минимализма. Бизнес вдруг вспомнил, что не всё новое лучше старого, и что “лучший код тот, который не был написан”.

- Jenkins, например. Некогда король автоматизации сборок сегодня выглядит архаично из-за сложной настройки и проблем с масштабированием. В 2024 году доля Jenkins в новых проектах сократилась на 40%. Однако это не касается закрытых систем, типа финтеха или банкинга. Там уровень кастомизации как сервисов, так и инфраструктуры высок, как и раньше. В России, например, Jenkins часто используется по инерции и воспринимается надёжным self-hosted решением, создатели которого не могут заблокировать его по каким-либо причинам в России, как GitLab или GitHub, потому что Jenkins просто не имеет облачной версии.

Также ушли в прошлое классические серверы "домашних животных" — именованные сервера, которые админы знают "в лицо" и настраивают вручную. Сейчас инфраструктура строится по принципу "скота" — идентичные, взаимозаменяемые инстансы. Вся конфигурация хранится в условной “простыне”, то есть в коде. Подход Infrastructure as Code (IaC) теперь практически must-have, если вы верите в рост своего проекта.

- Platform Engineering выделился в отдельную дисциплину. Создание внутренних платформ разработки стало критически важным для крупных команд. И это хорошая новость для DevOps инженеров – меньше зоопарка, больше стандартизации в любой компании.

Observability заменил классический мониторинг. Недостаточно просто следить за метриками — нужно понимать внутреннее состояние системы через трейсинг, логирование и метрики. То есть можно отследить, что пошло не так, а не просто “серверу/сервису плохо.

— У вас есть конкретные примеры того, как эти подходы работают на практике?

- Конечно. Для одного заказчика я переработал инфраструктуру так, что ее части стали развертываться независимо друг от друга. Раньше при каждом неудачном изменении в продакшене — а это примерно каждое девятое — страдали все шесть микросервисов. Теперь падает только один, остальные независимы.

Более того, благодаря Infrastructure as Code и serverless-подходу, даже при самой страшной аварии восстановить инфраструктуру можно за час вместо целого дня. Ускорение развертывания на 80%.

Для другого клиента создал автоматизацию, которая сократила время развертывания нового инстанса с четырех часов до 30 минут — экономия 88% времени. У этого заказчика каждый клиент имеет свой экземпляр продукта, и создание инстансов происходит постоянно.

— Расскажите о своем опыте работы с крупными компаниями.

- В топовом дубайском финтехе Tabby, который оценивается в 3,3 миллиарда долларов, я создавал кластер для отдела информационной безопасности. Также участвовал в создании инфраструктуры для проекта eBay, правда, как суб-подрядчик.

Сейчас в Digital Wave Technology я единственный DevOps-инженер на всю компанию — около 100 человек. Это IT-компания, связанная с AI, так что ответственность огромная. За полгода автоматизировал создание инфраструктуры для клиентов и настроил весь мониторинг. За время моей работы у компании появились такие заказчики, как The Home Depot и Aldi.

— Какие инструменты реально работают в 2025 году?

- В CI/CD лидируют GitHub Actions и GitLab CI благодаря простоте настройки и богатой экосистеме. Terraform остается королем Infrastructure as Code, несмотря на предложения облачных провайдеров (например Cloud Formation от AWS). Terraform просто универсальный и относительно свободно распространяется. Связка Terraform+Ansible буквально теперь классическая.

В мониторинге правит триумвират: Prometheus, Grafana, Jaeger. Эта связка стала настолько популярной, что вендоры предлагают готовые интеграции. Плюс OpenTelemetry как единый стандарт для сбора телеметрии.

Классический путь: появляется крутой инструмент с проприетарной лицензией, люди придумывают opensource аналог, и так технология становится народной, а общее развитие в IT двигается вперёд.

— Вы также разрабатываете собственные решения?

- Да, у меня несколько проектов на GitHub. Написал роль для Ansible, которая работает без изменений уже три года — редкость в ИТ-мире. На нее до сих пор появляются новые "звездочки".

Также участвовал в разработке дистрибутива OpenStack — очень масштабной системы для построения приватных облаков.

Сейчас развиваю три проекта: infobot для ежедневных уведомлений, ccalbot для подсчета калорий с помощью ИИ, и betcalc для дружеских ставок, который планируется выпустить в AppStore.

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

Platform Engineering. Всё больше компаний хотят свою внутреннюю экосистему. Особо крупные игроки делают Platform as a Service (PaaS). OpenStack им в помощь.

Можно также заметить, что идёт усиление в части безопасности. Например SBOM. Появляется всё больше security требований. Хотя на мой взгляд КПД от фокуса на новых технических решениях совсем небольшой. Главной точкой входа и дырой в безопасности остаётся социальная инженерия (до 90% случаев взлом именно там).

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

- Безусловно, будет меньше работы руками. Возвращение к истокам DevOps. То, что раньше возлагалось на DevOps-инженеров, теперь будет делаться с помощью ИИ. Такие инструменты как Cursor позволяют иногда чинить сервис одной кнопкой, даже когда ещё неизвестна природа проблемы.

Кроме того, DevOps окончательно стал стандартом в компаниях (особенно в ИТ- сфере). И теперь из DevOps вырастают новые направления: MLOps – где больше работы с данными, больше работы с GPU (появляется даже так называемым LLMOps), FinOps – где происходит работа с эффективностью затрат.

Разделение DevOps по конкретному облаку тоже будет уходить, и Azure DevOps инженер — это будет тот же человек, что и AWS DevOps инженер. И это хорошая новость для старых хардкорных девопсов, которые умели ставить k8s на голое железо (bare-metal). И если мы позволим себе громкие фразы, то для DevOps инструменты - ничто, процессы - всё.

Ключевые слова: DevOps, DevOps-инженер, GitHub, Platform Engineering.

Комментарии могут отставлять только зарегистрированные пользователи