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

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

Одна из ежедневных процедур у разработчиков, популяризованная Scrum, — это ежедневное собрание, короткая встреча. На нее собирается вся команда, и до всеобщего сведения доводятся три вещи: что было сделано вчера, что будет сделано сегодня, что мешает завершить работу [61].

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

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

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

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

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

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

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

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