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

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

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

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

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

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

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

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

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

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

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