Джин Ким - Руководство по DevOps

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

• владелец продукта. Представитель компании, определяющий набор функциональности в следующей версии продукта;

• разработчики. Команда, ответственная за разработку функциональности продукта;

• служба качества. Команда, ответственная за работу петель обратной связи и обеспечивающая, чтобы продукт функционировал так, как задумано;

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

• отдел информационной безопасности. Команда, отвечающая за обеспечение безопасности систем и данных;

• менеджеры релиза. Специалисты, ответственные за управление и координацию развертывания в производство и процессы релиза;

• технические руководители или менеджеры потока создания ценности. В литературе, посвященной бережливому производству, так называют тех, кто «обеспечивает соответствие потока создания ценности требованиям клиента на всех этапах процесса».

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

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

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

Деймон Эдвардс, соведущий подкаста DevOps Cafе, отмечал: «По моему опыту, упражнения по составлению карт потоков создания ценности всегда открывают людям глаза. Нередко они при этом впервые обращают внимание, как много надо сделать и насколько чрезмерные усилия приложить, чтобы доставить продукт клиенту. Может оказаться, что отдел эксплуатации в первый раз видит последствия того, что разработчики не имеют доступа к правильно настроенной среде, и это создает еще более сумасшедшие условия во время развертывания кода. Отдел разработки может впервые увидеть, какие чудовищные усилия приходится прикладывать тестировщикам и отделу эксплуатации для развертывания их кода в производстве: им приходится еще долго заниматься им после того, как некоторая функция помечена флажком “выполнено”».

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

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

• Места, где производятся повторная работа или переделка либо возникает потребность в них.

На первом этапе документирования потока создания ценности должны рассматриваться только блоки высокого уровня. Обычно даже для сложных потоков создания ценности группы могут сформировать схему с числом блоков от 5 до 15 в течение нескольких часов. Каждый блок процесса должен включать в себя время выполнения заказа и время производства элемента, над которым ведется работа, а также показатель %C/A, измеренный на уровне конечных клиентов [45].

Мы используем количественные показатели из карты потока создания ценности, чтобы верно направить усилия по улучшению потока. В компании Nordstrom, например, внимание было сосредоточено на низком показателе %C/A в форме запроса, отправляемого менеджерами без указания табельного номера. В других случаях это может быть длительное время выполнения заказа или низкое значение %C/A при предоставлении командам разработчиков правильно настроенных тестовых сред. Или это может быть связано с длительным периодом выполнения регрессионного тестирования перед релизом новой версии программного обеспечения.

Рис. 10. Пример карты потока создания ценности (источник: Humble, Molesky, and O’Reilly, Lean Enterprise, 139)

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

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

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