Рекомендации по разработке стратегии аварийного восстановления

  • Статья

Применяется к этой рекомендации по контрольным спискам надежности Платформы Azure Well-Architected Framework:

RE:09 Реализуйте структурированные, протестированные и задокументированные планы непрерывности бизнес-процессов и аварийного восстановления (BCDR), соответствующие целевым показателям восстановления. Планы должны охватывать все компоненты и систему в целом.

В этом руководстве описываются рекомендации по проектированию надежной стратегии аварийного восстановления для рабочей нагрузки. Для достижения внутренних целей уровня обслуживания (SLO) или даже соглашения об уровне обслуживания (SLA), которое вы гарантируете для клиентов, необходимо иметь надежную и надежную стратегию аварийного восстановления. Ожидаются сбои и другие серьезные проблемы. Ваша подготовка к устранению этих инцидентов определяет, насколько ваши клиенты могут доверять вашему бизнесу, чтобы обеспечить их надежную доставку. Стратегия аварийного восстановления является основой подготовки к крупным инцидентам.

Определения

Термин Определение
Отработка отказа Автоматическое и (или) ручное перемещение трафика рабочей нагрузки из недоступного региона в не затронутый географический регион.
Восстановление размещения Автоматическое и (или) ручное перемещение трафика рабочей нагрузки из региона отработки отказа обратно в основной регион.

Ключевые стратегии проектирования

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

Стратегия надежного аварийного восстановления (DR) основана на надежной архитектуре рабочей нагрузки. Обеспечение надежности на каждом этапе создания рабочей нагрузки, чтобы обеспечить наличие необходимых компонентов для оптимизированного восстановления, прежде чем приступать к разработке стратегии аварийного восстановления. Эта основа гарантирует, что целевые показатели надежности рабочей нагрузки, такие как целевое время восстановления (RTO) и целевая точка восстановления (RPO), являются реалистичными и достижимыми.

Обслуживание плана аварийного восстановления

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

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

  • Четко определите, что представляет собой аварию и, следовательно, требует активации плана аварийного восстановления.

    • Аварии — это крупномасштабные проблемы. Это могут быть региональные сбои, сбои служб, таких как Microsoft Entra ID или Azure DNS, или серьезные вредоносные атаки, такие как атаки программ-шантажистов или атаки DDoS.

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

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

    • Разработка планов аварийного восстановления для непроизводственных сред зависит от бизнес-требований и влияния на затраты. Например, если вы предлагаете среды контроля качества (QA) определенным клиентам для предварительного тестирования, вы можете включить эти среды в планирование аварийного восстановления.

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

    • Сторона, ответственная за объявление аварии.

    • Сторона, ответственная за объявление о закрытии инцидента.

    • Роли операций.

    • Роли тестирования и проверки.

    • Внутренние и внешние роли связи.

    • Роли ведущих ролей ретроспективного и первопричинного анализа (RCA).

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

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

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

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

    • Включите необходимые компоненты для выполнения процедуры. Например, перечислим необходимые скрипты или учетные данные, которые необходимо собрать.

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

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

    Примечание

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

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

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

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

    Примечание

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

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

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

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

Проведение отработок аварийного восстановления

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

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

  • Выполняйте по крайней мере одну отработку аварийного восстановления в рабочей среде в год. Отработки на столешнице (сухой запуск) или непроизводственные отработки помогают убедиться, что участвующие стороны знакомы со своими ролями и обязанностями. Эти отработки также помогают операторам создать навыки ("мышечная память"), следуя процессам восстановления. Но только рабочие отработки по-настоящему проверяют правильность плана аварийного восстановления, а также метрик RTO и RPO. Используйте рабочие отработки для процессов восстановления компонентов и потоков, чтобы обеспечить достижение целевых объектов RTO и RPO, определенных для вашей рабочей нагрузки. Для функций, которые находятся вне вашего контроля, таких как распространение DNS, убедитесь, что целевые объекты RTO и RPO для потоков, которые включают эти функции, учитывают возможные задержки, выходящие за рамки вашего контроля.

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

Рекомендации

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

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

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

Упрощение azure

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

Для систем IaaS (инфраструктура как услуга) используйте Azure Site Recovery для автоматизации отработки отказа и восстановления. Общие продукты PaaS см. в следующих статьях:

Пример

Рекомендации по подготовке корпоративного пространства данных для аварийного восстановления см. в серии аварийного восстановления для платформы данных Azure .

Контрольный список надежности

Ознакомьтесь с полным набором рекомендаций.

Контрольный список надежности