Поделиться через

Стратегии архитектуры для аварийного восстановления

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

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

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

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

Определения

Срок Определение
Активно-пассивный холодный резерв Шаблон развертывания аварийного восстановления, в котором вторичный регион имеет минимальную или отсутствующую инфраструктуру до возникновения аварии, что требует полного развертывания при переходе на резерв.
Активно-пассивный режим горячего резервирования Шаблон развертывания аварийного восстановления, где в дополнительном регионе инфраструктура предварительно развернута и работает на сниженной мощности, что обеспечивает более быстрое переключение на резервную систему, чем полностью аварийный резерв.
Резервное копирование Копия данных, хранящихся отдельно от основной системы, чтобы включить восстановление данных при потере, повреждении или аварии.
Критически важное значение для бизнеса Классификация рабочих нагрузок или компонентов на основе их важности для бизнес-операций, влияющих на приоритеты восстановления и уровни инвестиций.
Условия активации аварийного восстановления Предопределенные пороговые значения и условия, определяющие, когда следует объявлять процедуры аварийного восстановления и активировать их.
Тренировка аварийного восстановления Запланированное упражнение для тестирования процедур аварийного восстановления и проверки возможностей восстановления в контролируемых условиях.
Возврат к исходному состоянию Автоматическое и/или ручное перемещение трафика производственной нагрузки из резервного региона обратно в основной регион.
Переключение на резервную систему Автоматическое и/или ручное перемещение трафика производственной нагрузки из недоступного региона в незатронутый географический регион.
Восстановление на определенный момент времени Возможность восстановления данных в определенный момент времени, обычно используемая для восстановления после повреждения данных или случайных изменений.
Цель точки восстановления (RPO) Максимально допустимое количество потери данных, измеряемое во времени, определяющее, сколько данных бизнес может позволить себе потерять во время аварии.
Цель времени восстановления (RTO) Максимально допустимое время восстановления бизнес-операций после аварии.
Синхронная репликация Репликация данных, в которой изменения записываются одновременно в несколько мест, обеспечивая отсутствие потери данных, но потенциально более высокую задержку.
Асинхронная репликация Репликация данных, в которой изменения записываются в основное расположение, затем копируются в вторичные расположения, что позволяет допускать некоторые потери данных, однако снизить задержку.
Комната войны Централизованное расположение или канал связи, где ключевые сотрудники координируются во время аварийного восстановления.

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

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

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

Определение пороговых значений аварий

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

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

Установка протоколов связи

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

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

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

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

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

Проектирование архитектуры с поддержкой восстановления

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

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

Замечание

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

Подготовка процедур инфраструктуры и восстановления

Подготовьте вторичный регион заранее. Создайте контрольный список, чтобы команда была готова при возникновении инцидента, например:

  • Уровень вычислений: для неактивных активных/пассивных рабочих нагрузок заранее развертывайте минимальные вычислительные ресурсы для обеспечения быстрой обработки отказов.
  • Сетевая инфраструктура: выполните репликацию топологии, включая виртуальные сети (VNets), подсети, маршруты, брандмауэры и группы безопасности, и подтвердите все конфигурации.
  • Управление идентификацией и доступом: дублирование настроек учетных записей, разрешения RBAC и политики, обеспечивая тот же базовый уровень безопасности, что и в продуктивной среде.
  • Мониторинг. Развертывание инфраструктуры мониторинга с помощью оповещений и панелей мониторинга, настроенных для видимости.

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

Сохраняйте стратегию возврата отдельно от переключения на резерв.

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

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

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

Реализация надежных стратегий резервного копирования

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

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

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

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

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

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

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

Поддерживайте актуальность и дееспособность планов

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

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

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

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

Обеспечение доступности во время сбоев

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

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

Автоматизируйте безопасное выполнение процедур восстановления

Автоматизируйте процедуры развертывания и восстановления в резервных средах, где это возможно, обеспечивая достижение целевых показателей времени восстановления (RTO). Используйте декларативные и идемпотентные скрипты для надежности и создания защитных механизмов, таких как логика повторных попыток и логика прерывания цепи для любого пользовательского кода. Предустановка и настройка конвейеров DevOps, чтобы развертывания могли начаться немедленно, используя автоматизированные сквозные процессы с ручными шлюзами утверждения только при необходимости. Убедитесь, что сроки развертывания соответствуют целевым объектам восстановления.

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

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

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

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

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

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

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

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

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

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

  • Last updated on