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

Рис. 7. Симуляция «игры в письма» (сложить, вложить, заклеить, проштамповать) (источник: Стефан Люйтен, запись «Поток с единичным размером партии: почему массовое производство — не самый эффективный способ что-то сделать» в блоге Medium.comот 8 августа 2014 г., Medium.com/@stefanluyten/single-piece-flow-5d2c2bec845b#.9°7sn74ns)

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

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

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

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

В своем блоге Startup Lessons Learned Эрик Райс утверждает: «Размер партии — это количество продукции, передающееся как единое целое с одного этапа на другой в ходе процесса разработки (или DevOps). В случае программного обеспечения самый простой вариант видимого пакета — код. Каждый раз, когда инженер загружает написанный код в систему контроля версий, создается партия определенного объема. Существует множество методов контроля за этими партиями, начиная от крошечных пакетов, необходимых для непрерывного развертывания, до более традиционных методов разработки на основе ветвления кода, когда весь код, написанный многими разработчиками, увязывается в один пакет и из него составляют единое целое».

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

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

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

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