План аварийного восстановления (DRP) для сайта

Представьте: ваш сайт не загружается, команда в панике, данные под угрозой. Без заранее подготовленного плана аварийного восстановления каждый час простоя может стоить сотен тысяч долларов потери выручки и репутации. Типичная ситуация — отказ primary PostgreSQL в час пик. Ручное восстановление занимает 30–60 минут, автоматическое — 2–3 минуты. Разница в 10–20 раз — критично для интернет-магазина или SaaS. Disaster Recovery Plan (DRP) — это документированный набор процедур, позволяющий восстановить инфраструктуру за минуты. В статье разберём, из чего состоит готовый DRP, какие сценарии он покрывает, и как мы его создаём.

Какие сценарии отказов покрывает DRP?

Любой план начинается с классификации возможных сбоев. Для каждого сценария определяем целевое время восстановления (RTO) и точку восстановления (RPO). Вот типичная матрица для среднестатистического веб-проекта:

Как автоматизация сокращает время восстановления?

Сравним ручной процесс и автоматический failover на Patroni. Разница драматическая — автоматизация сокращает RTO в 10–20 раз:

По данным Gartner, компании с автоматизированным DRP сокращают простой на 60% и экономят в среднем $250 000 на инцидент.

Этапы разработки Disaster Recovery Plan

Процесс создания DRP состоит из пяти этапов:

1. Анализ инфраструктуры. Выявляем критически важные компоненты: базы данных (PostgreSQL, MySQL), серверы приложений, Redis, объектные хранилища (S3). Определяем RTO и RPO для каждого.
2. Проектирование сценариев. Описываем возможные отказы и назначаем ответственных. Контакты и роли фиксируются в YAML-файле.
3. Создание runbook'ов. Пишем пошаговые инструкции для каждого сценария. Runbook содержит признаки отказа, команды для диагностики и восстановления, а также пост-инцидентные действия.
4. Автоматизация. Разрабатываем bash-скрипты для автоматического failover. Используем Patroni для управления кластером PostgreSQL, Ansible для развёртывания, AWS Route53 для DNS-переключения.
5. Тестирование и доработка. Проводим симуляцию отказа (DR Drill) и корректируем процедуры.

Пример инвентаризации критических компонентов

Каждый DRP включает список всех критических систем с указанием резервных копий, репликации и ссылок на runbook'и. Вот фрагмент такого описания:

# drp/inventory.yml critical_systems: - name: "PostgreSQL Primary" host: "db-primary.internal" backup_location: "s3://backups/postgres/" backup_frequency: "hourly" replication: "streaming to db-replica-1, db-replica-2" runbook: "runbooks/db-failover.md" - name: "Application Servers" hosts: ["app-1", "app-2", "app-3"] ami_id: "ami-0abc123def456" auto_scaling_group: "app-asg-prod" runbook: "runbooks/app-restore.md" - name: "Redis" host: "redis-primary.internal" persistence: "RDB + AOF" backup_location: "s3://backups/redis/" runbook: "runbooks/redis-restore.md" - name: "S3 Media Bucket" bucket: "myapp-media-prod" replication: "Cross-region to eu-west-1" runbook: "runbooks/s3-restore.md" 

Пошаговая инструкция при отказе primary БД

Рассмотрим конкретный сценарий — потерю primary PostgreSQL. Вот краткий алгоритм из runbook:

1. Подтвердить отказ. Проверьте доступность хоста: ssh db-primary.internal и выполните psql -h db-primary.internal -U postgres -c "SELECT 1;". Если нет ответа — primary недоступен.
2. Выбрать лучшую реплику. На каждой реплике проверьте отставание: pg_last_wal_receive_lsn() - pg_last_wal_replay_lsn(). Выбирайте ту, где lag наименьший.
3. Промоут реплики. Если используется Patroni: patronictl failover cluster-name --master db-replica-1. Вручную: pg_ctl promote.
4. Перенаправить трафик. Обновите DNS или HAProxy: aws route53 change-resource-record-sets ... с TTL 60 секунд.
5. Перезапустить приложение. Например, kubectl rollout restart deployment/api -n production.
6. Верифицировать. Выполните health-check и тестовый запрос к БД.
7. Пост-инцидент. Создайте новую реплику, расследуйте причину отказа, обновите мониторинг.

Что входит в готовый DRP?

После завершения работы вы получаете:

• Документ с классификацией сценариев, контактами и ответственными.
• 5–10 runbook'ов в формате Markdown для каждого критического сценария.
• Автоматизированные скрипты для failover (bash, Ansible) с интеграцией в Slack и PagerDuty.
• Полную инвентаризацию критических компонентов.
• Рекомендации по мониторингу (метрики, алерты, дашборды).
• Одну сессию обучения команды.
• Доступ к Git-репозиторию с документацией и скриптами.

Почему важно регулярно тестировать DRP?

План, который не тестировали, — это фикция. Мы рекомендуем проводить учения ежеквартально:

• Каждый квартал: симуляция отказа primary БД (failover drill). Критерии успеха: восстановление менее чем за 30 минут, нулевая потеря данных, автоматическое восстановление приложения.
• Раз в год: полный отказ региона (region failover). Цель — восстановление менее чем за 4 часа с потерей данных не более 1 часа.

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

Сроки и стоимость разработки

Стандартный план для типового веб-проекта разрабатывается за 3–5 рабочих дней. Стоимость рассчитывается индивидуально в зависимости от сложности инфраструктуры и количества сценариев. Мы работаем с сайтами на любой CMS и стеке — от WordPress до высоконагруженных проектов на React/Node.js.

Наш опыт: более пяти лет на рынке, свыше 20 проектов по аварийному восстановлению, сертификация AWS. Мы гарантируем, что каждый runbook проходит тестирование. Простой сайта может стоить от $1k–5k в час для интернет-магазина, а разработка DRP обходится в сумму от $500–1.5k и окупается при первом же серьезном сбое.

Хотите получить такой план для своего сайта? Свяжитесь с нами для консультации и закажите разработку DRP уже сегодня.