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

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

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

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

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

• каковы новые функциональные возможности продукта и почему мы создаем его;

• каковы принципы его действия — в том, что касается работоспособности, масштабируемости и наблюдаемости (схематическое отображение настоятельно рекомендуется);

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

• имеются ли какие-либо отступления от ранее использовавшихся архитектур и методик и как они обосновываются;

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

• каковы планы запуска функций в производство.

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

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

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

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

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

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

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