Как построить DevOps в крупной компании, которая едет и не останавливается? Тимофей Нецветаев, руководитель отдела платформенных сервисов CDEK, расскажет, что они с командой инженеров делали в период с 2019 по 2023 год. Как всё трансформировали и как при этом изменилась компания.

CDEK 23 года занимается логистикой. Уже больше 1500000 клиентов. Все процессы очень быстрые! Поэтому возникла необходимость DevOps-трансформации. Требовалось ускорить time to market, уменьшить количество сбоев, сэкономить вычислительные ресурсы и улучшить поддержку разработки. Разработчики хотели быстрее разрабатывать и меньше страдать. Конечно, это можно сделать и без DevOps-методологии и культуры, но в CDEK решили, что так не интересно, не эффективно и медленно.

2019 год. Начало пути

Тимофей пришёл в компанию в 2019 году. Тогда был классический DevOps-отдел: восемь инженеров занимались базами, CI, инфраструктурой типа Rabbit. Тогда ребята только что отделились от ops’ов и чисто железной инфраструктуры, с виртуалкой, сетями и прочим.

Айтишная часть CDEK’а была классическим сервисным подразделением. Крупные департаменты приходили в IT, а IT, в свою очередь, обслуживали ERP-систему.

В ERP есть RM, WMS, финансы и куча других функций. То есть по факту IT обслуживали все процессы, происходящие в рамках CDEK.

CDEK работал так, что внутри ERP были продуктовые модули. То есть там был, например, склад, система отчётности для менеджеров продаж. Каждый из них по факту являлся отдельным продуктом. Запросы в них приходили либо через айтишку, заявки на фичи от лидеров данных функций, либо от владельцев продукта, которых тогда было ещё совсем мало.

Cаппорт и инфраструктура поддерживалась двумя командами: классическим DevOps-отделом и инфраструктурой. Разделение произошло по уровню ASI. Начали работать с DevOps. По факту был классический антипаттерн, который на сайте DevOps Apology можно описать как антипаттерн В. То есть выделили людей и сказали, что они теперь DevOps.

Задачи шли от разработчиков напрямую. То есть разработчик знал, чем конкретно этот инженер занимается, например, FTP’шником и шёл именно к нему, ставил задачу. Более организованные разработчики делали тикет в саппорт и делегировали задачу дальше на инженеров. Если с чем-то не справлялись или задача оказывалась не в зоне их ответственности, задачу отправляли в инфраструктуру.

С таким подходом были проблемы:

• Инженеры практически ничего не знали про контекст продуктов. К ним могли прийти из BI, со склада или с РНР-проектом, созревшим в команде маркетинга;

• При таких заходах через саппорт был долгий цикл релизов;

• Приходилось постоянно переключать контесты между дежурными;

• Разработчики ничего не знали объективно про инфраструктуру. Сколько это всё стоит, как работает, насколько плохо то или иное обновление сказалось на инфраструктуре — про это никто не думал.

В конце 2019 года были такие метрики:

• Семь инженеров в отделе;

• Двухнедельный релизный цикл, то есть классический регресс — в выходные катили все модули ERP-системы. Если возникала проблема, всё это всплывало во вторник, начинали искать, что пошло не так;

• Набегало суммарно 150 релизов в месяц с учётом хот фиксов и доработок;

• Было 28 критических инцидентов в месяц. Они могли касаться разных модулей ERP-системы.

2020 год. Функциональные микрокоманды

Когда начали думать, как лучше сделать саппорт, разработку и в целом работу с задачами, первое, что пришло в голову — разделиться по функциям.

DevOps-отдел поделили на отдельные функции. Разделились на четыре группы:

• DBA;

• Observability;

• Команда сервиса, заточенная на поддержку разработки. Они больше общаются с разработчиками, принимают больше тикетов, у них более активная система дежурств;

• TECH — зародыш платформенной команды. Ребята, которые работают с инфровыми сервисами, кубами, CI, системой деплоя.

В техкоманде были очень умные ребята, но их было мало — два-три человека. Была медленная скорость изменения и того, что они выпускают. Более того, с ними начали терять контакт. Они начали творить что-то клёвое, но никто не знал, что с этим делать.

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

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

Вся эта тема дала размышления, как дальше всё это развивать. На конец 2020 года уже были такие метрики:

• Сформировалось DBA направление из трёх человек. Сделали должности, грейды. DevOps’ов в контексте большого классического отдела было уже 15;

• Был двухнедельный релиз цикла;

• 250 релизов в месяц;

• 24 инцидента в месяц.

2021 год. Переход на Spotify-модель

В 2021 году в CDEK поменялось руководство в IT-кластере. Начали чаще собираться и думать, как преобразовать взаимодействие классического сервисного IT с бизнесом во что-то более интересное. К тому времени уже начали появляться идеи продуктовой модели, трансформации от бизнеса. Владельцы продуктов становились более заинтересованными в синергии с айтишниками. Айтишники становились более прошаренными.

Пришли новые ребята, сформировалась команда, многое поменялось. Появилась идея Spotify-модели:

Это модель, Scaled Agile Framework наподобие Less или Safe. Можно заменить трайбы на арты, и получится Safe. Есть трайбы: крупные образования, отвечающие за конкретное бизнесовое направление. Например, есть склад, но его не стали называть складом, а назвали командой. У команд есть владельцы. И самое интересное, здесь есть два образования: чаптеры и гильдии.

• Чаптер — это сборище одной профессии внутри трайба. Чаптер QA либо DevOps внутри одного трайба. У них может быть лид.

• Гильдия — это сообщество конкретной спецификации. Например, всех DevOps-инженеров или тех, кому DevOps интересен. Это горизонтальная структура в рамках всей иерархии.

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

Подготовка к трансформации

Возникла необходимость переделать поддержку всей этой истории. Был 2021 год, observability отдельно не взлетело, его запихали в техкоманду.

Команда сервиса превратилась в продакт DevOps, то есть это те DevOps’ы, которые находятся в командах разработки. Сделали платформу, взяли старую команду, переименовали её, немного изменили требования, но в целом сделали просто команду платформы.

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

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

Начали разделять инженеров по трайбам. В каждом было определённое количество инженеров:

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

Могли ли по-другому распределить инженеров? Первое, что приходит в голову: разделить инженеров по командам. Это простой и хороший паттерн, но инженеров на все команды может не хватить. Например, сейчас их в CDEK около 30. Более того, они разного размера. В определённых командах инженеры могут быть не загружены, а в других, наоборот, перегружены. Не получилось бы балансировать на эту тему.

Можно было разделить по продуктам. То есть 100 продуктов разделить на части и раздать каждому инженеру по своему набору. Но продукты могут быть разной размерности, сложности, бизнес критичности. У продуктов может быть своя специфика.

В итоге сделали разделение по трайбам, есть специфика продуктов. К примеру, логистика с сортировочными центрами, работающими в разных городах. У них есть мобильный курьер на IOS, на Андроид, система дозвона — робот-звонки. Есть парни, работающие с суперсетами и с другими штуками. У них много задач, связанных с данными. И есть маркетинг, у которого всё завязано вокруг веба, сайтов, облака, включая Казахстан, Китай. Они сильно отличаются в работе инженеров. Именно поэтому сделали разделение по трайбам, а не какое-либо другое.

Что получили в конце 2021 года?

Сначала рассказали всем про полезность, что будет продуктовый DevOps прямо в команде, и он будет помогать. Написали статьи, как это всё должно выглядеть, сделали схемки. Тимофей выступал на ряде внутренних митапов. Сформировали метрики и начали всё активно продавать. У Тимофея была помощь в лице руководства, потому что это сильно совпадало с продуктовой трансформацией компании, переходом CDEK из классической логистической компании в IT-продуктовую. Начали делать боевой пилот на пяти командах: раздали ребят по командам и собирали обратную связь.

Выделили нужные метрики, посмотрели, что прямо горит. Измеряли:

• Количество релизов;

• Скорость решения инцидентов и их количество;

• Покрытие алертами инфраструктуры и модулей самих разработчиков;

• Скорость решения задачи;

• Покрытие документацией.

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

• Пять продуктовых инженеров в пяти командах. Взяли для пилота самое простое: одна команда — один инженер;

• 350 релизов в месяц: убили двухнедельный релизный цикл с помощью команд разработки и тестирования. Сделать это только через DevOps инженеров было невозможно;

• Было 22 инцидента в месяц;

• Продуктовый подход в ряде команд: гипотезы, VP.

2022 год. Развитие концепции

В 2022 году начали активно развивать эту концепцию и закреплять результат. Пытались всё корректировать, понять, что работает, а что нет.

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

В 2019 году DevOps-отдел состоял из семи инженеров. На 2022 год уже было так:

Семь инженеров платформы, 12 инженеров в семи трайбах продакта и DBA’шники, которых тоже становилось больше. Не было такого, что один инженер — один трайб, так как размерности плавали. Появились лиды, и гильд-мастер отвечал за продакт DevOps.

Получается CDEK сделал паттерн Platform Ops:

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

В чём суть гильдии?

Гильдия — объединяет сообщество единых ребят. В CDEK есть гильдия тестировщиков, java разработчиков, DevOps’ов. Её суть заключается в:

• Проработке инициатив. Если кто-то хочет, например, чтобы все DevOps’ы начали отвязку от какой-то legasy-системы, то сначала обсуждается это на гильдии. Обговаривается в каких трайбах эта legasy-система используется, у кого будет больнее отвязываться, у кого нет;

• Решении общих проблем, то есть инженер трайб маркетинга может прийти с проблемой, остальные подскажут, может кто-то это уже решал;

• Контроле развития технологий;

• Развитии как инженерное сообщество. Все темы связанные с развитием, аттестациями, грейдами.

Кто кому подчиняется?

В идеале должен быть руководитель трайба. Он очень умный и отвечает за DevOps-инженеров. Но реальный вариант выглядит так:

Так как команда трансформировалась недавно, есть платформенная команда, ПМ, руководитель трайба, гильд-мастер. Все они что-то хотят от DevOps-инженера. Более того, сам Тимофей условный head of DevOps, когда все ходят к нему, так как ещё не перестроились. Но всё-таки в CDEK стараются переходить к тому, чтобы использовать структуру трайба. Чтобы у ПМ-ов в командах, обладающих продуктами, была привязка к разному количеству DevOps-инженеров.

Гильд-мастер и платформенную команду вообще вынесли за скобки, чтобы они работали с какими-то крупными инициативами только через руководителя трайба.

Если, например, есть задача обновить кучу сервисов на безопасность, то заводят мегаинициативу и сначала разговаривают с руководителем трайбов. В целом в таком контексте всё работает, но если штат на х5, и количество инженеров трайбов будет 10, придётся придумывать что-то другое. Если увеличить количество инженеров в командах, в трайбах, то возникнут проблемы, связанные с коммуникацией и подчинением.

Что получили в командах?

Когда в CDEK пропилотились, зафиксировались и раздали инженеров практически по всем трайбам, получили следующее:

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

• Разработка стала активнее работать с инфраструктурой, потому что есть DevOps-инженер, который при релизе скажет, если что-то пошло не так. Они вместе начинают это прорабатывать. Разработчик больше погружается в контекст инфраструктуры;

• Чтобы избавиться от поддержки, инженер придумывает автоматизации;

• Крупные задачи удобнее масштабируются на команды;

• Инженеры активнее растут по софт скиллам, нужно общаться с ПМ, с QA. Они находятся именно в бизнесовой команде.

Как развивают инженеров?

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

Есть должности, по определению из Гугла — это положение в штатной структуре, то, что пишут в трудовой. Можно называться DevSecOps Advocate, но в трудовой будет написано старший инженер автоматизации. Роль — это принадлежность к функциональной группе.

Есть матрица навыков:

Есть роли и грейды. Роль — продакт и платформа. Грейды — младший, старший. Получается, CDEK стремится, чтобы была некая школа роста в продакты, поскольку там задачи попроще. В продактах есть младший инженер, инженер и продакт-DevOps заканчивается на старшем. Старший уже может переходить в платформенную команду. При определённых условиях, у него есть такая возможность. Получается, с ростом грейда увеличились скиллы платформ DevOps’ов и увеличились софт скиллы, активно работает HR. Если инженер растёт вверх, у него должны расти софт скиллы. Если инженер — архитектор, он должен быть софтовым богом.

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

Какие проблемы бывают?

• Количество платформ-инженеров ограничено. Команда Тимофея — 8 человек, это какая-то сумма в бюджете. Платформенных инженеров — 20 человек.

• Рост требований пока не прозрачен. Продуктовый инженер сопровождает команду, аттестуется на старшего инженера. А потом — кубы, CI, Тераформ, Консул, и на него это всё сваливается.

• Непонятно, как сделать плавный рост компетенций. Как вырасти в платформенного инженера тем, кто делает только задачи команды? Вся эта история ещё дорабатывается.

Важен контроль

Поскольку DevOps можно делать по-разному, — сверху, снизу, сбоку, они выросли из одного отдела. Важно было сохранить собственный сильный технический центр. Не хотели, чтобы был большой технический дрифт, поэтому сделали практику стандартного технического радара.

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

Ещё в CDEK сделали RFC — request for change:

Это классическая согласовательная модель, когда любой инженер может прийти в платформенную команду с некой идеей. Например, кто-то хочет, чтобы для его команды был Terraforming для быстрого развертывания тестовых средств. Это всё согласовывают, прорабатывают, проводят ревью и только потом внедряют данную технологию.

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

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

Примерно за полгода создали 40 RFC, из них принято 15, а отклонено 25. Изменений и реальных внедрений технологий было больше. Кто-то к кому-то сходил, договорился, поднял на тесте, а тест потом стал продом. Но сейчас возникли проблемы:

• Инициаторы создают мало RFC;

• Изменения сложно контролировать «вручную»;

• Бывает, что у команды Platform что-то горит, есть другие дела и они долго согласовывают всё это.

Этот механизм не нравится CDEK’у, его планируют улучшать. Для тех, кто хочет контролировать именно то, что делают инженеры с точки зрения развития технологий — такой механизм в целом неплохой.

Итоги в цифрах

Изменения, происходящие в компании, не могут происходить только за счёт DevOps-инженеров. Это должно идти параллельно с развитием самой компании. В CDEK, параллельно с темой DevOps занимались развитием автотестов и инцидентов менеджмента, потому что это были боли компании. Так или иначе, это повлияло на метрики.

Общее количество релизов на 1 квартал 2023 года — 700 в месяц. В CDEK релизят в любое время: ночью или днём. Команда сама выбирает время релиза. Синий график — это двухнедельный релизный цикл. Красный график — это технологические окна, когда все могут релизиться с 9 до 11. CDEK оставили некоторое количество технологических окон для особо критичных сервисов.

Про инциденты. Если бы не прошлый год, то всё было бы хорошо. Пика на графике — это когда CDEK DD-осили и пытались убить. Но они всё отлично преодолели. В среднем за 1 квартал 2023 случается 5 инцидентов в месяц. Конечно, здесь было много внедрений, улучшений. Во многом повлияло то, что сделали инженеров в командах, появилась связь между инженером и разработчиком, инженер понимает контекст команды.

Circle time разработки сейчас в среднем — 14 дней на фичу.

В CDEK анализируют, смотрят все команды и работают с антитопом. Если кто-то выбивается, например, среднее — 14, а у кого-то — 56, то выясняют причины, почему так.

На конец 2022 года в CDEK стало: 5 DBA, 7 платформенных инженеров и 14 DevOps’ов. Суммарно разработчиков в компании 200-250 человек.

Если вспомнить, какие проблемы стояли перед командой CDEK в начале статьи, то в итоге вышло следующее:

• Ускорили выпуск продуктов;

• Есть поддержка разработки;

• Снизили количество сбоев.

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

Сейчас каждый трайб бюджетируется отдельно по инфраструктуре, нанимает инженеров по своим потребностям. Все хотят в инвентаризацию, потому что увидели, сколько это стоит. Был проведен мониторинг. Когда раньше человек приходил и говорил, что нужен сайт, 8 ЦПУ, 32 РАМа и место 5 терабайт, он не знал, сколько это стоит. Сейчас знает, потому что это падает в его бюджет. Теперь он сравнивает потребности с балансом и работает над оптимизацией ресурсов.

В дальнейшем в CDEK хотят создать динамическую инфраструктуру под каждый трайб. Чтобы затраты на все операции были прозрачными. И были отдельные дашборды по затратам и объемам инфраструктуры под каждый трайб.

Итого: как развить идею

1. Понять, хотите ли вы залезать во всю эту историю. Time line показывает, что это дело не быстрое;

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

3. Работайте с энтузиастами. Когда Тимофей начал это делать, сразу появились ребята, которым было интересно;

4. Покажите ценность идеи;

5. Выработайте нужные метрики;

6. Развивайте успешные кейсы;

7. Сразу корректируйте проблемы;

8. Масштабируйте успех, как только закрепили результат;

9. Работайте с обратной связью и улучшайтесь.

Вот весь цикл, который был в CDEK по факту, включая перевод по документам и балансировку мощностей:

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

Если рассуждать на тему получилось ли у CDEK к 2023 году решить проблемы, которые ставились вначале пути, то да, получилось. Однако теперь получили другие проблемы, которые тоже нужно сейчас решать:

• Неочевидный путь роста инженера в компании;

• Слабый контроль технологий;

• Не все трайбы хорошо рулят инженерами;

• Смешанные зоны ответственности — platform/product;

• Много саппорта у продакт-DevOps.

Эти проблемы получили вследствие трансформации. Их нужно проработать, доработать, убрать косяки. CDEK в этом плане не стоят на месте и впереди много всего интересного. Заняло это всё 3-4 года, но это нормально, так как в крупных компаниях, в интерпрайзе масштабные изменения делаются долго.

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

• Помните о своих целях;

• Не бойтесь экспериментировать;

• Измеряйте результат;

• Работайте с людьми.