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

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

Часть IV. Второй путь: методики обратной связи

Введение

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

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

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

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

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

• создание системы измерения показателей, позволяющей фиксировать и решать проблемы;

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

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

• создание системы обратной связи, чтобы разработка и IT-эксплуатация могли безопасно осуществлять внедрение продукта;

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

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

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

Глава 14. Создайте телеметрию, позволяющую замечать проблемы и решать их

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

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