Восстановление после сбоев

Previous Next

Восстановление платформы после крупных сбоев: отказ дата-центра, потеря данных, массовый сбой сервисов.

Цели

  • RTO (Recovery Time Objective) — целевое время восстановления сервисов после инцидента; определяется критичностью (см. Criticality).
  • RPO (Recovery Point Objective) — допустимая потеря данных (например, последние N минут транзакций); влияет на частоту бэкапов и репликации.
  • Минимизация потери данных и скорейшее возвращение к нормальной работе в рамках согласованных RTO/RPO.

Компоненты DR

Компонент Стратегия восстановления
Kubernetes Восстановление кластера из бэкапа или развёртывание нового; применение манифестов из Git (GitOps).
PostgreSQL Восстановление из WAL-архива и полных бэкапов; PITR при необходимости; реплики для снижения RTO.
Kafka Восстановление из бэкапов топиков или репликация в другой кластер; переподключение consumer'ов.
Redis Persistence (RDB/AOF) и бэкапы; при сбое — перезапуск с загрузкой дампа; кеш можно восстановить из источников (БД).
Секреты (Vault) Резервное копирование Vault; восстановление в новом инстансе; синхронизация в K8s через External Secrets.
Конфигурация Инфраструктура как код в репозитории; повторное развёртывание через CI/CD.

Процедуры

  • Runbook'и — пошаговые инструкции по восстановлению каждого критичного компонента; хранение в Runbooks, регулярное обновление и проверка на учениях.
  • Роли и эскалация — кто принимает решение о запуске DR, кто выполняет шаги; связь с Incident Management и Escalation Policy.
  • Тестирование — периодические DR-учения (восстановление в тестовом окружении) для проверки процедур и RTO/RPO.

Связь с backup и инцидентами

  • Регулярные бэкапы и их проверка — основа DR; см. Backup & Recovery.
  • При объявлении disaster (масштабный инцидент) запускается процесс DR по runbook'ам; постмортем после стабилизации — Postmortems.

Связанные страницы

Обратное давление и повторы Архитектурные принципы