Меня зовут Андрей Трегубов, я руковожу группой DevOps в Ви.Tech, IT-дочке ВсеИнструменты.ру. Недавно мы записали подкаст с Александром Крыловым, директором по развитию продукта «Штурвал», и обсудили, где у DevOps заканчивается роль "ребят, которые иногда помогают разработке" и начинается сервисная модель с понятным входом, приоритетами и правилами игры. В этой статье я собрал из нашего разговора самое практичное: когда DevOps уже пора выстраивать как сервис, почему на росте перестает работать героизм, как не утонуть в поддержке, что делать с зоопарком технологий и где в этой истории нужны Enabling Team, безопасность и ИИ.

Можно долго спорить о терминах, но на практике все очень приземленно. Есть команда, к ней приходят с запросами, она что-то делает, где-то автоматизирует, где-то чинит, где-то вытаскивает всех из пожара. И какое-то время это даже выглядит нормально. Проблема в том, что "нормально" и "масштабируется" далеко не одно и то же.

Где DevOps перестает быть героизмом

Мне очень зашла формулировка Саши:

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

Вот с этого места для меня и начинается DevOps как сервис. Не с модной вывески. Не с красивой схемы в Miro. И не с идеи "давайте сделаем внутренний платформенный юнит". А с понятного вопроса: что именно получает команда на выходе, как она за этим приходит и почему в следующий раз это не будет делаться по совершенно другой схеме.

Нужно поднять CI/CD для нового сервиса, это услуга. Нужно выдать доступ, это услуга. Нужно автоматизировать создание окружения, это тоже услуга. Нужно стандартизировать деплой, да, это опять услуга. Но если все это делается через личку, созвон, старую дружбу, удачно пойманного инженера и фразу "слушай, можешь быстро помочь", то это не сервис. Это героизм. А героизм, как назло, масштабируется хуже всего.

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

Ориентир такой: когда у вас в DevOps уже хотя бы четыре человека и есть 3-5 систем или команд, которым нужна постоянная помощь, стоит как минимум задумываться о сервисной модели. Я бы сказал еще проще: в этот момент она уже начинает проситься сама. Не ради бюрократии, а просто потому, что иначе команда начинает тонуть.

Дежурство не должно быть черной дырой

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

И в какой-то момент приходится вслух проговорить очевидное: дежурство не резиновое.

"Если у вас 5 условных инженеров, но при этом 7 задач максимального приоритета, так это не работает".

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

Не надо. Надо по-другому устроить процесс.

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

Мне в этом месте вообще нравится одна шутка, которую я как-то сам же и вспомнил в разговоре: если вам надо вчера, приходите вчера. Шутка смешная ровно до тех пор, пока у вас не начинается реальная очередь из "вчерашних" задач.

Самая неприятная правда про приоритеты

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

И вот это ловушка.

Да, DevOps должен уметь объяснить риски, показать capacity и честно сказать, почему семь критичных задач не могут поехать одновременно. Но финальный конфликт приоритетов чаще всего не наш. Если у вас два стейкхолдера пришли с двумя "самыми важными задачами", это не повод героически проглотить проблему и тащить ее внутрь команды. Это повод свести конфликт туда, где принимаются решения.

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

Нужна сквозная приоритизация. Не декоративные low, medium, high для успокоения души, а живая система, в которой видно горизонт исполнения. День, неделя, спринт, квартал, позже. И отдельно важно договориться о простом правиле: в спринт без разговоров влетают только реальные пожары. Все остальное должно попадать туда через нормальную оценку, а не через силу крика.

"Поднимите нам коробку", начало многих бед

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

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

"Играться, играйся вне рабочее время. А если хочется действительно причинить пользу себе, команде и компании, давайте идти по понятному прозрачному процессу".

Вот это, мне кажется, надо вообще печатать и вешать рядом с техрадаром.

Если в компании нет процесса пилотирования новых технологий, он все равно появится. Просто либо как аккуратный понятный путь, либо как боль. Минимальный вариант очень простой: есть вход, есть пилот, есть критерии успеха, есть MVP или демо, есть решение по итогам. Попадает технология в техрадар или нет. Остается локальной историей или нет. Умирает спокойно или начинает жить дальше. Все. Без этого вы очень быстро собираете инфраструктурный зоопарк, который сначала выглядит бодро, а потом внезапно жрет кучу поддержки.

Enabling Team, санитары леса или новые вахтеры

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

В здоровом варианте это реально полезная история. В плохом, еще один уровень "не пущать".

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

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

И вот здесь очень уместна еще одна фраза из разговора:

"Мы пришли вам тут не рушить разработку, а наоборот причинять добро".

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

Унификация это не "все снести"

Когда у вас в одной компании живут Helm, kubectl, Terraform, Ansible, bash-скрипты и какие-нибудь артефакты древней цивилизации, первая реакция обычно очень эмоциональная: давайте оставим один инструмент и забудем это как страшный сон. Проблема в том, что унификация тоже стоит денег. Иногда очень ощутимых.

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

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

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

Безопасность и ИИ, без фанатизма

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

Проблема не в разработке. Проблема в том, что людям резко ломают привычный способ работы и не объясняют, зачем. Поэтому безопасность надо внедрять ступенчато. Сначала пилот. Потом прозрачная подсветка. Потом постепенное ужесточение. И только потом обязательные требования. И еще очень нужны люди, которые умеют переводить с языка безопасности на язык IT и обратно. Иначе все быстро превращается в бессмысленную войну терминов и запретов.

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

Если команда начинает бездумно тащить в инфраструктуру то, что ей нагенерировала модель, появляется новый легаси. Причем очень неприятный, потому что он свежий, быстрый и иногда выглядит убедительно ровно до первого падения. История "мне ChatGPT посоветовал" хороша для мемов, а не для продовой инфраструктуры.

Что бы я делал первым

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

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

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