HA и DR

HA (High Availability) — подход к проектированию систем, при котором сервис продолжает работать при отказе отдельных компонентов. DR (Disaster Recovery) — набор процессов и технических решений для восстановления системы после серьёзной аварии, затрагивающей площадку, регион, данные или значительную часть инфраструктуры.

Ключевые понятия:

• HA уменьшает вероятность и продолжительность локальных простоев.
• DR определяет, как восстановить сервис после масштабной аварии.
• Backup сохраняет копию данных, но сам по себе не обеспечивает ни высокую доступность, ни быстрое восстановление.
• Fault tolerance — способность продолжать работу без заметного перерыва даже при отказе компонента.
• Resilience — способность системы выдерживать сбои, адаптироваться и восстанавливаться.

Упрощённая модель:

HA: отказ экземпляра или зоны → переключение на исправный компонент
DR: потеря площадки или повреждение данных → восстановление по плану
Backup: источник данных для восстановления → требуется проверенная процедура restore

Содержание

• High Availability
• Основные HA-паттерны
• Устранение единственных точек отказа
• Балансировка нагрузки и health checks
• Отказоустойчивость приложения
• Disaster Recovery
• Планирование DR
• RTO и RPO
• Стратегии Disaster Recovery
• Резервное копирование
• Репликация
• Failover и failback
• Защита от split-brain
• Тестирование аварийного восстановления
• Наблюдаемость и оповещения
• HA и DR в Kubernetes
• Практический пример
• Чек-лист HA
• Чек-лист DR

High Availability

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

Доступность обычно выражают долей времени, когда сервис работоспособен:

Availability = Uptime / (Uptime + Downtime) × 100%

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

SLA, SLO и SLI

• SLI (Service Level Indicator) — фактически измеряемый показатель: доступность, задержка, доля ошибок, корректность обработки задач.
• SLO (Service Level Objective) — внутренняя цель для SLI, например доступность не ниже 99.95% за месяц.
• SLA (Service Level Agreement) — соглашение с пользователем или заказчиком, часто предусматривающее последствия нарушения уровня сервиса.

Пример:

SLI: доля успешных HTTP-запросов
SLO: 99.95% успешных запросов за 30 дней
SLA: при результате ниже 99.9% клиент получает компенсацию

HA-архитектура должна соответствовать SLO. Если SLO не определён, невозможно объективно решить, достаточно ли отказоустойчива система.

Основные HA-паттерны

Избыточность

Критически важные компоненты запускаются более чем в одном экземпляре:

                ┌───────────────┐
Users ─────────▶│ Load Balancer │
                └───────┬───────┘
                        │
              ┌─────────┴─────────┐
              ▼                   ▼
        App instance A      App instance B

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

Active-active

Несколько экземпляров одновременно обрабатывают трафик:

Load Balancer
 ├── App A — active
 ├── App B — active
 └── App C — active

Преимущества:

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

Ограничения:

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

Active-passive

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

Primary — active
Standby — passive

Преимущества:

• модель проще для систем, поддерживающих только одного активного владельца;
• ниже риск конфликтующей записи.

Ограничения:

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

Резерв может быть:

• hot standby — запущен, синхронизирован и почти сразу готов принять нагрузку;
• warm standby — частично подготовлен, но требует масштабирования или дополнительного запуска;
• cold standby — создаётся или восстанавливается после аварии.

N+1

Для нормальной работы требуется N компонентов, а дополнительно поддерживается хотя бы один резервный:

Требуется для нагрузки: 3 экземпляра
Работает: 4 экземпляра
Резерв: 1 экземпляр

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

Multi-AZ

Компоненты распределяются между независимыми зонами доступности одного региона:

Region
 ├── AZ-A
 │    ├── Load Balancer node
 │    ├── Application pods
 │    └── Database replica
 └── AZ-B
      ├── Load Balancer node
      ├── Application pods
      └── Database replica

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

Multi-region

Копии системы размещаются в разных регионах. Такой вариант сложнее и дороже Multi-AZ из-за:

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

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

Cell-based architecture

Инфраструктура разделяется на независимые ячейки. Каждая ячейка содержит необходимый набор компонентов и обслуживает часть пользователей:

Global Router
 ├── Cell A: app + cache + database partition
 ├── Cell B: app + cache + database partition
 └── Cell C: app + cache + database partition

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

Bulkhead

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

Примеры:

• отдельные connection pools для критических и фоновых запросов;
• отдельные очереди для разных типов задач;
• лимиты CPU и памяти;
• квоты для клиентов;
• независимые worker-пулы.

Graceful degradation

При отказе второстепенной функции система сохраняет основные возможности:

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

Для этого функции должны быть классифицированы по критичности, а зависимости — иметь определённое поведение при сбое.

Устранение единственных точек отказа

Single Point of Failure (SPOF) — компонент, отказ которого делает недоступной всю систему или критическую функцию.

Типичные SPOF:

• один экземпляр приложения;
• один балансировщик без управляемой отказоустойчивости;
• одна база данных без реплики или восстановления;
• один NAT-шлюз для нескольких зон;
• DNS, управляемый только из одной учётной записи;
• единственный VPN-шлюз или сетевой канал;
• один Kubernetes control plane;
• единственный администратор, владеющий процедурой восстановления;
• ключи шифрования без резервной процедуры доступа;
• CI/CD-система, без которой невозможно выполнить аварийное развёртывание.

Для каждого критического компонента следует определить:

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

Балансировка нагрузки и health checks

Load balancer распределяет запросы между экземплярами и исключает нездоровые цели.

L4- и L7-балансировка

Health checks

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

Пример разделения endpoint:

/live   — процесс запущен и не завис
/ready  — экземпляр готов получать пользовательский трафик
/startup — приложение завершило длительный запуск

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

Параметры health check:

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

Connection draining

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

Отказоустойчивость приложения

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

Timeout

Каждый сетевой вызов должен иметь ограничение времени:

Client timeout > API timeout > dependency timeout

Бесконечное ожидание удерживает потоки, соединения и память, что может вызвать каскадный отказ.

Retry

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

Рекомендуется применять:

• ограниченное число попыток;
• exponential backoff;
• случайный разброс задержки — jitter;
• общий deadline операции;
• повтор только для подходящих ошибок.

delay = min(base × 2^attempt + jitter, max_delay)

Нельзя бездумно повторять неидемпотентную операцию: повтор запроса на оплату или создание заказа может привести к дублям.

Идемпотентность

Идемпотентная операция при повторном выполнении приводит систему к тому же результату.

Пример с ключом идемпотентности:

POST /payments
Idempotency-Key: 2bc741c8-82f7-4e90-a03f-79b93a88f610

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

Circuit breaker

Circuit breaker временно прекращает вызовы нестабильной зависимости:

Closed → запросы проходят
Open → запросы быстро отклоняются или используется fallback
Half-open → пропускается ограниченное число тестовых запросов

Это уменьшает нагрузку на повреждённую систему и предотвращает накопление зависших запросов.

Очереди и асинхронная обработка

Очередь отделяет приём запроса от обработки:

API → Message Queue → Workers

При временной недоступности worker сообщения остаются в очереди. Необходимо учитывать:

• повторную доставку;
• идемпотентность обработчика;
• dead-letter queue;
• максимальное число попыток;
• порядок сообщений;
• срок хранения;
• мониторинг возраста и размера очереди.

Контроль нагрузки

Для защиты применяются:

• rate limiting;
• backpressure;
• ограничение очередей;
• concurrency limits;
• load shedding;
• приоритеты трафика;
• кэширование.

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

Disaster Recovery

Disaster Recovery охватывает восстановление после событий, с которыми обычные механизмы HA не справляются.

Примеры DR-сценариев:

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

HA и DR дополняют друг друга:

Планирование DR

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

Business Impact Analysis

BIA (Business Impact Analysis) определяет влияние недоступности функции на бизнес.

Для каждого сервиса фиксируют:

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

Пример классификации:

Точные значения tier и показатели устанавливаются организацией. Название уровня само по себе не заменяет числовые RTO и RPO.

Модель угроз и сценарии

План должен быть сценарным. Для каждого события описываются:

1. условие объявления аварии;
2. ответственный за решение о переключении;
3. ожидаемое состояние систем;
4. порядок действий;
5. проверки после каждого этапа;
6. критерии остановки или отката процедуры;
7. коммуникации;
8. порядок failback;
9. сбор фактов для последующего разбора.

Пример сценария:

Сценарий: основной регион недоступен более 15 минут

1. Подтвердить, что проблема не ограничена одним сервисом.
2. Назначить руководителя восстановления.
3. Заморозить обычные изменения инфраструктуры.
4. Проверить актуальность реплики и доступность DR-региона.
5. Переключить запись на DR-базу.
6. Масштабировать приложение в DR-регионе.
7. Переключить глобальную маршрутизацию.
8. Выполнить технические и бизнес-проверки.
9. Уведомить заинтересованные команды.
10. Наблюдать за ошибками, задержкой и целостностью данных.

Dependency mapping

Необходимо знать полную цепочку зависимостей:

DNS
 └── Load Balancer
      └── Application
           ├── Database
           ├── Cache
           ├── Message Queue
           ├── Object Storage
           ├── IAM / KMS
           └── External APIs

Если приложение восстановлено, но недоступны DNS, секреты, ключи шифрования или очередь, бизнес-функция всё равно не работает.

DR runbook

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

Хороший runbook включает:

• область применения;
• предпосылки;
• необходимые доступы;
• ссылки на dashboards и alerts;
• команды диагностики;
• точные шаги переключения;
• ожидаемый результат каждого шага;
• проверки целостности;
• rollback;
• failback;
• контакты и роли;
• дату последней проверки.

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

Infrastructure as Code

Terraform, CloudFormation, Pulumi и аналогичные инструменты позволяют воспроизводить инфраструктуру. Однако IaC обычно не восстанавливает пользовательские данные автоматически.

Для DR необходимо отдельно определить:

• где хранится код инфраструктуры;
• как получить доступ к репозиторию при аварии;
• где находится state;
• как защищён и резервируется state;
• как восстанавливаются секреты;
• как создаются базы и загружаются данные;
• какие ручные зависимости остаются.

RTO и RPO

RTO

RTO (Recovery Time Objective) — целевое максимальное время восстановления функции после аварии.

Авария в 10:00
RTO = 2 часа
Сервис должен быть восстановлен не позднее 12:00

RTO включает не только запуск ресурсов, но и:

• обнаружение аварии;
• принятие решения;
• получение доступов;
• восстановление инфраструктуры;
• восстановление данных;
• проверку работоспособности;
• переключение пользователей.

RPO

RPO (Recovery Point Objective) — максимально допустимый объём потери данных, выраженный во времени.

Авария в 10:00
Последняя пригодная копия — 09:45
Фактическая потеря данных — до 15 минут

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

RTO и RPO на временной шкале

Последняя пригодная                 Авария                  Восстановление
копия / точка данных                  │                           │
        │<----------- RPO ----------->│<----------- RTO ---------->│
────────┴─────────────────────────────┴────────────────────────────┴────▶

Пример требований

RTO и RPO задаются для конкретной функции или набора данных. Одно значение для всей организации обычно слишком грубое.

Фактические показатели

После теста или аварии измеряют:

• RTA (Recovery Time Actual) — фактическое время восстановления;
• RPA (Recovery Point Actual) — фактическую точку восстановления и реальную потерю данных.

Цель тестирования — доказать, что:

RTA ≤ RTO
RPA соответствует RPO

Стратегии Disaster Recovery

Стратегия выбирается исходя из RTO, RPO, бюджета, сложности и допустимого риска.

Backup and restore

Инфраструктура и данные восстанавливаются после аварии из резервных копий.

Primary environment → backups
Disaster → create infrastructure → restore data → switch traffic

Преимущества: низкая стоимость постоянных ресурсов.

Ограничения: большое RTO, риск неполной автоматизации, необходимость проверять совместимость копий и программного обеспечения.

Подходит для некритичных систем или компонентов с допустимым длительным простоем.

Pilot light

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

DR region:
- network — ready
- database replica — running
- application — minimal or stopped
- compute capacity — created during recovery

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

Warm standby

В резервном регионе работает уменьшенная копия системы. После аварии она масштабируется и принимает весь трафик.

Primary: 100% capacity
DR:      10–30% capacity → scale up during failover

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

Active-active / multi-site

Несколько регионов постоянно принимают рабочий трафик.

Преимущества: минимальное время переключения и постоянная проверка работоспособности площадок.

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

Сравнение

Значения относительные. Реальное время восстановления необходимо подтвердить тестом.

Резервное копирование

Правило 3-2-1-1-0

Практический ориентир:

• 3 копии данных, включая рабочую;
• 2 разных типа носителей или независимых систем хранения;
• 1 копия вне основной площадки;
• 1 offline, air-gapped или immutable-копия;
• 0 ошибок по результатам автоматической проверки backup и тестов restore.

Полные, инкрементальные и дифференциальные копии

Point-in-Time Recovery

PITR позволяет восстановить состояние на выбранный момент времени с помощью базовой копии и журнала изменений.

Full backup + transaction logs → restore to 2026-09-24 09:42:00

PITR полезен при ошибочном изменении или удалении данных. Реплика без PITR может быстро повторить логическую ошибку primary.

Требования к backup

Резервные копии должны быть:

• зашифрованы;
• защищены от изменения и удаления;
• изолированы от обычных административных учётных данных;
• снабжены политикой retention;
• распределены по нужным площадкам или регионам;
• наблюдаемы через метрики и alerts;
• регулярно проверяемы восстановлением.

Retention

Пример политики:

Hourly:  24 копии
Daily:   30 копий
Weekly:  12 копий
Monthly: 12 копий
Yearly:   7 копий

Политика выбирается с учётом RPO, требований хранения, объёма данных, стоимости и времени восстановления.

Backup не равен restore

Успешный статус задания backup подтверждает создание копии, но не гарантирует, что:

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

Поэтому основной критерий качества backup — успешный проверенный restore.

Репликация

Репликация поддерживает копии данных на нескольких узлах или площадках. Она повышает доступность, но не заменяет backup.

Синхронная репликация

Запись считается успешной после подтверждения несколькими узлами:

Client → Primary → Replica confirmation → Success

Преимущества: минимальная или нулевая потеря подтверждённых данных.

Ограничения: выше задержка записи; проблемы сети могут остановить запись; расстояние между узлами ограничивается требованиями latency.

Асинхронная репликация

Primary подтверждает запись до того, как replica полностью применит изменения:

Client → Primary → Success
                 └── async replication → Replica

Преимущества: меньше влияние на задержку; подходит для удалённых регионов.

Ограничения: при аварии возможна потеря последних записей; необходимо контролировать replication lag.

Semi-synchronous replication

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

Физическая и логическая репликация

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

Репликация не защищает от всех ошибок

На replica могут распространиться:

• DROP TABLE;
• ошибочный UPDATE без условия;
• повреждённые данные приложения;
• удаление объектов;
• вредоносные изменения.

Для защиты требуются versioning, immutable backups, PITR и изоляция копий.

Контроль репликации

Необходимо наблюдать за:

• replication lag по времени и объёму;
• состоянием каналов репликации;
• ошибками применения журнала;
• заполнением диска;
• расхождением данных;
• возрастом последней подтверждённой точки восстановления;
• доступностью и производительностью replica.

Failover и failback

Failover

Failover — переключение с отказавшего или недоступного primary на резервный компонент.

Он может быть:

• автоматическим — выполняется системой оркестрации после health checks и достижения quorum;
• ручным — запускается оператором после подтверждения условий;
• плановым switchover — выполняется без аварии, например для обслуживания.

Типовой процесс:

1. Detect — обнаружить проблему.
2. Confirm — исключить ложное срабатывание.
3. Fence — гарантированно отключить прежний primary от записи.
4. Promote — повысить replica до primary.
5. Redirect — переключить клиентов.
6. Validate — проверить данные и бизнес-функции.
7. Stabilize — восстановить избыточность и наблюдать систему.

Способы переключения трафика

• изменение DNS-записи;
• глобальный load balancer;
• смена target group;
• virtual IP;
• service discovery;
• изменение маршрута;
• обновление конфигурации клиентов.

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

Failback

Failback — возврат нагрузки на исходную или новую основную площадку после стабилизации.

Failback часто сложнее failover, потому что требуется:

• восстановить исходную площадку;
• синхронизировать данные в обратном направлении;
• определить источник истины;
• предотвратить конфликтующую запись;
• проверить совместимость версий;
• выполнить новое переключение;
• снова восстановить резервирование.

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

Автоматический или ручной failover

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

Критерии выбора:

• качество health checks;
• риск split-brain;
• скорость распространения ошибки;
• стоимость ложного переключения;
• частота тестирования;
• возможность быстро проверить целостность данных.

Защита от split-brain

Split-brain возникает, когда два узла считают себя primary и одновременно принимают конфликтующие записи.

Причиной может быть сетевое разделение:

Primary A  ←X→  Primary B
   ▲                 ▲
Clients A         Clients B

Quorum

Решение принимается большинством участников:

3 узла → quorum 2
5 узлов → quorum 3

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

Fencing

Fencing гарантирует, что режний primary больше не может изменять общие данные.

Варианты:

• остановка виртуальной машины через API;
• отключение сетевого доступа;
• отзыв lease;
• блокировка доступа к storage;
• STONITH в кластерных системах;
• fencing token с монотонно возрастающим номером.

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

Leader election и leases

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

Нужно учитывать:

• задержки сети;
• рассинхронизацию времени;
• паузы процесса;
• доступность хранилища координации;
• поведение при истечении lease.

Тестирование аварийного восстановления

Непроверенный DR-план является предположением. Тестирование подтверждает доступность копий, корректность runbook, наличие доступов и достижимость RTO/RPO.

Виды тестов

Проверка backup

Автоматически проверяются:

• завершение задания;
• размер копии;
• контрольная сумма;
• срок хранения;
• наличие шифрования;
• возраст последней успешной копии.

Это базовый уровень, но он не заменяет restore.

Restore test

Копия восстанавливается в изолированную среду. Проверяются:

• читаемость данных;
• запуск СУБД;
• целостность схемы;
• количество и согласованность ключевых записей;
• запуск приложения;
• бизнес-операции;
• фактическое время восстановления.

Tabletop exercise

Участники пошагово разбирают сценарий без изменения production:

«Основной регион недоступен. Кто принимает решение? Где runbook?
Как получить доступ? Какая копия используется? Как переключается DNS?»

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

Component test

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

Partial failover

Часть трафика или некритичная функция переводится на резервную площадку. Это снижает риск по сравнению с полным переключением.

Full failover test

Вся выбранная система переключается на DR-среду. Такой тест даёт наиболее реалистичные результаты, но требует строгой подготовки и rollback-плана.

Chaos engineering

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

Эксперимент должен иметь:

• гипотезу устойчивого состояния;
• ограниченную область воздействия;
• метрики;
• автоматическое или ручное условие остановки;
• rollback;
• согласованное окно проведения.

План DR-теста

1. Определить сценарий и область воздействия.
2. Зафиксировать целевые RTO и RPO.
3. Назначить роли и ответственных.
4. Проверить резервные каналы связи и доступы.
5. Подготовить критерии остановки.
6. Зафиксировать начальное состояние.
7. Выполнить процедуру по runbook.
8. Измерить RTA и фактическую потерю данных.
9. Проверить технические и бизнес-функции.
10. Выполнить failback или очистку тестовой среды.
11. Провести разбор и назначить исправления.
12. Обновить runbook и повторить проблемные этапы.

Что измерять

• время обнаружения;
• время объявления аварии;
• время получения доступа;
• длительность восстановления инфраструктуры;
• длительность restore;
• время переключения трафика;
• время полной функциональной проверки;
• потерю данных;
• число ручных шагов;
• число ошибок runbook;
• производительность резервной среды.

Проверка бизнес-функций

HTTP 200 не доказывает полное восстановление. Нужны проверки пользовательских сценариев:

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

Периодичность

Частота зависит от критичности и темпа изменений. Тест следует повторять после значимых изменений архитектуры, платформы, схемы данных, IAM, сетей или процедуры backup.

Пример программы:

Ежедневно:  проверка выполнения backup и replication lag
Еженедельно: автоматический restore небольшой выборки
Ежемесячно: restore критической базы в изолированную среду
Ежеквартально: tabletop и component failover
Раз в полгода: полный или частичный DR-тест
После крупных изменений: целевой повторный тест

Это пример, а не универсальный норматив.

Post-incident review

После теста или аварии фиксируют:

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

Цель разбора — улучшение системы и процесса, а не поиск виновного.

Наблюдаемость и оповещения

HA и DR зависят от своевременного обнаружения сбоя.

Основные сигналы

• Latency — задержка запросов;
• Traffic — объём нагрузки;
• Errors — доля ошибок;
• Saturation — исчерпание ресурсов.

Дополнительно для DR:

• возраст последнего backup;
• результат последнего restore-теста;
• replication lag;
• состояние replica;
• доступная ёмкость DR-среды;
• срок действия сертификатов;
• доступность DNS и IAM;
• расхождение конфигурации между площадками;
• готовность ключей и секретов.

Alerting

Оповещение должно быть actionable: получатель понимает, что произошло, насколько это критично и где находится runbook.

Пример структуры alert:

Problem: replication lag > 10 minutes
Impact: RPO 5 minutes may be violated
Service: orders-db
Dashboard: <link>
Runbook: <link>
Owner: database-on-call

Не следует оповещать только о CPU или памяти без связи с пользовательским воздействием. Ресурсные alerts полезны как ранние признаки, но главными остаются симптомы сервиса и нарушение SLO.

HA и DR в Kubernetes

Kubernetes перезапускает контейнеры и поддерживает желаемое число реплик, но не делает приложение автоматически отказоустойчивым.

Распределение Pod

Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
    spec:
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: topology.kubernetes.io/zone
          whenUnsatisfiable: DoNotSchedule
          labelSelector:
            matchLabels:
              app: api
      containers:
        - name: api
          image: example/api:1.4.0
          ports:
            - containerPort: 8080
          readinessProbe:
            httpGet:
              path: /ready
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 10
          livenessProbe:
            httpGet:
              path: /live
              port: 8080
            initialDelaySeconds: 20
            periodSeconds: 10
          resources:
            requests:
              cpu: 200m
              memory: 256Mi
            limits:
              memory: 512Mi

topologySpreadConstraints распределяет Pod по зонам, если nodes имеют соответствующие topology labels.

PodDisruptionBudget

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: api
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: api

PDB ограничивает добровольные disruptions, например drain узла. Он не гарантирует доступность при аварийном отказе nodes и не создаёт дополнительные replicas.

Anti-affinity

spec:
  affinity:
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
        - weight: 100
          podAffinityTerm:
            topologyKey: kubernetes.io/hostname
            labelSelector:
              matchLabels:
                app: api

Anti-affinity уменьшает вероятность размещения всех replicas на одном node.

Stateful workloads

Для StatefulSet необходимо отдельно определить:

• репликацию на уровне приложения или СУБД;
• поведение PersistentVolume при потере зоны;
• snapshots и backup;
• порядок promotion;
• fencing старого primary;
• восстановление DNS и Service;
• проверку согласованности.

Несколько Pod StatefulSet не означают, что данные реплицируются между ними.

Backup кластера

Обычно необходимо сохранять:

• декларации Kubernetes-ресурсов;
• persistent data;
• CRD и custom resources;
• конфигурацию операторов;
• необходимые secrets в защищённой форме;
• настройки ingress, DNS и сертификатов.

Если манифесты и Helm values хранятся в Git, инфраструктуру проще воссоздать, но persistent data всё равно требует отдельной стратегии.

Managed Kubernetes

Облачный провайдер может обеспечивать HA control plane, но пользователь остаётся ответственным за:

• распределение worker nodes;
• replicas приложений;
• requests и limits;
• PDB и topology constraints;
• ingress и DNS;
• backup данных;
• IAM и secrets;
• план восстановления региона;
• тестирование приложения после failover.

Практический пример

Рассмотрим веб-приложение с API, PostgreSQL, Redis, очередью и объектным хранилищем.

Требования

Доступность API: 99.95%
RTO API и базы: 30 минут
RPO транзакционных данных: 5 минут
RTO фоновой обработки: 2 часа
RPO объектных файлов: 1 час

Основная архитектура

                           ┌──────────────────┐
Users ── DNS ─────────────▶│ Cloud LB / WAF   │
                           └────────┬─────────┘
                                    │
                     ┌──────────────┴──────────────┐
                     ▼                             ▼
                 AZ-A                           AZ-B
              App replicas                  App replicas
                     │                             │
                     └──────────────┬──────────────┘
                                    │
                    ┌───────────────┼────────────────┐
                    ▼               ▼                ▼
              PostgreSQL HA      Redis HA       Message Queue
                    │
             backups + PITR
                    │
            isolated backup account

HA-меры

• балансировщик работает между зонами;
• приложение имеет не менее трёх replicas;
• replicas распределены по разным nodes и зонам;
• пользовательская сессия не хранится на локальном диске Pod;
• база имеет standby в другой зоне;
• очередь и Redis используют поддерживаемый кластерный режим;
• health checks разделены на readiness и liveness;
• обновление выполняется постепенно;
• capacity сохраняет запас при потере одного узла или зоны;
• зависимости имеют timeout, retry с backoff и circuit breaker.

DR-меры

• в резервном регионе подготовлена сеть и минимальный Kubernetes-кластер;
• database logs и snapshots копируются в резервный регион;
• объектное хранилище использует versioning и межрегиональную репликацию;
• образы контейнеров доступны независимо от основного региона;
• Terraform state и Git-репозиторий доступны при потере основной площадки;
• секреты и ключи имеют защищённую процедуру восстановления;
• глобальный DNS или load balancer может направить трафик в DR;
• runbook содержит команды масштабирования и promotion базы.

Упрощённый runbook failover

1. Подтвердить региональную аварию и объявить DR-событие.
2. Остановить автоматические deployments.
3. Проверить время последней применённой транзакции на DR-replica.
4. Зафиксировать ожидаемый RPO и возможную потерю данных.
5. Убедиться, что primary изолирован от записи.
6. Promote DR-replica.
7. Обновить application secrets и database endpoint.
8. Масштабировать node pool и application replicas.
9. Выполнить миграции только при подтверждённой совместимости.
10. Переключить глобальный трафик.
11. Проверить login, чтение, запись, очередь и файлы.
12. Контролировать error rate, latency и database health.
13. Зафиксировать RTA и фактическую точку данных.
14. После стабилизации подготовить отдельный план failback.

Проверка RPO

Предположим:

Время аварии:                   14:20
Последняя транзакция на primary: 14:19:58
Последняя транзакция на DR:      14:17:30

Потенциальная потеря:

14:19:58 - 14:17:30 = 2 минуты 28 секунд

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

Проверка RTO

Авария обнаружена:       14:20
DR объявлен:              14:27
База переключена:         14:35
Трафик переключён:        14:42
Бизнес-проверки завершены: 14:47

Фактическое время восстановления:

14:47 - 14:20 = 27 минут

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

Чек-лист HA

Архитектура

• Для сервиса определены SLI и SLO.
• Найдены и устранены критические SPOF.
• Компоненты распределены по независимым доменам отказа.
• После отказа одного компонента остаётся достаточная ёмкость.
• Приложение поддерживает запуск нескольких экземпляров.
• Состояние не зависит от локального диска конкретного экземпляра.
• База данных и очереди имеют подходящую схему высокой доступности.
• Реплики регулярно проверяются.

Приложение

• Для внешних вызовов настроены timeout.
• Retry ограничены, используют backoff и jitter.
• Критические операции идемпотентны.
• Настроен circuit breaker или контролируемый fallback.
• Приложение выдерживает повторную доставку сообщений.
• Реализованы rate limiting и защита от перегрузки.
• Некритичные функции могут деградировать независимо.

Развёртывание

• Настроены readiness, liveness и при необходимости startup probes.
• Используется connection draining.
• Обновление не останавливает все replicas одновременно.
• Есть автоматический или быстрый rollback.
• Изменения базы совместимы с поэтапным обновлением приложения.
• Регулярно проверяется отказ экземпляра, node и зоны.

Наблюдаемость

• Измеряются latency, traffic, errors и saturation.
• Есть синтетические и бизнес-проверки.
• Alerts связаны с влиянием на сервис.
• В alert указана ссылка на актуальный runbook.
• Дежурная команда имеет необходимые доступы.

Чек-лист DR

Требования

• Для критических функций определены RTO и RPO.
• Проведён BIA и задан порядок восстановления.
• Описаны сценарии потери узла, зоны, региона и данных.
• Выбрана DR-стратегия с учётом стоимости и риска.
• Определены условия объявления аварии и владелец решения.

Данные

• Backup выполняется по расписанию.
• Копии зашифрованы и имеют корректную retention policy.
• Есть изолированная или immutable-копия.
• Ключи расшифрования доступны по аварийной процедуре.
• Настроен мониторинг backup и replication lag.
• Регулярно выполняется restore в изолированную среду.
• Проверяется не только техническая, но и логическая целостность данных.

Инфраструктура

• Инфраструктура описана как код.
• Код, state, артефакты и контейнерные образы доступны при аварии.
• В DR-среде настроены сеть, IAM, DNS, сертификаты и секреты.
• Проверена доступная вычислительная ёмкость.
• Учтены внешние зависимости.
• Существует безопасный механизм fencing.
• Описаны failover и failback.

Процесс

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

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