Canary, поступовий rollout, blue-green, rollback
Головна ідея безпечних релізів: обмежити радіус ураження. Замість «усім і одразу» нову версію показують невеликій частині трафіку, дивляться на сигнали й лише тоді розширюють.
- Canary. Нова версія працює паралельно зі старою й отримує малий відсоток трафіку (1–5%). Якщо метрики в нормі, відсоток росте; якщо ні, canary вимикають, і постраждала мала частка користувачів. Назва — від канарки в шахті;
- Поступовий rollout (staged / percentage). Те саме на рівні фічі чи застосунку: 1% → 10% → 50% → 100% з паузами на спостереження. Мобільні застосунки мають staged release у магазинах;
- Blue-green. Дві повні копії середовища: «синя» обслуговує трафік, у «зеленій» розгортають нову версію й перевіряють її. Потім трафік перемикають цілком. Відкат — перемкнути назад. Мінус: потрібні подвійні ресурси, а спільна база даних вимагає сумісних міграцій;
- Dark launch / за прапором. Код уже в продакшені, але функція вимкнена або видима лише команді.
Rollback чи fix-forward? Rollback — повернути попередню версію: швидко й передбачувано, коли вплив серйозний, а причина не очевидна. Fix-forward — швидко випустити виправлення: доречно, коли причина відома, виправлення мале, а відкат ризикований (наприклад, уже застосована міграція даних, несумісна зі старим кодом). Тому міграції роблять сумісними: спочатку додають нове, потім переходять, і лише згодом видаляють старе (expand / contract).
Умова для всього цього — критерії до старту: які метрики і які порогові значення вважаємо сигналом зупинити rollout. Ці рішення ухвалюють до релізу, а не під тиском інциденту.
Після релізу: моніторинг, фідбек, blameless post-mortem
Реліз не закінчується деплоєм. Частина дефектів проявляється лише на реальних даних, пристроях і навантаженні, тому QA дивиться на продакшен як на ще одне середовище для спостереження. Цей підхід називають shift-right.
Що моніторити одразу після релізу.
- Технічні сигнали: частка помилок (error rate, 5xx), затримки (latency, p95/p99), креші застосунку, помилки в клієнтських логах;
- Бізнес-показники: конверсія, кількість замовлень на годину, успішні оплати, реєстрації. Реліз може не давати жодної помилки й при цьому ламати цінність (кнопка зникла, крок воронки не спрацьовує). Порівнюють із тим самим часом попереднього тижня, щоб відсікти сезонність;
- Звернення користувачів: тікети в підтримку, відгуки в магазині застосунків, згадки в соцмережах. Різке зростання однотипних скарг після релізу — сильний сигнал. Їх групують за темою, відтворюють і додають автотест, щоб помилка не повернулась;
- Алерти й дашборди: зручні лише тоді, коли пороги осмислені; шумний алерт ігнорують.
Smoke у продакшені. Короткий набір безпечних перевірок після деплою (логін, головна сторінка, перегляд товару) з окремим тестовим акаунтом, що не псує реальні дані й не спотворює метрики.
Blameless post-mortem. Після інциденту команда збирається не шукати винного, а зрозуміти, чому система й процес дозволили цьому статися. Структура: хронологія подій, вплив на користувачів, першопричина (часто їх кілька), що спрацювало добре, action items з власниками й термінами (тест, алерт, чек-ліст релізу). Люди чесно діляться деталями лише тоді, коли не бояться покарання. Для QA це шанс питати: чому тест цього не зловив і що додати.