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

Применяется к этой рекомендации проверки надежности платформы 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 имеют встроенные возможности отказоустойчивости. Ознакомьтесь с этими возможностями и включите их в процедуры восстановления.

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

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

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

• Служба Azure Kubernetes

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

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

• Кэш Azure для Redis

Пример

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

Упрощение службы архивации Azure

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

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

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

• Служба Azure Kubernetes

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

• Файлы Azure

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

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

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

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

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

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