Ролбэки и восстановление стабильности

(Раздел: Технологии и Инфраструктура)

Краткое резюме

Откат — это управляемое возвращение к последней стабильной версии с минимальным риском потери данных и нарушений SLO. Надежный процесс включает: сигналы SLO, четкие гейты и критерии отката, механизм переключения (GitOps/Ingress/меш), совместимую схему данных, изолированные конфиги/секреты/кэши, рунабук-и и пост-инцидентный цикл улучшений.

1) Когда откатывать (критерии запуска)

SLO/бизнес-гейты: p95/99 выше порога, error-rate ↑, падение конверсии платежей/ставок, рост таймаутов PSP.
Техсигналы: краши подов, утечки памяти, рост очередей, деградация токенов/сек (LLM), 5xx на Edge.
Риск данных: некорректные миграции, несогласованность реплик, орфанные транзакции/выплаты.
Безопасность/PII: подозрение на утечку — немедленный откат/изоляция.

Правило: если 2+ ключевых метрики за пределами порогов > N минут — запускается откат.

2) Типы ролбэков

1. Приложение: откат контейнеров/пакета на предыдущий тег.
2. Фичи: мгновенное выключение через feature flag/kill-switch.
3. Маршрутизация: возврат веса на стабильную версию (canary→stable) или Blue→Green.
4. База данных: логический откат (компенсации), поэтапное возвращение схемы; PITR — крайняя мера.
5. Инфраструктура: откат манифестов/Terraform-плана; возвращение конфигураций сети/WAF.
6. Данные/кэш/очереди: сброс/инвалидация/переигрывание сообщений; версионные кэши.

3) Архитектурные принципы безопасного отката

Совместимость схем: стратегия expand→migrate→contract (откат возможен между expand и contract).
Изолированные зависимости: раздельные секреты/конфиги/кэши/очереди для ревизий.
Идемпотентные операции: повтор запуска миграций и джоб — безопасен.
Иммутабельность артефактов: образы, чарты, SQL-скрипты — версионированы и подписаны.
GitOps-истина: текущая версия и маршрутизация зафиксированы в манифест-репозитории.

4) Механика отката (Kubernetes/GitOps)

Argo Rollouts (возврат веса)

yaml apiVersion: argoproj. io/v1alpha1 kind: Rollout metadata: { name: api }
spec:
strategy:
canary:
steps:
- setWeight: 5
- pause: { duration: 10m }
in case of analysis failure → automatic rollback to stable

GitOps-откат (идея)

git revert <commit_with_bad_version>
git push # Argo CD/Flux revert cluster to previous revision

NGINX: быстрый свитч на stable

nginx map $cookie_canary $to_canary { default 0; 1 1; }
upstream stable { server api-stable:80; }
upstream canary { server api-canary:80; }
server {
location / {
if ($to_canary) { proxy_pass http://canary; }
proxy_pass http ://stable; # removed canary cookie - instant rollback
}
}

5) Ролбэк БД и защита данных

• Expand: добавьте новые поля/индексы, код поддерживает старую и новую схему.
• Migrate: код начинает писать в новую схему, старую не ломаем.
• Contract: удаляем старое только после стабилизации.
• PITR/снапшоты: используйте только при невозможности логической компенсации.
• Компенсации: отдельные скрипты/джобы для исправления вставок/балансов/выплат.
• Read-only окна: при критике — временно блокируем запись, чтобы «заморозить» состояние.

sql
-- expand
ALTER TABLE wallet ADD COLUMN bonus_balance NUMERIC DEFAULT 0 NULL;
CREATE INDEX CONCURRENTLY idx_wallet_bonus ON wallet(bonus_balance);

-- migrate in code, two-sided write
-- contract (after stabilization)
ALTER TABLE wallet DROP COLUMN legacy_bonus_balance;

6) Очереди и кэши при откате

Версионный кэш: ключи с префиксом версии (`v2:`) → безопасное сосуществование.
Инвалидация: при откате — массовая чистка `v2:`, возврат к `v1:`.
Очереди: партиции/топики по версии; переигрывание сообщений «от контрольной точки».
Дедубликация/идемпотентность: ключи идемпотентности для повторной обработки без дублей.

7) SLO-гейты и авто-откаты

Метрики: p95/99, error-rate, saturations (CPU/IO/GPU), queue depth, токены/сек, конверсия платежей.

if p95_latency_ms > 250 for 5m OR error_rate > 1. 5% for 3m OR payment_conv < baseline-0. 3%
then rollback release && open incident && freeze deploys

8) Рунабуки (playbooks)

A) Рост p99 и 5xx после релиза

1. Stop promote (заморозить canary/blue-green).
2. Switch traffic на стабильную ревизию.
3. Проверить кэш-хит/очередь/PSP-задержки.
4. Снять диагностику: логи, профили, версии клиентов/схем.
5. Коммуникация: ChatOps, статус-канал, инцидент-карточка.
6. Начать корректирующее действие: патч/горячий фикс/отмена фичи.

B) Ошибка в миграции БД

1. Freeze writes (read-only, кратко).
2. Откат приложения → стабильная версия (совместима со старой схемой).
3. Выполнить компенсации / rollback-скрипт.
4. Разморозить запись; наблюдать дрейф/ошибки.

C) Деградация платежей (PSP)

1. Переключить маршрутизацию PSP на прежний маршрут.
2. Откат релиза процессинга.
3. Сверка всех незавершенных платежей, повтор с идемпотентными ключами.

D) LLM/рекомендации деградируют

1. Отключить новую модель/параметры (feature flag).
2. Вернуть прежний endpoint/веса; очистить KV-кэш новой ревизии.
3. Проверить tokens/s, первый токен latency, токсичность.

9) Коммуникации и заморозка релизов

Freeze window: после отката — пауза релизов до RCA/фикса.
Единый канал: статус-апдейты, хронология действий, кто что делал.
Стейкхолдеры: продукт/CS/платежи/юристы (при PII).

10) Пост-инцидент: разбор и профилактика

RCA (без обвинений): первопричина, вклад факторов, почему гейты не сработали (если не сработали).
Действия: тесты миграций, лимиты, фичефлаг-гейты, наблюдаемость.
SLO-порог: корректировка, если слишком «мягкий»/«жесткий».
Документация: обновить рунабуки, добавить алерты, тренировки (game-day).

11) Инструменты и шаблоны

GitOps: Argo CD/Flux — `revert`/`rollback` коммита с версией.
Progressive delivery: Argo Rollouts/Flagger — стоп/откат по метрикам.
Edge/Ingress: весовая маршрутизация, cookie-роутинг, быстрый свитч.
Feature flags: fractional rollout, kill-switch.
DB миграции: миг-фреймворки с up/down, dry-run, throttling.
Observability: готовые дашборды «release compare» (stable vs canary).

12) Чек-лист готовности к откатам

1. Версионированные и подписанные артефакты (образы/чарты/SQL).
2. Двухрельсовые конфиги/секреты/кэши/очереди (версионные префиксы).
3. Схема БД по expand→migrate→contract.
4. Канареечные и blue-green релизы с SLO-гейтами и авто-откатами.
5. Рунабуки на ключевые сценарии (платежи/БД/кэш/LLM).
6. ChatOps-кнопки: `/rollback`, `/freeze`, `/promote`.
7. Аудит и логирование: кто, когда, что откатил; артефакты диагностики.
8. Game-day тренировки: имитация провалов и восстановлений.
9. План коммуникаций с бизнесом и саппортом.
10. Метрики сравнения (stable vs new) на одном экране.

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

Разрушающие миграции до раската кода (нет обратной совместимости).
Общие кэши/очереди без версий → «грязный» откат.
Отсутствие GitOps/истории изменений → «ручные» правки в прод.
Канареечный релиз без гейтов/телеметрии → позднее обнаружение.
Откат без freeze и RCA → повтор инцидента.
Мониторинг только техметрик без бизнес-метрик (платежи/ставки).
«Секреты общие» для всех ревизий → трудно изолировать инцидент.

Итоги

Надежный ролбэк — это не «стоп-кран», а процесс, встроенный в релизы: версионность и совместимость, изолированные зависимости, SLO-гейты, GitOps-реальность, автоматические откаты и четкие рунабуки. Такой подход позволяет iGaming-платформам быстро возвращать стабильность, минимизируя потери данных и выручки, и превращать каждый инцидент в источник улучшений.