Аналитика смен и производительности

1) Цель и ценность

Аналитика смен — это система измерений, которая делает управление 24×7-операциями предсказуемым: подтверждает покрытие SLO, выявляет узкие места (ночные слоты, перегруженные домены), предотвращает выгорание и повышает качество хендоверов. Для iGaming это напрямую влияет на скорость депозитов/сеттлов, KYC/AML-сроки и репутацию.

2) Таксономия метрик

2.1 Покрытие и готовность

Coverage Rate — % часов с полным составом (по роли/домену/региону).
On-Call Readiness — доля смен с назначенными IC/CL и валидными контактами.
Handover SLA — соблюдение окна передачи (10–15 мин) и чек-листа.

2.2 Скорость реакции и восстановления

MTTA/MTTR (по слотам Day/Swing/Night, по доменам): медиана, p90.
Detection Lead — лаг между SLI-деградацией и первым действием.
Post-Release Monitoring Time — фактическое наблюдение за релизом.

2.3 Качество передачи смены

Handover Defect Rate — незаполненные пункты чек-листа.
Info Drift — расхождение фактов между вар-румом, ITSM и статус-каналом.
Action Carryover — доля задач, “перекочевавших” без владельца/ETA.

2.4 Нагрузка и усталость

Pager Fatigue: алертов/чел/неделя, ночные пейджи, P1/чел/смена.
Escalation Density: доля инцидентов, дошедших до L2/L3 (против runbook-фиксов L1).
Idle vs. Busy Ratio: время продуктивной загрузки vs. ожидание.

2.5 Эффективность и автоматизация

Auto-Fix Rate — инциденты, решенные автодействиями/ботом.
Runbook Usage — % алертов, закрытых по стандартным сценариям.
First Contact Resolution (FCR) — закрытие на уровне L1 без эскалации.
Mean Time Between Incidents (MTBI) — устойчивость домена/слота.

2.6 Справедливость и устойчивость

Fair-Share Index — равномерность ночей/выходных по людям.
Replacement SLA — замены, подтвержденные ≥48 ч до смены.
Training Coverage — доля смен с shadow-слотом для онбординга.

2.7 Бизнес-связка

SLO Impact Score — сколько времени смена держала SLO в зеленой зоне.
Revenue at Risk (proxy) — оценка упущенной выручки от P1/P2 в смене.
Partner Latency/Declines — вклад PSP/KYC-партнеров в инциденты смены.

3) Модель данных

3.1 Зерно событий

shift_event: начало/конец, состав, роли (IC/CL/L1/L2), регион, домены.
alert_event: сигнал, приоритет, владелец, закрытие, runbook/автодействие.
incident_event: P1–P4, таймлайны, IC/CL, статус-публикации.
handover_check: отметки чек-листа + дефекты/комментарии.
release_watch: окна наблюдения, гейты, авто-откаты.
worklog: продуктивные минуты (диагностика, фиксы, комм-апдейты, пост-мортем).
fatigue_signal: частота пейджей/ночей, отработанные часы.

3.2 Схема (упрощенно)

Ключи: `timestamp`, `tenant`, `region`, `environment`, `domain`, `role`, `severity`.
Варианты хранения: событийный lake (parquet/iceberg) + предагрегаты в DWH/TSDB.
Политика PII: только агрегаты и псевдонимы; e-mail/ID маскируются.

4) Сбор данных (ETL)

1. ChatOps/бот: команды `/handover`, `/incident`, `/runbook` → журнал WORM.
2. ITSM: статусы инцидентов/тикетов, связка с вар-румами.
3. Metrics API: SLI/SLO (auth-success, bet→settle p99, error-rate), KRI (queue lag, PSP declines).
4. Планировщик смен: календари, замены, роли, shadow.
5. CI/CD: релизы, окна наблюдения, авто-откаты.

ETL нормализует, добавляет `shift_slot` (Day/Swing/Night), вычисляет derived-метрики (MTTA/MTTR, Fair-Share).

5) Дашборды

5.1 Exec (обзор на неделю/месяц)

CFR, MTTR, Auto-Fix Rate, SLO Impact, Revenue-at-Risk (proxy).
Карта перегрузки слотов и доменов (тепловая).

5.2 Ops/SRE (ежесменно/ежедневно)

Реал-тайм панель: открытые P1–P4, burn-rate, очереди/репликации, guardrails.
Хендовер-карта статуса чек-листа и дефектов.
Fatigue-панель: пейджи/чел, ночи/чел (последние 4 недели), предупреждения.

5.3 Team/Domain

MTTA/MTTR по домену, FCR, Runbook Usage, доля эскалаций на L2/L3.
Fair-Share и Replacement SLA для конкретной команды.

6) Формулы и пороги

Coverage Rate = покрытые часы / 168. Цель ≥ 99%.
Handover SLA = % смен, где передача выполнена и чек-лист закрыт ≤ 15 мин (цель ≥ 95%).
Pager Fatigue (нед.): p95 алертов/чел ≤ целевого; предупреждение при > p90.
Fair-Share Index = 1 − (σ ночей / target_ночей). Цель ≥ 0.8.
Auto-Fix Rate ≥ 40% для L1 за квартал (цель зависит от зрелости).
Runbook Usage ≥ 70% для повторяющихся алертов (топ-10 сигналы).

Контрольные карты (X-MR, p-charts) для MTTA/MTTR и Defect Rate; алерты при выходе за контрольные пределы.

7) Аналитические методы

Аномалии: STL/ESD/CUSUM по алертам и MTTA/MTTR, помечать аутлаеры и причины (релиз, провайдер).
Прогнозирование нагрузки: Prophet/ARIMA по алертам и P1/P2 на слот → планирование FTE.
Атрибуция результата: uplift-модель изменений в процессах (например, новый хендовер-шаблон) → MTTR.
Контрольные эксперименты: A/B во внутренних процессах (вариант чек-листа, новый runbook).
Когортный анализ: производительность новичков (shadow→solo) vs. опытных.

8) Интеграции

Инцидент-бот: постит метрики смены, напоминает о незакрытом хендовере, стартует ретро.
Release-портал: связывает релизные окна с пиками нагрузки; auto-pause при красных SLO.
Metrics API: готовые SLO-вью + exemplars (trace_id) для RCA.
HR/PTO: факторы усадки (shrinkage) → планирование и аналитика fair-share.

9) Политики и RACI

Ops Analytics Owner (SRE/Platform): модель данных, дашборды, точность метрик.
Service Owners: интерпретация доменных сигналов, планы улучшений.
Duty Manager: еженедельный разбор KPI/KRI, баланс слотов.
Compliance/Sec: соблюдение PII/SoD в телеметрии и отчетах.
Training Lead: планы онбординга из выводов аналитики.

10) Шаблоны артефактов

10.1 Каталог метрик (YAML)

yaml apiVersion: ops.analytics/v1 kind: MetricCatalog items:
- id: coverage_rate owner: "SRE"
formula: "covered_hours / 168"
slice: ["region","slot","domain"]
target: ">=0.99"
- id: mtta_p50 owner: "Ops"
formula: "median(ack_ts - alert_ts)"
slice: ["slot","severity","domain"]
target: "<=5m (P1)"
- id: handover_defect_rate owner: "Ops"
formula: "defects / handovers"
target: "<=5%"
- id: pager_fatigue_p95 owner: "SRE"
formula: "p95(alerts_per_person_week)"
target: "<=team_threshold"

10.2 Пример запроса (SQL-агрегат)

sql
SELECT slot, domain,
percentile_cont(0.5) WITHIN GROUP (ORDER BY ack_s-emit_s) AS mtta_p50,
percentile_cont(0.9) WITHIN GROUP (ORDER BY ack_s-emit_s) AS mtta_p90,
AVG(auto_fix)::float AS autofix_rate
FROM alerts_fact
WHERE ts BETWEEN:from AND:to AND severity IN ('P1','P2')
GROUP BY slot, domain;

10.3 Хендовер чек-лист (сигналы качества)

SLO/SLI сводка приложена

Открытые инциденты имеют владельцев/ETA

Плановые работы/релизы привязаны

Провайдерские риски зафиксированы

Комм-черновики готовы

Контакты on-call актуальны

Watchlist обновлен

11) Управление рисками и улучшениями

KRI: рост DLQ/queue-lag на ночной слот, падение FCR < целевого, всплеск Info Drift.
План улучшений: еженедельный Ops-план с владельцами/ETA на топ-3 провалы.
Пост-мортем дисциплины смен: ретро по дефектам хендоверов и флаппингу алертов.
Процессные A/B: проверка влияния новых регламентов на MTTR/Auto-Fix.

12) KPI/OKR примеры (квартал)

KR1: MTTR P1 (медиана) ↓ с 22 мин до 15 мин.
KR2: Handover SLA ≥ 95% в трех слотах.
KR3: Auto-Fix Rate ≥ 45% для топ-10 сигнальных правил.
KR4: Pager Fatigue p95 ↓ на 20% (после оптимизации алертинга).
KR5: Fair-Share Index ≥ 0.85 во всех командах.

13) Дорожная карта внедрения (6–10 недель)

Нед. 1–2: схемы событий, ETL из бота/ITSM/Metrics API, первый каталог метрик, базовые дашборды.
Нед. 3–4: контрольные карты и пороги, fatigue-панель, handover-качество, связка с релизами.
Нед. 5–6: прогнозирование нагрузки (слоты/домены), fair-share и replacement-аналитика.
Нед. 7–8: авто-советы (какие runbooks автоматизировать), отчеты ROI авто-фиксов, ретро-шаблоны.
Нед. 9–10: эксперименты в процессах (A/B чек-листов), KPI на Exec-панелях, обучение команд.

14) Антипаттерны

Считать “успех смены” только по количеству закрытых тикетов (без MTTR/SLO-контекста).
Игнорировать хендовер-дефекты (“и так понятно”).
Метрики без нормализации по объему трафика/сезонным пикам.
Персонификация и “рейтинги людей” без учета сложности/входных условий.
Отсутствие fair-share → выгорание и рост ошибок.
Нулевая корреляция с релизами/экспериментами → ложные выводы.
Данные без WORM-аудита и без политики PII.

Итог

Аналитика смен и производительности — это производственная система измерений поверх ChatOps, ITSM и телеметрии: четкая таксономия KPI/KRI, корректные модели данных, дашборды для разных ролей, статистические методы и связь с SLO/бизнес-эффектом. Такой подход выравнивает нагрузки, ускоряет реакцию, снижает выгорание и предсказуемо улучшает качество операций iGaming-платформы.