Runbook — Откат релиза

Когда: только что задеплоенная версия Notty показывает деградацию (5xx, рост latency, поломанные сценарии). Цель — откатить как можно быстрее, потом разбираться.

Главное правило: rollback всегда выполняется до анализа. Не теряйте время на «ещё чуть-чуть посмотрим».

Decision (≤ 2 мин)

Триггер на rollback:

• 5xx error rate > 1% больше 5 мин;
• p95 latency > 2× baseline больше 10 мин;
• readiness probe нестабилен > 5 мин;
• появились критические алёрты, не существовавшие до деплоя;
• регрессия в admin UI, блокирующая работу операторов.

При сомнении — откатывайте.

Rollback — Kubernetes

# 1. Откатить Deployment к предыдущему ReplicaSet
kubectl -n notty rollout undo deploy/notty
kubectl -n notty rollout status deploy/notty --timeout=180s

# Альтернатива — фиксированная ревизия:
kubectl -n notty rollout history deploy/notty
kubectl -n notty rollout undo deploy/notty --to-revision=<N>

# 2. Smoke
./deployment/scripts/verify-deploy.sh https://cms.example.com

maxUnavailable: 0 ⇒ rollback тоже без даунтайма.

Rollback — docker-compose

# Используйте предыдущий tag image (зафиксированный в pre-deploy шаге)
export NOTTY_TAG=<previous_sha>
docker compose -f deployment/docker-compose.yml pull notty
docker compose -f deployment/docker-compose.yml up -d --no-deps notty
./deployment/scripts/verify-deploy.sh http://localhost:2102

База

Откат image сам по себе не откатывает БД. Если новый релиз сделал схемы-миграцию, которую старый код не понимает:

1. Решите: можно ли продолжать на старом коде с новой схемой? Часто — да (новые поля просто игнорируются).
2. Если нет — нужен полный restore из backup'а. См. database-restore.md.
3. Никогда не «понижайте» managed PG версии руками во время инцидента.

Подтверждение

• verify-deploy.sh зелёный.
• /api/health возвращает ожидаемую (предыдущую) версию.
• Метрики error rate / latency вернулись к baseline.
• Алёрты, поднявшиеся при деплое, гаснут.

Communication

Сразу после rollback в operations-канал:

↩️ rollback notty <bad_sha> → <good_sha>
- reason: <короткая причина>
- ETA postmortem: <дата/время>

Postmortem

В течение 24 часов: postmortem с разбором — что сломалось, почему не поймали в CI/staging, какие алёрты сработали, какой был MTTR. Шаблон — incident-response.md, секция Postmortem.