Операции и Управление → Аудит метрик и SLA

Аудит метрик и SLA

1) Зачем это нужно

Если метрики неверны — решения будут неправильными, SLA будут нарушаться «на бумаге» или наоборот скрывать проблемы. Аудит метрик и SLA гарантирует сопоставимость, достоверность и юридическую защищенность обещаний перед пользователями и партнерами.

• Обеспечить единый «источник правды» (SSOT) и воспроизводимые расчеты.
• Снизить расхождения между дашбордами/отчетами/биллингом.
• Сделать SLA выполнимыми и проверяемыми (evidence-based).
• Выявлять деградации в измерениях так же рано, как и в сервисах.

2) Базовые понятия и границы ответственности

Metric (метрика): измеряемая величина (RPS, p95, CR, GGR, Success Rate).
KPI/OKR: цели, к которым метрики привязаны.
SLO: целевое качество сервиса (например, «p99 ≤ 400 мс 99.9% времени»).
SLA: внешнее обещание; юридически значимое, основано на SLO.
OLA: внутреннее соглашение между командами/вендорами, поддерживает SLA.
SSOT: система/хранилище, чьи данные считаются эталонными для отчетов.

3) Таксономия метрик (слои)

1. Инфраструктура: CPU/Memory/IO/Net, поды/узлы, HPA/VPA.
2. Платформа: очереди/стримы (lag, throughput), БД/кэши (коннекты, hit), API (p95/p99, 5xx).
3. Бизнес-потоки: депозиты/выводы, ставки, запуск игр, авторизация, KYC.
4. Продукт/маркетинг: конверсии, ARPPU/LTV, кампании.
5. Качество процессов: MTTA/MTTR, Change Failure Rate, покрытие чек-листов.

Правило: каждая метрика должна иметь слой, владельца и формулу.

4) Источники данных и «истина»

Телееметрия онлайн: Prometheus/OTel, логи (ELK/ClickHouse), трассировки.
События и бухгалтерия: Kafka/Outbox, DWH/дата-марты (BigQuery/ClickHouse).
Ручные артефакты: постмортемы, тикеты, реестры инцидентов.
Внешние реестры: отчеты провайдеров (PSP/KYC/студии), биллинг.

Решение конфликта: при расхождениях «онлайн vs DWH» действует регламент приоритета (например, для SLA — агрегаты из DWH с источниковой трассируемостью).

5) Процесс аудита метрик (контур управления)

1. Инвентаризация: каталог метрик/SLO/SLA (название, владелец, слой, формула, источник, частота расчета).
2. Верификация формул: сверка SQL/пром-запросов с определением (unit-тесты расчетов).
3. Сэмплирование и перепроверки: выборки строк событий/логов и ручная сверка.
4. Сопоставление контуров: сравнение онлайн-дашбордов и DWH-отчетов.
5. Контроль изменений: ревью формул при релизах схем/логики.
6. Аудит SLA: проверка корректности сборок и исключений (planned maintenance, форс-мажор).
7. Отчет и улучшения: список обнаруженных расхождений и фиксов с дедлайнами.

6) Определения и формулы (образцы)

• `success = requests - (5xx + timeouts + circuit_open)`
• `success_rate = success / requests`

• в SSOT фиксируется единое определение окна (rolling 5m / 1h) и агрегации (HDR/TDigest).

• `SLO_availability_month = (время_работы - допустимые_исключения) / общее_время`

• `SLA_month = 99.90% аптайма по окну UTC, исключая плановые окна (T-48 уведомление), доказуемые аварии у транзитных операторов (документы).`

7) Качество данных: проверки и алерты

• Полнота (completeness): `received_events / expected_events ≥ 0.99`.
• Своевременность (timeliness): лаг загрузки ≤ N минут.
• Уникальность (uniqueness): без дублей по ключам (idempotency-key).
• Согласованность (consistency): суммы/валюта/знаки.
• Линейность (monotonicity): счетчики не «откатываются».

ALERT MetricsIngestionLagHigh
IF dwh_ingest_lag_minutes > 15 FOR 10m

ALERT EventsCompletenessDrop
IF (events_received / events_expected) < 0. 99 FOR 15m

ALERT DuplicateEventsSpike
IF rate(events_duplicates_total[10m]) > baseline_7d 2

8) Аудит SLA/OLA: методика

1. Соберите календарь исключений: плановые окна, согласованные деградации, акты вендоров.
2. Расчет аптайма: по единой временной зоне, с опорой на SSOT.
3. Сверка с инцидентами: таймлайн, билеты, постмортемы.
4. Атрибуция: собственные сбои, провайдер, транзит, DDoS, регламентные работы.
5. Периметр SLA: пользовательский опыт (E2E) vs один конкретный API.
6. Отчетность: отчет по месяцу/кварталу: факт, отклонения, компенсации (если применимо), корректирующие меры.

9) Проверка воспроизводимости расчетов

Версионирование формул: Git-репозиторий с SQL/PromQL/док-спецификациями.
Юнит-тесты метрик: на synthetic данных (edge-кейсы: пропуски, дубли, границы дат).
Data lineage: от дашборда назад к исходным таблицам и событиям.
Снапшоты: заморозка данных на отсечку, чтобы пере-расчеты были сопоставимы.

10) Контрольные выборки (sampling)

Ежедневно: 10–20 событий по ключевым потокам (депозит/ставка/KYC) — ручная сверка трассировки ↔ DWH.
Еженедельно: 1% сэмпл для сравнения «онлайн vs DWH» по агрегатам.
Ежемесячно: набор инцидентов с SLA-эффектом — детальная реконструкция.

Date/Window: 2025-10-01.. 2025-10-07
Metric: SLO_api_p99
Source A: Prometheus (rolling 5m)
Source B: DWH snapshot (1h buckets)
Deviation: + 6. 2% (A above B)
Reason: different aggregation windows
Action: align window in both contours to 5m/rolling
Term/Owner: 2025-11-10/squad-observability

11) Аудит дашбордов и оповещений

Единый словарь метрик: глоссарий прямо на дашборде.
Аннотации релизов/ивентов: чтобы видеть причину отклонений.
Сравнение «до/после релиза»: автоматические панели регрессий.
Дубли/расхождения: выявление «двух разных p99» — правка формул/окон.
Доступность панелей: права, резерв, контроль ссылок/версий.

12) Управление изменениями в метриках

RFC-процесс: изменение формулы/окна/источника — через RFC с оценкой влияния на SLA/отчеты.
Миграция «expand → migrate → contract»: временно ведем обе версии, сравниваем, затем выключаем старую.
Коммуникации: заранее уведомлять продукт/бизнес о сдвигах значений «по новой методике».

13) Специфики iGaming/финтех

Пики спроса: метрики должны выдерживать взрывные нагрузки (агрегации не «залипают»).
Провайдеры: SLA зависит от OLA вендоров → хранить их отчеты, статусы инцидентов и квоты.
Стоимость: `cost_per_1k_calls` и «стоимость успеха» — обязательные панели.
Антифрод/риск: чувствительность к задержкам и «ложным срабатываниям» метрик.

14) Дашборды аудита (минимальный набор)

Metrics Health: completeness/timeliness/duplicates, ingest-lag, ошибки ETL.
SLO/SLA Evidence: вычисленный SLO, фактический SLA, исключения, ссылки на инциденты/акты.
Online vs DWH Compare: p95/p99/Success Rate, отклонения и тренды.
Vendor SLA: аптайм/квоты/тайм-ауты/стоимость в разрезе провайдеров.
Release Impact: регрессии метрик после выкладок/включения фич.

15) Чек-лист аудита (операционный)

• Каталог метрик/SLO/SLA с владельцами и формулами актуален.
• SSOT определен для каждого отчета/панели.
• Юнит-тесты формул зеленые, пайплайны расчетов задокументированы.
• Алерты на качество данных активны (completeness/timeliness/duplicates).
• «Online vs DWH» расхождения ≤ допустимого порога (например, ≤2%).
• Согласованные исключения SLA задокументированы и приложены к отчету.
• Проведены контрольные выборки и оформлены акты.
• Все изменения формул прошли RFC и миграцию.

16) Примеры (фрагменты)

api_p99_ms:release:ratio =
(api_latency_p99_ms{release="after"} / api_latency_p99_ms{release="before"})

sql
SELECT event_date,
COUNT() AS received,
SUM(expected_count) AS expected,
COUNT()::decimal / NULLIF(SUM(expected_count),0) AS completeness
FROM events
JOIN expected_events USING (event_date, event_type)
WHERE event_type IN ('deposit','bet_placed','kyc_completed')
AND event_date BETWEEN:from AND:to
GROUP BY 1;

ALERT DwhVsOnlineDrift
IF abs(dwh_kpis{metric="api_p99"} - online_kpis{metric="api_p99"}) > 0. 02 online_kpis
FOR 30m
LABELS {severity="warning", team="observability"}

17) Анти-паттерны

Две разные формулы «одной» метрики на разных панелях.
Изменение метрики без миграции и уведомления — «скачки» в OKR/SLA.
Отчеты в локальном Excel как «истина» (невоспроизводимо).
Смешение часовых поясов и календарей в SLA-расчетах.
Исключения SLA не фиксируются документально.
Нет алертов на качество измерений.

18) KPI зрелости измерений

Drift Rate Online↔DWH (цель ≤2%).
Metrics Health Uptime (время без деградаций ingest/ETL).
Time-to-Fix Formula (время устранения ошибки в формуле).
SLA Dispute Rate (частота спорных кейсов с партнерами).
Coverage SLO/SLA (доля критичных путей с формально описанными SLO/SLA).

19) Роли и ответственность

Владелец метрики/сервиса: формула, источник, дашборд, алерты.
Observability/SRE: SSOT/платформа, тесты формул, алерты качества данных.
Data/BI: DWH, воспроизводимость отчетов, lineage.
Юристы/партнер-менеджеры: SLA-договоренности и исключения.
Инцидент-менеджер: атрибуция и связка инцидентов с SLA.

20) Быстрый старт (30 дней)

Неделя 1: инвентаризация метрик/SLO/SLA и владельцев; назначить SSOT.
Неделя 2: включить алерты качества данных и панель «Online vs DWH».
Неделя 3: провести контрольные выборки, выровнять оконность p95/p99.
Неделя 4: формализовать RFC-процесс для формул, подготовить ежемесячный SLA-отчет с приложениями.

21) FAQ

Q: Что считать SSOT для SLA?
A: Хранилище с воспроизводимыми расчетами (DWH) и полным lineage; онлайн-панели — для оперативного контроля, не для юридических актов.

Q: Как бороться с «двумя p99»?
A: Зафиксировать окно/метод агрегации в каталоге метрик, мигрировать панели, добавить алерт на дрейф.

Q: Как учитывать плановые работы?
A: Вести календарь исключений и автоматически вычитать их из SLA по правилам договора; хранить подтверждающие артефакты.