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

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

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

При этом деятельность не только становится прозрачной: ею можно управлять, чтобы она как можно быстрее передвинулась с левого края к правому. Больше того, можно измерить время выполнения, то есть время, за которое карточка, попав на доску, перешла в колонку «сделано».

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

Рис. 6. Пример доски канбан, охватывающей формулирование требований, разработку, тестирование, подготовку к производству и позицию «в производстве» (источник: Дэвид Андерсен и Доминика Деграндис, учебные материалы для бизнес-тренинга Kanban for ITOps, 2012)

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

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

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

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

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

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

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

Скажем, можно установить лимит НзП на тестирование в три карточки. И если в тестовой колонке уже есть три карточки, то нельзя добавить еще одну, пока одна из имеющихся не будет завершена или пока карточка не будет удалена из колонки «выполнение» и помещена обратно в очередь (то есть вернется в самую левую колонку). Никакую деятельность нельзя начать выполнять, пока на столе не появится карточка с задачей. Именно это гарантирует, что можно видеть все.

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

Ограничение НзП также облегчает обнаружение проблем, препятствующих завершению [25]. Например, установив такое ограничение, мы обнаруживаем, что в данный момент нам нечего делать, поскольку мы ждем, что финальную точку поставит кто-то другой. Хотя на первый взгляд кажется заманчивым начать делать нечто новое (действуя по принципу «лучше хоть что-то, чем безделье»), гораздо полезнее понять, что именно приводит к задержкам, и помочь решить эту проблему. Дурная многозадачность зачастую появляется, когда инженеров назначают сразу на несколько проектов, в результате чего возникают проблемы с определением приоритетов.

Другими словами, как язвительно заметил Дэвид Андерсен, автор книги Kanban: Successful Evolutionary Change for Your Technology Business, «заканчивайте начинать, начинайте заканчивать».