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

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

Ми розробляємо Disaster Recovery Runbook для критичних систем — не як теорію, а як інструмент, який реально працює о 3 годині ночі, коли бізнес стоїть, а директор телефонує кожні 10 хвилин. У таких умовах допомагає тільки один формат: конкретний крок → конкретна команда → очікуваний результат → що робити, якщо щось пішло не так. Докладніше про концепцію Disaster Recovery.

Загальні фрази на кшталт «відновити базу даних з останнього бекапу» — це не runbook. Це сценарій для імпровізації, яка в стресовій ситуації майже гарантовано призведе до помилки. Наші DR-документи, навпаки, містять готові команди: від pg_ctl promote до команд Ansible для перемикання додатку.

Чому DR Runbook критично важливий?

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

Як ми розробляємо DR Runbook?

Ми не пишемо шаблонні інструкції. Кожен runbook створюється під конкретну інфраструктуру: стек, версії, топологію, хмарного провайдера. Наші інженери з семирічним досвідом у DevOps опрацьовують усі сценарії відмови — від відмови одного вузла до втрати цілої зони доступності. Тестування показало: інструкції аварійного відновлення, написані за нашим стандартом, забезпечують відновлення вдвічі швидше, ніж типові — це у 2 рази швидше за стандартні підходи. Замовте розробку 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 для ваших систем.