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

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

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

Определения

Основные стратегии проектирования

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

• Определите критические и некритические потоки.

• Выполните анализ режима сбоя (FMA) для потоков.

• Определение целевых показателей надежности.

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

• Разработка надежной стратегии тестирования.

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

Поддерживать план аварийного восстановления

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

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

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

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

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

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

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

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

  • Партия, отвечающая за объявление аварии.

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

  • Операционные роли

  • Роли в тестировании и валидации.

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

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

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

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

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

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

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

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

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

  Замечание

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

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

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

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

  Замечание

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

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

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

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

Проведение учений по восстановлению после аварийных ситуаций

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

Следуйте этим рекомендациям для успешных учений по аварийному восстановлению:

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

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

Соображения

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

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

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

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

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

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

• Определите необходимые периоды хранения для каждой службы.

• Понять, что один инструмент может не работать для всего. Средства Azure Backup могут охватывать множество типов ресурсов, но не все.

• Иногда оптимальным вариантом восстановления определенных типов объектов является повторное развертывание из определенного типа репозитория с высоким уровнем доступности. (Azure DevOps, GitHub или другие)

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

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

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

Упрощение функций Azure

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

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

• Служба приложений Azure

• Приложения контейнеров Azure

• Служба Azure Kubernetes

• База данных SQL Azure

• Центры событий Azure

• Кэш Azure для Redis

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

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

• Служба приложений Azure

• Служба Azure Kubernetes

• База данных SQL Azure

• Файлы Azure

Связанные ссылки

• Рекомендации по проектированию с учетом отказоустойчивости

• Рекомендации по проектированию высокодоступных систем для нескольких регионов

• Рекомендации по использованию зон доступности и регионов

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

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