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

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

Из примеров компаний Etsy и Target мы видим, как значительно архитектура и проектирование организационной структуры могут улучшить результаты. Неправильно примененный закон Конвея приведет к тому, что компания получит плохие результаты, не обретя безопасность и гибкость. При правильном применении организация даст возможность разработчикам независимо и бесстрашно разрабатывать, тестировать и развертывать продукт для клиента.

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

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

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

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

Фаррел подумал, что наилучший способ решения этой проблемы — добавление знаний и навыков сотрудников отдела эксплуатации к знаниям разработчиков. Он отметил: «Когда у команд разработчиков были проблемы с тестированием или развертыванием, они нуждались в чем-то большем, чем просто технологии или окружение. Им нужны были помощь и наставничество. Сначала мы добавили специалистов по эксплуатации и архитекторов в каждую команду разработчиков, но у нас просто было недостаточно инженеров, чтобы охватить все команды. Мы смогли помочь разработчикам, применив то, что мы назвали “контакт с отделом эксплуатации”, привлекая даже меньше людей».

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

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

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

Фаррел отмечает благодаря этим изменениям увеличилась скорость выпуска новых релизов, а также улучшились рабочие отношения с отделом эксплуатации. Он заключает: «модель “контактов с эксплуатацией” позволила нам внедрить знания и навыки отдела эксплуатации в команды разработчиков продуктов без добавления нового персонала».

Преобразования DevOps в компании Big Fish Games показывают, как централизованная команда эксплуатации смогла добиться результатов, обычно ассоциирующихся с рыночно ориентированными командами. Мы можем использовать следующие три общие стратегические установки:

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

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

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

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

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