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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Всеобъемлющее применение модели DevOps не гарантирует мгновенное создание способных команд DevOps.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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