Меня зовут Дмитрий Синявский, я SRE в Ви.Tech — IT-дочке «ВсеИнструменты.ру». В какой-то момент я заметил, что вокруг DevOps снова ведутся споры, будто мы вернулись в начало 2010-х: одни кричат, что DevOps умер, другие переименовывают всё в platform engineering, третьи ждут, что ИИ наконец возьмёт на себя всю рутину. Вместе с Владимиром Уратенко, прошедшим путь от техподдержки до технического директора и сейчас развивающим платформу «Штурвал», мы разобрались, что из этого — шум, а что — реальные вызовы и практики.
В этой статье — ключевые выводы из нашего разговора: как DevOps стал нормой, почему автоматизация ослабляет навыки, и какое место ИИ реально занимает в инженерной культуре.
DevOps: когда религия закончилась
Фраза «DevOps умер» звучит эффектно, но она примерно того же уровня, что и «умер Git». Хайп вокруг DevOps действительно прошёл, многие разочаровались — но это не смерть, а взросление.
Владимир сформулировал это просто: DevOps стал коммодити. Мы прошли стандартный путь — от «вау, мы девопсы, у нас бесконечность на слайдах» до «это всё фигня, верните старое». Сейчас наступила тихая фаза, когда DevOps воспринимается как must-have инженерная практика. Без него можно, но будет медленнее и болезненнее.
Это видно и по рынку: в вакансиях разработчиков и техдиректоров почти везде требуют «понимание DevOps практик», «опыт с CI/CD», «навыки работы с observability». DevOps всё реже выглядит как отдельная роль загадочного инженера и всё чаще — как часть нормальной инженерной культуры.
При этом у каждого DevOps свой. Для одних — это просто CI/CD. Для других — наличие SRE. Для третьих — Kubernetes. Для четвёртых — дежурства и постмортемы. Как в притче про слепых и слона: один потрогал хобот — и решил, что слон похож на змею, другой — ногу, и решил, что это колонна. Так и с DevOps: каждый видит только часть.
Отсюда и главный риск: когда DevOps внедряют как одну тулзу или процесс, почти гарантированно получается карго-культ. Есть красивая схема на плакате, есть слово в презентациях — но эффекта нет. Потому что настоящая «звездная карта» DevOps намного шире, чем просто «билд-тест-деплой».
Когда IT становится заводом
Разговор неожиданно ушёл в сторону заводов, Toyota, теории ограничений Голдратта, Деминга и теории очередей. Но при масштабировании IT эта аналогия встаёт на место сама собой.
Два человека, которые пилот MVP, — это ремесло. Всё держится на личных контактах и «на коленке».
Команда из 20–30 человек — уже мануфактура. Появляется разделение труда, очереди задач, необходимость координации, чтобы не было пробок.
Более пятидесяти человек — это маленький завод по производству софта. Появляется конвейер, стоимость ошибок, узкие места, зависимость от отдельных звеньев.
Владимир шутил, что мы строим «фронтендостроительный завод», выпускающий панели. Но по сути — так и есть. Когда десятки команд работают над постоянным потоком задач, образ «мы творческие художники» заканчивается. Хоть как мы ни цепляемся за него.
На таком масштабе DevOps и появился не как модный ярлык, а как ответ на конкретную задачу: оптимизировать конвейер разработки и эксплуатации, чтобы изменения доходили до пользователей быстро и без постоянного героизма.
Историческая боль: год разработки, год интеграции
Чтобы понять, откуда взялась идея непрерывной интеграции, мы отмотали назад — к классическому водопадному SDLC.
Сначала аналитики «пыхтят» над документами. Потом архитекторы «пыхтят» над схемами. Потом разработчики год пишут код в изоляции, время от времени скидывая что-то тестировщикам.
А потом наступает этап интеграции. И выясняется, что 200 разработчиков год писали код, который теперь нужно собрать в одну базу. Начинается мерж-хелл, который тянется ещё год. Каждый делал по-своему, бизнес изменился, предположения устарели.
Владимир привёл пример: фича-ветка лежала почти год. Когда её решили внедрить, продукт уже ушёл вперёд — половину пришлось переписывать. Это не катастрофа, а закономерность, если нет культуры постоянной интеграции.
Именно здесь и родился термин continuous integration, появились доклады про десятки деплоев в день, первые DevOps-конференции. Но корень был не в романтике, а в боли: людям надоело годами разгребать последствия старого цикла «год пилить — год интегрировать».
Team Topologies и платформенные команды
Ещё один важный аспект — организация команд. Владимир вспоминал, как в Узуме DevOps внедряли не через «давайте купим правильную тулзу», а через DevOps Topologies и Team Topologies.
Идея простая, но болезненная: важно не только то, какие практики у вас есть, но и какие типы команд и как они взаимодействуют. По Team Topologies картина выглядит так:
- Stream-aligned команды — создают прямую ценность для пользователя.
- Enabling команды — помогают другим внедрять практики и наращивать компетенции. Это, по сути, место, где живёт миссия SRE.
- Платформенные команды — предоставляют общие инструменты, снижают когнитивную нагрузку. Это не «люди на серверах», а те, кто превращает инфраструктуру в внутренний продукт.
- Команды сложных подсистем — отвечают за узкие, тяжело заменяемые домены.
В этом контексте platform engineering перестаёт быть модным словом. Это естественный ответ на ситуацию, когда зоопарк инструментов и поток запросов разваливают процесс. Без платформенной команды разработчики тонут в деталях, а DevOps-группа превращается в узкое горлышко.
Владимир точно подметил: DevOps чаще всего ломается не на уровне «мы выбрали не тот Jenkins», а на уровне взаимодействия. Когда всё завязано на нескольких людях, каждый деплой — ручной квест, а развитие платформы стоит из-за постоянных пожаров.
Self-service: минимальный, но работающий
Один из самых практичных моментов — про self-service. Эта штука почти всегда «выстреливает», даже если выглядит скромно.
Иногда компаниям хочется сделать идеальный портал, красивый интерфейс, большой каталог сервисов — будто self-service имеет смысл только если его можно презентовать на конференции.
У Владимира взгляд проще. Он рассказывал, как в американском издательстве ему регулярно приходилось разворачивать окружение из полутора десятков микросервисов. У него был скрипт. В какой-то момент надоело делать это вручную по запросам.
Он задал себе простой вопрос: «Рядом сидят умные чуваки, которые пишут более сложный код, чем этот скрипт. Неужели они не справятся с shell-скриптом?»
«Рядом сидят умные чуваки, которые пишут более сложный код, чем этот скрипт. Неужели они с shell-скриптом не справятся?»
Он показал скрипт команде, объяснил, как его менять, добавил кнопку в CI. После этого разработчики сами разворачивали окружения, не дергая его.
Это и есть минимальный self-service: без порталов, без красивых интерфейсов. Просто инструмент, который снимает боль и делает команду автономной.
Практика жёсткая: автоматизация, которая реально помогает, приживается мгновенно. Она может быть некрасивой, но если экономит время и нервы — её будут использовать.
Обратная сторона автоматизации
Автоматизация ускоряет процессы, но параллельно ослабляет нас в критических ситуациях — когда нужно вручную вытаскивать систему из проблем.
Цепочка простая:
- Вы автоматизируете сложную операцию — становится лучше.
- Люди перестают делать это вручную — в этом нет необходимости.
- Приходят новые инженеры, для которых с самого начала существует только кнопка. Они даже не видели, как это делалось вручную.
- Кнопка ломается — и никто не знает, как сделать это без неё.
Это касается не только инфраструктуры. Когда бизнес-процесс автоматизирован настолько, что ручной сценарий нужен раз в год, через год он исчезает из коллективной памяти. Люди начинают считать, что «так было всегда».
Владимир привёл бытовой пример: умный свет в детской, интернет упал — семья не знает, как включить свет.
Когда это происходит в доме — смешно. Когда это происходит в проде — совсем не смешно.
Отсюда — честные, но неприятные выводы:
- Автоматизация — это продукт, а не скрипт на коленке.
- У продукта должен быть владелец — человек или команда, которая знает детали, принимает решения и отвечает за результат.
- Нужны тренировки. Если вы никогда не проигрываете сценарий «кнопка не работает», не удивляйтесь, что в критический момент никто не знает, что делать.
- Любой набор скриптов, пайплайнов и плейбуков со временем превращается во внутреннюю платформу — даже если вы так её не называете. И если делать вид, что это просто «куда-то работает», она рано или поздно сгниёт.
Как не дать навыкам разложиться
К счастью, есть противоядия. Мы сошлись на нескольких проверенных практиках:
- Учения по аварийным переключениям. Если есть сценарии DR, их нужно проигрывать — не в документах, а в реальности. Раз в квартал или полгода включайте резерв вручную.
- Регулярная проверка бэкапов. Не «мы делаем бэкапы», а «мы восстанавливаем и знаем, сколько это занимает».
- Хаос-инжиниринг. Даже простые контролируемые эксперименты, когда вы сознательно ломаете систему, уже прокачивают команду.
- Kaizen вокруг автоматизации. Постоянные небольшие улучшения, а не редкие «большие реформы». Это помогает не доводить всё до полного устаревания.
- Работа с зависимостями и версиями. Неважно, через dependabot или ручной регламент. Важно регулярно возвращаться к системе и смотреть, где она уже не соответствует реальности.
«Выход в поля» против абстракции
Один из самых ярких моментов — про склад и Grafana.
Команда поехала на распределительный центр, чтобы посмотреть, как живёт логистика. И неожиданно увидела, что операционщики на складе сидят в их же Grafana, смотрят дашборды по волнам сборки и работают по ним в смену.
До этого падение Grafana на 20 минут воспринималось как неприятность. После — стало понятно: это mission-critical. Падает Grafana — встаёт склад. Потом — вся цепочка по компании.
Такой опыт не вытащишь из документации. Его нужно прожить. И после этого фразы вроде «ну упало и упало» перестают быть абстракцией. Это уже конкретно: кто-то не выполнит план, кто-то потеряет премию, у кого-то вырастет очередь клиентов.
Мы сошлись: «выходы в поля» не должны быть только у новичков. Это должна быть регулярная практика. Хотя бы раз в год инженеры должны увидеть свою систему глазами тех, кто на ней работает. Иначе абстракция неизбежно оторвётся от реальности.
ИИ как станок с ЧПУ
Когда речь дошла до ИИ, ожидали либо «нас заменят», либо «это игрушка». В итоге картина оказалась скучнее, но полезнее.
Если упростить, ИИ сейчас — как станок с ЧПУ. Мощный инструмент, который ускоряет работу, но сам по себе инженером не становится.
Модели обучаются на «всём коде мира» — там и хорошие решения, и странные. На выходе — статистически усреднённый результат. Уровень — «не очень смышлёный мидл».
Чтобы получить пользу, к ИИ нужно относиться как к джуну: чётко формулировать задачу, делить на этапы, ревьюить результат. Желательно иметь чёткую архитектуру в голове, а не пытаться родить её из промптов.
Типичная история: человек загрузил pet-проект в модель, сказал «сделай хорошо». Модель аккуратно разложила код по модулям, почистила зависимости. Красиво. Но не заработало.
Нормальная роль ИИ:
- Собирать scaffold и типовой код.
- Генерировать пайплайны и конфиги по понятным требованиям.
- Помогать с однообразными задачами.
- Отвечать на «почему эта штука уже четыре часа не работает».
Но не пытаться «подменить» архитектора или команду, которая понимает домен.
Есть и побочный эффект: порог входа для джунов растёт. Если джун будет полностью полагаться на ИИ, он может годами не нарабатывать хардскиллы. В итоге получим поколение, которое умеет писать промпты, но не понимает, что происходит под капотом.
Для синьора и мидла нейронка — отличный помощник. Для джуна — часто костыль. Если компания хочет нормальную лестницу роста, ей придётся сознательно учить джунов думать, а не просто просить «сделай красиво».
«Пиши код», даже если ты не разработчик
В конце я спросил Владимира, какой совет он дал бы себе в начале карьеры. Ответ был коротким:
«Пиши код. Даже если ты системный инженер»
Причины прагматичные:
- Код разворачивает мозги.
- Расширяет T-образные навыки.
- Помогает понимать, как решения выглядят на земле, а не только на диаграммах.
И да, рынок до сих пор ценит «опыт коммерческой разработки» даже в ролях, где он, казалось бы, не нужен. Этот опыт меняет то, как ты думаешь о системах, автоматизации и платформах.
Что делать завтра
После разговора у меня сложился набор конкретных шагов, а не идеологий:
- Если DevOps живёт за счёт героизма нескольких людей — попробуйте рассматривать его как сервис. Есть ли у него понятный вход, ожидаемый результат и процесс, который не зависит от того, поймали ли вы нужного человека в коридоре?
- Если у вас много автоматизации и страх «кнопка сломается» — заведите владельцев и раз в полгода проигрывайте сценарии без неё.
- Если хотите использовать ИИ — перестаньте просить «сделай хорошо». Начните с scaffolding, отдельных модулей, пайплайнов по чётким требованиям. Ревьюйте как код джуна.
- Не забывайте выходить в поля. Где-то на складе, в магазине, в поддержке ваш код уже живёт отдельной жизнью. Раз в какое-то время стоит своими глазами увидеть, как именно.