Операционные процедуры для критически важных рабочих нагрузок в Azure

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

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

Процессы DevOps

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

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

DevSecOps интегрирует мониторинг безопасности, аудит и обеспечение качества в жизненный цикл DevOps. Для критически важных рабочих нагрузок выравнивайте методики DevSecOps с руководством по обеспечению безопасности и применяйте модель "Никому не доверяй" во всех операционных процедурах.

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

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

• Зависимости от центральных ИТ-команд. Процессы DevOps могут быть трудно применять, если существуют жесткие зависимости от централизованных функций, так как эти зависимости предотвращают сквозные операции.

• Управление удостоверениями и доступом. Команды DevOps могут рассмотреть детализированные роли Azure RBAC для отдельных технических функций. Применение модели нулевого доверия между ролями DevOps.

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

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

• Избегайте зависимостей от централизованного выделения ресурсов, которые могут привести к риску проблемы «шумного соседа». Дополнительные сведения см. в разделе "Архитектура единиц масштабирования". Если зависимости от централизованного выделения ресурсов неизбежны, приведите требования к доступности этих зависимостей в соответствие с требованиями к критически важным системам. Требовать прозрачности от центральных команд по их процессам управления изменениями и реагирования на инциденты.

• Выделить часть инженерных ресурсов во время каждого спринта для осуществления основных улучшений платформы и повышения её надёжности. Мы рекомендуем выделить 20–40 процентов емкости для этих улучшений.

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

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

• Применение модели нулевого доверия в критически важных средах приложений. Используйте такие технологии, как Microsoft Entra управление привилегированными пользователями, чтобы гарантировать последовательность операций и их выполнение только через процессы CI/CD или автоматизированную операционную процедуру.

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

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

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

Операции приложения

Рекомендации по проектированию приложений и платформам влияют на операционные процедуры. Сведения о мониторинге безопасности и обнаружении угроз см. в руководстве по мониторингу компонентов безопасности. Сведения о процедурах реагирования на инциденты см. в разделе "Реагирование на инциденты безопасности".

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

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

• Рабочий доступ и время выполнения. Большинство необходимых операций предоставляются и доступны через API Azure Resource Manager или портал Azure. Однако некоторые операции требуют помощи от инженеров поддержки. Например, для некоторых сценариев восстановления из периодических резервных копий Azure Cosmos DB требуется обращение в службу поддержки Azure. Эта зависимость может повлиять на время простоя приложения. Для ресурсов без отслеживания состояния рекомендуется повторно развернуть развертывание, а не ожидать, чтобы инженеры поддержки пытались восстановить удаленные ресурсы.

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

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

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

• Используйте собственные возможности платформы для резервного копирования и восстановления, обеспечивая соответствие их требованиям к RTO/RPO и хранению данных. Определите стратегию долгосрочного хранения резервных копий по мере необходимости.

• Используйте встроенные возможности для управления SSL-сертификатами и продления, например, предоставляемых Azure Front Door.

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

• Заранее практикуйте операции восстановления для непроизводственных ресурсов и данных в рамках стандартной подготовки непрерывности бизнес-процессов.

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

• Примените Политика Azure для обеспечения операционных возможностей и надежной базовой конфигурации. Дополнительные сведения см. в разделе "Управление на основе политик".

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

Мониторинг и моделирование состояния

Критически важные нагрузки требуют единой стратегии наблюдаемости, охватывающей ресурсы глобального, регионального и stamp-уровня. Соберите все данные наблюдаемости из компонентов приложения и инфраструктуры в единое хранилище данных, которым может быть рабочая область Log Analytics, чтобы группа эксплуатации могла сопоставлять данные о работе рабочей нагрузки и выявлять проблемы и сбои во всей среде. Используйте Application Insights с распределенной трассировкой для комплексного отслеживания запросов.

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

Управление обновлениями

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

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

• Регулярно обновляйте версию Kubernetes в Azure Kubernetes Service (AKS), особенно учитывая, что поддержка старых версий не поддерживается. Также обновите компоненты, работающие в Kubernetes, например cert-manager и Azure Key Vault CSI, и приведите их в соответствие с версией Kubernetes в AKS. Сведения о конфигурации см. в руководстве по службе Kubernetes.

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

• Установите автоматическую процедуру удаления старых версий образов из реестра контейнеров Azure.

Управление секретами

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

Для критически важных нагрузок выбор момента получения секретов (во время развертывания, при запуске или во время выполнения) напрямую влияет на доступность. Зависимость во время выполнения от решения для управления секретами означает, что сбои в Key Vault могут блокировать перезапуск приложений и операции горизонтального масштабирования.

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

• По возможности используйте аутентификацию Microsoft Entra и управляемые удостоверения Azure вместо строк подключения или ключей.

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

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

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

• Используйте уведомление о истечении срока действия ключа в Azure Key Vault для получения оповещений о предстоящих сроках действия.

Рекомендации, связанные с IaaS при использовании виртуальных машин

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

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

• Отдавайте приоритет использованию Масштабируемые наборы виртуальных машин вместо отдельных виртуальных машин, чтобы обеспечить масштабирование, автомасштабирование и избыточность между зонами.

• Избегайте ручных операций на виртуальных машинах и реализуйте надлежащие процессы для развертывания и развертывания изменений. Автоматизируйте подготовку ресурсов с помощью решений типа «инфраструктура как код», таких как Bicep или Terraform.

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

Следующий шаг

Просмотрите шаблон архитектуры для сценариев критически важных приложений: