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

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

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

• «Две недели назад мы обнаружили слепое пятно, которое не отслеживалось системой мониторинга, и пришли к согласию, как это исправить. Наше решение заработало. В прошлый вторник у нас произошел сбой, но мы быстро обнаружили его и исправили еще до того, как он затронул клиентов».

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

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

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

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

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

Однако мы должны напомнить, что улучшение повседневной работы важнее, чем работа сама по себе, и что все команды должны иметь выделенные ресурсы (например, резервирование 20 % всего времени на улучшение работы, для чего нужно запланировать выделение одного дня в неделю или одной недели в месяц и так далее). Без этого продуктивность команды будет почти наверняка значительно снижаться под давлением собственного технического долга.

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

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

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

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

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

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

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