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

Сопоставьте этот подход с более традиционным, где команды разработчиков и тестировщиков назначаются на проект, а затем перебрасываются на другой сразу после завершения первого проекта и прекращения его финансирования. Это приводит к различного рода нежелательным результатам, включая то, что разработчики не могут увидеть долгосрочные последствия принятых решений (форма обратной связи), и такую модель финансирования, где учитываются и оплачиваются расходы лишь на ранних стадиях жизненного цикла программного обеспечения, а он, к сожалению, стоит меньше всего в случае успешного продукта или сервиса[52]52
  Как язвительно заметил Джон Лодербах, в настоящее время вице-президент по информационным технологиям в компании Roche Bros. Supermarkets, «каждое новое приложение подобно подаренному щенку. Это не аванс в счет капитальных затрат, когда можно сказать “все, хватит!”. Это неотвратимая необходимость в постоянном обслуживании и поддержке». Прим. авт.


[Закрыть].

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

Устанавливайте границы между командами в соответствии с законом Конвея

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

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

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

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

Создавайте слабосвязанные архитектуры, чтобы обеспечить продуктивность и безопасность труда разработчиков

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

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

Напротив, если архитектура позволяет небольшим командам разработчиков реализовывать, тестировать и развертывать код в производство независимо, быстро и безопасно, мы можем увеличить и поддерживать на высоком уровне продуктивность разработчиков и улучшить результаты развертывания. Такими характеристиками обладает сервис-ориентированная архитектура (SOA), впервые описанная в 1990-е гг., в которой сервисы тестируются и развертываются независимо друг от друга. Ключевая особенность архитектуры SOA заключается в том, что она состоит из слабосвязанных сервисов с ограниченными контекстами[53]53
  Такими же свойствами обладает микросервисная архитектура, построенная на принципах SOA. Один из популярных наборов шаблонов для современных веб-архитектур, создаваемых на основе этих принципов, – «двенадцатифакторное приложение» (12-factor app).


[Закрыть].

Слабосвязанная архитектура означает, что сервисы можно обновлять в производстве независимо друг от друга, без необходимости обновления других сервисов. Сервисы должны быть отделены от других сервисов и, что не менее важно, от общих баз данных (хотя они могут совместно использовать сервисы баз данных при условии, что они не имеют никаких общих схем).

Ограниченные контексты описаны в книге Эрика Эванса «Предметно-ориентированное проектирование (DDD). Структуризация сложных программных систем»[54]54
  Издана: М.: Вильямс, 2015. Прим. перев.


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

Рэнди Шуп, бывший технический директор Google App Engine, отметил: «Организации с этими типами сервис-ориентированной архитектуры, такие как Google и Amazon, невероятно гибки и масштабируемы. Эти организации имеют десятки тысяч разработчиков, небольшие группы которых все еще способны быть невероятно продуктивными».

Сохраняйте размеры команд небольшими (правило «команда на две пиццы»)

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

В рамках своей инициативы по преобразованию и уходу от монолитной базы кода, начатой в 2002 г., компания Amazon использовала для определения размеров команд правило «двух пицц» (2PT – two-pizza team) – команда должна иметь такой размер, чтобы всех ее участников можно было накормить двумя пиццами (это обычно от пяти до десяти человек).

Такое ограничение размера порождает четыре следствия.

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

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

3. Оно децентрализует производительность и делает возможной автономную деятельность. Каждая команда «двух пицц» функционирует настолько автономно, насколько возможно. Руководитель команды, действуя совместно с менеджерами компании, решает, за какие ключевые бизнес-метрики, или функции пригодности, отвечает команда, и эти функции становятся общим критерием оценки тех экспериментов, которые проводит команда. После этого группа сможет действовать автономно, чтобы максимизировать эти показатели[55]55
  В производственной культуре компании Netflix одно из семи ключевых правил гласит: «Сильно согласованы, слабо связаны». Прим. авт.


[Закрыть].

4. Руководство командой 2PT – способ для сотрудников получить некоторый опыт работы на руководящих должностях в среде, где сбои не имеют катастрофических последствий. Важным элементом стратегии Amazon была связь между организационной структурой 2PT и архитектурным подходом, взятым от сервис-ориентированной архитектуры.

Технический директор компании Amazon Вернер Фогельс в 2005 г. объяснил преимущества такой структуры Ларри Дигнану, сотруднику сайта Baseline. Дигнан пишет:

«Небольшие команды действуют быстро и не увязают в так называемом администрировании… Каждая команда назначена на отдельный участок бизнеса и полностью за него отвечает… Она оценивает объем задач по исправлению ошибки, разрабатывает исправление, внедряет его и контролирует его повседневное использование. Таким образом, программисты и архитекторы получают прямую обратную связь от потребителей кода или приложений – в ходе регулярных совещаний и неофициальных бесед».

Еще один пример того, как архитектура может коренным образом улучшить производительность, – это программа API Enablement компании Target.

Практический пример

Программа API Enablement компании Target (2015 г.)

Target – шестая по величине компания розничной торговли в США. Ежегодно она тратит на технологии более миллиарда долларов. Хэзер Микман, директор развития компании, так описывала начало использования DevOps: «В недобрые старые дни бывало так, что работа серверов поддерживалась десятью различными командами, и когда что-то ломалось, мы, как правило, приостанавливали ее, чтобы не возникло дальнейших проблем, что, конечно, еще более ухудшало ситуацию».

Затруднения были вызваны тем, что получение сред и выполнение развертывания создали значительные сложности для разработчиков, такие как получение доступа к необходимым базам данных. Как описывала Микман, «проблема заключалась в том, что большая часть наших основных данных, таких как информация о материальных запасах, ценообразовании и магазинах, была “заперта” в устаревших системах и мейнфреймах. Нередко у нас оказывалось несколько источников одних и тех же данных, особенно при взаимодействии системы электронной торговли и физических хранилищ, которые принадлежали различным командам с различными структурами данных и имевшими различные приоритеты… В результате если новая группа разработчиков хотела создать что-то для наших пользователей, то требовалось от трех до шести месяцев только для того, чтобы осуществить интеграцию с работающими системами для получения необходимых данных. Мало того, еще от трех до шести месяцев требовалось для тестирования вручную, чтобы убедиться, что они не сломали ничего критически важного, поскольку система была очень сильно связанной и имела множество пользовательских соединений типа точка – точка. Управление взаимодействием 20–30 различных команд с учетом существующих зависимостей требовало большого числа руководителей проектов для организации координации и передачи задач между командами. Это означает, что разработчики тратили все время на ожидание, когда придет их очередь, вместо того чтобы обеспечивать результаты.

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

Пытаясь решить проблему с данными, Микман создала в 2012 г. команду API Enablement, чтобы команды разработчиков могли «обеспечивать новые возможности в течение нескольких дней, а не месяцев». Они хотели, чтобы каждая инженерная команда внутри компании Target имела возможность получать и хранить необходимые им данные, такие как информация о продукции или о магазинах, в том числе о часах работы, местоположении, о том, имеется ли в магазине кафе Starbucks и т. д.

Нехватка времени играла большую роль при выборе членов команды. Микман объяснила это так:

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

За следующие два года команда API Enablement добавила 53 новые возможности для бизнеса, в том числе Ship to Store и Gift Registry, а также их интеграцию с Instacart и Pinterest. Как описывала Микман, «неожиданно взаимодействовать с командой Pinterest стало очень легко, потому что мы просто предоставили им API».

В 2014 г. команда API Enablement обслуживала более полутора миллиардов вызовов API в месяц. К 2015 г. это возросло до 17 миллиардов вызовов в месяц, объединяя 90 различных API. Для поддержки этой возможности команда регулярно выполняла 80 развертываний в неделю.

Благодаря изменениям были созданы основные преимущества для бизнеса компании Target – рост цифровых продаж на 42 % в течение праздничного сезона 2014 г. и увеличение еще на 32 % во втором квартале следующего года. В 2015 г. в «черную пятницу»[56]56
  Черная пятница – пятница после Дня благодарения в США. С нее начинается традиционный рождественский сезон распродаж. Прим. перев.


[Закрыть] и в последовавшие за ней выходные было оформлено свыше 280 000 заказов с получением их в магазине. К 2015 г. целью компании было увеличить число магазинов, способных выполнять интернет-заказы, со 100 до 450 при общем количестве магазинов 1800.

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

Заключение

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

Глава 8. Как получить лучшие результаты, интегрируя эксплуатацию в повседневную деятельность разработчиков

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Создание общедоступных инструментов для повышения эффективности разработчиков

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


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

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


[Закрыть].

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

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

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

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

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

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

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

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

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


[Закрыть].

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

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

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

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

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

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

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

Назначение «контактов с эксплуатацией» в каждую команду разработки сервисов

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

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

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

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

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

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

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

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

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

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