Книга: Руководство по DevOps

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

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

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

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

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

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

• сделать ограничения, накладываемые проблемой, более мягкими;

• если предыдущие шаги оказались неудачными — возвратиться к первому шагу, но не позволять бездеятельности нарушить всю систему.

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

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

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

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

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

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

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

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

Оглавление книги