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

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

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

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

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

В качестве примеров неэффективного контроля качества можно привести следующие ситуации:

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

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

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

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

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

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

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

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

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