Топологии команд DevOps

Распределение ролей, обязанностей и доверия между ИТ-командами и командами приложений имеет первостепенное значение для оперативного преобразования, связанного с внедрением облака в масштабе.

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

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

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

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

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

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

В следующей таблице представлена упрощенная классификация этих команд.

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

Рекомендации по проектированию

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

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

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

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

• Одеялое приложение модели DevOps не мгновенно устанавливает команды DevOps.

• Инвестиции в инженерные возможности и ресурсы критически важны.

• Команды приложений для некоторых устаревших приложений могут не иметь инженерных ресурсов, необходимых для согласования с стратегией DevOps.

Рекомендации по проектированию

В следующих разделах содержатся рекомендации по проектированию топологий команд.

Выравнивание топологий команд с помощью облачной операционной модели

Убедитесь, что вы выравниваете топологии группы с требуемой облачной операционной моделью.

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

Определение функций для команды платформы

В следующем списке представлен рекомендуемый набор функций для группы платформы, ответственной за целевые зоны Azure:

• Управление архитектурой
• Подготовка подписки и делегирование необходимых политик управления сетями, удостоверениями и доступом
• Управление платформой и мониторинг (целостные)
• Управление затратами (целостное)
• Платформа как код (управление шаблонами, скриптами и другими ресурсами)
• Общие операции с Microsoft Azure в клиенте Microsoft Entra (управление субъектами-службами, регистрацией API Microsoft Graph и определениями ролей)
• Azure RBAC (целостное)
• Управление ключами для центральных служб (простой протокол передачи почты и контроллеры домена)
• Управление политиками и их принудительное применение (целостное)
• Мониторинг безопасности и аудиты (целостные)
• Управление сетью (целостное)

Определение функций для команд рабочей нагрузки приложений

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

• Создание ресурсов приложения и управление ими с помощью модели DevOps
• Управление базами данных
• Миграция или преобразование приложений
• Управление приложениями и мониторинг (ресурсы приложения)
• Azure RBAC (ресурсы приложения)
• Мониторинг безопасности и аудит (ресурсы приложения)
• Управление секретами и ключами (ключи приложения)
• Управление затратами (ресурсы приложения)
• Управление сетью (ресурсы приложения)

Определение функций для включения команд

В следующем списке представлен рекомендуемый набор функций для группы включения, ответственной за помощь другим командам:

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

Определение режимов взаимодействия между командами

Цели взаимодействия между командами :

• Обеспечение автономии
• Разблокировка зависимостей
• Свести к минимуму время траты
• Избегайте узких мест

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

Режим взаимодействия	Description
Совместная работа	Teams тесно сотрудничают.
X-as-Service	Teams использует или предоставляет что-то другим командам с минимальным сотрудничеством, аналогично взаимодействию сторонних поставщиков.
Содействие	Команда помогает или помогает другой команде устранить препятствия.