Магия внедрения сервисного подхода DevOps. Часть 1. Развиваем культуру коммуникации и разработки в компании

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

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

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

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

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

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

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

Теперь давайте попробуем дать определение, что же обозначает подход “DevOps as a service”. На мой взгляд, подход “DevOps as a service” - это набор процессов и программно-аппаратных средств в компании, преимущественно on-prem реализации, которые при правильном балансе способствуют уменьшению t2m для бизнес задач. Туда входят:

Сам по себе подход 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 представляет из себя сервисную службу.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Теги

#devops #devops_услуги