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

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

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

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

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

Терминология

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

Что такое аварийное восстановление?

Аварийное восстановление (АВ) — это стратегический и методический подход для восстановления систем или их критически важных частей после серьезного сбоя.

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

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

• Полные региональные сбои

• Потеря доступа к контрольной плоскости или возможностей управления сервисами

• Поврежденные рабочие среды из-за вредоносных действий или критической неправильной настройки

• Серьезные сбои инфраструктуры, влияющие на несколько уровней системы

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

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

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

Выберите уровень критической важности

Не все нагрузки (или их части) нуждаются в серьезном плане восстановления. Восстановление должно отражать его критическость.

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

Распространенный способ квалифицировать уровни — это цели уровня обслуживания (SLO), часто выраженные как "пять девяти" (99,999%), "четыре девять" (99,99%) и т. д. Эти процентили широко представляют уровень доступности, ожидаемый для данной рабочей нагрузки.

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

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

Уровень 0: критически важный для миссии

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

Этот уровень требует SLO выше 99,99%, при этом RTO измеряется в секундах и RPO приближается к нулю. Для удовлетворения этих требований обычно требуется активное развертывание с несколькими регионами, что обеспечивает мгновенное восстановление без прерывания работы с пользователями.

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

Уровень 1. Критически важный для бизнеса

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

Обычно для них требуются SLO на уровне около 99,95% с показателями RTO и RPO, измеряемыми в минутах. Сочетание активно-активного или теплого резервного развертывания часто используется для балансировки резерва с затратами.

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

Уровень 2. Операционная деятельность бизнеса

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

Эти системы обычно предназначены для SLO порядка 99,9%, при этом RTO и RPO измеряются в часах. Стратегия активного-пассивного развертывания с использованием теплого/холодного развертывания распространена: вторичные среды остаются неактивными до тех пор, пока не потребуется, что оптимизирует затраты в ущерб быстроте восстановления.

Сбои на этом уровне могут не сразу повлиять на клиентов, но более длительные нарушения могут замедлить бизнес. Своевременное восстановление важно, даже если это не немедленно.

Уровень 3. Администрирование

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

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

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

Классификация рабочей нагрузки

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

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

Обратитесь к заинтересованным сторонам вашего бизнеса, чтобы получить их одобрение по этим классификациям. Подтвердите целевые показатели RTO и RPO на основе реальных бизнес-последствий, а не только технических мнений. Их приверженность закладывает основу, и ваша стратегия аварийного восстановления опирается на нее. Без выравнивания по бизнес-рискам технический ответ не имеет направления.

Регулярно просматривайте эти классификации. По мере развития бизнес-потребностей обновите план аварийного восстановления соответствующим образом.

Следите за этими точками трения

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

• Несоответствие между ожиданиями и бюджетом. Настройте ожидания должным образом, чтобы заинтересованные стороны не ожидали горячей резервной производительности в холодном резервном бюджете. Разрыв между обещаниями RTO/RPO и бюджетами может привести к риску и разочарованию.

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

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

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

Оптимизация затрат на восстановление

Стоимость аварийного восстановления масштабируется с критичностью рабочей нагрузки.

• Уровень 0 (критически важный для миссии) поставляется с самой высокой стоимостью, и это ожидается. Развертывания active-active и резервная инфраструктура существенно увеличивают ваши затраты для достижения почти нулевого времени простоя. При оптимизации затрат лучшие варианты — это стандартные методики, такие как зарезервированные экземпляры или преимущество гибридного использования Azure, где это применимо.

  Стремитесь к простоте в дизайне. Чрезмерное проектирование, выходящее за рамки четко определенных требований, — это то, где скрытые затраты незаметно накапливаются. Имейте в виду, что базовые методики, такие как инфраструктура как код, автоматизированные развертывания и тестирование, представляют предварительные усилия по проектированию. Хотя эти усилия могут конкурировать с предоставлением новых функций, компрометирование инвестиций в сильные операции просто не вариант.

• Уровень 1 (Критически важный для бизнеса) предлагает баланс, обычно используя теплые резервные среды, которые снижают затраты.

  Снизьте базовую производительность в теплом резерве, развернув вычислительные ресурсы в вторичном регионе в частичном масштабе и включив автоматическое масштабирование для увеличения только в случае необходимости. Этот подход позволяет избежать оплаты за полную емкость 24/7.

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

• Уровень 2 (Бизнес-операционный) фокусируется на оптимизации затрат с помощью холодных резервных настроек и вариантов оплаты по мере использования, таких как точечные экземпляры и цены на потребление. Автоматизировать развертывание PaaS-вычислений в дополнительном регионе только при необходимости, чтобы избежать оплаты за неактивные ресурсы. Определите четкие критерии аварийных ситуаций и процессы переключения на резерв, чтобы предотвратить ненужные сбои. Регулярное тестирование гарантирует выполнение целевых показателей восстановления и выделяет области для снижения затрат.

• Уровень 3 (Административный) определяет экономию затрат, используя резервное копирование и архивное хранилище с более длинными окнами восстановления. Используйте реплицированные резервные копии и хранилища Azure Backup в дополнительном регионе для защиты постоянных данных без выполнения резервной инфраструктуры. Регулярно тестируйте процессы восстановления, чтобы обеспечить надежность при сохранении затрат на минимальное значение.

Независимо от выбранного уровня, используйте правильный инструментарий для анализа затрат. Используйте такие средства, как Microsoft Cost Management и Azure Advisor, чтобы отслеживать, прогнозировать и оптимизировать расходы на всех уровнях. Пометьте ресурсы и установите пределы бюджета, чтобы облегчить отслеживание моделей подотчетности и возврата расходов. Сведения о тегах, рекомендуемых корпорацией Майкрософт, см. в разделе «Теги критически важных рабочих нагрузок».

Документируйте план аварийного восстановления

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

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

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

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

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

• Роли и обязанности. Определите, кто отвечает за общение и кому.

• Ключевые заинтересованные лица. Определите ключевые внутренние и внешние аудитории, такие как, сотрудники, руководство, партнеры и клиенты.

• Каналы связи. Установите основные и резервные методы, такие как электронная почта, SMS и другие. Также установите частоту обновлений этих каналов.

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

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

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

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

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

  Разработайте пошаговый процесс для выполнения аварийного переключения:

  Действие	Владелец	Критерии
  1. Обнаружение инцидента	Мониторинг и операции	Инцидент активируется оповещениями или отчетами пользователей.
  2. Оценка серьезности	Диспетчер инцидентов	Используйте таблицу классификации инцидентов для определения уровня серьезности.
  3. Объявление сбоя (при необходимости)	Старший руководитель Ops/BCDR	Объявите о сбоях только для инцидентов высокой и критической серьезности.
  4. Уведомление заинтересованных лиц	Руководитель по связям и коммуникациям	Следуйте установленному плану коммуникации для уведомлений.
  5. Запуск выполнения runbook	Группа операций	Инициируйте выполнение руководства аварийного восстановления (DR), включая автоматизированные и ручные шаги.
  6. Подготовка вторичной инфраструктуры	Группа операций	Разверните и(или) масштабируйте и проверьте конфигурацию инфраструктуры в дополнительном регионе.
  7. Обеспечение целостности данных	Группа операций	При необходимости восстановите данные из резервных копий и проверьте целостность данных и соблюдение RPO.
  8. Восстановление приложений	Команда Ops/QA	Развертывание, при необходимости и активация приложений в дополнительных. Проверка правильной операции и всех зависимостей
  9. Переключение трафика	Группа операций	Переход пользователя на вторичную среду. При необходимости обновите записи DNS
  10. Закрытие инцидента и документирование	Диспетчер инцидентов	Проводите постмортем и обновляйте записи инцидентов.

  Аналогичным образом создайте решение о восстановлении после сбоя и процесс выполнения решения (при доступности основного региона).

  Действие	Владелец	Критерии и точка принятия решений
  1. Мониторинг состояния основного региона	Операции/Облачная команда	Убедитесь, что основной регион проходит все проверки работоспособности и полностью работает. Используйте средства автоматического мониторинга и проверку вручную для подтверждения готовности.
  2. Оценка влияния на бизнес	Владелец приложения/Непрерывность бизнеса	Проверьте готовность бизнеса к возврату после отказа, включая окна с низким трафиком и необходимые утверждения. Координируется с заинтересованными лицами, чтобы обеспечить соответствие времени бизнес-потребностям.
  3. Проверка синхронизации данных	Команда по базе данных и инфраструктуре	Убедитесь, что данные в дополнительном регионе синхронизированы с основным и соответствуют требованиям RPO/RTO. Используйте панели мониторинга состояния репликации для проверки согласованности данных.
  4. Сообщите о плане возврата к начальной системе	Диспетчер инцидентов	Уведомите заинтересованных лиц о запланированном откате, что включает таймлайн и потенциальное влияние. Используйте электронную почту, Teams или средства управления инцидентами для общения.
  5. Подготовка основного региона	Команда по инфраструктуре и облаку	Убедитесь, что компоненты инфраструктуры, безопасности и приложений готовы в основном регионе. Выполните контрольные проверки перед возвратом после отказа, чтобы обеспечить полную готовность.
  6. Инициализация отказоустойчивости	Операции/Облачная команда	Следуйте только с утвержденным запросом на изменение, и только если выполняются все критерии. Начните перенаправление трафика и рабочих нагрузок в основной регион.
  7. Мониторинг хода восстановления размещения	Операции/Облачная команда	Отслеживайте ошибки, задержку или потерю данных во время перехода. Используйте панели мониторинга и системы оповещений для отслеживания хода выполнения.
  8. Проверка функциональности приложения	Владелец приложения/QA	Убедитесь, что приложения и службы полностью работают в основном регионе. Выполните тесты дыма и регрессионные тесты для проверки функциональности.
  9. Завершение и закрытие инцидента	Диспетчер инцидентов	Убедитесь, что все системы стабильны, заинтересованные стороны информированы, и документация обновляется. Полный анализ после смерти и сбор извлеченных уроков.

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

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

План эскалации в процессе аварийного восстановления

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

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

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

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

Ниже приведен пример шаблона:

Регулярное тестирование и улучшение плана

Аварийное восстановление — это операционная дисциплина. План аварийного восстановления, который никогда не тестировался, остается теоретическим и непроверенным.

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

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

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

Стратегия восстановления для резервного копирования и восстановления

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

Предлагаемые действия

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

Стратегия восстановления для активно-пассивного (холодного резерва)

Развертывания с активным-пассивным резервированием удерживают вычислительные ресурсы во вторичном регионе в состоянии остановки до тех пор, пока они не понадобятся. Этот подход идеально подходит для рабочих нагрузок уровня 2 или уровня 3, где ОСРВ могут терпеть более длительные задержки, но восстановление по-прежнему должно быть надежным и повторяемым.

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

Предлагаемые действия

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

Стратегия восстановления для пассивно-активного режима (теплое резервирование)

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

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

Предлагаемые действия

Создайте стратегии восстановления для активного пассивного (холодного ожидания) и охватывайте эти моменты. При необходимости расширьте его.

Стратегия восстановления для развертываний «active-active»

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

Выберите один из двух подходов к развертыванию:

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

• Active-active (overprovisioned): зеркальные метки развертывания или геодоки в двух или более регионах. Каждый регион работает в полной мощности в любое время, самостоятельно обрабатывая 100% трафика.

Предлагаемые действия

Основывайтесь на стратегиях восстановления для режима активно-пассивного (теплого ожидания). При необходимости расширьте его.

Дальнейшие шаги

• Стратегии архитектуры RE:09 для разработки стратегии аварийного восстановления

• Стратегии архитектуры RE:05 для проектирования избыточности