Руководство по DevOps. Как добиться гибкости, надежности и безопасности мирового уровня в технологических компаниях

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

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

Уменьшить количество случаев передачи работы

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

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

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

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

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

Постоянно выявлять затруднения и стремиться их разрешать

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

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

• обнаружить затруднения в работе системы;

• определить, что следует улучшить в месте затруднения;

• подчинить все остальные задачи решению проблемы;