Playbook отката деплоя

Составь rollback playbook для {{stack}} с БД {{db}}. Цель: от обнаружения до восстановления за ≤ 10 минут.

Стадия 1: симптомы (когда откатываем)

Автоматические триггеры (на дашборде / алертах)

• Error rate > X% за 5 минут
• p95 latency > Y ms за 5 минут
• Падение availability checks 2+ раза подряд
• Резкое падение бизнес-метрики (conversion, signups)
• Spike в 5xx логах
• Спайк в alarm от Sentry/Datadog

Ручные триггеры

• Юзер-репорт по приоритетной фиче
• Visual regression на ключевом флоу
• Платежи отваливаются

Не откатываем сразу если:

• Метрика дрогнула на < 10% и стабильна
• Известный flaky-тест в smoke
• Локальная проблема одного региона (диагностика сначала)

Стадия 2: решение

Симптомы → определить blast radius → решить:
  - Rollback (быстро вернуть стабильное)
  - Hotfix (если фикс простой, < 5 минут и понятен)
  - Disable feature flag (если фича за флагом)

Правило: если сомневаешься — откатывай. Анализ потом.

Стадия 3: как откатить (по стеку)

Vercel / Netlify / Fly

• В UI: previous deployment → Promote to production
• CLI: vercel rollback <url> / fly releases + fly deploy --image <previous>

k8s

• kubectl rollout undo deployment/<name>
• Проверь: kubectl rollout status

pm2 / systemd

• Git revert последнего merge → push → CI redeploy
• Или: pm2 reload с предыдущей сборки если хранится

Bare metal / SSH

• git revert -m 1 <merge-sha>
• ./deploy.sh или эквивалент
• Restart процессов

Стадия 4: миграции БД (самое опасное)

Принципы

• Каждая миграция — обратимая или прямо-совместимая
• ❌ DROP COLUMN в одном релизе с кодом
• ✅ Двухфазный паттерн: expand → migrate → contract
• Backup перед каждой production-миграцией

Если откат включает миграцию:

1. Проверить наличие down-migration
2. Если её нет — НЕ откатывать схему, только код
3. Скрипты восстановления данных (если был UPDATE data)
4. Snapshot/PITR — последняя линия обороны

Стадия 5: smoke-тесты после отката

Минимум:

• Главная грузится, 200
• Login работает
• Главный платный флоу: запрос → ответ
• API healthcheck → 200
• Очереди живы (если есть)
• Метрики вернулись к baseline за 5-10 минут

Стадия 6: коммуникация

Во время инцидента

• Статус-страница: «Investigating» в течение 5 мин с момента триггера
• Internal: канал #incidents, тег on-call
• Внешним: только когда подтверждено

После отката

• Обновить статус: Identified → Monitoring → Resolved
• Customer-facing post-mortem — если инцидент видел юзер

Стадия 7: пост-мортем (24-48 часов)

Шаблон

• Что произошло (факты, не оценки)
• Timeline: T0 (deploy) → T+X (alert) → T+Y (rollback) → T+Z (resolved)
• Impact: сколько пользователей, сколько денег
• Что сработало (что помогло)
• Что не сработало (где потеряли время)
• Action items: owner + due date

Blameless

• Не «кто виноват», а «какой процесс позволил»
• Не «больше внимания», а «какой автоматический контроль»

Формат вывода (артефакт)

Markdown playbook со всеми пунктами выше, конкретизированный под {{stack}} и {{db}}. Каждая команда — копипастабельная.

Анти-паттерны

• ❌ Откатывать только код, забыв про БД-миграцию
• ❌ Hotfix вместо отката когда не уверен (теряешь часы)
• ❌ «Сначала разберёмся, потом откатим» (если уже плохо)
• ❌ Нет smoke-теста после отката — откатили, а оно тоже сломано
• ❌ Пост-мортем превращён в поиск виноватого — команда учится врать
• ❌ Нет ownerа у action items — ничего не сделают
• ❌ Нет регулярных drill'ов отката (rollback заржавел)