KPI инфраструктуры и аптайм

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

KPI инфраструктуры превращают «чувства» о стабильности в измеримые цели, управляют риском и фокусом работ. Правильные метрики связывают технические SLI с бизнес-результатами (конверсия, Time-to-Wallet, LTV) и позволяют планировать развитие, нагрузку и долю инноваций vs надежности.

Базовые понятия: SLI, SLO, SLA и бюджет ошибок

SLI (Service Level Indicator) — измеряемый показатель качества: доля успешных запросов, p95 latency, аптайм за интервал.
SLO (Service Level Objective) — цель по SLI (например, «успех ≥ 99.9% за 30 дней»).
SLA (Agreement) — внешнее обещание с неустойками/кредитами. Всегда производное от SLO, но не равно ему.
Бюджет ошибок = `1 − SLO`. Это максимально допустимая доля «неуспеха» за окно измерения. Используется для принятия решений о рисковых релизах и экспериментах.

• SLO доступности 99.95% за 30 дней → бюджет ошибок 0.05% ≈ 21.6 минут «неуспеха» в календарном месяце.

Четыре «золотых» сигнала и дополнительные

1. Латентность (p50/p90/p95/p99, tail важнее среднего).
2. Ошибки (5xx/timeout/бизнес-ошибки).
3. Трафик/пропускная (RPS/QPS, MBps).
4. Насыщение (CPU/RAM/IO/FD/подключения/GC/квоты).
Дополнительно: холодный старт, очереди/беклог, время деплоя, SLO-комплаенс.

Модель SLI для разных типов сервисов

HTTP/API

Доступность: `(успешные 2xx/3xx − логические ошибки) / (все запросы)`

Латентность: `p95` для успешных запросов; цель по «горячим» маршрутам.
Качество: доля запросов с `audience/scope` корректными (без authZ-ошибок).

Очереди/асинхрон

Время обработки сообщения: p95 end-to-end ≤ N сек.
Backlog: медиана < X, хвост p99 < Y.
Ошибка доставки: ≤ Z ppm.

БД/кэш

Латентность операций: p95 get/put/commit.
Насыщение: connection pool usage, hit-ratio кэша.
Ошибки: timeouts, deadlocks, eviction storms.

CDN/статик

Hit Ratio: ≥ целевого уровня; деградация → рост нагрузки на origin.
Доступность POP: Anycast-раскладка, отказы компенсируются соседями.

Платежи (бизнес-SLI)

Time-to-Wallet p95, успешность депозита/вывода %, rate отказов PSP.

Расчет доступности и «аптайма»

Доступность сервиса = `успешные запросы / все запросы` (предпочтительно, а не «минуты аптайма»).
Альтернатива для инфраструктурных узлов: `время в состоянии «зеленый» / время окна`.
Календарное окно: 28–31 день, скользящее окно: последние 30/90 дней.
Рабочие часы/критические окна: для backoffice может считаться аптайм по графику (например, 08:00–22:00 местного времени).

• `Availability(A) ≈ Av(B) × Av(C) × Av(A|B,C)` — важно закладывать SLO на границах.

Пример SLO-набора (образец)

API Gateway: доступность ≥ 99.95%/30д; p95 latency ≤ 120 мс; ошибка ≤ 0.2%.
Checkout/Payments: успех депозита ≥ 98.5%/30д; Time-to-Wallet p95 ≤ 90 с; PSP-timeouts ≤ 0.3%.
База данных: p95 read ≤ 10 мс; p95 write ≤ 25 мс; replica lag p95 ≤ 150 мс.
Кэш: hit ratio ≥ 85%; eviction storms = 0/30д.
Выплаты: p95 обработка ≤ 5 мин; фрод-фолс-позитивы ≤ 0.3%.

Бюджет ошибок и управление изменениями

Если бюджет ошибок исчерпан на 50%+ раньше середины окна — вводится «заморозка» фич/релизов, фокус на стабилизации.
Если бюджет расходуется медленно — можно ускорять эксперименты/канарейки.
Потребление бюджета связывайте с конкретными релизами/инцидентами через `release_id`.

Алертинг: как не «звонить ночью» зря

Алерты только по SLO-деградации и жизненно важным симптомам, а не по каждой метрике.
Multi-window, multi-burn rate: короткое окно (5–15 мин) + длинное (1–6 ч).
Пример: «Burn rate 14× за 5 мин И 6× за 1 час» → страница on-call.
Тихие часы для не-P1 сигналов; маршрутизация по ответственности (ownership).

Дашборды и практики визуализации

SLO-панель: комплаенс по сервисам, оставшийся бюджет, карты зависимостей.
Latency-панель: p50/p90/p95/p99, разложение по маршрутам/тенантам/странам/ASN.
Error-панель: коды/причины, корреляция с релизами/фичфлагами.
Capacity-панель: срез CPU/RAM/IO/нетворк/FD/коннекты, тренды и прогнозы.
Бизнес-панель: конверсия, Time-to-Wallet, депозиты/выводы, влияние защит (WAF/антибот).

Инциденты, MTTR и постмортемы

• MTTD (обнаружение), MTTA (аккепт), MTTR/MTTC (восстановление/сдерживание), % инцидентов без RCA в срок.
• Плейбуки: кто эскалирует, как включить фичфлаги/блоки, как откатить релиз, коммуникация с бизнесом.
• Постмортем (blameless): факты, линия времени, первопричины (тех/процессы), действия: немедленные/долговременные, тесты регрессии, влияние на SLO.

Производительность, насыщение и деградация

Headroom: целевой запас ресурсов (например, CPU < 70% p95, RAM < 75% p95).
Hot paths: профилирование критических маршрутов; `p99` важнее среднего.
Degradation modes: кэш-только, read-only, drop-шлифовка неважных запросов, «ограничение ставок»/квоты.

Формулы и примеры расчетов

1) Доступность по запросам

availability = (total_requests - error_requests) / total_requests

где `error_requests` = 5xx + timeouts + бизнес-ошибки (настраивается).

2) Бюджет ошибок (минуты)

error_budget_minutes = window_minutes (1 - SLO)

Пример: 30 дней (43 200 мин), SLO 99.95% → 21.6 мин.

3) Burn rate

burn_rate = observed_error_ratio / (1 - SLO)

Если SLO 99.9% (бюджет 0.1%), а ошибка 1% → burn_rate = 10×.

4) Составная доступность

A_total ≈ A_gw × A_auth × A_db × A_psp

Небольшие падения мультипликативно бьют по общему A.

Политики измерения и исключений

Внеплановые окна (инциденты) — учитываются.
Плановые окна обслуживания — учитываются только если SLA так прописан; для SLO часто не вычитаются (или помечаются отдельно как `planned_downtime`).
Синтетика vs реальные пользователи: полезно иметь оба канала (RUM + синтетические проверки).

Примеры артефактов

KQL/PromQL (идеи)

promql sum(rate(http_requests_total{status=~"5..    timeout"}[5m]))
/
sum(rate(http_requests_total[5m]))

promql histogram_quantile(0. 95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, route))

promql
(
sum(rate(errors_total[5m])) / sum(rate(requests_total[5m]))
) / (1 - 0. 999)

SQL (бизнес-SLI по платежам)

sql
SELECT date_trunc('minute', finished_at) AS ts,
100. 0 sum((status='SUCCESS')::int)::float / count() AS payment_success_pct,
percentile_cont(0. 95) WITHIN GROUP (ORDER BY EXTRACT(EPOCH FROM (finished_at - started_at))) AS ttw_p95_sec
FROM payments
WHERE finished_at > now() - interval '30 days'
GROUP BY 1 ORDER BY 1;

Управление зависимостями и каскадами

Контракты SLO между командами: gateway↔auth↔wallet↔PSP.
Degradation policies: при падении зависимости сервис переходит в «упрощенный режим».
Feature flags: отключение не-критичных функций, «серый выпуск» для снижения хвостов latency.

Capacity Planning и прогнозы

Щомес. прогноз RPS/MBps по трендам и событиям (турниры, матчи, акции).
Load testing по «золотым путям», отдельные тесты для PSP/выплат.
Запас в пике: целевой коэффициент 1.3×–2.0× от ожидаемой нагрузки.

Чек-лист внедрения SLO/KPI

1. Определить критичные пользовательские пути и договориться о SLI «с точки зрения клиента».
2. Выбрать цели SLO и окно (30/90 дней); посчитать бюджет ошибок.
3. Встроить сбор метрик в шлюзы/сервисы, нормализовать коды/причины.
4. Настроить burn-rate алерты (короткое + длинное окно), маршрутизацию и on-call.
5. Визуализировать SLO-комплаенс, связывать с релизами/фичфлагами.
6. Завести политику «бюджет против изменений» и процесс заморозки.
7. Ретроспективы и RCA по каждому превышению, тесты регрессии.
8. Ежеквартально ревизировать SLO по фактическому использованию бюджета и бизнес-целям.

Типичные ошибки

Измеряют «аптайм по пингу», игнорируя ошибки приложений.
SLO выставлены «про запас» (99.999%), но недостижимы и ничего не решают.
Алерты по низкоуровневым метрикам вместо пользовательских симптомов.
Нет карты зависимостей → непонятно, где горит.
Нет связи SLO с релизами → непонятно, кто «съел» бюджет.
Игнор хвостов p99 → хорошие средние, но плохой UX VIP-пользователей.

Специфика для iGaming/финтех

Пики по расписанию: матчи/ивенты/акции — заранее повышать capacity, прогревать кэш/CDN, включать особые профили лимитов.
Бизнес-SLI: Time-to-Wallet, успешность депозита/вывода, «скорость выплаты» p95; в корне дашбордов.
PSP/партнеры: отдельные SLO/дашборды по провайдерам, автоматическое переключение маршрутов.
Антибот/антифрод: не должно выедать бюджет ошибок — отделяйте «правомерные блоки» от «технических ошибок».
Регуляторика: хранение журналов, воспроизводимость расчетов SLO/SLA, отчеты по инцидентам.

FAQ

Нужно ли вычитать плановые работы из SLO?
Обычно нет: SLO отражает переживаемый пользователем опыт. Для SLA можно оговорить исключения.

Почему p95, а не среднее?
Среднее маскирует хвосты; UX определяют хвосты (p95/p99).

Можно ли один SLO на весь продукт?
Нужно дерево SLO: агрегатный по продукту и дочерние по критичным путям/компонентам.

Итог

Сильная система KPI инфраструктуры — это пользовательские SLI, реалистичные SLO, бюджет ошибок как рычаг управления изменениями, умный алертинг и дисциплина инцидентов и RCA. Свяжите технические показатели с бизнес-метриками, автоматизируйте сбор и визуализацию — и инфраструктура станет предсказуемой, а аптайм подконтрольным даже в пиковых сценариях.