Меня зовут Дмитрий Синявский, я SRE в Ви.Tech, IT дочке «ВсеИнструменты.ру». В какой то момент я поймал себя на мысли, что вокруг DevOps снова спорят как в начале десятых: одни уверяют, что он умер, другие переименовывают все в platform engineering, третьи ждут, что ИИ наконец сделает всю грязную работу за инженеров. Мы с Владимиром Утратенко, который прошел путь от техподдержки до техдиректора и сейчас развивает платформу «Штурвал», спокойно разложили это по полочкам.

В этой статье я собрал самое полезное из нашего разговора: что стало с DevOps после хайпа, как автоматизация одновременно помогает и ослабляет, и какое место ИИ реально занимает в инженерке.

DevOps: когда религия закончилась

Фраза «DevOps умер» звучит красиво, но по ощущениям она из той же серии, что «умер Git». Да, хайп вокруг DevOps прошел, да, многие успели разочароваться. Но это не смерть, а взросление.

Вова сформулировал это просто: DevOps как подход стал коммодити. Мы уже пробежали стандартный маршрут. Сначала стадия «вау, мы девопсы, у нас бесконечность на слайдах». Потом стадия «это все фигня, верните как было, микросервисы и DevOps только ухудшили жизнь». И сейчас тихая фаза, когда DevOps воспринимается как must have инженерная практика. Без него можно, но будете медленнее и болезненнее.

Это хорошо видно даже по рынку. Откроете вакансии разработчиков и техдиректоров, почти везде встретите требования уровня «понимание DevOps практик», «опыт с CI/CD», «умение жить с observability». DevOps все меньше выглядит как отдельная роль загадочного инженера с туманным описанием, и все больше как часть нормальной инженерной культуры.

При этом DevOps у всех в голове свой. Для одних DevOps это просто CI/CD. Для других DevOps означает «у нас есть SRE». Для третьих это «мы купили Kubernetes». Для четвертых это дежурства и постмортемы. Вова любит притчу про слона и слепых: один потрогал хобот и решил, что слон это хобот, другой потрогал ногу и решил, что слон это колонна. С DevOps происходит то же самое.

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

Когда айтишка становится заводом

В какой то момент разговор ушел в сторону, которая сначала звучала странно. Мы обсуждали заводы, Toyota, теорию ограничений Голдратта, Деминга, теорию очередей. Но если посмотреть на IT на масштабе, аналогия вылезает сама собой.

Примерно так это раскладывается по шагам.

Два человека пилят MVP. Это ремесло. Начальная стадия, когда все держится на том, что пара людей «на коленке» собирает продукт и одновременно придумывает процессы.

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

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

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

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

Историческая боль: год разработки, год интеграции

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

Типичная схема выглядела так.

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

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

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

В какой то момент здесь случился щелчок. Появился термин 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 скриптом не справятся»

Он взял свой скрипт, показал команде, объяснил, где что менять, куда добавлять новые сервисы. Обернул это в кнопку в CI. После этого разработчики сами могли развернуть себе окружение, не дергая его по каждому поводу.

Это и есть минимальный self service. Без порталов, без модных слов, без красивых интерфейсов. Просто инструмент, который снимает боль и делает команду более автономной.

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

Обратная сторона автоматизации

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

Цепочка выглядит так.

Вы автоматизируете какую то сложную операцию, становится сильно лучше.

Люди перестают делать это руками, потому что в этом просто нет необходимости.

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

В какой то момент кнопка ломается. И происходит не абстрактная «авария», а очень конкретная ситуация: никто не знает, как сделать это без кнопки.

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

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

Пока это про дом и детскую, история смешная. Пока это про прод и критичные системы, история становится уже совсем другой.

Отсюда вылезает несколько неприятных, но честных выводов.

Автоматизация это продукт, а не скрипт на коленке.

У этого продукта должен быть владелец. Человек или команда, которая знает детали, принимает решения про развитие и отвечает за результат.

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

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

Как не дать навыкам разложиться

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

Учения по аварийным переключениям. Если у вас есть сценарии DR, ими надо пользоваться не только в документах. Один раз в квартал или полгода проиграть «переключение на резерв» руками, посмотреть, где все ломается не на словах, а на деле.

Регулярная проверка бэкапов. Не в формате «мы делаем бэкапы», а в формате «мы регулярно пробуем восстанавливаться и знаем, сколько времени и усилий это занимает».

Хаос инжиниринг. Не обязательно сразу тащить себе сложные платформы. Даже простые контролируемые эксперименты, когда вы сознательно ломаете кусок системы и смотрите, как она себя ведет, уже прокачивают команду.

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

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

«Выход в поля» против абстракции

Один из самых ярких эпизодов нашего разговора был про склад и Grafana.

Ребята поехали на распределительный центр, посмотреть, как реально живет логистика. И неожиданно увидели, что операционные команды на складе сидят в инфраструктурной Grafana, которую делали они. У них там свои дашборды по волнам сборки, по которым они живут в смену.

До этого падение Grafana на 20 минут воспринималось как неприятная, но переживаемая история. После склада стало понятно, что это mission critical штука. Падает Grafana, встает процесс на складе. Дальше цепочка по всей компании.

Такой опыт никак не вытянуть из документации. Его можно только прожить. И после этого в голове сильно меняется восприятие фраз «ну упало и упало» и «давайте еще немного потерпим». Это перестает быть абстракцией и превращается в очень конкретное: кто то сейчас в смену не выполняет план, кто то потеряет в премии, у кого то вырастает очередь клиентов.

Мы оба сошлись в одном. Таких «выходов в поля» не должно быть только у новичков на онбординге. Это должна быть регулярная практика. Хотя бы раз в год у инженеров должен быть шанс посмотреть на свою систему глазами людей, которые работают поверх нее. Иначе инженерная абстракция неизбежно отрывается от реальности.

ИИ как станок с ЧПУ

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

Если сильно упростить, ИИ сейчас выглядит как станок с ЧПУ. Это мощный инструмент, который может сильно ускорить работу, но при этом сам по себе инженером не становится.

Модели учатся на «всем коде мира». Там есть и классные решения, и очень странные. На выходе появляется статистически усредненный результат. Уровень примерно «не очень смышленый мидл».

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

Очень узнаваемая история. Человек загрузил в модель свой pet проект, сказал «сделай хорошо». Модель аккуратно разложила все по модулям, убрала лишние связи, почистила зависимости. На бумаге получилось красиво. Но не заработало.

В такой картине нормальная роль ИИ выглядит так.

Собирать scaffold и типовой код.

Генерировать пайплайны и конфиги по понятным требованиям.

Помогать с однообразными задачами, которые скучно делать руками.

Отвечать на тупые вопросы «почему эта штука уже четыре часа не работает».

Но не пытаться «подменить» собой архитектора или команду, которая понимает домен.

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

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

«Пиши код», даже если ты не разработчик

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

«Пиши код. Даже если ты системный инженер»

Причины у него очень прагматичные. Код разворачивает мозги. Расширяет твой T shape. Помогает лучше понимать, как решения выглядят на земле, а не только в инфраструктурных диаграммах.

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

Что с этим делать завтра

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

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

Если у вас много автоматизации и есть страх «кнопка сломается», заведите конкретных владельцев и хотя бы раз в полгода проиграйте руками сценарии без этой кнопки.

Если вы хотите использовать ИИ, перестаньте просить его «сделать хорошо». Начните просить scaffolding, отдельные модули, пайплайны по четким требованиям. Ревьюйте все это так, как ревьюили бы код джуна.

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