Ролбек і відновлення стабільності

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

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

Відкат - це кероване повернення до останньої стабільної версії з мінімальним ризиком втрати даних і порушень 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-платформам швидко повертати стабільність, мінімізуючи втрати даних і виручки, і перетворювати кожен інцидент на джерело поліпшень.