Текстовый курс по DevOps

Как наладить поток работы в DevOps?

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

Определите миссию преобразований DevOps

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

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

Вот примеры формулировок миссии для начала преобразований DevOps:

• За 3 месяца сократить на 75% среднее время от внесения кода до его запуска в рабочей среде.
• За 6 месяцев сократить на 33% среднее время от поступления запроса до запуска в рабочей среде.
• За 12 месяцев сократить на 50% число инцидентов в рабочей среде.

Что такое поток создания ценности и кто в нём участвует?

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

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

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

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

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

По возможности устраняйте передачи работы, ограничения и потери

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

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

Преодолеть эти проблемы помогут следующие шаги:

• Пересмотрите, сколько времени занимает каждая передача работы. Например, на карте выше успешно протестированный код ждёт 80 часов, прежде чем его забирает команда развёртывания. Почему так происходит? Можно ли автоматизировать процесс? Конечно, можно.
• Устраняйте потери, вызванные повторными передачами работы. На карте выше команда тестирования возвращает 65% функций разработчикам. Исправления некоторых дефектов приходится поставлять до 3 раз, прежде чем тестировщики их примут. Можно ли ускорить эти итерации, улучшив взаимодействие разработки и тестирования? Большое число дефектов также говорит о проблемах в работе команды разработки. Причины этих проблем с качеством нужно выявить и устранить.
• Пересматривайте передачи работы и по возможности устраняйте их. На карте выше после уточнения запроса проходит 320 часов, прежде чем его рассмотрит ответственный за согласование. Зачем вашей организации такой согласующий? Какую пользу он приносит потоку создания ценности? Достаточно ли у него информации и понимания ситуации, чтобы принять взвешенное решение? Почему бы не включить его в команду, уточняющую запросы? Тогда он будет гораздо лучше понимать, что согласовывает, а в процессе станет на одну передачу работы продолжительностью 320 часов меньше. Пока ограничения и барьеры замедляют поток, многого от DevOps ждать не стоит.

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

Сделайте поток работы видимым для всех

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

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

Ограничивайте размер пакетов и объём незавершённой работы

Исследование, проведённое в Stanford University , показало, что выполнять несколько задач одновременно менее продуктивно, чем заниматься ими по очереди. Исследователи также выяснили, что людям, которых регулярно перегружают несколькими потоками цифровой информации, труднее концентрироваться, вспоминать сведения и переключаться между задачами, чем тем, кто выполняет их по одной.

Что это значит для вашей команды DevOps? Сокращайте объём незавершённой работы и ограничивайте размер пакетов поставляемого кода. Например, в разработке одновременно может быть не более 6 задач, чтобы участникам не приходилось постоянно переключаться и они могли сосредоточиться на текущей работе. Другой вариант — оценивать задачи в баллах по числам Фибоначчи (0, 1, 2, 3, 5, 8, 13, 21, 34, …), а команда DevOps за заданный период (спринт) выполняет работу в пределах определённого числа баллов, отражающего её скорость.

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

Тратьте 20% времени на сокращение технического долга

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

ВЫВОДЫ

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