Как IT-специалисту ввести культуру DevOps в своей компании

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

Продюсер курса «DevOps-инженер» в Нетологии Александр Зверев пообщался с Юрием Игнатовым, лидером направления инфраструктурных платформ Экспресс 42 и консультантом по адаптации DevOps-практик, который дал практические советы, как IT-специалисту, готовому к развитию и усложнению задач, мотивировать руководителя на внедрение DevOps.

Юрий Игнатов

консультант по адаптации DevOps-практик в «Экспресс 42»

С чего начинать подготовку предложения

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

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

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

Важно обосновать, какие «боли» решает внедрение DevOps:

1. Скорость поставки изменений в продукте. Если у компании есть возможность быстро и легко проверять гипотезы по продукту или быстро реагировать на рыночные изменения, то это ее конкурентное преимущество.
2. Время отклика сайта/приложения или количество сбоев, которые увидели пользователи. У компании есть технические риски, которые касаются отказоустойчивости, скорости восстановления после сбоев, риски, связанные с безопасностью.
3. Исключая рутинную и повторяющуюся работу из процессов разработки и поставки, команда может сфокусироваться на развитии своих продуктов.

С какими трудностями можно столкнуться

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

Многие процессы и разграничение зон ответственности могут заработать «со скрипом». В этой ситуации может понадобиться специалист для фасилитации и контроля процессов.

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

Дополнительно потребуются ресурсы на обучение: новые практики и инструменты требуют освоения, не лишним будет посещение конференций/митапов по теме DevOps. Учитывайте, что вам и вашим коллегам придется больше отрываться от текущих рабочих задач, чтобы пройти онлайн-курс или мастер-класс, посмотреть записи докладов.

Как руководитель может отнестись к идее о внедрении DevOps

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

За последние 10 лет по теме внедрения DevOps накопилось много материалов, книг, докладов и исследований от разных представителей IT-индустрии. Стоит ознакомиться с кейсами известных компаний, как русских, так и зарубежных — многие охотно рассказывают о результатах своей DevOps-трансформации. Также полезно почитать книгу «Accelerate», которая основана на 4-летнем исследовании DevOps. И если руководителя не убедил опыт других компаний, то, возможно, его сдерживают факторы, которые не очевидны для инициатора DevOps-трансформации.

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

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

Что делать, если руководитель отнесся скептически к предложению о внедрении DevOps и отклонил его

Если вы проанализировали процессы поставки ПО в компании и убедились, что DevOps нужен, а руководитель против, то можно попробовать получить одобрение на изменения, которые затрагивают только техническую составляющую процессов разработки и поставки, это тоже может принести свои результаты. Лучше начинать не с инструментов, а с инженерных практик.

Одни из самых распространенных практик непрерывная поставка и инфраструктура как код. Какими инструментами вы это сделаете, не так важно. Например, автоматизированный повторяемый процесс развертывания продукта компании или создание тестовых стендов «по кнопке». И только после этого смотрите, что для этого можно использовать: какие компетенции и инструменты уже есть в команде, какие инструменты доступны в экосистеме вашего языка программирования и т.д.

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

Но если руководитель не оценит это, то результатами можно поделиться с корпоративным сообществом, например, другими командами разработки. Или с руководителем другого департамента, который оценит результаты, попробует повторить их в своем департаменте. Возможно, успешный опыт внедрения в соседнем отделе повлияет на мнение вашего руководителя.

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

Как произвести расчеты инвестиций, которые потребуются для внедрения DevOps

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

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

Кроме этих метрик, в компании есть часть работы, которую называют «Unnecessary work». Ее можно прикинуть в часах — сколько лишней работы делают сотрудники. К такой работе относится, например, ручное обновление серверов. Автоматизация этой работы сэкономит рабочее время сотрудников. В данном случае можно заранее прикинуть, что внедрение технологии сэкономит 10 часов работы в неделю для инженера. От этого времени прикидывается, сколько новых фич инженер сможет сделать за неделю в освободившееся время. Если собрать такие расчеты по всей компании, то получится, что отказ от внедрения DevOps приводит к упущенной выгоде.

Про возврат инвестиций в DevOps хорошо написано в работе «Forecasting The Value Of DevOps Transformations» от организации DORA. Здесь описаны формулы расчетов, даны таблицы со средними показателями, по которым крупная компания может рассчитать, какие могут быть изменения после ликвидации «Unnecessary work» с помощью DevOps.

Как сформировать команду по внедрению DevOps

Формирование выделенной DevOps-команды — антипаттерн. DevOps работает, если практики применяются всеми уже существующими у вас участниками создания и эксплуатации продуктов.

В современных технологичных компаниях выделяют несколько типов IT-команд:

• Stream-aligned-команда (продуктовая команда), которая нацелена на цепочку создания ценностей. Команда разрабатывает продукты и делает все для того, чтобы компания прямо или косвенно зарабатывала деньги.
• Platform team предоставляет сотрудникам продуктовых команд сервисы, необходимые для обеспечения процессов разработки, тестирования и эксплуатации. Это позволяет продуктовым командам не отвлекаться от создания ценности. Специалисты по платформе могут выступать консультантами и помощниками для продуктовых команд по вопросам применяемых инструментов, использованию сервисов облачных провайдеров и создают внутренние инструменты, полезные продуктовым командам.
• Enabling team — это команда экспертов по конкретным сферам, которые временно присоединяются к продуктовым командам и помогают им в формате менторства, анализа и решения технических задач. Enabling team дополняют продуктовые команды недостающими компетенциями.

О принципах формирования команд хорошо написано в книге «Team Topologies» а также на сайте DevOps Топологии. Другой вопрос, как из существующих продуктовых команд в компании выбрать ту, которая станет первопроходцем по внедрению DevOps практик.

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

Как сформировать стратегию реализации проекта по внедрению DevOps: этапы, задачи, цели бизнеса

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

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

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

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

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

Масштабирование DevOps на другие команды

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

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

На этапе масштабирования обычно сталкиваются с тем, что вводить изменения в 10 командах компании намного труднее, чем вести одну (пилотную) команду. Для этого нужны синхронизация и процессы контроля и управления изменениями. Это значит, что от инициатора внедрения подхода DevOps требуются отдельные управленческие компетенции.

В пилотную команду обычно идут самые инициативные ребята в компании. Но при масштабировании подхода DevOps на всех остальных часто выясняется, что не всем это нужно и интересно. Будьте честны, если вы можете сделать работу коллеги лучше — расскажите как это будет. Если нет, то расскажите, почему это важно для компании

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

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

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

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

Какие софт-скиллы нужны инициатору внедрения DevOps и как их развивать

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

Важно уделять внимание таким вещам, как взаимопомощь и эмпатия. Стремитесь понять, что важно коллегам, как им помочь сделать работу лучше, какие нюансы им нужно объяснить. В конце концов, все сотрудники компании — одна большая команда, где все свои.

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

В качестве аналогии можно привести практику разработки — code review, когда разработчик прежде, чем отправить изменения в продукте пользователям, показывает свою работу коллегам для конструктивной критики. В этом случае критика — это формат обучения. Критикующий должен стремиться помогать и дать совет, что поправить в работе, чтобы улучшить результат.

Еще один способ чему-то научиться и развить навык — это научить другого. Сделайте доклад, презентацию, исследование и выступите с этими материалам перед командой. И здесь важно вытаскивать людей на обсуждение, заставлять говорить, делиться мнением, вести дискуссию. Но делать это культурно — без оскорблений и переходов на личности.