Взаємодія команд в операціях
1) Навіщо
iGaming-платформа - це десятки доменів (Payments, Games/Core, Risk/KYC, Data, Infra/SRE, Support, Compliance). Без формалізованої взаємодії зростають MTTR, CFR і операційні ризики. Мета - перетворити розрізнені функції в єдину операційну систему: передбачувані контакти, прозорі черги, загальні сигнали і узгоджений пріоритет.
2) Принципи
1. SLO-first: спільні рішення зав'язані на SLO/бюджети помилок.
2. Єдине джерело правди: загальні дашборди, єдині статуси і артефакти.
3. Чіткі межі та інтерфейси: у кожної пари команд - описаний контракт (OLA/Runbook/API).
4. Малі батчі і оборотність: зміни через фічефлаги/канарю, швидкий rollback.
5. No blame — yes data: розбори за фактами, поліпшення - обов'язкова частина циклу.
6. Мінімально необхідні привілеї та SoD: розподіл ролей для чутливих операцій.
7. Автоматизуй рутину, стандартизуй інше.
3) Ролі і RACI (наскрізні)
Head of Ops/SRE Lead - власник операційного каркасу, KPI/KRI. A
Service Owners (Payments/Games/KYC/Data) - доменні цілі, зміни, ризик. A/R
Platform/Infra - доступність, перформанс, релізи/канарі. R
Risk/Compliance/Security - SoD, RG/KYC/PII, аудити. C/A
Support/CRM - фронт скарг, комунікації гравцям. R/C
On-call IC/CL - інцидент-менеджмент і зовнішні апдейти. R
Release Manager - календар, CAB, статус змін. R
Data/Analytics - продуктові та операційні метрики, RCA-підтримка. R/C
4) Контракти взаємодії (OLA/SLx)
OLA (Operational Level Agreement) - внутрішні домовленості між командами (не зовнішні SLA). Включають:- Зони відповідальності: що чия зона (наприклад, PSP-роутинг - Payments; кеш/БД - Infra).
- Цілі/порогові метрики: MTTA інциденту, час реакції на ескалацію, вікно пост-моніторингу.
- Черги та пріоритети: P1-P4, бізнес-критичність, freeze-вікна.
- Інтерфейси: канали, команди бота, API/Runbook, каталоги власників.
- Артефакти: які документи/логи/дашборди зобов'язані супроводжувати подію.
5) Канали та протоколи спілкування
Операційний чат (змінний): щоденні апдейти, міні-ритуали, handover.
Вар-руми щодо інцидентів: створюються ботом; ролі IC/CL призначаються командою.
CAB/Change-канал: обговорення змін, ризиків, реліз-календар.
Статус-канал (read-only): зведення SLO/інцидентів/планових робіт.
Ескалації: шаблони команд '/page', '/escalate', SLA звітності.
Єдиний протокол повідомлень: «факт → вплив → ETA/ETR → наступне вікно апдейта → власник».
6) Хендовери між змінами і регіонами
Шаблон 10-15 хвилин:1. SLO/SLI: де ризик вигорання бюджету.
2. Відкриті інциденти/ескалації та їх ETA.
3. Планові роботи/релізи в найближчі 24-48 год.
4. Провайдери (PSP/KYC/студії): активні тікети, очікування.
5. Склад on-call і контакти (IC/CL/domains).
6. «Watchlist» - зони підвищеної уваги (черги/реплікації/кеш).
Хендовер фіксується в змінному журналі, посилання - на вар-руми і дашборди.
7) Спільна робота при інцидентах
Старт: алерт → бот створює картку'#inc -YYYY-MM-DD-XXX', призначає IC/CL і доменних лідів.
Правило одного голосу: IC - фінальне рішення; CL - комунікації.
Факти і гіпотези: відокремлюємо; «червоні» сигнали - пріоритетні.
Guardrails: фічефлаги/PSP-роутинг змінюються тільки через runbook з SoD/dual-control.
Комунікації: чернетки публічних апдейтів через CL, партнери - таргетовано.
Закриття: пост-моніторинг, генерація пост-мортема і завдань поліпшень з власниками/термінами.
8) Спільна робота при змінах
Календар релізів: загальнодоступний, з freeze-періодами і слотами on-call.
Гейти якості: unit/contract/e2e, безпека, SLO-гейти staging.
Канарські розкатки: покроково 5%→25%→100% по GEO/тенантам/банкам.
Авто-відкат: політики щодо ключових SLI/KRI, журнал WORM.
Комм-пакети: чернетки апдейтів, узгоджені заздалегідь з CL/Legal.
RACI зміни: RM (A/R), SO (A/R), SRE (R), Sec/Compliance (C/A), CAB (A), IC/CL (R/C).
9) Єдина телеметрія та артефакти
Загальний каталог метрик: SLI/SLO, бізнес-метрики, KRI (черги, PSP, реплікації).
Дашборд «Карта операцій»: зведення по доменах, регіони, статус інцидентів/робіт.
Таймлайни: єдиний формат (час, автор, дія, результат, посилання).
Пост-мортеми: шаблон без звинувачень, заходи запобігання, дата ревізії.
Runbooks/Checklists: versioned; посилання з алертів і карток інцидентів.
10) Пріоритезація та планування
Щотижневий Ops-план (30-45 хв): узгодження топ-ризиків, релізів, лімітів, поліпшень з пост-мортемів.
Канбан операцій: стовпці'Backlog → Ready → In Progress → Validate → Done', WIP-ліміти.
Критерії пріоритету: вплив на SLO/виручку/комплаєнс, розмір/оборотність, залежність від провайдерів.
11) Матриця ескалацій (вичавка)
12) Політики і SoD
SoD/4-eyes: висновки/бонуси/роутинг PSP/експорт PII - тільки при подвійному схваленні.
JIT-права: тимчасова ескалація привілеїв для дій по runbook.
Політики даних: заборона PII у відкритих каналах/дашбордах; гео-кордони.
Аудит: незмінювані журнали дій (WORM), ревізії політик.
13) Інструменти взаємодії
Інцидент-бот: '/incident new', ролі, таймери апдейтів, комм-чернетки, '/runbook', '/flag', '/config'.
Metrics API: загальні SLO-в'ю і KRI, exemplars (trace_id) для RCA.
Release-портал: маніфести, гейти, статус розкатки/відкату.
Довідник власників/CMDB: домени, контакти, резервні канали.
14) Метрики колаборації (KPI/KRI)
MTTA/MTTR по доменах і слотах (день/ніч), частка інцидентів, спійманих до скарг.
Handover Quality: дефекти передачі (пункти чек-листа, не закриті вчасно).
Change Collaboration: % релізів з готовими комм-пакетами і без відкатів.
Guardrail Discipline: частота порушень SoD/політик (мета - 0).
Comms Cadence: дотримання інтервалів публічних апдейтів при P1/P2.
Post-mortem SLA: частка пост-мортемів ≤ D + 5, виконаність дій.
Fair-share Load: розподіл ночей/піків по людях/командах.
Customer Signal Lead: лаг між об'єктивною деградацією і першими скаргами.
15) Дорожня карта впровадження (6-10 тижнів)
Нед. 1–2: інвентаризація доменів/власників; шаблони OLA; запуск змінного каналу і хендовер-чек-листа; базова матриця ескалацій.
Нед. 3–4: інцидент-бот (MVP), загальний статус-канал, єдина карта SLO/SLI/KRI; каталог runbooks.
Нед. 5–6: САВ/реліз-календар, комм-пакети та freeze-вікна; SoD/4-eyes для чутливих операцій.
Нед. 7–8: канарні розкатки і авто-відкат як стандарт; пост-мортем шаблон, Exec/Ops-дашборди колаборації.
Нед. 9–10: навчання P1, крос-регіональні хендовери, аудит WORM, звіти KPI/KRI, коригування OLA.
16) Шаблони (фрагменти)
16. 1 OLA (Payments ↔ Infra/SRE)
yaml ola:
scope: "Payments-Auth & Routing"
contacts:
payments_so: "@pay-so"
infra_oncall: "@sre-oncall"
objectives:
mtta_p1: "≤5m"
rollback_ttr: "≤10m canary"
interfaces:
runbooks: ["psp-failover", "reroute", "auth-throttle"]
dashboards: ["auth_success", "psp_latency", "queue_lag"]
escalation:
p1: ["IC","Payments Lead","SRE L2"]
p2: ["Payments OnCall","SRE OnCall"]
artifacts:
status_templates: ["public","partners"]
postmortem_due: "D+5"16. 2 Хендовер чек-лист (10 пунктів)
1. SLO-статуси доменів
2. Відкриті інциденти (ЕТА/власники)
3. Планові роботи/релізи + вікна спостереження
4. Провайдери (PSP/KYC/студії) - ризики/очікування
5. Черги/реплікації/кеш - lag/аномалії
6. Зміни лімітів/фічефлагів
7. Скарги/тікети і пороги навантаження
8. Комм-плани і статус-чернетки
9. Склад on-call і резерв
10. «Watchlist» на слот
17) Антипатерни
«Хто-небудь займеться?» без RACI і власника.
Інциденти без IC/CL і таймерів апдейтів.
Приховані зміни (ручні кліки), немає Git/Audit.
Необщая телеметрія: різні цифри в різних командах.
Релізи без комм-пакетів і канарів.
SoD-порушення «заради швидкості».
Хендовери усно, без записів і чек-листів.
Пост-мортеми без дій і термінів.
Підсумок
Взаємодія команд в операціях - це контрактна колаборація: OLA/SLx, чіткі канали і ролі, дисципліна хендоверів, загальна телеметрія, узгоджені релізи і інцидент-процеси. Такий каркас знижує MTTR і CFR, вирівнює пріоритети, захищає SLO, виручку і комплаєнс - і робить щоденну роботу передбачуваною і стійкою.