Операції та Управління → Передача контексту між змінами

Передача контексту між змінами

1) Навіщо це потрібно

Зміна приходить - система вже «біжить». Якість хендовера безпосередньо впливає на MTTR, шум алертів і стабільність релізів. Хороший хендовер - це швидкий орієнтир, чіткі ризики і зрозумілі наступні кроки.

• Виключити втрату контексту щодо інцидентів, релізів і провайдерів.
• Знизити «час входження» нової зміни до хвилин, а не годин.
• Стабілізувати SLO критичних шляхів (депозит, ставка, запуск гри, виведення).
• Зробити комунікації передбачуваними і перевіряються.

2) Принципи хорошого хендовера

1. Стандартизована форма (один шаблон, одна термінологія).
2. Єдині артефакти (посилання на одні і ті ж дашборди/тікети/runbook'і).
3. Таймбокс (короткий «брифінг» + «лонгрід» в письмовому вигляді).
4. Actionable: в кінці - явний список завдань «хто/що/коли».
5. SLO-орієнтованість: статус по SLO/помилкам, а не «лог подій».
6. Трасування: будь-який факт підтверджується артефактом.

3) Ролі та відповідальність

Lead зміни (минає): готує пакет хендовера, проводить брифінг.
Lead зміни (приймаюча): фіксує питання/ризики, підтверджує прийняття.
Інцидент-менеджер: оновлює таймлайн/канал інциденту, стежить за SLA апдейтів.
Власники доменів (Payments/Bets/Games/KYC): по своїх секціях дають «статус і ризик».
SRE/Observability: підтримують артефакти (дашборди, анотації релізів, алерти).

4) Таймінг і канали

T-30 хв до зміни: зміна заморожує статус, оновлює шаблон.
T-10 хв: швидкий брифінг (15-20 хвилин максимум) в голосовому/відео-каналі.
T+0: публікація пакету хендовера в загальному каналі «#ops -handover».
T + 15 хв: приймаюча зміна підтверджує прийом і уточнює відкриті питання.
Ескалації: всі «червоні» пункти відразу в канал відповідної команди.

5) Структура пакету хендовера (шаблон)

Handoff - <date, time, TZ>
Shift: <outgoing> → <receiving>
Overall SLO status (last 4h):
- API p95/p99: <values/trends>
- Error rate: <values/trends>
- Queue lag/DB connections/Cache: <brief>
Critical incidents:
- <INC-123>: status, impact, next update ETA, links (ticket, channel, postmortem draft)
Providers (PSP/KYC/studios):
- PSP-X: quotas/errors/fake <links>
- KYC-A: Webhook delays <links>
Releases/Features:
- In progress: <service>, stage (canary X%), gate/metrics, risk
- Scheduled: windows/locks/dependencies
Risks and observations:
- <briefly, with links and graphs>
Action items (before <time>):
- [Owner] <task>, readiness criterion
Useful links:
- Dashboard Overview, dependency map, escalation matrix, runbook 'and
On-call contacts:
- Domains/Names/Channels

6) Міні-SOP хендовера

1. Зміна оновлює анотації релізів і дашборди (SLO, провайдери, черги).
2. Перевіряє «червоні» алерти за останні 4 години, фіксує статус/причину.
3. Оновлює розділ «Ризики та спостереження» (тенденції/підозри, не факти).
4. Заповнює Action items з дедлайнами і власниками.
5. Проводить брифінг: 10-15 хвилин, строго за шаблоном.
6. Приймаюча зміна задає питання; якщо потрібно - миттєва ескалація власникам.
7. Підтвердження прийому: «отримано, питання/ні», список перших кроків.

7) Метрики якості хендовера (KPI)

Handoff Quality Score (HQS) - скоринг пакету (0-100) за чек-листом.
Handoff Time - тривалість брифінгу (цільовий коридор 10-20 хв).
Acknowledgement SLA - підтвердження прийому ≤ 15 хвилин.
Missing Context Rate - частка інцидентів з «втратою контексту» після зміни.
Post-Handoff Incident Spike - зростання алертів/інцидентів в перші 60 хвилин.
Action Items SLA - частка завдань, закритих в термін після зміни.

8) Чек-лист якості пакета (оцінка HQS)

• Заповнені SLO/ключові метрики за 4 години з трендами.
• Всі «червоні» алерти перераховані з причинами/посиланнями.
• Інциденти: номер, статус, вплив, наступний апдейт (час).
• Провайдери: квоти/помилки/фейловер, останні зміни.
• Релізи/фічі: стадія, ризики, гейти/канарка.
• Action items: власник, термін, критерій готовності.
• Посилання: дашборди, канали, runbook'і, матриця ескалацій.
• Контакти on-call і резервні канали зв'язку.

9) Дашборди «для хендовера» (мінімум)

Operations Overview: p95/p99, error rate, capacity headroom, queue lag.
Incidents Board: відкриті інциденти, ETA апдейтів, вплив.
Release & Feature: канарки, порівняння «до/після», автогейти.
Providers Panel: квоти, таймаути, cost/1k calls, перемикання.
Dependency Map: проблемні ребра (latency/errors/retries).

10) Алерти на якість хендоверів (ідеї)

ALERT HandoffNotPublished
IF handoff_published == 0 AND within(10m, shift_change) == true
LABELS {severity="warning", team="ops"}

ALERT HandoffAckSLA
IF handoff_ack_minutes > 15
LABELS {severity="warning", team="ops"}

ALERT MissingActionOwners
IF count_over_time(handoff_action_items{owner=""}[1h]) > 0
LABELS {severity="warning", team="ops"}

ALERT PostHandoffIncidentSpike
IF incidents_rate_60m_after_shift > baseline_14d 1. 5
LABELS {severity="info", team="ops"}

11) Комунікації та формат апдейтів

[HH: MM] Handoff published. SLO OK/Degraded. Incidents: INC-123 (ETA 18:30), releases: bets-api canary 10%. Risks: PSP-X 85% quota. Action items: @ squad-payments until 7pm to check out the feilover.

• Без приватних чатів для критичних пунктів - тільки загальні канали.
• Будь-яка «червона» зона - негайний тред з власниками.
• Всі рішення/компроміси - в письмовому вигляді, з посиланням на дані.

12) Особливості доменів (iGaming)

Payments: пріоритет: конверсія депозиту і час авторизації, маршрути фейловера PSP, ліміти по провайдерам.
Bets: оновлення коефіцієнтів/кешів, навантаження на стрімінг/черги, затримка розрахунків.
Games/Live: широкомовні івенти (джекпоти/стріми), ліміти вебсокетів, деградації UI.
KYC/AML: черга перевірок, SLA провайдерів, чутливість до піків.

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

Вільна «довільна форма» хендовера (кожен пише як хоче).
Немає дедлайну на підтвердження прийому.
Пакет без Action items і власників.
Хендовер перетворюється на «читку логів» замість SLO/ризиків.
Секретні рішення в приватних чатах - відсутність трассируемости.
Шаблон не містить посилань на артефакти - нічим перевіряти.

14) Інтеграції та артефакти

Анотації релізів на графіках, автоссылки в хендовер.
Link unfurling: вставка посилань на дашборди/тікети з прев'ю ключових метрик.
Runbook-прив'язки: кожна «червона» зона з прямим посиланням на конкретний runbook.
Матриця ескалацій: у шаблоні - єдиний актуальний документ.

15) Політика зберігання та аудит

Хендовери - зберігаються централізовано (геос, дата/час, автори).
Щотижневий аудит HQS і вибірковий розбір «поганих» хендоверів.
Ревізія шаблону - щоквартально або за підсумками постмортемів.

16) Швидкий старт (30 днів)

Тиждень 1: затвердити шаблон, ролі і таймінг; запустити пілот на одній лінії (наприклад, Payments).
Тиждень 2: включити дашборди «для хендовера», алерти HandoffNotPublished/AckSLA.
Тиждень 3: ввести HQS-скорард і аудит 10% хендоверів.
Тиждень 4: розширити на Bets/Games/KYC, провести ретроспективу, оновити SOP.

17) Приклад «картки ризику» для пакета

Risk: PSP-X hits 90% quota in prime time
Impact: rise in deposit refusals, SLO payments at risk
Signals: outbound_error_rate, quota_usage_ratio
Mitigation: raise PSP-Y up to 20% of traffic in advance, enable token cache
Owner/ETA: integrations@oncall / до 18:00

18) FAQ

Q: Що робити, якщо брифінг затягується?
A: Строгий таймбокс і правило «в тред після брифінгу». У пакеті повинно бути все для асинхронного ознайомлення.

Q: Як боротися з «різними версіями правди»?
A: Уніфікувати артефакти: єдині дашборди, анотації релізів, SSOT для SLA; лінкувати тільки на них.

Q: Чи потрібно записувати брифінг?
A: Так, для спірних кейсів і навчання. Але запис не замінює стандартизований письмовий пакет.