Операции и Управление → Метрики производительности

Метрики производительности

1) Зачем нужны метрики производительности

• обнаруживать деградации до инцидентов,
• прогнозировать емкость и бюджет,
• сравнивать альтернативные решения (кэш vs БД, gRPC vs REST),
• управлять регрессиями после релизов.

Принципы: единый словарь метрик, агрегирование по перцентилям (p50/p90/p95/p99), раздельный учет «горячих» и «холодных» путей, контекст (версия, регион, провайдер, устройство).

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

2.1 Базовые SRE-рамки

Четыре золотых сигнала: Latency, Traffic, Errors, Saturation.
RED (для микросервисов): Rate, Errors, Duration.
USE (для железа): Utilization, Saturation, Errors.

2.2 Уровни

Инфраструктура: CPU, RAM, диск, сеть, контейнеры, узлы.
Платформа/Сервисы: API-эндпойнты, очереди, кэши, БД, шины событий.
Клиентский опыт: Web Vitals, мобильные SDK, стриминг, CDN.
Дата-платформа: ETL/ELT, стримы, витрины, BI задержки.
Бизнес-критичные флоу: авторизация, KYC, депозиты/выплаты, гейм-раунды.

3) Каталог ключевых метрик и формулы

3.1 API и микросервисы

RPS (Requests per second).
Latency p50/p95/p99 (ms) — желательно «end-to-end» и «backend-only».
Error Rate (%) = 5xx + валидируемые 4xx / все запросы.
Saturation: средняя длина очереди воркеров, «in-flight» запросы.
Cold Start Rate (для FaaS).
Throttling/Dropped Requests.

SLO пример: p95 latency ≤ 250 ms при RPS до 2k в регионе EU-East; ошибки ≤ 0.5%.

3.2 Базы данных

QPS/Transactions/s, avg/median query time, p95 query time.
Lock Waits / Deadlocks, Row/Index Hit Ratio, Buffer Cache Miss%.
RepLag (репликация), Checkpoint/Flush time, Autovacuum lag.
Hot Keys/Skew — топ-N ключей по нагрузке.

Формула «Запросов на ядро»: QPS / vCPU_core_count → сигнал для шардирования.

3.3 Кэш и CDN

Hit Ratio (%), Evictions/s, Latency p95, Item Size percentiles.
Origin Offload (%) для CDN, TTFB, Stale-while-revalidate hit%.

3.4 Очереди/стримы

Ingress/egress msg/s, Consumer Lag (сообщений/время), Rebalance rate.
Processing Time p95, DLQ Rate.

3.5 Инфраструктура/контейнеры

CPU Utilization %, CPU Throttle %, Run Queue length.
Memory RSS/Working Set, OOM kills, Page Faults.
Disk IOPS/Latency/Throughput, Network RTT/ retransmits.
Node Saturation: pods pending, pressure (CPU/Memory/IO).

3.6 Web-клиент (UX)

Core Web Vitals: LCP, INP, CLS.
TTFB, FCP, TTI, Resource Timing (DNS, TLS, TTFB, download).
Error Rate (JS), Long Tasks, SPA route change time.
CDN Geo-Latency (перцентильный).

3.7 Мобильный клиент

App Start time (cold/warm), ANR rate, Crash-free sessions %.
Network round-trips/session, Payload size, Battery drain/session.
Offline success rate (кешированные операции).

3.8 Дата-платформа и отчетность

Freshness Lag (T-now → витрина), Throughput rows/s, Job Success %.
Cost per TB processed, Skew по партициям, Late events %.
BI Time-to-Render p95 для ключевых дашбордов.

3.9 Доменно-критичные флоу (iGaming как пример)

Auth p95, KYC TTV (Time-to-Verify), Deposit/Withdrawal p95.
Game Round Duration p95, RNG call latency, Provider RTT p95.
Payment PSP success rate, Chargeback investigation SLA.

4) Нормализация, перцентили и атрибуция

Перцентили против средних: фиксируем p50/p90/p95/p99 — средние сглаживают пиковые боли.
Разрезы: версия приложения, регион, провайдер, канал сети (4G/Wi-Fi), устройство.
Корреляция: связываем «backend-only» и «real-user» метрики для причинно-следственных цепочек.
Exemplars/Traces: связываем экстремальные перцентили с трассировками.

5) Пороги и алерты (примерная сетка)

Latency p95 (core API): warning > 250 ms, critical > 400 ms 5 мин подряд.
Error rate: warning > 0.5%, critical > 2% (по эндпойнту, не глобально).
DB RepLag: warning > 2 s, critical > 10 s.
Kafka consumer lag (time): warning > 30 s, critical > 2 min.
Web LCP (p75): warning > 2.5 s, critical > 4 s.
Mobile ANR: warning > 0.5%, critical > 1%.
ETL Freshness: warning > +15 min, critical > +60 min от SLA.

Используем статические + адаптивные пороги (сезонность, дневные шаблоны), дедупликацию и группировку алертов по сервисам/релизам.

6) Тестирование производительности

Типы: baseline, стресс, длительное (soak), хаос (degrade links/PSP).
Нагрузочные профили: по реальным трейсам (distribution-based), «бурсты», региональные пики.
Цели: достижение SLO при целевых RPS и mix операций, валидация backpressure.
Метрики прогона: Throughput, Error%, p95 latency, GC паузы, CPU throttle, queue lag, cost/run.

Правило регрессий: релиз считается успешным, если p95 не ухудшен >10% при равном профиле, а стоимость запроса (CPU-ms/запрос) не выросла >15%.

7) Планирование емкости и цена/производительность

Demand model: RPS по часам × средняя работа/запрос (CPU-ms, IO-ops).
Headroom: 30–50% запаса для критичных путей, auto-scaling по P95.
Cost KPIs: Cost per 1k requests, Cost per GB served, $ per 1 p.p. LCP улучшения.
Кэширование/денормализация: считать «cache ROI» = (экономия CPU-ms − стоимость кэша).
Теплые и холодные регионы: offload в CDN/edge, репликация «только чтение».

8) Практики наблюдаемости и профилирования

Трассировки: распределенные trace-ID через все hop’ы; семплирование умное (tail-based).
Метрики: Prometheus/OpenTelemetry, единая нотация имен и лейблов.
Логи: с корреляцией по trace/span, budget на лог-шум, редактирование PII.
Профилировщики: CPU/Heap/Alloc/Lock profiles, непрерывное профилирование (eBPF).
Экземпляры-образцы: связываем p99 всплески с конкретными span/SQL/PSP-коллом.

9) Метрики релизов и команд (для полноты)

DORA: Deployment Frequency, Lead Time, Change Failure Rate, MTTR.
SPACE: удовлетворенность, производительность, активность, коммуникация, эффективность.
Эти метрики не про железо, но напрямую влияют на устойчивость производительности.

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

Гнаться за средними: игнорирование p95/p99.
«Глобальный» error rate: скрывает болезненные эндпойнты.
Без атрибуции по версиям: невозможно ловить регрессии клиента.
Алерт-спам: пороги без гистерезиса и коррекции сезонности.
Оптимизация «вслепую»: отсутствие профилирования и трассировок.
Смешение UX и backend latency: неверные выводы по клиентскому опыту.

11) Чек-листы

Единый стандарт метрик

• Словарь метрик с формулами, единицами, владельцами
• Обязательные перцентили p50/p90/p95/p99
• Трейс-корреляция и лог-корреляция
• Теги: регион, версия, провайдер, устройство, канал сети
• Пороги с гистерезисом и дедупликацией

Перед релизом

• Бейзлайн p95/p99 на стейдже и проде
• Канареечный трафик + сравнение метрик A/B
• Фича-флаг с быстрым откатом
• План наблюдения (observability runbook)

Регулярно

• Ревью самых медленных топ-N запросов/SQL
• Аудит кэш-политик и TTL
• Проверка Freshness и репликаций БД
• Тесты деградации внешних провайдеров (PSP, KYC)

12) Мини-плейбуки (пример)

Деградация p95 /api/payments

1. Сверить error% и внешние таймауты PSP.
2. Проверить consumer lag очереди коллбеков.
3. Просмотреть trace примеров p99: узкое место SQL/HTTP?
4. Включить кэш справочников/лимитов, снизить N+1.
5. Бюджет: временно поднять ресурсы воркера на 20%, включить autoscale.
6. Post-fix: индекс по (psp_id, status, created_at), ретрай-джиттер.

Рост RepLag в БД

1. Проверить «тяжелые» запросы и долгие транзакции.
2. Увеличить параллелизм репликации, тюнить checkpoint.
3. Offload чтения в кэш/реплики только чтение.
4. При пиковых окнах — частичный денорм + батчи.

13) Примеры формул/SQL (упрощенно)

Error Rate по эндпойнту

sql
SELECT endpoint,
100. 0 SUM(CASE WHEN status >= 500 THEN 1 ELSE 0 END) / COUNT() AS error_pct
FROM http_logs
WHERE ts >= now() - interval '5 minutes'
GROUP BY 1
HAVING COUNT() > 500;

Latency p95 (TDigest/Approx)

sql
SELECT endpoint, approx_percentile(latency_ms, 0. 95) AS p95_ms
FROM http_metrics
WHERE ts >= date_trunc('hour', now())
GROUP BY 1;

Consumer Lag (время)

sql
SELECT topic, consumer_group,
max(produced_ts) - max(consumed_ts) AS lag_interval
FROM stream_offsets
GROUP BY 1,2;

Web LCP p75

sql
SELECT approx_percentile(lcp_ms, 0. 75) AS lcp_p75
FROM web_vitals
WHERE country = 'UA' AND device IN ('mobile','tablet')
AND ts >= current_date;

14) Встраивание в дашборды и отчетность

Карточки KPI: p95 latency, error%, RPS, saturation с трендами WoW/DoD.
Топ-N «худших» эндпойнтов/SQL/ресурсов, кликабельный drill-down → trace.
Корреляция версий клиента: граф «версия → p95 LCP/INP → конверсия».
Карта мира: geo-latency (CDN), PSP latency по регионам.
SLO-панель: доля времени в SLO, вылеты из SLO, «бюджет ошибок».

15) Итоги

Метрики производительности — это системная дисциплина: единый словарь, перцентили, атрибуция, хорошая наблюдаемость и строгие SLO. Комбинируя технические (латентность, лаги, кеш-хиты) и продуктовые сигналы (время KYC, депозит p95, LCP), вы управляете качеством опыта и стоимостью его доставки — предсказуемо и масштабируемо.