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

Рис. 24. Репозиторий кода Blackboard Learn с использованием Building Blocks (источник: DOES14 — David Ashman — Blackboard Learn — Keep Your Head in the Clouds, видео на YouTube, 30:43, размещено 28 октября 2014 г. оргкомитетом конференции DevOps Enterprise Summit 2014, https://www.youtube.com/watch?v=SSmixnMpsI4)

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

Когда Building Blocks стал доступен разработчикам, размер репозитория монолитного исходного кода начал уменьшаться (измеренный в количестве строк кода). Эшман пояснил: это происходило потому, что разработчики перемещали код в репозиторий исходного кода модулей Building Blocks. «Фактически, — сообщил Эшман, — каждому разработчику, которому предоставлена возможность выбора, хотелось бы работать в базе кода Building Blocks, где они могли бы работать с большей автономностью, свободой и безопасностью».

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

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

Архитектура, в рамках которой работают наши сервисы, в значительной степени диктует то, как мы будем тестировать и развертывать наш код. Это было подтверждено в докладе 2015 State of DevOps Report компании Puppet Labs, показавшем, что архитектура — один из лучших инструментов предсказания производительности инженеров, работающих в ее рамках и того, насколько быстро и безопасно можно производить изменения.

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

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

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

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

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

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

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

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

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

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

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

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

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

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