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

Продолжайте, улучшая качество кода

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

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

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

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

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

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

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

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

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

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

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

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