Аналітика змін і продуктивності
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 - частка завдань, «перекочували» без власника/ЕТА.
2. 4 Навантаження і втома
Pager Fatigue: алертів/чол/тиждень, нічні пейджі, Р1/чол/зміна.
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 зведення прикладена
Відкриті інциденти мають власників/ЕТА
Планові роботи/релізи прив'язані
Провайдерські ризики зафіксовані
Комм-чернетки готові
Контакти on-call актуальні
Watchlist оновлено
11) Управління ризиками та поліпшеннями
KRI: зростання DLQ/queue-lag на нічний слот, падіння FCR <цільового, сплеск Info Drift.
План поліпшень: щотижневий Ops-план з власниками/ЕТА на топ-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-платформи.