# Burn rate inference SLO: оповещения в нескольких окнах

Как строить burn-rate alerts для inference SLO: error budget, несколько временных окон, низкий трафик и проверка правил на синтетических рядах.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/provider-error-budget-burn-rate-alerts/
Language: ru

Короткий всплеск ошибок и медленное ухудшение требуют разной реакции. Простой alert «ошибок больше заданного процента» может пропустить длительный расход бюджета либо часто срабатывать на малом трафике. Для inference API полезен burn rate, связывающий наблюдаемую долю плохих событий с допустимым бюджетом. Но арифметика имеет смысл только после определения, какой stream считается успешным и какие запросы входят в знаменатель.

## Начните с определения SLO

[Google SRE об alerting](https://sre.google/workbook/alerting-on-slos/) рассматривает правила как способ обнаружить существенный расход error budget. Это не источник готового обязательного SLA для OpenRouter или любого другого inference-провайдера. Цель и период выбираются продуктом, затем переводятся в измеримые good и total events.

Сохраните ссылку на определение SLI вместе с правилом. Если midstream failure считается плохим событием, он должен попасть в счётчик независимо от HTTP 200. Если cancellation обрабатывается отдельно, это тоже отражается до расчёта rate. Нельзя исправить неверную классификацию подбором красивого alert threshold.

## Вычислите смысл burn rate

Burn rate сопоставляет фактическую долю плохих событий с долей, допускаемой выбранной целью. Безразмерное отношение показывает темп расхода, но не гарантирует, что он сохранится в будущем. Короткое наблюдение описывает текущее окно, а не прогноз качества всего следующего месяца.

[Методика SLO](https://sre.google/workbook/implementing-slos/) помогает отделить техническое измерение от решения о допустимой надёжности. В документации правила назовите единицу события, окно, поведение при отсутствии данных и ответственного за действие. Само наличие метрики не устанавливает, когда требуется срочное вмешательство человека.

## Используйте несколько окон

Короткое окно помогает заметить быстрый расход, длинное подтверждает устойчивость проблемы. Их сочетание уменьшает часть шумных срабатываний, но конкретные значения требуют проверки на выбранном трафике. Не копируйте числа из примера как универсальную настройку без объяснения цели и времени реакции.

Для потокового сервиса задержка между началом и завершением запросов влияет на момент появления результатов. Сохраните end-based семантику счётчиков, если она выбрана, и проверьте влияние длинных операций. Иначе alert может казаться запоздавшим из-за измерительной границы, а не ошибки арифметики.

## Проверьте низкий трафик

При малом числе запросов один отказ резко меняет долю ошибок. Отсутствие запросов и отсутствие наблюдений — разные состояния. Политика должна определить, когда формируется диагностическое уведомление, когда нужен дополнительный сигнал, а когда автоматическое вычисление не даёт достаточного основания для срочного alert.

Синтетический набор включает тихий период, краткий всплеск, устойчивое ухудшение и восстановление. Каждый ряд имеет ожидаемое время срабатывания и снятия. Эти данные являются test fixtures, а не историей реального сервиса и не доказательством фактической надёжности проекта.

## Тестируйте правило до включения

[Prometheus promtool](https://prometheus.io/docs/prometheus/latest/configuration/unit_testing_rules/) позволяет проверять rules на заданных временных рядах. Сохраните inputs, expected alerts и версию выражений. После изменения denominator или metric names повторите fixtures, а не сравнивайте только внешний вид dashboard. Ошибка labels может отключить alert без явного синтаксического сбоя.

Связанные темы — [мониторинг GPU](/ru/journal/gpu-monitoring-scorecard/) и [планирование ёмкости](/ru/journal/inference-capacity-planning/). Результатом становится объяснимое правило реакции на измеренную деградацию, без обещаний универсального SLA, нулевых ошибок или уже работающей системы оповещения конкретной компании.