Розроблення плану аварійного восстановлення (DRP)
Disaster Recovery Plan (DRP) — документований набір процедур для відновлення IT-інфраструктури після катастрофічного сбою. Без DRP команда паніує, дані втрачаються, відновлення займає дні замість годин. Хороший DRP існує у двох форматах: детальний документ для аналізу та короткі runbook'и для виконання о 3 ночі.
Структура DRP
1. Класифікація сценаріїв за пріоритетом
| Сценарій | RTO | RPO | Ймовірність |
|---|---|---|---|
| Падення сервера програм | 15 хв | 0 | Висока |
| Відказ primary БД | 30 хв | 5 хв | Середня |
| Втрата дата-центра (регіон) | 4 ч | 1 ч | Низька |
| Атака ransomware / видалення даних | 8 ч | 24 ч | Низька |
| Помилка деплоя (критична регресія) | 30 хв | 0 | Висока |
2. Відповідальні та контакти
# drp/contacts.yml
incident_commander: "CTO"
primary_oncall: "DevOps Team"
contacts:
- role: "Incident Commander"
name: "Aleksei Petrov"
phone: "+7-xxx-xxx-xxxx"
telegram: "@apetrov"
- role: "DB Admin"
name: "Marina Sidorova"
phone: "+7-xxx-xxx-xxxx"
3. Інвентаризація критичних компонентів
# 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: втрата primary БД
# RUNBOOK: PostgreSQL Primary Failure
**Час:** 15-30 хвилин
**Вимоги:** доступ AWS, ssh до серверів
## Кроки
### 1. Підтвердити відказ (2 хв)
```bash
ssh db-primary.internal
psql -h db-primary.internal -U postgres -c "SELECT 1;"
2. Вибрати кращу реплік (3 хв)
Перевірити запізнення на кожній реплік та вибрати ту, що має найменше запізнення.
3. Промоут реплік (5 хв)
patronictl -c /etc/patroni/patroni.yml failover cluster-name --master db-replica-1
4. Перенаправити трафік (5 хв)
Оновити DNS або HAProxy
5. Перезапустити програму (2 хв)
kubectl rollout restart deployment/api -n production
6. Верифікація
curl https://api.example.com/health
psql -h db-primary.example.com -U app -c "SELECT count(*) FROM users;"
### Автоматизація DR-процедур
```bash
#!/bin/bash
# scripts/dr/db-failover.sh
# Автоматичний failover при підтвердженому відказі primary
set -euo pipefail
# 1. Підтвердити відказ
if pg_isready -h "$DB_PRIMARY_HOST" -U postgres -t 5; then
echo "[$(date -u)] Primary is up. Aborting."
exit 1
fi
# 2. Знайти кращу реплік
BEST_REPLICA=""
BEST_LAG=999999999
for replica in $DB_REPLICAS; do
LAG=$(psql -h $replica -U postgres -tAc "
SELECT extract(epoch from (now() - pg_last_xact_replay_timestamp()))::int
" 2>/dev/null || echo 999999999)
if [ "$LAG" -lt "$BEST_LAG" ]; then
BEST_LAG=$LAG
BEST_REPLICA=$replica
fi
done
# 3. Промоут (Patroni)
patronictl -c /etc/patroni/patroni.yml failover \
postgres-cluster --master $BEST_REPLICA --force
# 4. Сповістити Slack
curl -s -X POST "$SLACK_WEBHOOK" -H 'Content-type: application/json' \
-d "{\"text\": \"DB Failover completed. New primary: $BEST_REPLICA (lag was ${BEST_LAG}s)\"}"
Тривалість
Розроблення повного DRP з runbook'ами для 5–10 сценаріїв, інвентаризацією та скриптами автоматизації — 3–5 робочих днів.