Магия сервисного подхода в DevOps as a Service. Двигаем культуру коммуникации в компании

Всем доброе утро! С Вами Крылов Александр, и сегодня я расскажу Вам про занимательную магию сервисного подхода DevOps, или как можно двигать культуру коммуникации в компании.

Немного расскажу о себе

Уже более 12 лет в ИТ и более 6 лет в руководстве. Имею разносторонний опыт работы с командами разной численности: от небольших подразделений в 3-4 человека до крупных проектных команд более 20 человек, состоящих как из внутренних, так и внешних сотрудников. Весь этот опыт помогает мне решать поставленные задачи, об одной из которых я Вам сейчас и расскажу. В текущий момент времени я являюсь Team Lead DevOps в компании Bimeister.

Вопросы и аудитория

Прежде чем начинать рассказ, следует ответить на вопрос, чем внедрение “DevOps as service” может быть полезно для компании? Какую пользу это внедрение может принести? И что так же не маловажно – кому это будет полезно?

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

• DEV – от мало до велика;

• QA – все виды представителей данного направления;

• Поддержка – или внедрение. В разных компаниях эти подразделения могут называться по разному, суть в том, что это те, кто либо поддерживает промышленный контур, то есть OPS, либо те, кто работает с контурами заказчика при развёртывании новой версии продукта/ПО;

• Архитектура – важно, представители архитектуры всегда заинтересованы в том, чтобы разрабатываемый продукт и процесс его разработки были прозрачны на всех этапах его ЖЦ;

• Product owner – понимание расходования ресурсов и быстрого выявления и устранения различного рода проблем, безусловно, важно;

• Lead (back, front, QA, etc) – лиды всех направлений участников цикла разработки любят, когда всё хорошо и прозрачно, поэтому избыточным будет дополнять данный пункт пояснениями.

Исходные данные и обозначение проблем

Находясь в компании Bimeister, которая достаточно быстро росла, но при этом не все процессы росли вместе с ней так же быстро, стало ясно, что культуру взаимодействия между участниками цикла разработки необходимо менять. Об этом и пойдёт речь. Прежде всего я подсвечу набор проблем, с которыми мы столкнулись. Это будет для нас AS-IS, далее опишу, что представляет из себя подход “DevOps as a service”, исходя из личного опыта. После чего мы перейдём к фактическим вариантам решения обозначенных проблем. А завершим всё подведением итогов. Итак, начнём.

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

Какие же это были проблемы?

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

• Пожар в инфраструктуре CI/CD. Предпосылок для этого было много, рост компании и продукта были быстрыми. Поэтому какие-то проблемы могли выпадать из фокуса, но, нужно отдать должное, всё было не так плохо, как могло бы быть. Определенную роль сыграло и отсутствие ресурсного планирования. Результат не заставил себя ждать, появился неконтролируемый прирост утилизации ресурсов серверов, находящихся на ферме, вследствие чего стали появляться различного рода проблемы инфраструктуры.

• Хаотичное ведение задач через чат. Данная проблема, по опыту, присутствует во многих компаниях, особенно там, где нет интеграции и процесса по концепту ChatOps, который подразумевает возможность управления инфраструктурой через чаты мессенджеров. При подходе так же возможно: заводить таски в тикетные системы, создавать алёрты и дополнительные нотификации в чаты и т.д. В принципе, здесь было тоже самое, то есть, процесса не было, плюс команды привыкли к мелким консультациям из чатов, которые, в совокупности, могли насчитывать большое количество времени. Таким образом мог пройти целый рабочий день, когда выделенный человек из подразделения, де факто дежурный, занимался чатом. Что он делал? Осуществлял небольшие консультации, решал различного рода проблемы, помогал тем, кто не мог решить вопрос самостоятельно. При этом активности нигде не фиксировались, а потому не было понятно сколько реально времени уходит на разбор вопросов из чата. Так же важно отметить, что у большинства подразделений в культуре своей коммуникации, полностью отсутствовала практика заведения задач по проблемам и трека времени в них. И тут мы плавно переходим к следующей проблеме.

• Порядка 60% активности подразделения DevOps поступает через мессенджеры. И это проблема серьезная. Поскольку большая часть активности идёт вне тикетной системы, в нашем случае jira, нет понимания полного объема бэклога подразделения. Присутствует большая воронка входящих обращений, которые даже не всегда возможно систематизировать. Да, были попытки вести активность чата посредством RCA (root cost analysis), но это, конечно, плохая история. Выгрузка из чата и последующий парсинг проблем по ключевым словам, даже если это делается автоматизировано, требует не мало времени, которое можно было бы потратить более рациональным образом.

• Нет понимания направлений развития сотрудников, отсутствие ИПР. Эта проблема связана с отсутствием понимания возможных вариантов развития сотрудников как на краткосрочный период, так и долгий – квартал, год и более. Отсутствие индивидуальных планов развития каждого сотрудника подразделения порождает либо полное отсутствие развития, либо бесконтрольное и хаотичное развитие как каждого сотрудника персонально, так и подразделения в целом.

• Отсутствие процесса внедрения и фильтрации технологий (разработка, инфраструктура, CI/CD). Фактически процесс внедрения новых технологий в инфраструктуру отсутствовал. Кто первый вставал, того и были тапки.

• Нет процесса работы с бэклогом и сквозной приоритизации. Как следствие выше описанных проблем.

• Смещение фокуса с развития на поддержку.

Теперь давайте попробуем дать определение, что же обозначает подход “DevOps as a service”.

Сам по себе подход DevOps as a service, или DaaS, достаточно широко распространён уже порядка 5 лет. Пожалуй, сошлюсь на упоминания его в статье “2018 in review: State of DevOps adoption”, когда он был представлен с первой версией Dora capabilities.

Так же стоит упомянуть статью “DevOps as a Service or Do You Really Need a DevOps Team” авторства Julia Matyunina от 08/20/2020, где уже более подробно идёт разбор данного подхода до атомов. Начиная от принципов DevOps, заканчивая причинами использования подхода.

Разумеется, подход используется далеко не всеми компаниями, поскольку не всем подходит, например, по причине особенностей орг структуры, когда единой службы DevOps нет, а инженеры принадлежат точечно командам или проектам. Там же, где он подходит, он становится удобным механизмом взаимодействия всех участников цикла разработки. Давайте попытаемся дать определение данному концепту через принципы, которые были апробированы личным опытом.

1 принцип. Служба, она же “service DevOps”, превращается в некую сервисную службу, принципами которой является выполнения неких работ или “услуг” “под ключ”. Причём понятных работ, результат которых возможно оценить или измерить. Например, есть некая автоматизация с использованием одной из следующих технологий - shell, python, ansible, helm, и есть понятный результат этой автоматизации:

• автоматизация рутинных задач;

• очистка места файлов старше определённого срока;

• проверка монтирования шар;

• ротация логов и т.д. 

2 принцип. Подразделение DevOps представляет из себя сервисную службу.

Помимо выполнения задач “под ключ”,  есть понятный дизайн задач в части того, как всё происходит. А именно использование:

• best practice разработки;

• Cost менеджмент с точки зрения аллокации ч/ч на ту или иную задачу;

• списание, контроль и ревью времени всего подразделения;

• непрерывный обмен опытом между участниками подразделения;

• консультирование участников сторонних команд;

• практик безопасности;

• практики CI/CD/CT и прочих;

• проактивный мониторинг;

• контроль активностей подразделений, посредством использования различной отчётности;

• активная коммуникация;

• и т.д.

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

• привлечение людей на проекты в виде аллокации;

• аллокация на вид работ по какой-то системе;

• использование конкретной работы “под ключ”.

3 принцип – понятная услуга = понятный результат.

При этом есть чёткое понимание используемой для выполнения этой самой “услуги” технологии и её результат. Например, нам необходим тестовый контур. Для того чтобы реализовать “услугу”, нужно сделать какие-то шаги:

• узнать, с каким количеством ресурсов должен быть развёрнут контур или по аналогии с каким контуром;

• посмотреть, есть ли ресурсы под его развёртывание;

• развернуть его (по кнопке из пайпа, либо вручную);

• настроить для него deploy;

• настроить мониторинг и алёртинг, если это необходимо;

• настроить бэкапы, если это необходимо;

• выдать права на контур заказчику и группе лиц.

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

4 принцип - Контроль за качеством (MTTD, MTTR, MTTF)

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

• время на развёртывание;

• количество коммитов кода на спринт;

• время обнаружения проблем;

• частота развёртываний;

• время сборки;

• частота сборок в релизной ветке.

5 принцип. Сквозной приоритет задач.

Этот принцип не всегда называют, но, исходя из личного опыта, я решил его добавить. Потому как наличие сквозного приоритета задач – это удобный инструмент планирования. У вас всегда есть понимание, особенно при больших объемах задач, например, более сотни, в какой очерёдности, с каким приоритетом, и что мы делаем на перспективу недели, месяца, квартала и т.д.

6 принцип. Прозрачность процессов разработки на всех этапах.

Думаю, что здесь будет излишним  что-либо говорить. Лишь добавлю, что должен присутствовать некий Flow, на основе которого происходит взаимодействие всех участников цикла разработки.

Этапы внедрения “DevOps as a Service”

Давайте попробуем привести пример этапов внедрения данного подхода. Рассмотрим, как на примере компании Bimeister, проходило внедрение. Внедрение состояло из 4 этапов, давайте разберём каждый из них.

Начнём с первого  этапа, который называется - Презентация.

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

Если есть проблемы, то у них должно быть решение, которое нам и предстоит найти, используя известные фреймфорки, личный опыт, советы коллег с конференций, дополнительную литературу. На основе найденных решений, следует составить slide desk (в виде презентации, miro-досок или других подходящих инструментов), в который будут включены:

• описание текущих проблем;

• способы и сроки их решения;

• этапы решения проблем в виде флоу или древовидной структуры;

• какие, чьи и в каком объёме  ресурсы потребуются для внедрения.

Презентуем это руководству, и, если необходимо, вносим правки то количество раз, которое потребуется