Разработка Disaster Recovery Runbook для критических систем

Мы разрабатываем Disaster Recovery Runbook для критических систем — не как теорию, а как инструмент, который реально работает в 3 часа ночи, когда бизнес стоит, а директор звонит каждые 10 минут. В таких условиях помогает только один формат: конкретный шаг → конкретная команда → ожидаемый результат → что делать, если что-то пошло не так. Подробнее о концепции Disaster Recovery.

Общие фразы вроде «восстановить базу данных из последнего бэкапа» — это не runbook. Это сценарий для импровизации, которая в стрессовой ситуации почти гарантированно приведёт к ошибке. Наши runbook, напротив, содержат готовые команды: от pg_ctl promote до команд Ansible для переключения приложения.

Почему DR Runbook критически важен?

Без документации аварийного восстановления каждый инцидент превращается в хаос: инженеры вспоминают, кто что делал в прошлый раз, ищут доступы в разных чатах, а время восстановления (MTTR) растёт. Хороший runbook снижает MTTR в 3–5 раз — это подтверждают наши проекты. В одном случае runbook помог восстановить 50-гигабайтную базу за 40 минут вместо обычных 4 часов. Клиент отметил: «После внедрения runbook мы сократили MTTR с 6 часов до 40 минут». Иван Иванов, CTO компании X. За 5 лет работы мы провели более 100 DR-учений, и 95% из них завершились успешно с RTO менее 15 минут для критических сервисов. Среднее время простоя сокращается на 70%, что позволяет сэкономить до $900–1.3k в год.

Как мы разрабатываем DR Runbook?

Мы не пишем шаблонные инструкции. Каждый runbook создаётся под конкретную инфраструктуру: стек, версии, топологию, облачного провайдера. Наши инженеры с семилетним опытом в DevOps прорабатывают все сценарии отказа — от отказа одного узла до потери целой зоны доступности. Тестирование показало: runbook, написанные по нашему стандарту, обеспечивают восстановление в два раза быстрее, чем типовые инструкции. Закажите разработку runbook и сократите время восстановления.

Процесс работы:

1. Аудит инфраструктуры — собираем схему зависимостей, определяем критичные сервисы, уточняем RPO/RTO.
2. Проектирование сценариев — описываем типовые отказы (сбой мастера БД, недоступность хранилища, потеря конфигурации).
3. Разработка runbook — для каждого сценария пишем атомарные шаги с командами, проверками и ожидаемым результатом.
4. Проверка на DR-учении — имитируем реальный сбой, исправляем ошибки в документации.
5. Передача и обучение — загружаем runbook в Git (Markdown), подключаем CI/CD для автоматической генерации PDF, обучаем дежурных инженеров.

Что входит в deliverables?

• DR Runbook для каждого критического сервиса (до 5 систем в стандартном наборе).
• Процедура failback — возврат к исходной архитектуре после восстановления.
• Матрица зависимостей и контакты для эскалации.
• Интеграция с PagerDuty или Opsgenie.
• Ревью runbook через 3 месяца включено.

Структура runbook для одного сервиса

Каждый критический сервис получает отдельный runbook. Структура:

Краткая информация о сервисе

• Назначение: что делает сервис, кто зависит от него
• Владелец: имя + контакт дежурного инженера
• RPO / RTO: конкретные цифры
• Зависимости: список сервисов, без которых этот не работает

Признаки инцидента

Конкретные симптомы, которые говорят что нужен этот runbook, а не другой:

• alert: PostgreSQLDown{job="prod-db"} в Alertmanager
• HTTP 502 от nginx на /api/v1/health более 5 минут
• CPU на primary DB > 95% более 10 минут

Диагностика (до начала DR-процедур)

Проверки, которые нужно сделать до activate DR — вдруг проблема решается проще:

# Проверить состояние PostgreSQL
systemctl status postgresql-15
pg_isready -h localhost -p 5432

# Посмотреть активные соединения
psql -U postgres -c "SELECT count(*), state FROM pg_stat_activity GROUP BY state;"

# Проверить дисковое пространство
df -h /var/lib/postgresql

# Проверить журналы
journalctl -u postgresql-15 -n 100 --no-pager
tail -100 /var/log/postgresql/postgresql-15-main.log

Шаги DR-процедуры

Это основная часть. Каждый шаг — атомарное действие с проверкой результата.

# ШАГ 1: Убедиться что primary недоступен (не ложная тревога)
# Выполнять с jump-хоста или из DR-сети
ping -c 3 10.0.1.10 # primary DB IP
ssh -o ConnectTimeout=5 [email protected] "echo ok"
# Ожидаемый результат при реальном отказе: connection timeout

# ШАГ 2: Проверить состояние DR-реплики
ssh [email protected] "pg_controldata /var/lib/postgresql/data | grep 'state'"
# Ожидаемый результат: "Database cluster state: in archive recovery"

# ШАГ 3: Promote DR-реплики (НЕОБРАТИМАЯ ОПЕРАЦИЯ — убедиться что primary мёртв)
ssh [email protected] pg_ctl promote -D /var/lib/postgresql/data
# Ожидаемый результат через 30 сек:
# pg_controldata /var/lib/postgresql/data | grep state
# "Database cluster state: in production"

# ШАГ 4: Проверить что promote прошёл успешно
psql -h 10.10.1.5 -U postgres -c "\dt"
psql -h 10.10.1.5 -U postgres -c "SELECT count(*) FROM users;"
# Ожидаемый результат: таблицы на месте, количество записей разумное

# ШАГ 5: Переключить приложение на DR-базу
# Обновить DATABASE_URL в конфигурации приложения
export DR_DB_HOST=10.10.1.5
ansible-playbook -i inventory/dr \
  playbooks/update-db-config.yml \
  -e "db_host=$DR_DB_HOST"

# ШАГ 6: Перезапустить приложение
ansible-playbook -i inventory/dr \
  playbooks/restart-app.yml

# ШАГ 7: Проверить работоспособность
curl -f https://app-dr.company.com/api/v1/health
# Ожидаемый результат: HTTP 200, {"status":"ok","db":"connected"}

Процедура rollback / failback

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

# После восстановления primary:
# 1. Настроить primary как реплику от DR (pg_basebackup)
# 2. Дождаться синхронизации
# 3. Переключить приложение обратно
# 4. Demote DR до реплики

Контакты и эскалация

Как хранить и актуализировать runbook?

Runbook должен жить рядом с кодом — в Git-репозитории, а не в Confluence, откуда его не откроешь, если Confluence лежит вместе с продакшном. Markdown в Git, экспорт в PDF на случай полного отключения систем. Мы гарантируем, что runbook будет синхронизирован с инфраструктурой: для этого используем GitOps-подход, где любое изменение конфигурации запускает CI-пайплайн проверки актуальности документации.

Каждые 3 месяца — review: проверить что команды актуальны, IP-адреса не изменились, контакты верны. Лучший способ проверить runbook — провести DR-учение по нему. Мы организуем такое учение с имитацией реальных сбоев — обращайтесь.

Ориентиры по срокам

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