Сценарії відкату змін

(Розділ: Операції та Управління)

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-гвардрайли. Тоді будь-який реліз залишається керованим, а бізнес - передбачувано стабільним.