Azure делает отказоустойчивость непрерывной частью модернизации

Устойчивость проектируют до первого сбоя

Microsoft описала обновлённый подход Azure к infrastructure resiliency: для распределённых приложений, AI-сервисов, hybrid и multicloud сред резервного копирования и плана disaster recovery уже недостаточно. Устойчивость должна одновременно охватывать архитектуру, эксплуатацию, восстановление и постоянную оптимизацию, а требования к availability, recovery, performance и compliance задаются отдельно для каждой нагрузки.

Базовые строительные блоки остаются знакомыми: availability zones, отказоустойчивая сеть, durable storage, recovery services, Azure Well-Architected Framework и Azure Architecture Center. Существенное изменение — переход от разовой проверки проекта к управлению на уровне приложения. Azure Infrastructure Resiliency Manager помогает определить цели, учесть критичность workload, увидеть разрывы и сопоставить текущее состояние с выбранными resiliency objectives.

Через resiliency agent в Azure Copilot команды могут описывать workload, создавать deployment templates, оценивать существующую среду и получать рекомендации. Это помощь в проектировании, а не автоматическая гарантия непрерывности: итоговая архитектура всё равно должна соответствовать реальным зависимостям, допустимой потере данных и времени восстановления конкретного сервиса.

Оценка должна продолжаться после запуска

Microsoft отмечает, что надёжная при запуске конфигурация со временем меняется: появляются новые зависимости, deployment, scaling, обновления и configuration drift. Поэтому Infrastructure Resiliency Manager предназначен для постоянной оценки posture, приоритизации пробелов и рекомендаций, а не только для документа перед первым production-релизом.

На storage layer компания показала per-disk resiliency для Azure Managed Disks, доступную в public preview в отдельных регионах. При длительной потере связи с конкретным data disk Azure может временно отключить только его, сохранив работу virtual machine и остальных дисков, а после восстановления связи автоматически подключить диск снова.

Механизм подходит не всем. Microsoft прямо ограничивает сценарий workloads, которые способны пережить временную потерю отдельного data disk: например, некоторым clustered applications, системам с auxiliary disks и отдельным containerized architectures. Если приложение жёстко зависит от пропавшего тома, уменьшение технического blast radius не превращает его бизнес-функцию в доступную.

Планы восстановления проверяют контролируемым отказом

Recovery readiness предлагается подтверждать не наличием документа, а повторяемыми испытаниями. Azure Infrastructure Resiliency Manager и Azure Chaos Studio помогают проверять failover procedures, искать скрытые зависимости и сравнивать результат с заранее определёнными recovery objectives до реальной аварии.

Chaos Studio может моделировать сбои availability zone, database failover, нарушения DNS и Microsoft Entra. Для упражнений Microsoft упоминает guided drills, автоматическую очистку и audit-ready reporting. Практический смысл такого цикла — отделить архитектуру, которая выглядит устойчивой на схеме, от системы, действительно выдерживающей нужный класс отказа.

Безопасное chaos testing требует жёстких границ: известного blast radius, наблюдаемости, условий немедленной остановки и владельца восстановления. Официальная публикация перечисляет возможности платформы, но не отменяет необходимость начинать с изолированной среды и отдельно доказывать, что эксперимент не затронет критичные данные и пользователей.

Cyber recovery требует доверенной точки возврата

Microsoft рассматривает инфраструктурный сбой и cyberattack как разные варианты одной задачи восстановления. Azure Backup предлагает immutable vaults, soft delete, multi-user authorization и recovery orchestration, чтобы сохранять чистые recovery points и снижать риск возврата вместе со скомпрометированными данными или конфигурацией.

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

Итоговая модель Microsoft состоит из трёх повторяющихся действий: строить resilient by design, отслеживать устойчивость по мере изменений и регулярно подтверждать recovery на практике. Новые Azure-инструменты связывают эти этапы, однако их рекомендации и отчёты имеют ценность только вместе с измеримыми SLO, проверенными runbooks и результатами реальных drills.