Если дашборд показывает среднее время ответа 120 мс, звучит здорово. Но если 1% пользователей ждёт каждый запрос по 4 секунды — это серьёзная проблема, и средние её никогда не покажут.
Проблема средних
Среднее схлопывает распределение в одно число. Сервис, отвечающий за 100 мс на 99 запросов и за 10 000 мс на один, имеет среднее ~199 мс. Ни 100 мс, ни 10 000 мс. Бесполезно.
Перцентили рассказывают правду
Перцентильные метрики режут распределение в конкретных точках:
- p50 (медиана) — половина пользователей быстрее, половина медленнее
- p95 — 95% запросов укладываются в это время
- p99 — 99% запросов укладываются в это время
- p999 — хвост хвоста
Для большинства пользовательских API p99 — самая рабочая цель SLO: она ловит реальные выбросы, но не подчиняется редким наихудшим пикам.
Осмысленные SLO
Хорошая отправная точка для веб-API:
p50 < 100 ms — типичный пользовательский опыт
p95 < 500 ms — приемлемый «медленный день»
p99 < 1000 ms — система деградировала, но работает
В k6 пороги задаются прямо в конфиге теста:
export const options = {
thresholds: {
http_req_duration: [
'p(50)<100',
'p(95)<500',
'p(99)<1000',
],
},
};
При нарушении любого порога k6 завершается с ненулевым кодом — идеально, чтобы валить CI-пайплайн.
Гистограммы тоже важны
Даже p99 может обмануть, если окна перцентилей слишком широкие. Для высоконагруженных сервисов смотрите гистограммы и heatmap'ы во времени. p99, всплескивающий каждый час в минуту :00, указывает на scheduled job, а не на проблему масштабирования.
Отслеживайте перцентили во времени и ставьте алерты на устойчивые нарушения — а не на одиночные пики.