---
title: Бюджеты ошибок
description: Как рассчитать error budget, измерять его расход и использовать для решений о релизах и работе над надёжностью.
---

## Что такое бюджет ошибок

**Error budget** — допустимое отклонение от [SLO](https://wpcraft.ru/kb/infrastructure/sre/sli-slo-sla.md) за то же окно оценки. Он превращает требование надёжности в конкретный ресурс: пока бюджет не исчерпан, команда может выпускать изменения; при слишком быстром расходе приоритет смещается к стабильности.

```text
Бюджет ошибок = 100% − SLO
```

Для SLO 99,9% бюджет составляет 0,1%. Если сервис получил 1 000 000 учитываемых запросов за четыре недели, допускается не более 1 000 неуспешных запросов при request-based SLI.

Во временной модели при SLO 99,9% за 30 дней бюджет — 43,2 минуты недоступности. Модели нельзя смешивать: долю ошибок запросов нельзя напрямую переводить в минуты простоя.

## Расход и скорость расхода

**Расход бюджета** показывает, какая доля допустимого отклонения уже использована:

```text
Расход, % = фактические ошибки / допустимые ошибки × 100%
```

При бюджете 1 000 ошибок фактические 250 ошибок означают расход 25%.

**Burn rate** показывает, насколько быстро бюджет расходуется относительно равномерного темпа:

- `1` — темп соответствует полному расходу к концу окна;
- больше `1` — SLO будет нарушен при сохранении темпа;
- `0` — ошибок в выбранном интервале нет.

Для реакции важны и величина burn rate, и длительность. Короткий всплеск и устойчивая деградация требуют разных проверок, поэтому [alerting](https://wpcraft.ru/kb/infrastructure/observability/alerting.md) обычно использует несколько окон наблюдения.

## Политика использования

Бюджет полезен только при заранее согласованных действиях. Пример упрощённой политики:

| Состояние | Решение |
|---|---|
| SLO выполняется, расход умеренный | Обычный процесс релизов |
| Бюджет быстро расходуется | Расследование, дополнительная проверка изменений, приоритет работам над устойчивостью |
| Бюджет за окно исчерпан | Приостановка необязательных изменений до восстановления SLO |
| Критическая уязвимость или восстановление | Исключение из ограничений на релизы |

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

## Внедрение за пять шагов

1. Зафиксировать SLI, SLO, окно и источник данных.
2. Настроить расчёт фактического и допустимого числа ошибок в одной модели.
3. Показать текущий остаток и burn rate на дашборде.
4. Согласовать владельца решений и действия для каждого состояния.
5. Связать крупный расход с [postmortem](https://wpcraft.ru/kb/infrastructure/incidents/postmortems.md) и конкретными follow-up.

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

## Типовые ошибки

- Расчёт SLO за месяц, а бюджета — за несопоставимый период.
- Смешение request-based и time-based моделей.
- Автоматическая остановка всех релизов без владельца и исключений.
- Игнорирование пропавших данных и неправильно классифицированных ошибок.
- Бюджет на графике без изменения реальных приоритетов.

## Связанные инструменты

- [Prometheus](https://wpcraft.ru/kb/infrastructure/tools/prometheus.md) — recording rules и оповещения по скорости расхода.
- [Grafana](https://wpcraft.ru/kb/infrastructure/tools/grafana.md) — панели SLO, остатка и burn rate.
- [Better Stack](https://wpcraft.ru/kb/infrastructure/tools/better-stack.md) — связь целей, телеметрии и инцидентов.

## Связанные материалы

- [SLI, SLO и SLA](https://wpcraft.ru/kb/infrastructure/sre/sli-slo-sla.md) — исходная цель для расчёта.
- [Alerting](https://wpcraft.ru/kb/infrastructure/observability/alerting.md) — оповещения по burn rate.
- [CI/CD](https://wpcraft.ru/kb/infrastructure/devops/ci-cd.md) — выпуск и приостановка изменений.
- [Метрики DevOps и инфраструктуры](https://wpcraft.ru/kb/processes/kpi/devops-infra.md) — пример расчёта расхода бюджета.

## Материалы и источники

- [Google SRE Workbook: Error Budget Policy](https://sre.google/workbook/error-budget-policy/) — пример политики, расчёт и действия при нарушении SLO.
- [Google SRE: Embracing Risk](https://sre.google/sre-book/embracing-risk/) — бюджет как баланс надёжности и скорости изменений.
- [Google SRE Workbook: Alerting on SLOs](https://sre.google/workbook/alerting-on-slos/) — скорость расхода и окна оповещения.