Взаимодействие команд в операциях

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)

• Зоны ответственности: что чья зона (например, PSP-роутинг — Payments; кэш/БД — Infra).
• Цели/пороговые метрики: MTTA инцидента, время реакции на эскалацию, окно пост-мониторинга.
• Очереди и приоритеты: P1–P4, бизнес-критичность, freeze-окна.
• Интерфейсы: каналы, команды бота, API/Runbook, каталоги владельцев.
• Артефакты: какие документы/логи/дашборды обязаны сопровождать событие.

5) Каналы и протоколы общения

Операционный чат (сменный): ежедневные апдейты, мини-ритуалы, handover.
Вар-румы по инцидентам: создаются ботом; роли IC/CL назначаются командой.
CAB/Change-канал: обсуждение изменений, рисков, релиз-календарь.
Статус-канал (read-only): сводки SLO/инцидентов/плановых работ.
Эскалации: шаблоны команд `/page`, `/escalate`, SLA отчетности.

Единый протокол сообщений: “факт → влияние → ETA/ETR → следующее окно апдейта → владелец”.

6) Хендоверы между сменами и регионами

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: CAB/релиз-календарь, комм-пакеты и 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. Открытые инциденты (ETA/владельцы)

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, выручку и комплаенс — и делает ежедневную работу предсказуемой и устойчивой.