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

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

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

Важно!

Эта статья является частью серии критически важных рабочих нагрузок Azure Well-Architected Framework . Если вы не знакомы с этой серией, рекомендуется начать с что такое критически важная рабочая нагрузка?.

Процессы DevOps

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

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

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

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

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

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

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

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

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

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

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

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

• Посвятите часть инженерного потенциала во время каждого спринта, чтобы обеспечить фундаментальные улучшения платформы и повысить надежность. Для этих улучшений рекомендуется выделить 20–40 % емкости.

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

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

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

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

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

• Рассмотрите возможность использования AIOps для постоянного улучшения операционных процедур и триггеров.

Операции с приложением

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

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

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

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

• Применение политики. Политика Azure предоставляет платформу для применения и аудита базовых показателей безопасности и надежности, чтобы обеспечить соответствие общим критериям проектирования для критически важных приложений. В частности, Политика Azure является ключевой частью уровня управления Azure Resource Manager, дополняя RBAC, ограничивая действия, которые могут выполнять авторизованные пользователи. Вы можете использовать Политика Azure для обеспечения жизненно важных соглашений о безопасности и надежности в разных службах платформы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Автоматическое обнаружение обновлений. Настройте процессы для мониторинга и автоматического обнаружения обновлений. Используйте такие средства, как GitHub Dependabot.

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

• Зависимости среды выполнения. Обрабатывать зависимости среды выполнения так же, как и любые другие изменения в приложении. Более старые версии могут привести к уязвимостям системы безопасности и негативно повлиять на производительность. Отслеживайте среду выполнения приложения и поддерживайте ее в актуальном состоянии.

• Гигиена компонентов и уборка. Списание или удаление ресурсов, которые не используются. Например, можно отслеживать реестры контейнеров и удалять старые версии образов, которые вы не используете.

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

• Отслеживайте эти ресурсы и поддерживайте их в актуальном состоянии:

  • Платформа размещения приложений. Например, необходимо регулярно обновлять версию Kubernetes в Служба Azure Kubernetes (AKS), особенно учитывая, что поддержка более старых версий не поддерживается. Кроме того, необходимо обновить компоненты, которые работают в Kubernetes, такие как cert-manager и Azure Key Vault CSI, и согласовать их с версией Kubernetes в AKS.
  • Внешние библиотеки и пакеты SDK (.NET, Java, Python).
  • Поставщики Terraform.

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

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

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

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

Многие службы Azure поддерживают проверку подлинности Microsoft Entra вместо использования строк подключения и ключей. Использование идентификатора Microsoft Entra значительно сокращает эксплуатационные издержки. Если вы используете решение для управления секретами, оно должно интегрироваться с другими службами, поддерживать зональную и региональную избыточность, а также обеспечивать интеграцию с идентификатором Microsoft Entra для проверки подлинности и авторизации. Key Vault предоставляет эти функции.

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

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

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

  Только субъект-служба развертывания должен иметь доступ к секретам, что упрощает разрешения RBAC в системе управления секретами.

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

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

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

  Распространенные варианты хранения включают поставщик azure Key Vault для драйвера CSI хранилища секретов и akv2k8s. Также доступно собственное решение Azure, Key Vault параметры приложения, на которые ссылается ссылка.

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

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

  Однако для этого подхода для компонентов приложения требуется прямая зависимость и подключение к системе управления секретами. Это затрудняет тестирование компонентов по отдельности и обычно требует использования пакета SDK.

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

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

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

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

• Чтобы избежать необходимости управлять учетными данными субъекта-службы или ключами API, используйте управляемые удостоверения вместо субъектов-служб для доступа к Key Vault, когда это возможно.

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

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

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

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

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

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

• Отдельные виртуальные машины не обеспечивают высокий уровень доступности, избыточность между зонами или геоизбыточность.
• Отдельные виртуальные машины не обновляются автоматически после их развертывания. Например, развернутая SQL Server 2019 в Windows Server 2019, не будет автоматически обновлена до более нового выпуска.
• Службы, работающие на виртуальной машине, нуждаются в особой обработке и дополнительных инструментах, если вы хотите развернуть и настроить их с помощью инфраструктуры как кода.
• Azure периодически обновляет свою платформу. Для этих обновлений может потребоваться перезагрузка виртуальной машины. Обновления, для которых требуется перезагрузка, обычно объявляются заранее. См. статьи Обслуживание виртуальных машин в Azure и Обработка уведомлений о плановом обслуживании.

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

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

  • Автоматизируйте подготовку ресурсов Azure с помощью решений "инфраструктура как код", таких как шаблоны Azure Resource Manager (ARM), Bicep, Terraform или другие решения.

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

• Убедитесь, что существуют стратегии для отката до последнего известного работоспособного состояния, если более новая версия работает неправильно.

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

• Мониторинг виртуальных машин и обнаружение сбоев. Необработанные данные для мониторинга могут поступать из различных источников. Анализ причин проблем.

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

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

• Приоритезировать использование стандартных образов из Azure Marketplace, а не пользовательских образов, которые необходимо поддерживать.

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

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

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

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

Шаблон архитектуры