Сценарии отката изменений

(Раздел: Операции и Управление)

1) Зачем нужны сценарии отката

Даже при идеальном тестировании часть изменений приводит к деградациям. Откат — это управляемая операция возврата к заранее определенной «безопасной» версии без потери данных и комплаенса. Цели: сократить MTTR, защитить деньги/данные, сохранить доверие партнеров и регуляторов.

2) Классификация изменений и подходы к откату

Код и контейнеры: версионируемые артефакты → blue-green, canary, rolling с мгновенным откатом на предыдущий образ.
Конфигурации/фичефлаги: feature toggle rollback, атомарные коммутаторы с TTL и аудитом.
Схемы БД: expand → migrate → contract, двунаправимые миграции, «теневые» колонки, backfill в фоне.
Данные/прайс-листы/налоги: версии артефактов (`fx_version`, `tax_rule_version`, `pricelist_version`), «заморозка» и возврат.
Интеграции (PSP/KYC/провайдеры контента): переключение маршрутов/пулов, fallback на резервного провайдера.
Инфраструктура/сети/CDN: поэтапный откат правил/маршрутов, откат сертификатов/ключей с двойной загрузкой.

3) Архитектурные паттерны для обратимости

Immutable releases: каждый релиз — подписанный артефакт (образ/конфиг) с возможностью мгновенного выбора предыдущего.
Слои совместимости: schema-compat (добавление, не удаление), tolerant-reader на стороне потребителей.
Двойная запись (dual-write) и shadow-reads: перед «переключением» сравнивайте консистентность.
Идемпотентность и саги: компенсационные шаги для кросс-сервисных транзакций.
Фичефлаги: быстрое отключение/поэтапное включение вместо «горячего» редеплоя.

4) Стратегии раскатки с точками возврата

Canary N%: метрики/гвардрайлы → при деградации авто-откат; при успехе — расширение до 100%.
Blue-Green: два прод-стека; переключение трафика и мгновенный rollback обратно.
Rolling with pause: обновление по партиям с «точками паузы» и возможностью отката на предыдущую волну.
Фичефлаги по когортам: «темный запуск», whitelists, региональные/тенант-флаги.

5) Откат БД и миграций: безопасные шаблоны

1. Expand: добавить новые колонки/индексы/эндпоинты, код пишет в обе версии.

2. Migrate: backfill и валидации; чтение «теневое» из новой структуры.

3. Contract: отключить старое после стабильности.

Двунаправимость: каждая миграция имеет `down()`; для больших наборов — logical revert (флаги, маршрутизация) вместо физического удаления.

Снапшоты/пойнт-ин-тайм: PITR/снапшот таблиц перед критичным релизом.

Контроль схем: валидаторы контрактов в CI/CD + «dry-run» на staging/реплике.

6) Откат данных каталога/цен/налогов

Версионируйте прайс-листы и налоговые правила; храните квитанции публикации.
В заказах фиксируйте `fx_version`/`tax_rule_version` — возврат не ломает старые чеки.
При «PriceMismatch» → форс-инвалидация кэша, возврат на предыдущую версию артефакта, компенсации по политике.

7) Интеграции и внешние провайдеры

PSP/KYC/контент: держите резервные маршруты, health-пробы, быстрое переключение DNS/LB, отдельные ключи.
Вебхуки: включайте write-drop и очереди; при откате — реплей из «мертвых писем» с идемпотентными ключами.
Сертификаты/ключи: двойная загрузка (старый+новый), проверка совместимости перед переключением.

8) Автоматизация откатов («руны») и гвардрайлы

Руны (кнопки): Rollback Release, Disable Flag, Re-route, Flush Cache, Scale Back, Restore Schema.
Гвардрайлы: запуск отката доступен IC/владельцу; журнал подписан (DSSE), лимиты частоты операций, чек-лист подтверждения.
Авто-откат: условия по SLO/перцентилям/ошибкам/финансовым сигналам (например, Δ quote↔checkout ≠ 0).

9) Коммуникации и артефакты

В карточке релиза: версия, хэши, чек-лист пререквизитов, плейбук отката, ответственные.
При откате: метки времени, причина, объем затронутого трафика, артефакты (лог-ссылки, метрики до/после).
Внешние коммуникации (статус-страница/партнеры): кратко и фактологично.

10) Плейбуки отката (референс)

1. Re-route/Blue-Green back → 2) зафиксировать версию → 3) заблокировать дальнейшие раскатки → 4) форензика.

1. Disable Feature Flag (100%) → 2) очистка кэша/фоллбеков → 3) тикет на исправление.

1. остановить heavy-backfill → 2) вернуть чтение на старую схему (dual-read off) → 3) понизить нагрузку/индексы → 4) оценить `down()` или логический откат.

1. откат `pricelist_version`/`tax_rule_version` → 2) инвалидация edge-кэша → 3) компенсации и сверка чеков.

1. переключение на резервный PSP → 2) карантин «серых» транзакций → 3) реплей очереди после стабилизации.

1. вернуться на предыдущий ключ (dual-key) → 2) ротация и репаблиш.

11) RACI

12) Метрики качества и SLO

Change Failure Rate (CFR) — доля релизов с откатом (цель ↓).
MTTR (с откатом) — медиана времени возврата к стабильности.
Time-to-Rollback — от триггера до завершения отката (P1 ≤ 15–20 мин).
Δ-метрики до/после (p95, error-rate, E2E success).
Повторные откаты одной и той же причины ≤ N/квартал.
Аудит-покрытие: 100% откатов с артефактами и подписями.

13) Безопасность, приватность, комплаенс

WORM-журналы на релизы/откаты; хранение артефактов по регуляторам.
PII/финансы: проверка, что откат не открывает доступ к неразрешенным зонам/старым политикам.
SoD: «кто раскатывает» ≠ «кто одобряет» ≠ «кто инициирует откат».
Креды/секреты: dual-rollover и мгновенный возврат на предыдущий ключ.

14) Финансовые и операционные эффекты

Стоимость простоя vs стоимость отката: автоматизируйте решение через SLO-гвардрайлы.
Компенсации/кредиты по SLA — шаблоны в плейбуках.
Egress/compute-кап: откат может временно поднять нагрузку (реплей/прокачка кэшей) — планируйте окна.

15) Чек-лист перед релизом (go/no-go)

• Подписанные артефакты и точка возврата (образ/конфиг/версия данных).
• План раскатки и плейбук отката (по шагам).
• Валидированы миграции: expand→migrate→contract, PITR активен.
• Dials/гвардрайлы SLO: условия авто-отката в системе алертов.
• Каналы связи: IC/Owners/Comms on-call.
• Тесты обратной совместимости и «сухой прогон» на staging.
• Резервные маршруты для критичных интеграций.
• План коммуникаций (внутр./внешн.) и шаблоны.

16) Чек-лист при откате (во время инцидента)

• Подтвердить триггер и затронутый объем (регион/тенант/канал).
• Зафиксировать версию «на что откатываемся».
• Выполнить руну отката (код/флаг/маршрут/данные).
• Проверить SLI/SLO и бизнес-метрики (E2E, checkout, вебхуки).
• Сверить каталоги/версии (FX/Tax/PriceList).
• Закрепить состояние: запрет новых раскаток, сбор артефактов.
• Коммуникация: статус-страница, партнеры, внутренние.

17) Частые ошибки и анти-паттерны

Откат «вручную» без артефактов и подписей.
Разрушающие миграции без двунаправимости и PITR.
Feature-flag без «глобального выключателя».
Отсутствие резервных маршрутов к PSP/KYC.
Очистка кэша без прогрева → лавина холодных запросов.
Неучтенный quote≠checkout после возврата прайс-листа.

18) FAQ

Когда лучше откат, а не фикс «на месте»?
При нарушении SLO/риске денег/данных быстрее и безопаснее вернуться на известную стабильную версию.

Можно ли откатывать «разрушающие» миграции?
Да, если спроектированы как expand→migrate→contract с `down()`/PITR и логическим фоллбеком.

Как автоматизировать решение об откате?
SLO-гвардрайлы (p95, error-rate, Δ-цены, успех вебхуков) + матрица рисков → авто-руна.

Что делать с заказами/транзакциями «между»?
Идемпотентные ключи, карантин «серых» операций, реплей очередей с дедупом.

Резюме: Сценарии отката — это не импровизация, а заранее спроектированная способность быстро вернуться к стабильности. Версионируйте все, держите обратимую схему данных, используйте фичефлаги и canary, автоматизируйте руны, фиксируйте артефакты и SLO-гвардрайлы. Тогда любой релиз остается управляемым, а бизнес — предсказуемо стабильным.