План аварийного восстановления (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 проходит тестирование. Простой сайта может стоить от 100 000 до 500 000 рублей в час для интернет-магазина, а разработка DRP обходится в сумму от 50 000 до 150 000 рублей и окупается при первом же серьезном сбое.

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

Мы регулярно сталкиваемся с ситуацией: «Сайт не открывается» в 3 часа ночи — и выясняется, что disk full на VPS, потому что логи nginx не ротировались полгода. Или сервер лёг под нагрузкой в день запуска рекламной кампании, потому что на shared хостинге стоял лимит в 50 одновременных соединений. Настройка хостинга и деплоя — это не про «где дешевле», это про то, что происходит в момент, когда что-то идёт не так. Наша команда помогает избежать таких инцидентов, проектируя инфраструктуру с учётом реальных паттернов нагрузки.

Когда выбирать Vercel и Netlify?

Vercel создан под Next.js — деплой в один push, preview deployments для каждого PR, автоматический CDN, Edge Functions, ISR без конфигурации. Для фронтенд-проектов и JAMstack это оптимальный выбор: нет операционной нагрузки, time-to-deploy измеряется минутами.

Ограничения реальные: Vercel Serverless Functions запускаются в us-east-1 по умолчанию (latency для Европы +80–100ms), Function timeout 300 секунд на Pro, Bandwidth 1TB/месяц на Pro. Для тяжёлого backend — нужны воркеры или отдельный сервер.

Netlify ближе к статике и Edge Functions на базе Deno Deploy. Build minutes — основное ограничение на бесплатном тарифе.

Почему Docker — основа предсказуемого деплоя?

«Работает на моей машине» — классика. Docker решает это через контейнеризацию окружения. Но плохой Dockerfile создаёт новые проблемы.

Типичная ошибка: копировать всё в образ без .dockerignore, получать 800MB образ вместо 80MB. node_modules внутри образа весит столько же. Правильно: multi-stage build.

FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
RUN npm run build

FROM node:20-alpine AS runner
WORKDIR /app
COPY --from=builder /app/.next ./.next
COPY --from=builder /app/node_modules ./node_modules
COPY --from=builder /app/package.json ./package.json
EXPOSE 3000
CMD ["npm", "start"]

Итоговый образ: 180MB вместо 1.2GB. Время сборки CI сокращается из-за layer caching — если package.json не изменился, слой с npm ci берётся из кэша.

Docker Compose для локальной разработки и простых продакшен-сценариев: приложение + PostgreSQL + Redis в одной конфигурации. Для production на одном сервере — вполне рабочий вариант, если нет требований горизонтального масштабирования.

Подробнее о контейнеризации — Wikipedia: Docker.

Как настроить Nginx как reverse proxy?

Nginx перед приложением — стандарт для VPS и выделенных серверов. Основные функции: SSL termination, gzip, static files, rate limiting, upstream балансировка.

Конфигурация, которую часто делают неправильно: worker_processes auto — количество процессов равно числу CPU. worker_connections 1024 — это 1024 на каждый воркер-процесс. При 4 CPU и 1024 connections = 4096 одновременных соединений. Для высоконагруженного сайта нужно worker_connections 4096 и настройка keepalive_timeout 65.

Для статических ассетов с хешем в имени файла:

location ~* \.(js|css|woff2|png|webp)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
}

immutable сообщает браузеру: не проверяй этот файл даже при hard refresh. Правильно работает только с content-hashed именами файлов (что делает Vite/webpack по умолчанию). Документация — Wikipedia: Nginx.

AWS: гибкость и сложность

EC2 + Auto Scaling Group — классика для горизонтального масштабирования. AMI с предустановленным приложением, Launch Template, ASG с min/desired/max instances, Application Load Balancer. При CPU > 70% на 3 минуты — scale out, при CPU < 30% на 15 минут — scale in. Health check через ALB исключает нездоровые инстансы из ротации.

ECS Fargate — контейнеры без управления EC2. Деплой Docker-образа, задаёте CPU/память (512 CPU units = 0.5 vCPU, от 512MB памяти), Fargate запускает. Дороже Lambda, но нет cold start и нет timeout-ограничений. Подходит для long-running процессов, WebSocket-серверов, тяжёлых воркеров.

RDS для PostgreSQL с Multi-AZ: автоматический failover за 1–2 минуты при падении primary. Read Replicas для масштабирования чтения. RDS Proxy для connection pooling — Lambda-функции не умеют держать долгосрочные соединения, прокси буферизует это.

Kubernetes: когда это оправдано

K8s добавляет значительную операционную сложность. Оправдан, когда: несколько команд деплоят независимые сервисы, нужна тонкая настройка ресурсов на сервис, canary deployments и blue/green без простоя — требование.

AWS EKS, GKE или managed k8s от Hetzner (дешевле). Helm charts для стандартных сервисов. Horizontal Pod Autoscaler по CPU и custom metrics (RPS через Prometheus).

Для большинства стартапов и средних проектов — Kubernetes избыточен. ECS или Fly.io дают 80% возможностей при 20% операционной сложности.

Мониторинг и alerting

Сервер без мониторинга — это ожидание инцидента. Минимальный стек: Prometheus + Grafana (или Grafana Cloud для managed), alerting на disk > 80%, memory > 85%, CPU > 90% за 5 минут, error rate > 1%. Uptime через Better Uptime или Upptime (self-hosted).

Logs: Loki + Grafana или CloudWatch Logs Insights. Структурированные JSON-логи (winston, pino) — обязательно, иначе поиск по логам превращается в боль.

Что входит в настройку хостинга

• Аудит текущей инфраструктуры и профилирование нагрузки
• Выбор целевой архитектуры (VPS, AWS, serverless, Kubernetes)
• Настройка CI/CD pipeline (GitHub Actions, GitLab CI) с автоматическим деплоем
• IaC через Terraform или Pulumi (инфраструктура как код)
• Конфигурация Nginx, SSL-сертификаты, HTTP/2, brotli
• Мониторинг и алертинг (Prometheus + Grafana, PagerDuty)
• Документация runbooks и обучение команды

Дополнительно: пишите, если нужна миграция с текущего хостинга или интеграция с внешними сервисами.

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

1. Аудит текущей инфраструктуры (2–5 дней)
2. Выбор целевой архитектуры с обоснованием по нагрузке и бюджету (1–3 дня)
3. Настройка CI/CD pipeline (GitHub Actions, GitLab CI) (2–5 дней)
4. IaC через Terraform или Pulumi (3–10 дней)
5. Настройка мониторинга и alerting (2–5 дней)
6. Документация runbooks и обучение команды (1–3 дня)

Наш опыт — 7 лет на рынке, более 50 проектов, гарантия работоспособности после деплоя.

Сроки

• Базовый деплой на VPS с Docker + Nginx + CI/CD: 1–2 недели.
• Настройка AWS инфраструктуры с Auto Scaling, RDS, CDN: 3–6 недель.
• Миграция на EKS с нуля: 6–12 недель.
• Настройка Vercel/Netlify для JAMstack: 3–5 дней.

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