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

Видеть проблемы сразу после появления

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

Мы можем сделать это, создав петли обратной и прямой связи в системе работы. Доктор Питер Сенге в книге «Пятая дисциплина. Искусство и практика самообучающейся организации»[31] описал петли обратной связи как чрезвычайно важную часть процесса обучения мышлению в категориях организаций и систем. Петли обратной и прямой связи дают возможность компонентам системы взаимно усиливать или нейтрализовать друг друга.

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

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

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

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

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

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

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

Как сказала Элизабет Хендрисон, технический директор компании Pivotal Software и автор книги Explore It!: Reduce Risk and Increase Confidence with Exploratory Testing, «когда я возглавляла подразделение тестирования, я описывала свою работу как “создание циклов обратной связи”. Обратная связь — важнейший фактор, поскольку она позволяет управлять разработкой. Мы должны постоянно сверять нужды клиентов с нашими стремлениями и тем, что у нас получается. Тестирование — это лишь одна из форм обратной связи».

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