Операції та Управління → Управління змінами

Управління змінами

1) Призначення та принципи

Мета: поставляти зміни швидко і безпечно, знижуючи ризик інцидентів, простоїв і регуляторних порушень.

• Predictable & Reversible: кожна зміна планована, перевірена і оборотна.
• Risk-based: глибина контролю залежить від ризику (юрисдикції, гроші, PII).
• Small & Frequent: дрібні інкременти легше оцінювати і відкочувати.
• Automation first: інфраструктура як код, тести, валідації, автоперевірки.
• Single Source of Truth: єдиний RFC/тікет, єдиний календар і лог дій.

2) Область охоплення

Продуктовий код (backend/frontend, мобільні SDK).
Інфраструктура (IaC, Kubernetes/VM/CDN/Edge).
Дані (схеми БД, міграції, вітрини/ETL).
Конфігурації і фіча-прапори.
Інтеграції (PSP, KYC, ігрові провайдери).
Політики безпеки та доступів.

3) Ролі та RACI

Власник зміни (Change Owner) - Responsible.
Куратор релізу/RelEng - координація релізного поїзда.
SRE/Ops - експлуатація, гейт SLO/SLA.
Security/Compliance - перевірка ризиків і відповідності.
CAB (Change Advisory Board) - затвердження нормальних/високоризикових змін.
Стейкхолдери бізнесу/підтримка - Informed.

4) Класифікація змін

Standard (типові, попередньо затверджені): часті, низькоризикові, по готовому плейбуку (наприклад, оновлення прапора, ротація ключів).
Normal: вимагають RFC, оцінки, можливого CAB, тестів і плану відкату.
Emergency: термінові фікси для P1-інцидентів; мінімальний бюрократичний шлях, пост-фактум рев'ю/САВ.

5) Життєвий цикл зміни

1. Ініціювання (RFC): мета, обсяг, ризик, порушені сервіси/регіони, бекаут-план.
2. Оцінка ризику: матриця Impact × Likelihood, вплив на SLO/комплаєнс/вартість.
3. Планування: вікно, залежності, міграції, комунікації, валідуючі тести.
4. Валідація: автотести, статичний аналіз, security-чек, перформанс-прогін.
5. Розгортання: прогресивна стратегія (див. § 8), телеметрія і гардрейли.
6. Спостереження: burn-rate SLO, алерти, бізнес-метрики (GGR/NGR, конверсія).
7. Завершення: прийняття результату, оновлення документації, пост-мортем при відхиленнях.

6) RFC: Мінімальний склад

Контекст: навіщо змінюємо, гіпотеза впливу.
Діапазон: системи, регіони, версії клієнтів.
Ризик: матриця і сценарії відмови, blast radius.
План розгортання: покроково, з критеріями «йдемо/стоп».
План відкату (Backout): команди/кроки, умови запуску, очікування по RTO/RPO.
Тест-план: що перевіряємо до/після (функціонал, перформанс, безпека).
Комунікації: кого сповіщаємо, шаблони повідомлень.
Аудит: посилання на тікети, коміти, артефакти CI/CD.

7) Календар змін та вікна

Єдиний календар: всі релізи, міграції, вимикання фіч, зовнішні події (спорт/маркетинг/свята).
Freeze-вікна: великі розпродажі/чемпіонати/пікові години, податкова звітність.
Політика перетинів: заборона конфліктуючих змін по одним і тим же критичним шляхам.
Регіональні хвилі: спочатку «теплі» регіони/низький трафік, потім - основні.

8) Технічні стратегії розгортання

Canary: мала частка трафіку → порівняння метрик (p95 latency, error%, конверсія).
Blue-Green: паралельні середовища, атомарне перемикання маршруту.
Progressive Delivery: відсоток-роллаут з автоматичними стоп-умовами.
Feature Flags: функціональні перемикачі, kill-switch, A/B.
Dark Launch/Shadow Traffic: перевірка на тіні без впливу на користувачів.
Ступінчасті ліміти: поступове підвищення QPS/конкурентності.

Гардрейли: автоматичний стоп при перевищенні порогів p95/error%, зростанні повернень/чарджбеків, падінні авторизацій/депозитів.

9) Зміни даних і схем

Сумісність: розширюють міграції (additive) → код, що читає і стару, і нову схему.
Двофазні міграції: (1) додати нові поля/індекси → (2) перемкнути код → (3) видалити старе.
Версіонування контрактів: Avro/Protobuf схеми з реєстром; back/forward compatible.
Міграції великих обсягів: батчі, паузи, ідемпотентність, чекпойнти і прогрес.
Катастрофостійкість: тест RPO/RTO, снапшоти, репетиції відновлення.
Дані BI: зміна вітрин/метрик - через MR/SR і словник метрик (ID, формула).

10) Управління конфігураціями та секретами

Config as Data: версіоновані конфіги, валідація схемою, промоут через оточення.
Секрети: ротація ключів, принципи мінімальних привілеїв, аудит звернень.
Регіональні оверрайди: ліміти/партнери (PSP/KYC) - через параметризацію, не через форки коду.

11) Комплаєнс і аудит (iGaming-контекст)

Сліди змін: хто/коли/що перемкнув (прапори, конфіги, маршрути, міграції).
Segregation of Duties: різні ролі для автора, рев'юера і деплоєра (SOX-подібно).
Регуляторні звіти: фікс-релізи, контроль версій розрахунків (GGR/NGR, бонуси), контроль доступів до PII.
Постачальники: зафіксовані версії SDK/сертифікатів провайдерів, SLA-зобов'язання.

12) Комунікації

Шаблони сповіщень: до релізу (що/коли/ризики), під час (статус,% трафіку, метрики), після (підсумки).
Зовнішні повідомлення: банери/статус-сторінка при впливі на клієнтів.
Координація: канал #release -war-room, власник релізу, частота апдейтів.

13) Метрики ефективності

DORA: Deployment Frequency, Lead Time for Changes, Change Failure Rate (CFR), MTTR.
SLO Impact: частка часу в SLO до/після релізів.
Backout Rate: частота відкатів за категоріями змін.
Release Debt: незавершені міграції/фіч-прапори в «підвішеному» стані.
Business Impact: конверсія, KYC TTV, success rate PSP, GGR/NGR drift при розкатках.

14) Анти-патерни

Big-bang релізи: багато змін за один раз - складно зрозуміти причину регресії.
Несумісні міграції: видалення/перейменування полів без подвійного читання.
Прапори без власників і термінів зняття: «вічні» розгалуження логіки.
Релізи без телеметрії та стоп-критеріїв: «на око» і пізніше виявлення збитку.
Ігнорування календаря: перетину з піковими подіями/кампаніями.
Ручні кроки без плейбуків та аудиту: висока варіативність і ризик.

15) Чек-листи

Перед початком (RFC готовність)

• Ціль і KPI зміни сформульовані
• Ризик і blast radius оцінені, клас зміни обраний
• План розгортання і Backout прописані покроково
• Тест-план і результати на стейджі/канарі є
• Комунікації та календар оновлені, стейкхолдери повідомлені

Під час розкатки

• Метрики p95/error%, бізнес-сигнали і логи моніторяться в реальному часі
• Ступені прогресу підтверджуються чек-поінтами
• При спрацьовуванні гардрейлів - авто-стоп і відкат

Після

• Підсумки релізу зафіксовані (changelog, версії, артефакти)
• Пост-мортем при відхиленнях (≤ 5 робочих днів)
• Борги (видалення прапорів, фінальні міграції) занесені в backlog з власниками

16) Міні-шаблони

• Мета/гіпотеза
• Обсяг та впливи (сервіси, регіони, дані, клієнти)
• Ризик (Impact × Likelihood) та заходи зниження
• План розкатки (кроки,% трафіку, критерії go/no-go)
• Backout-план (кроки, RTO/RPO, дані)
• Тест-план (функціонал/перформанс/безпека)
• Комунікації (канали, частота)
• Артефакти (тікети, PR, білд-номери)

• Зміна: «Payments-Service v2. 14 + міграція psp_limits"
• Вікно: 2025-11-02 00:00–01:00 EET
• Порушені регіони: EU, LATAM (10%→50%→100%)
• Ризики/гардрейли: error%> 2% 10 хв - стоп і відкат
• Контакти: @Owner, @SRE-on-call, @Support-lead

• Тригери: p95> + 25% 10 хв, PSP success <97%
• Кроки: (1) traffic −→ 0% на v2. 14; (2) перемкнути прапори на v2. 13; (3) відкат міграції через снапшот/чекпойнт; (4) smoke-тести; (5) звіт.

17) Інтеграція з релізним поїздом

Release Train: фіксовані слоти (наприклад, 2 × на тиждень), SLA на merge-cut.
Hotfix-політика: окремі поїзди/гілки, прискорений шлях в прод.
Версіонування: semver, мітки в артефактах і оточеннях, SBOM.

18) Підсумок

Управління змінами - це не гальмо для швидкості, а механізм безпечного прискорення. Ризик-орієнтована класифікація, хороші RFC, прогресивна розкочка, сумісні міграції даних, чіткі комунікації та вимірюваність ефекту перетворюють релізи в керований, повторюваний і аудитований процес.