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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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