Всем доброе утро! С Вами Крылов Александр, и сегодня я расскажу Вам про занимательную магию сервисного подхода 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” - это набор процессов и программно-аппаратных средств в компании, преимущественно on-prem реализации, которые при правильном балансе способствуют уменьшению t2m для бизнес задач. Туда входят:

• организация и поддержки CI/CD инфраструктуры для развития и автоматизации продукта или системы;

• гибкие практики разработки, например, agile;

• инструменты замера метрик эффективности разработки;

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

• наличие процессов и фреймворков эффективного ведения разработки, вроде, kanban, dasa devops, devops maturity matrix и т.д.

• возможность построения задач подразделения DevOps, как услугу, а участников цикла разработки, как заказчика этой услуги, в качестве которой могут быть - поднятие контура, настройка CI/CD, реализация дашбордов мониторинга и т.д.

Сам по себе подход 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-досок или других подходящих инструментов), в который будут включены:

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

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

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

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

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

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

Второй этап - управляемое сопротивление.

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

После того, как мы переформулируем и внесем корректировки в slide desk, мы делаем повторную презентацию в тестовом формате. Важно: делаем это в тестовом формате на существующих или потенциальных сторонников, например со стороны лидов middle lvl management, которые помогут Вам с внедрением данного концепта. После проведения презентации, вы собираете обратную связь и вносите необходимое количество правок. И делаете большую презентацию на уровне компании. Почему так широко? Потому что, как правило, данное внедрение осуществляется на уровне компании, а не просто на примере небольшого подразделения,  ибо все участники цикла разработки должны начать жить по новому процессу, иначе это работать не будет.

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

Если всё “oк”, то мы переходим на следующий этап внедрения. Но, да, опять всё сразу “ок” - не бывает. Поэтому мы собираем то количество встреч, сколько нужно, пока озвученные решения не будут приняты или озвучены альтернативные. Эта работа проводится на всех тех, кому остаётся не понятна ценность данного внедрения. Если решение всё-таки находится, это круто. Если нет, всегда спрашиваем – “Есть ли предложения, кроме озвученных?”. Если нет, то мы можем пойти по пути получения поддержки от топ-менеджмента через Top**-**down решение. Если на данном этапе руководство предпочитает по каким-то причинам не подключаться, а решает делегировать решение вопроса на ваши плечи, то поступаем следующим образом -  собираем встречи, пока не будет получено решение от последних членов сопротивления. Причём то количество раз, сколько потребуется. Если решения найдены и предложения озвучены -  всё прекрасно. Если нет, то уже делаем очередную эскалацию, то количество раз, которое необходимо для итогового принятия решения для всех участников. Если есть какие-то дополнительные предложения на предыдущей развилке, то мы их обсуждаем, выявляем самые здравые и запускаем в проработку. Это так же важно, предложения от коллег нужно слышать и слушать.

Следующий этап - внедрение.

И начнём мы этап со снятия дополнительной обратной связи по обучению команд. Составляем список тем, отбираем темы для общей площадки обучения и для точечного обучения, далее, при необходимости, создаём общую площадку обучения и назначаем проведение необходимого количества обучений. Там, где это необходимо, выполняем реализацию необходимой автоматизации, чтобы упростить жизнь себе и коллегам, что поможет сгладить внедрение, либо на переходный период, либо на постоянной основе. Безусловно, подобные манипуляции нужно осуществлять с точки зрения здравого смысла. Следующим шагом будет создание отчёта замера статистики проблем. Это может быть RSA (root cost analysis) или спринтовые ретро для разбора проблем, оба варианта рабочие. Далее, перенос того, что не попало в отчёт jira. Напомню, что это может быть часть активности, которая присутствует в Messenger-ах, переносим всё, что необходимо в jira. Следующим этапом обсуждение дополнительных изменений, если они нужны. Это важный этап, поэтому не пропускаем его. Т.к. идёт период внедрения, снимать обратную связь нужно, и это одна из тех точек, где это сделать крайне необходимо, т.к. к этому моменту уже будет какая-то картина от внедрения и, возможно, могут потребоваться напильник и корректировки.

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

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

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

Заключительный этап внедрения: обратная связь.

Начинаем его с того, что ставим отчёт замера проблем итеративно. Например, раз в sprint, релиз, инкремент посредством всё того же RCA.  В нашем случае –это 3-хнедельные sprint-ы. Далее наблюдаем за динамикой, делаем отчёт раз в выбранный квант времени. Собираем и делаем статистику за более продолжительный срок, например, раз в квартал, чтобы видеть всю динамику спринтов. Ну и смотрим в динамике, что и как “стреляет”, и как сделать так, чтобы оно перестало “стрелять”.

В последующих статьях, мы рассмотрим более подробное решение ранее описанных проблем.

А на сегодня всё, с Вами был Крылов Александр, до новых встреч.