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

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

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

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

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

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

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

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

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

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

Сделать работу эксплуатации прозрачной на общих досках канбан

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

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

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

Заключение