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

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

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

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

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

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

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

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