Error budget policy, latency SLO и составные journeys

Error budget policy: больше чем правило

Алерты настроены. Теперь спроси: когда пейдж срабатывает и бюджет достигает нуля — что происходит на самом деле? Без письменного ответа команда импровизирует — и обычно всё равно выкатывает. Error budget policy — это написанный, подписанный документ, задающий, что происходит при исчерпании бюджета. Без подписей — это рекомендация, которую давящие on-call-команды игнорируют в релизных авралах. С подписью director-уровня — это завет.

Обязательное содержание:

• Триггер заморозки деплоев: «при достижении нуля — стопаем feature-деплои, кроме P0-фиксов и security-патчей»
• Триггер postmortem: «если один инцидент сжигает >20% бюджета — postmortem обязателен»
• Выход из заморозки: «фокус на работе по надёжности до восстановления бюджета выше 50%»
• Путь эскалации: «если заморозка длится >2 недель — эскалация VP/CTO»

Out-of-scope exclusions (события, не сжигающие бюджет):

• Load test и penetration test запросы (помечены header’ом или IP-диапазоном)
• Известные боты и сканеры
• Запросы во время запланированных maintenance window
• Запросы, отброшенные rate-limit’ом на границе

Эти категории должны быть явно зафиксированы в документе policy и применяться как label-фильтры в SLO-платформе — иначе каждый postmortem превращается в спор о том, считать ли инцидент против бюджета.

Latency SLO: bucket’ы, а не квантили

Availability SLO тривиально — отношение счётчиков: 5xx_count / total_count. Latency SLO выражает «X% запросов под Y мс». Это звучит как percentile, но реализуется как счётчик:

latency_sli = http_request_duration_seconds_bucket{le="0.2"} / http_request_duration_seconds_count

Histogram bucket на пороге SLO даёт этот счётчик напрямую — histogram_quantile не нужен, и никакой погрешности оценки, загрязняющей бюджет. Именно поэтому RED-Duration histogram обязан иметь границу bucket’а ровно на пороге SLO: без неё SLO нельзя оценить без аппроксимации.

Multi-threshold latency SLO: «90% запросов под 100мс И 99% под 500мс» ловит tail-latency, прячущийся за одним percentile’ом. Сервис может пройти 99%-под-500мс, скрывая деградированный хвост, проваливающий 90%-под-100мс. Production-grade SLO-платформы поддерживают несколько порогов через отдельные SLI-отношения с worst-of-логикой.

Составные SLO: проблема умножения

Journey через API gateway → auth → inventory → payment → database означает, что запрос «хороший» только если все пять сервисов были хорошими. Каждый сервис независимо на 99.9% даёт потолок journey 0.999⁵ ≈ 99.5% — не 99.9%. При зависимых отказах (разделяемые зависимости, региональные инциденты) потолок ещё ниже, потому что отказы кластеризуются во времени.

Фикс: добавить journey-level SLI на API gateway — считать успешные завершения checkout / всего попыток checkout, не per-service 200-е коды. Per-service SLO становятся диагностическим контекстом; заголовок — journey SLO. Именно этот слой испытывают пользователи.

Найти доминирующего виновника: когда journey SLO красный, а per-service дашборды зелёные — вытаскиваем per-service failure rate’ы и ранжируем. Применяется Pareto: 80% journey-отказов обычно от 1–2 сервисов. Фиксируем их первыми — максимальный рычаг за инженерный час.