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

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

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: Да, для спорных кейсов и обучения. Но запись не заменяет стандартизированный письменный пакет.