Автоматизация rollback

Действуй как SRE. Спроектируй automated rollback для {{service}} на {{platform}}.

Шаги

1. Определи триггеры (что запускает rollback).

   • Error rate spike. 5xx > baseline * 3 в течение 2 минут после deploy. Источник: load balancer / APM (Datadog APM, NewRelic).
   • Health-check fail. /health или /ready валится на > 30% подов за 5 минут (k8s readiness gate).
   • SLO breach. Burn rate > 14.4 (consumes 2% of monthly budget in 1 hour) → fast burn alert → rollback.
   • Latency regression. p95 > baseline * 1.5 в течение 5 минут.
   • Resource saturation. Memory/CPU > 90% на > 50% подов (часто = memory leak в новой версии).
   • Custom business metric. Conversion drop > 20%, payment success rate < 95%, etc. — domain-specific.

2. Дизайн detection-to-action loop.

   • Окно наблюдения: 5-10 минут после deploy/promote. Дольше — пропустим инциденты. Короче — false positives.
   • Baseline: rolling 24 часов или previous version performance (более устойчив к сезонности).
   • Confidence interval: используй statistical tests (e.g. Mann-Whitney U) для нешумных сигналов, hard thresholds для шумных.
   • Action: для canary → traffic shift back (Argo Rollouts abort, Flagger Halt), для blue-green → router flip, для rolling → kubectl rollout undo.

3. Data integrity и ограничения.

   • БД-миграции необратимы кодом. Принцип: expand-contract — миграция (DDL) совместима со старой и новой версией кода. Rollback откатывает только код, миграция остаётся.
   • Никогда не drop column / drop table в release-deploy. Только soft-deprecate, удаление в отдельном release N+2.
   • Queue / event consumers. Новая версия может потреблять сообщения, которые старая не поймёт. Mitigation: версионируй message schema, старая версия игнорирует unknown fields (semantic versioning сообщений).
   • Caches. Новая версия пишет в кеш формат, который старая не читает — после rollback кеш отравлен. Mitigation: cache keys включают version или схему.
   • External side effects (платежи, email). Идемпотентность — обязательна. Без неё rollback может вызвать дубли.

4. Manual override.

   • Big red button. Команда /rollback <service> <version> в ChatOps + workflow_dispatch в CI. Доступ — у oncall + release manager.
   • Approval bypass для emergencies. Обычный production deploy требует approval — rollback в инциденте не требует (audit log фиксирует).
   • Rollback to specific version. Не только N-1: иногда нужно N-3 (если N-1 и N-2 имели тот же баг).
   • Documentation: runbook привязан к alert (Slack/PagerDuty action) — один клик ведёт к команде.

5. Verify rollback succeeded.

   • Re-run smoke tests post-rollback. Без verification rollback может «успешно сделаться» в неработающий N-1.
   • Метрики вернулись к baseline за 5-10 минут? Если нет — escalate (возможно проблема не в коде, а в инфре/upstream).

Anti-patterns

• ❌ Rollback по одной метрике (только error rate) — пропустит latency-only регрессии. Multi-signal обязателен.
• ❌ Rollback без cooldown — после flap (рост → откат → восстановление → новый деплой) может зациклиться.
• ❌ git revert + новый CI/CD прогон как rollback — слишком медленно. Артефакт N-1 должен быть готов.
• ❌ Тестирование rollback только в DR-учении раз в год — в момент инцидента runbook protokoль не работает.
• ❌ Auto-rollback в БД-миграциях (DROP COLUMN назад) — потеря данных. Только code rollback.

Формат вывода

## Triggers
| Signal | Threshold | Window | Source |

## Rollback action per scenario
| Scenario | Strategy | Command | Verification |

## Constraints
- DB: ...
- Queues: ...
- Caches: ...
- Side effects: ...

## Runbook (paste-ready for incident)
1. Confirm trigger
2. Execute: <command>
3. Verify: <metrics>
4. Communicate: <#incidents channel template>
5. Postmortem trigger if MTTR > 15 min

## Tested? When was last drill?

Принцип: rollback — это не «план Б». Это первичная функция production-системы. Если rollback не тестируется регулярно, его нет.