Команды разработки и DevOps начинают совместную работу с энтузиазма и взаимного уважения. Но со временем отношения превращаются в холодную войну. В ней нет победителей — только выгоревшие. Разработчики не понимают инфраструктуру, тестировщики хотят странного, безопасники закручивают гайки, DevOps окапываются в обороне, процессы тормозят работу, а CTO хватается за голову. Все стараются, но становится только хуже. Но есть способы это изменить и превратить конфликты в полезное сотрудничество.
DevOps-команды сегодня — это внутренние поставщики сервисов: от пайплайнов и окружений до документации и архитектурных решений. В этой статье поговорим о том, как выстроить эту работу так, чтобы было удобно и разработчикам, и самим девопсам. Как выйти из роли «пожарной команды», навести порядок в ожиданиях и инструментах, построить платформу и не сгореть.
Я Владимир Утратенко — CIO, DevOps-евангелист, соорганизатор сообщества DevOps Moscow. Я успел много где поработать — в американских и российских энтерпрайзах, в компаниях, которые стали бигтехами, и стартапах. Строю платформы и использую DevOps как подход к организации разработки. Сейчас обитаю в «Лаборатории Числитель», занимаюсь развитием контейнерной платформы «Штурвал».
Чтобы разобраться, где вообще рождаются платформенные практики и кто их использует, давайте посмотрим на разные типы компаний и что конкретно происходит на поле боя.
DevOps в разных типах компаний
Есть несколько вариантов. Первое поле — это крупные компании и бигтехи.
Обычно в их арсенале:
Платформенные сервисы. В бигтехах — ворох внутренних сервисов. Например, OZON делает свой сервис управления алертами, а команда Т-Банка не так давно выпустила «Нестора» — ИИ-модельку, которую ребята используют для ускорения разработки.
Infrastructure as Code (IaC). Как без него, если уже большие и взрослые.
Штат из 500 человек. Привет, Т-Банк! Все заняты разработкой собственных велосипедов.
SRE как OPS 2.0. Если OPS 1.0 — это ребята, которые крутят в ЦОДе, меняют зипы и сгоревшие винчестеры, то SRE — это уже про надёжность сервисов.
Второе поле боя — стартапы:
Полтора девопса — хотя бы так, иногда ведь вообще никого нет.
Модный (или не очень) клауд, в зависимости от уровня регулирования.
Многое сделано или развёрнуто «на коленке».
Минимум кода, максимум результата. Главное — выйти на инвестиционный раунд.
Винегрет из технологий. Что-то живо, что-то давно умерло, но забыли вынести труп.
Между этими крайностями, как в сэндвиче, находятся все остальные — компании среднего размера, многие из которых только сюда заходят.
Как правило, у нас есть набор готовых кубиков — хороших и стабильных open-source решений. Берём GitLab, Jenkins, Grafana и другие инструменты и отдаём разработчикам. Им что-то не нравится, что-то идёт не так. Мы пытаемся упростить жизнь: оборачиваем всё, что можем, в пайплайны, пишем скрипты. Чтобы не было так больно, автоматизируем — скорее всего, на Ansible. Иногда доходим до Kubernetes или Terraform.
Независимо от масштаба, все так или иначе собирают что-то своё — и всем больно. Где-то не хватает людей, где-то — связности. И возникают конфликты ожиданий, которые часто не совпадают.
Что нужно девопсам:
Стабильная инфраструктура, чтобы ничего не падало
Самостоятельность разработчиков и всех остальных
IaC (особенно если его нет) и любая автоматизация, чтобы не было больно
Поменьше глупых вопросов, потому что достали
Меньше работы по поддержке разработчиков, чтобы заниматься интересным, а не «У меня пайплайн упал, почини!»
Что хотят разработчики:
Стабильные сервисы
Кнопку «Задеплоить»
Кнопку «Передеплоить»
Кнопку «Снести всё нафиг и поднять заново»
Писать фичи
Не вникать в инфраструктуру, насколько возможно
Быстрой реакции DevOps на проблемы
Что хочет CTO:
Стабильной инфраструктуры и сервисов
Чтобы проект ехал быстро и не спотыкался
Чтобы техдолг не рос
Чтобы команды сотрудничали, а не конфликтовали
Чтобы никто не выгорал от неэффективных решений
Увы, так получается не всегда.
DevOps мёртв?
На этом фоне возникает ощущение, что DevOps не работает и подход себя исчерпал, но решение есть. Придумали его ещё в далёком 2009 году, когда появился DevOps: DevOpsDays, Гент, Патрик Дебуа.
Мы хотели быстро поставлять, оставаться надёжными, сотрудничать, двигаться к общей цели, Flickr и 10 деплоев в день — мир, дружба, жвачка. Но получили:
DevOps-команду как прослойку между Dev и Ops.
DevOps-команду вместо Ops.
Причём о том, что так делать не стоит, мы знали ещё в 2013 году, но всё равно почему-то продолжаем.
Негибкость централизованной функции DevOps.
Нам приносят универсальные пайплайны, которые не подходят. Мы колемся, плачем, но продолжаем есть кактус — другого нет. Или движемся в обратную сторону и децентрализуем функцию DevOps.
Плохую синхронизацию и недозагрузку инженеров.
В итоге имеем конфликты с разработкой и стену непонимания, как 20 лет назад. Народ массово уходит в SRE, а термин DevOps становится токсичным.
Всё мертво? Кажется, нет.
Новая надежда
Есть мысль, которая зрела последние 10 лет и, кажется, с ней всё больше начинают работать. Началось всё с идеи под названием DevOps Topologies. Это буквально one-pager из 2013 года, в котором авторы пытались ответить на вопрос: «Как выстроить взаимодействие команд, чтобы быть DevOps?»
Об этом подходе мало кто знает, а зря. Потому что ребята, которые его делали, не остановились на достигнутом и создали командные топологии, описанные в книге «Team Topologies: Organizing Business and Technology Teams for Fast Flow».
Есть четыре типа команд:
Stream-Aligned Teams — те, кто поставляет ценность.
Complicated-Subsystem Teams — занимаются сложными, важными, но непонятными компонентами.
Enabling Teams — помогают командам выстраивать практики, учат делать правильно.
Platform Teams — дают трём другим командам инструменты, чтобы работать эффективней.
И есть ещё режимы взаимодействия — кто, с кем и как работает. Нас интересует один конкретный — X as a Service, когда что-то предоставляется как сервис. Об этом будем говорить дальше.
Кажется, логично: трансформируем DevOps-команды в платформенные. Кто-то же должен поставлять инструменты, не всем же быть SRE? Можно просто переименоваться, сообщить, что теперь работаем по-другому. Но этого недостаточно.
Изменения нужно начинать с себя — с головы и подходов. И первое, на что я предлагаю обратить внимание (да, возможно, прозвучит как менеджерский буллшит) — для кого мы делаем платформу, на кого ориентируемся.
Клиентоориентированность
В работе с разработчиками, тестировщиками или безопасниками мы, увы, часто не особо клиентоориентированы. Мы не задумываемся, для кого мы делаем то, что делаем, каково им живётся с результатами нашего труда — мы решаем задачки, жалуемся, что коллеги не очень умные, строим системы, исходя из своего видения прекрасного. Вот только проще и удобнее нашим коллегам от этого становится не всегда. Что можно с этим сделать? Вот важные принципы, которых полезно придерживаться:
Пойми, кто твой клиент
Нужно разобраться, для кого мы делаем работу, кто ближайший к платформе пользователь. Как правило, это не пользователь продукта, который мы выпускаем на рынок, а кто-то из инженерной команды.
Обними своего клиента
По-хорошему его нужно принять, выпить с ним пива, попить кофе, скушать булочку, постоять вместе в курилке и разобраться, что ему действительно нужно. На этом этапе часто приходит осознание, что не такая большая стена нас разделяет.
Уважай своего клиента
Какую бы дребедень не нёс клиент, какой бы глупостью это не казалось — выслушай, запиши, поблагодари. Погладь его по голове и скажи: «Давай посмотрим, что можно с этим сделать, и обязательно тебе поможем».
Здесь нам на помощь приходит продуктовый подход. Знаю, что про него прожужжали все уши на последних конференциях, но мы всё равно к нему обратимся.
Продуктовый подход
Чтобы помогать клиентам, нужно смотреть на свою работу как на продукт. А значит — использовать продуктовые практики:
Jobs To Be Done (JTBD)
JTBD — это подход, который помогает понять, какую задачу пользователь на самом деле хочет решить, а не какую фичу он просит. Весь буллшит-лист, который выдал нам разработчик, можно раскидать по простому фреймворку:
«Когда я выкатываю изменение, я хочу его протестировать и ожидаю, что оно поднимется».
Так мы начинаем видеть сценарии использования:
что делают пользователи, как они работают,
что они берут из того, что мы им отдали,
что для них важно, и на что нам стоит обратить внимание.
Получив ответы на эти вопросы, движемся дальше.
UX — удобство использования
Нам нравятся удобные сервисы. Мы «по кнопке» заказываем такси, еду, товары, пользуемся VPN и пр.. Но почему-то, когда делаем внутренние продукты для коллег, то порой забываем, что они тоже должны быть удобными. Вместо этого звучит: «Да некогда. Пользуйся тем, что сделали, ешь, что дают».
Важно обращать внимание на пользовательский опыт. Всем приятно иметь дело с классными, удобными вещами. Так проще.
UI — сделай красиво
Мы любим красивые и понятные интерфейсы. Серебряной пули не бывает, но можно хотя бы сделать так, чтобы пользователь не чувствовал себя наказанным за то, что пользуется сервисом.
MVP — минимально полезное
Все знают про MVP, но не все умеют его готовить. Мы понимаем, что нужно сделать и как собрать прототип. А что предпринять, чтобы решить задачу пользователя и облегчить ему работу уже сейчас? Остальное доделаем позже. Или нет. Главное, MVP уже работает.
Метрики — измерение пользы
Как только отдали MVP, мы смотрим, как им пользуются. Метрики — это не то, что мы обычно привыкли отслеживать в Grafana, вроде CPU usage, memory, saturation, а фичи. Наблюдаем, как часто и с какой скоростью запускаются пайплайны, сколько людей получает доступ через наш инструмент, как они пользуются тем, что мы им отдали, и нужно ли им это вообще.
Tone of Voice
Корпоративные ИТ-системы, как правило, довольно канцелярские: «Пожалуйста, пойдите и соберите три апрува, желательно в четвёртое полнолуние месяца, и нажмите кнопочку». Друг с другом мы общаемся совсем не так. Просто говорим разработчику: «Петь, тут такая фигня, давай что-то с этим сделаем».
Классно, когда софт общается с нами на понятном языке, по-человечески. О продуктовом подходе во внутренних сервисах в прошлом году рассказывал Витя Попов, а в этом — Мария Летта.
Теперь, когда мы поняли, как подойти к работе с пользователями, пора посмотреть, как это связано с платформой.
Какие бывают платформы
Обычно, когда говорят «платформа», все думают про инфраструктуру. Но у нас есть бэкенд, фронтенд, тестирование, безопасность и много всего другого.
Любое экосистемное решение, с которым вы сталкиваетесь в работе, может однажды стать платформой. Даже 1С или PL/SQL на Oracle. Можно натаскать из него важных фичей, которые будут приносить людям пользу.
Но просто так мы это не сделаем. Чтобы что-то стало платформой, придётся занырнуть в душную зону, которую никто не любит: подумать про архитектуру, написать документацию.
Архитектура сервисов
Прежде, чем строить платформу, надо понять, какие сервисы в неё включить. Речь не про Kubernetes, GitLab, ELK или мониторинг как таковой, а про сервисы с точки зрения пользователя — что он реально видит и с чем взаимодействует. Затем понять, как эти сервисы выглядят архитектурно, может ли ими пользоваться кто-то, кроме вашей команды, и подумать, как улучшить то, что есть.
Что пользователь считает сервисом
Управление конфигурациями
Пользователь не думает в терминах Kubernetes, HELM, Ansible, Terraform. Вместо этого он видит возможности управления конфигурацией — как задать параметры и разложить приложение по стендам: на тест, в прод, куда угодно ещё.
Наблюдаемость (Observability)
Как только что-то ломается, пользователь хочет посмотреть метрики, открыть логи, залезть в трейсы, поймать exceptions — и желательно всё в одном окне.
Управление разработкой и тестированием
Тут тоже самое — линтеры, GIT, прехуки, которые вовремя бьют разработчика по рукам и говорят: «Скотина, положи сюда номер тикета, положи сюда это, положи сюда то, потому что иначе наши пайплайны не заработают».
Управление инцидентами
Это тоже часть платформы. Особенно, когда нас будят по ночам, что, мягко говоря, никому не нравится.
Всё, что реально используется
Если что-то применяется регулярно и приносит пользу — это уже кандидат в сервис.
Как сервисы выглядят изнутри
Мы определили, какие сервисы существуют. Теперь нужно понять их архитектуру: как они устроены, какие между ними потоки данных, через какие API, где начинаются, где заканчиваются — каждый кусочек.
Если вам знакома модель C4, воспользуйтесь ей. Если нет — почитайте подробней на c4model.com. Это визуальный паттерн, помогающий понятно описать архитектуру: какие компоненты у вас есть, как они взаимодействуют, как предоставляются ваши сервисы, они монолитные внутри или сервисно-ориентированы? А может, у вас пачка куберов, которые вы раздаёте всем, или у вас база данных под сервис, которая поднимается автоматом? Соберите то, что у вас получилось в понятную схему, по которой коллеги смогут понять существующий ландшафт.
Кто может этим пользоваться
Допустим, вы подняли сервис. Задокументировали, развернули и кому угодно можете объяснить его работу. А кто, кроме вас, может этим воспользоваться прямо сейчас? Если никто, стоит задуматься: что нужно, чтобы кто-то смог.
Платформы живут на сервисах самообслуживания. Только так мы можем снять с себя лишнюю нагрузку и не гореть.
Как построить лучше
Посмотрите на то, что вы успели построить. Что можно улучшить? Что можно отдать как сервис уже сейчас, чтобы помочь коллегам решить конкретную проблему?
Что по компонентам?
Компоненты-коробочки
Все хорошо знакомы с «коробочными» решениями. Они обычно проходят три стадии:
Вендорские или опенсорсные коробочки
Как правило, всё начинается с готовых решений. Мы пытаемся впихнуть их в коллегу, которому, как нам кажется, будет полезно — бери, пользуйся. Но итог непонятный, может и не зайти. Зато удобно, а если коллег мало — можно всех обучить.
Git, CI и обвязка коробочек кодом
В какой-то момент команда становится больше. Доходим до того, что обвязываем коробочки кодом, что-то запихиваем в CI, где-то автоматизируем.
Собственные коробочки
Потом нас становится много — начинаем писать собственные сервисы, потому что опенсорсных и вендорских не хватает. Всё это постепенно становится компонентами будущей платформы.
Внутренний портал разработки
Следующим этапом хочется общий интерфейс, из которого всё это можно достать. Такая штука есть и уже появляется в некоторых бигтехах. Это может быть очередной корпоративный портал, в зависимости от того, как вы его сконфигурируете и что туда положите. А лежать там должны ваши сервисы.
Это может быть коробочное решение — пожалуйста, берём набивший оскомину Backstage или менее известный Developer Portal, хороший, приятный и хорошо работающий на небольших масштабах. К нему можно подтянуть кучу open-source-интеграций.
Если захотите написать такой портал самостоятельно — у вас получится. Потому что API — простые, сервисы — понятные, вам знакома предметная область, и, возможно, даже найдётся разработчик, который это реализует.
На старте проще начинать с коробочной версии. Чтобы не изобретать с нуля: собираем MVP из готового, и уже можно хоть что-то отдать людям. Позже для нормальной автоматизации и построения сервисов самообслуживания вам, возможно, придётся написать свой интерфейс. Веб-версию, как на скриншоте или CLI, или и то, и другое, или даже чат-бот.
Истина — где-то посередине. В любом случае, в какой-то момент open-source догонит, просто потому что его делают люди с такими же болями, как у вас. Но это всё равно будет общее решение, которое нужно либо кастомизировать, либо смириться и жить с тем, что есть.
Сборка self-service
Ищем низко висящие фрукты. Сначала находим то, что можно быстро взять, автоматизировать и превратить в self-service. То, что уже сейчас болит, используется и будет полезно хотя бы кому-то.
Думаем над UX, в том числе на масштабе. Это должно быть удобно. Если неудобно — пользоваться не будут.
Прикидываем архитектуру. Смотрим, как всё будет взаимодействовать: где сходить в API, какие нужны ресурсы, что где поднять, какие зависимости.
Собираем прототип. Смотрим на него сами, обсуждаем в команде, трезво оцениваем: можно ли это уже кому-то показать.
Зовём лояльных клиентов, чтобы собрать обратную связь. Тех самых ребят, с которыми пили кофе, ходили в курилку или в бар. Просим их: «Посмотри и скажи, как тебе. Мы хотим сделать лучше». Обычно они дают честный фидбек.
Вносим правки на основе комментариев. Собираем новый прототип, снова тестируем — чаще всего на той же группе.
Выпускаем MVP. Когда прототип работает, выпускаем минимальный рабочий вариант.
Доводим MVP до вменяемого состояния. Снова собираем обратную связь, смотрим на метрики, думаем, где болит. Улучшаем так, чтобы пользоваться было не больно, а приятно — и чтобы это реально помогало людям.
И повторяем. Всё сначала — уже с новым сервисом. Снова находим идею, делаем прототип, показываем, собираем отзывы, выпускаем. И снова. И снова. И снова. Пока мир не закончится. Потому что всегда есть какие-то новые вызовы, с которыми нужно работать.
С кем делать платформу
Кто-то скажет: «Вов, чёрт побери, мне некогда — у меня Jenkins, Ansible, деплой в два часа ночи, всё горит! Ко мне постоянно приходят пользователи и что-то требуют! И вообще, что мне с этим делать?».
Даже с минимальными ресурсами можно построить базовую автоматизацию. На моей памяти мы делали это даже на Shell и Ansible и автоматизировали развёртывание стендов в любом количестве.
А что дальше? Когда у нас нет ресурсов, но есть прототип и метрики, мы дорисовываем сову, идём к начальнику и просим 500 рублей на скотч. Показываем метрики и говорим: «Вот как было, вот как стало. Давай делать». Никто не откажется от того, чтобы отдел разработки начал работать быстрее. Это дорогие специалисты, которые приносят много ценности. Если они работают лучше — блин, наконец-то.
Начинать можно с чего угодно. Главное — начать. И показать, что это работает.
Что почитать:
CNCF Platform Whitepaper — что такое платформа, зачем она нужна и как она вписывается в экосистему.
DevOps Topologies — тот самый one-pager про модели взаимодействия Dev и Ops. Очень рекомендую про него почитать.
Team Topologies — сайт книги и подхода. Про стрим-алайн, платформенные и enabling-команды.
CNCF Platform Maturity Model — модель зрелости платформ, чтобы понять, где вы сейчас и куда можно расти.
Platform Strategy (книга) — для тех, кто не боится архитектуры и хочет разобраться в стратегиях построения платформ и понять, как делать классно.
Бесконечность — не предел
Путь к платформе никогда не будет простым, и не в последнюю очередь потому, что нужно менять подход в голове и начинать работать по-другому. Но даже когда у нас есть самый минимальный набор — Jenkins, Ansible, Shell-скрипты и много кофе, — мы уже можем кому-то помочь.
Мы завтра придём на работу: кто-то будет смотреть доклады, кто-то тушить пожары, кто-то делиться с коллегами результатами конференции. А я вас призываю посмотреть, что болит у ваших клиентов, и улучшить самое простое, самое быстрое, что можно сделать.
На недельку выделите хотя бы 20% своего времени, где-то подвиньте дедлайны — ничего страшного, никто вас не съест. Коллеги точно скажут спасибо. Станут работать лучше и чуть-чуть быстрее, а у вас через какое-то время появится больше интересных задач.
Скрытый текст
А чтобы узнать еще больше интересного, приглашаем вас на IT-конференцию TeamLead++ 2025, которая пройдет в ноябре! Программа конференции построена так, что каждый участник сможет найти лекарство от своей боли — и тимлид небольшого стартапа, и опытный CTO крупной компании. Такая концентрация тимлидского опыта на человеко-час и квадратный метр бывает в Москве только один раз в год. Не пропустите!