SLO на малом трафике и математика burn rate из первых принципов

Сервис при 100 запросах в час срабатывает с алертом 100% error rate. On-call просыпается. Один запрос упал. Математика SLO технически верна — и полностью бесполезна.

Граничный случай: малый трафик ломает наивные SLO

Сервис при 100 запросах в час сталкивается со структурной проблемой в арифметике 99.9% SLO.

Математика: 99.9% SLO → бюджет = 0.1% → 1 допустимый отказ на 1000 запросов. При 100 req/h 1000 запросов накапливается за 10 часов. Один отказ за часовое окно — это 1/100 = 1.0% error rate — в десять раз выше годового бюджета — хотя падение одного запроса не обязательно кризис.

Алерт срабатывает, on-call расследует, оказывается таймаут рассосался сам. Этот цикл уничтожает доверие к SLO-алертингу на малотрафиковых поверхностях.

Решения:

Синтетический трафик (предпочтительно): Генерировать постоянные probe-запросы с фиксированной частотой — знаменатель никогда не упадёт слишком низко. Проба каждые 10 секунд = 360 запросов/час, что даёт SLO-арифметике стабильную базу. Проба покрывает доступность (был ли эндпойнт достижим?), но не полную корректность user journey — комбинируй с real-traffic SLO для критических путей.

Агрегация по связанным сервисам: Рассматривай 10 маленьких внутренних сервисов как одну SLO-цель. Суммарный трафик в 10 раз больше, знаменатель стабилен. Работает когда сервисы логически эквивалентны (например, 10 shard handler’ов для одного типа данных).

Более длинные SLO-окна: Считать SLO за неделю вместо 28 дней rolling window. Использовать 24h или 7d recording window для оценки алертинга вместо 1h. Один отказ за 7 дней при 100 req/h — это 16 800 запросов с 1 отказом = 0.006% error rate — ниже бюджета. Компромисс: медленнее детекция (недельное окно занимает дни для накопления значимого сигнала при новой деградации).

Гибрид: event-based алертинг: Для очень малотрафиковых поверхностей считать SLO для reporting, но алертить по сырым счётчикам, а не по rate. «Более 5 отказов за 30 минут» — actionable; «error rate > 0.1%» — может и нет.

Google Workbook и платформы Nobl9, Pyrra, Sloth поставляют явные акомодации для малого трафика. Паттерн — не граничный случай: любой не-business-critical сервис имеет малотрафиковые поверхности.

Шесть подходов к алертингу: почему пять не работают

Google SRE Workbook классифицирует шесть подходов к SLO-алертингу. Понимание того, почему пять не работают — то, что делает Approach 6 обоснованным: не как рекомендацию для зазубривания, а как результат систематического устранения failure mode’ов.

Approach 1 — алерт когда error rate > SLO-порог: error_rate > (1 − SLO) Простой и неверный. SLO-порог — это бюджетная скорость — спроектированная так, чтобы нормальная вариация её превышала. При 99.9% SLO любой спайк выше 0.1% даёт алерт. Один плохой батч запросов — пейдж. Команды учатся игнорировать пейджер в течение дней — классическая спираль alert fatigue. Любое 5-минутное окно с чуть повышенными ошибками — это пейдж.

Approach 2 — требуем N последовательных минут выше порога: for: 5m добавлен к Approach 1. Лучше: устраняет краткие спайки. Но задержка детекции масштабируется с окном — устойчивый 5-минутный outage не пейджит 5 минут. Сброс всё ещё быстрый, восстановление работает. Но порог всё ещё неверный (бюджетная скорость, не burn rate), поэтому чувствительность всё ещё слишком высокая.

Approach 3 — единственный burn rate за длинное окно (например 14.4x за 1ч): (1 - ratio_rate1h) > (14.4 * 0.001) Ловит реальные outage’и. Сжигает 2% бюджета до срабатывания. Но: после устранения инцидента в 12:00 часовое окно ещё содержит данные с 11:00–12:00. Алерт продолжает срабатывать до ~12:55. On-call не может понять, сработал ли фикс. Долгое время сброса.

Approach 4 — двойной burn rate, OR-логика (длинное ИЛИ короткое): expr: A or B Устраняет время сброса добавлением короткого окна. Но OR значит — любое из окон достаточно для срабатывания. Короткое окно срабатывает на транзиентных спайках (шум). Длинное окно срабатывает поздно после устранения. OR даёт худшее из обоих подходов.

Approach 5 — двойная severity (пейдж на 14.4x, тикет на 1x): Два отдельных одно-оконных алерта на разных порогах. Лучше одного порога, но каждый алерт всё ещё использует одно окно. Пейдж имеет проблему долгого сброса. Тикет лучше (медленное горение ловится), но всё ещё шумный.

Approach 6 — MWMBR: длинное AND короткое, на каждый уровень severity:

page:   (burn_1h > 14.4x) AND (burn_5m > 14.4x)
page:   (burn_6h > 6x)   AND (burn_30m > 6x)
ticket: (burn_3d > 1x)   AND (burn_6h > 1x)

AND между окнами устраняет оба failure mode’а: длинное окно отвергает шум (краткий спайк не поддерживает 14.4x burn за 1 час), а короткое окно даёт быстрый сброс (очищается в течение 5 минут после фикса, потому что burn rate короткого окна падает ниже порога). Approach 6 — единственный, балансирующий задержку детекции, устойчивость к шуму и задержку восстановления.

Математика burn rate: вывод из первых принципов

Каждый канонический порог MWMBR выводится из одного уравнения:

burn_rate = (budget_fraction × period) / window

Где:

• budget_fraction = доля общего бюджета, которую должен потребить этот tier алерта при устойчивом горении
• period = SLO-окно (например 30 дней = 720 часов)
• window = длинное окно алерта (например 1ч, 6ч, 3д)

Вывод 14.4x (page 1ч+5м): Цель: пейджить когда инцидент, при устойчивом горении, потребит 2% бюджета за 1 час. burn_rate = (0.02 × 720ч) / 1ч = 14.4

Вывод 6x (page 6ч+30м): Цель: пейджить когда устойчивое горение потребит 5% за 6 часов. burn_rate = (0.05 × 720ч) / 6ч = 6.0

Вывод 1x (ticket 3д+6ч): Цель: тикет когда устойчивое горение потребит 10% за 3 дня. burn_rate = (0.10 × 720ч) / 72ч = 1.0

5-минутные и 30-минутные короткие окна используют тот же burn rate, что и их парные длинные окна — они не меняют порог, только добавляют проверку «это всё ещё происходит прямо сейчас?»

Пересчёт для 28-дневного окна: Примеры Google Workbook используют 30 дней (720ч). Большинство платформ по умолчанию 28 дней (672ч). Пороги немного сдвигаются: (0.02 × 672) / 1 = 13.44x. Большинство команд округляют до 14x для 28-дневного окна. Любая команда может пересчитать — формула та же.

Пересчёт для другой SLO-цели: 99.5% SLO имеет бюджет = 0.5%. Error rate при 14.4x burn: 14.4 × 0.005 = 7.2%. Порог burn rate (14.4x) не меняется; меняется error rate порог, потому что меняется бюджетная скорость. PromQL-выражение (1 - ratio_rate1h) > (14.4 * 0.001) должно быть обновлено до (14.4 * 0.005) для 99.5% SLO. Это самая распространённая ошибка ручного написания: скопировать 99.9% алерт для 99.5% SLO и забыть обновить 0.001 → 0.005.