Слепота наблюдения

Вы уже научились отслеживать среднюю скорость запросов на проекте, и это большой шаг. Без преувеличений и какой либо иронии.
И теперь, когда вы перешли от "не измеряем ничего" до "измеряем среднее" — вы попали в ловушку.

Пока вы с удовольствием наблюдаете в отчетах красивые 200ms — ваши пользователи стучат в службу поддержки со словами "у меня все висит".
И они не врут, у них действительно время ответа порядка 6 секунд. Но и вы не врете, у вас действительно 200ms в отчете!

Врет метрика, а вы ей верите.

Давайте разбираться.

Ваши пользователи не живут в мире среднего. У них есть один единственный запрос, и они определяют по нему, быстрый у вас сервис или не особо.
1000 пользователей за минуту отправила по одному запросу. Распределение на графике.

Получаем среднюю задержку 272ms в окне за минуту на дашборде и 52 недовольных пользователей из которых 11 даже слегка в шоке от того что в 2025 кто то может отвечать в районе 10 секунд.

А теперь давайте добавим сюда перцентили.
Перцентиль — это значение, ниже которого укладывается определённый процент всех наблюдений. Обозначается как pX, где Х это процент порога.
Например, p95 — это время, меньше которого укладываются 95% всех запросов, а оставшиеся 5 % — самые медленные.

Для нашего примера p50 — 103ms, p95 — 1319ms, p99 — 6169ms
Вот теперь мы видим откуда приходят жалобы в службу поддержки.
Правда непонятно откуда такие задержки, по 10 секунд.

Придется взглянуть на физику распределенных систем чуть ближе...

Закон Литтла (Little’s Law) и чуть чуть теории массового обслуживания (queueing theory).

Чтобы понять откуда взялись задержки в десятки раз больше среднего нужно посмотреть на систему как на очередь.

Закон Литтла

Где:
— среднее число запросов в системе (или очереди)
— скорость прихода запросов (RPS)
— среднее время в системе (задержка)

Всего 3 параметра, но большинство инженеров, если и знают, то не используют на практике.

Сколько запросов обрабатывается одновременно?
Дано: λ = 100 req/s, W = 200ms
запросов в системе одновременно
Теперь вы можете посчитать сколько к примеру на сервере будет съедено памяти и сколько используется коннектов к БД. Если 1 запрос потребляет 20Mb — для нашего примера общее потребление будет 400Mb.

Какая задержка при текущей нагрузке?
Дано: λ = 50 req/s, в среднем L = 5 активных запросов.
 — среднее время жизни запроса в системе.
Это еще не SLA, сначала доберемся до  и .

Какая нагрузка сейчас у системы?
Дано: W = 300ms, воркеров
текущая нагрузка при полной занятости. Не предел, максимум зависит от μ (скорости обслуживания одного воркера).

Но сам по себе закон Литтла не учитывает загрузку системы, для этого нам придется обратиться к теории очередей чтобы разобраться как утилизация влияет. Если нужны подробности — вам под кат, если результаты — переходите сразу к графику.

Если коротко

• При повышении утилизации базовая задержка растет по экспоненте. При — вырастает в 2 раза, при — в 10 раз.

• При повышении утилизации количество запросов растет так же по экспоненте.

• В реальности чаще встречается модель G/G/N — несколько воркеров и произвольные распределения времени обслуживания.
  Хвосты там ещё тяжелее, поэтому эти формулы — эвристика, а целевую утилизацию стоит держать ниже.
  

Что это значит для нас?
Малое ρ (до 0.7) — систему устойчива, задержки предсказуемы.
Среднее ρ (0.8-0.9) — начинаются хвосты. p95/p99 растут.
Большое ρ (>0.95) — очередь растет лавинообразно. Время отклика предсказать невозможно.

Оценка конкурентности под бюджет.
Теперь, зная как ρ влияет на хвост, можем прикинуть нужную конкурентность.

Пример:
Цель — выдерживать 200rps при p95 = 150ms;

Это консервативная оценка: закладывайте буфер под хвост (p95 > среднее). Держим ρ < 0.7, чтобы хвост не взрывался.
Точное значение можно получить только через нагрузочное тестирование, но формула даст стартовую точку для планирования конкурентности.
А если внутри есть fan-out — нагрузка умножается.

Бюджет задержек

Если вы уже перешли от замеров среднего до перцентилей — возможно пора сделать еще одни небольшой но важный шаг. Шаг к e2e бюджету.

Давайте представим что у нас есть CUJ e2e SLO, p95=300ms. (critical user journey end to end service level objective. Набор конечно вышел, аж самому страшно)
Но как его достичь? Нельзя просто сказать "все сервис должны быть быстрыми а очереди пустыми". Без декомпозиции каждый сервис выставит свой таймаут наугад и e2e рассыпется.

Давайте посмотрим что такое вообще e2e бюджет.

• T_i — задержка конкретного узла (гейт, оркестратор, сервис, хранилище, внешние зависимости и т.д.),

• RTT — сеть/интернет,

• буфер — запас под вариации и хвосты.

Теперь будем декомпозировать.

И первым в голову приходит мой любимый антипаттерн "всем по справедливости". Когда у вас 5 сервисов и вы каждому раздаете по 60ms не учитывая фанаут и критичность.

Второй — "бюджетирования в ноль", когда забывают оставить буфер. Гейту дадим 60ms, оркестратору 80, зависимостям оставим 120, сеть съест 40. А потом p95 всплеск на любом этапе и в бюджет не уложились. А всплеск будет. И вероятность у него не 5%, потому что мы говорим про последовательные вызовы. Для 4 узлов для 6 , для 10 — 40%. Добавляем сюда корреляции (общие пики CPU/GC/сеть) и получаем еще более печальную картину.

Вобщем без буфера никуда. Закладывайте от 15% до 25% на весь e2e бюджет.
Гейт 30, оркестратор 40, зависимости 120, сеть 60, общи буфер 50.

И теперь команда отвечающая за гейт знает что хэпипас должен укладываться в 30ms, в противном случае они факапят общий e2e. А вы знаете кто ответственен за срыв SLO и куда прикладывать усилия по оптимизации.

Что дальше?

Теперь у вас есть:

• Понимание почему среднее врёт (перцентили!)

• Инструменты оценки (закон Литтла, утилизация)

• Метод планирования (e2e бюджет с буфером)

Следующий шаг — научить систему соблюдать бюджет в рантайме а не только в документации. Дедлайны, отмена и десяток паттернов для борьбы с хвостовой задержкой. Но это уже тема отдельной статьи.

А пока — пересчитайте вашу конкурентность по формуле , проверьте утилизацию (держите ) и разложите ваш SLO на критический путь с 20% буфером.

Хватит на месяц работы, а там глядишь и про управление хвостами напишу.

Удачи!