0Pricing
Azure Fundamentals · Урок

Определение RTO, RPO и уровней восстановления

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

«Определение RTO, RPO и уровней восстановления» — бесплатный урок Azure Fundamentals на CoddyKit. Это урок 1 из 4. Ты можешь прочитать весь урок бесплатно ниже — а потом практиковать его прямо в браузере с встроенным редактором кода и ИИ-репетитором 24/7. Это часть пути обучения Azure Fundamentals, и твой прогресс синхронизируется между веб-версией и приложением CoddyKit. Курс Azure Fundamentals содержит 4 уроков всего.

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

Планирование непрерывности бизнеса (BCP) — это процесс обеспечения непрерывности критически важных бизнес-функций во время и после аварии. В облачных вычислениях это означает проектирование систем, способных восстанавливаться после сбоев в пределах допустимых порогов времени и потери данных. Две ключевые метрики — RTO и RPO — определяют, что означает «допустимо» для каждой рабочей нагрузки.

Recovery — целевой показатель времени

Recovery Time Objective (RTO) — это максимально допустимая продолжительность недоступности системы после аварии. Этот показатель отвечает на вопрос: «Как долго бизнес может мириться с недоступностью этого приложения?». RTO выражается во времени — часах, минутах или секундах. Для системы обработки платежей RTO может составлять 15 минут, а для внутреннего HR-портала — 24 часа.

# RTO examples by workload type:
# Payment processing: RTO = 15 minutes
# E-commerce storefront: RTO = 1 hour
# Internal reporting: RTO = 4 hours
# Archive/audit data: RTO = 24 hours

# Shorter RTO = more expensive architecture required
# (warm standby, active-active, auto-failover)

Recovery — целевая точка

Recovery Point Objective (RPO) — это максимально допустимый объём потери данных, измеряемый во времени. Этот показатель отвечает на вопрос: «Какой объём данных бизнес может позволить себе потерять?». Если RPO равен 1 часу, бизнес принимает потерю данных транзакций продолжительностью до 1 часа. RPO определяет, как часто необходимо создавать резервные копии или реплицировать данные. RPO, равный 0, требует синхронной репликации, которая стоит дорого и может снизить производительность записи.

# RPO examples:
# Financial transactions: RPO = 0 (no data loss tolerated)
# E-commerce orders: RPO = 5 minutes
# User-generated content: RPO = 1 hour
# Configuration/metadata: RPO = 24 hours

# Shorter RPO = more frequent replication or synchronous writes
# = higher cost and possibly higher latency

RTO и RPO: ключевое различие

Важно не путать RTO и RPO:

  • RTO относится ко времени — как долго система недоступна
  • RPO относится к данным — какой объём данных потерян

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

Классификация рабочих нагрузок по критичности

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

  • Уровень 1 (критически важные) — строгие RTO/RPO, самые высокие затраты (например, платежи и торговые платформы)
  • Уровень 2 (важные для бизнеса) — умеренные RTO/RPO (например, CRM и ERP)
  • Уровень 3 (некритичные) — менее строгие RTO/RPO, самые низкие затраты (например, среды разработки и архивы)

Соответствие уровней возможностям Azure для восстановления

Разным уровням восстановления соответствуют разные возможности Azure:

  • Уровень 1 — запись в несколько регионов Cosmos DB, группы автоматического переключения SQL, архитектура active-active, Traffic Manager
  • Уровень 2 — Azure Site Recovery во вторичный регион, георепликация SQL (реплика для чтения), ежедневное резервное копирование с хранением в течение 30 дней
  • Уровень 3 — Azure Backup с еженедельным расписанием, без репликации, восстановление из моментального снимка

Расчёт стоимости простоя

Чтобы обосновать инвестиции в архитектуру с низким RTO, рассчитайте стоимость простоя рабочей нагрузки. Она включает потерю Revenue, штрафы по SLA для клиентов, снижение производительности Staff и ущерб репутации. Если 1 час простоя стоит $500,000, расходы в размере $50,000 в месяц на конфигурацию active-active легко обосновать. Используйте эти значения, чтобы подготовить бизнес-обоснование подходящего уровня восстановления.

# Cost of downtime formula:
# Hourly revenue at risk + (staff hours idle x hourly rate)
# + SLA penalty exposure + estimated reputational cost

# Example:
# Revenue: $100,000/hour
# Staff: 500 people x $60/hour = $30,000/hour idle
# SLA penalties: $5,000/hour
# Total cost of downtime: ~$135,000 per hour

Azure Site Recovery для уровня 2

Azure Site Recovery (ASR) — основная служба для достижения целевых показателей RTO/RPO уровня 2 в Azure. ASR непрерывно реплицирует VMs во вторичный регион и может инициировать переключение за несколько минут. Частота репликации для Azure VMs составляет 30 секунд (согласованность после сбоя) или 1–4 часа (согласованность приложения), поэтому RPO обычно находится в этом диапазоне в зависимости от Configuration.

# Enable replication for a VM with ASR:
az site-recovery protected-item create \
  --resource-group myRG \
  --vault-name myRecoveryVault \
  --fabric-name 'Primary' \
  --container-name 'asr-a2a-default-eastus-container' \
  --protected-item-name myVM-protected

RPO и частота резервного копирования

Для рабочих нагрузок, где RPO измеряется часами, достаточно использовать Azure Backup с подходящим расписанием. Например, для RPO в 4 часа требуется интервал резервного копирования не более 4 часов. Azure Backup поддерживает расширенные политики, позволяющие задавать почасовое резервное копирование Azure VMs. Для баз данных восстановление на момент времени (PITR) с резервными копиями журналов транзакций позволяет достичь RPO менее 1 часа при меньшей стоимости, чем ASR.

Документирование обязательств по RTO и RPO

Целевые показатели RTO и RPO следует официально документировать в анализе влияния на бизнес (BIA) и проверять с участием технических специалистов и представителей бизнеса. BIA сопоставляет каждое приложение с его уровнем восстановления, документирует целевые показатели RTO/RPO, определяет службы Azure, которые обеспечат эти показатели, и задаёт расписание проверок (как часто план DR проверяется с помощью учений).

Проверка соответствия целевым показателям RTO/RPO

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

Быстрая проверка

Проверьте своё понимание концепций Microsoft Azure Fundamentals (AZ-900) из этого урока.

Итоги урока

В этом уроке Вы узнали, что RTO — это максимально допустимое время простоя, а RPO — максимально допустимая потеря данных, измеряемая во времени; рабочие нагрузки классифицируются по уровням восстановления, которым соответствуют определённые службы Azure; а тестирование необходимо для проверки достижимости целевых показателей RTO/RPO. Далее мы рассмотрим планы восстановления и автоматическое переключение с помощью Azure Site Recovery.

Часто задаваемые вопросы

Урок «Определение RTO, RPO и уровней восстановления» бесплатный?

Да — полный текст урока «Определение RTO, RPO и уровней восстановления» бесплатно доступен здесь в веб-версии. Чтобы практиковать его интерактивно (встроенный редактор кода и ИИ-репетитор 24/7) и разблокировать остальной курс Azure Fundamentals, подпишись на CoddyKit PRO. Курс Azure Fundamentals содержит 4 уроков всего.

Чему я научусь в уроке «Определение RTO, RPO и уровней восстановления»?

Классифицируйте рабочие нагрузки по критичности, назначьте целевые значения RTO и RPO и сопоставьте их с подходящими возможностями восстановления Azure и частотой репликации. Ты практикуешь Azure Fundamentals с помощью реального кода, который запускаешь прямо в браузере, и ИИ-репетитор 24/7 отвечает на твои вопросы во время урока.

Нужен ли мне опыт, чтобы начать Azure Fundamentals?

Предыдущий опыт не требуется. Azure Fundamentals на CoddyKit структурирован для всех уровней — от новичков до продвинутых, поэтому ты можешь начать отсюда или с самого начала и учиться в своем темпе. Это урок 1 из 4.

Сколько времени занимает урок «Определение RTO, RPO и уровней восстановления»?

Большинство уроков CoddyKit занимают около 5–10 минут. Каждый из них компактный и интерактивный, поэтому ты постоянно делаешь прогресс и продолжаешь с того же места в веб-версии и приложении.

Можно ли писать и запускать код в этом уроке Azure Fundamentals?

Да. Каждый урок Azure Fundamentals включает встроенный редактор кода, поэтому ты пишешь и запускаешь реальный код прямо в браузере и получаешь моментальную обратную связь от AI — локальная установка не требуется.

Все уроки этого курса

  1. Определение RTO, RPO и уровней восстановления
  2. Планы восстановления и автоматическое переключение
  3. Тестирование DR без влияния на рабочую среду
  4. DR для служб PaaS
← Назад к Azure Fundamentals