Скорость сгорания бюджета ошибок — что тут не так?
Привет, %username%! В индустрии прижился термин «скорость сгорания бюджета ошибок» (Error Budget Burn Rate). Однако слово «скорость» здесь часто вводит в заблуждение, заставляя мозг искать привычные физические размерности там, где их нет.
Разберемся, почему Burn Rate — это в первую очередь безразмерный коэффициент, и как это влияет на наше понимание надежности.
Начнем с математики#
Представим сервис со стабильной нагрузкой в 1000 запросов в минуту (req/min).
Мы установили SLO = 99.99%.
- Определяем бюджет ошибок: $\text{Error Budget} = 1 - \text{SLO} = 0.01%$ (или $0.0001$ в долях).
- Считаем бюджет в абсолютных величинах:
- За 30-дневное окно общее количество запросов составит: $30 \text{ дней} \times 24 \text{ часа} \times 60 \text{ минут} \times 1000 \text{ req/min} = 43,200,000 \text{ запросов}$.
- Допустимое количество ошибок: $43,200,000 \times 0.0001 = \mathbf{4320 \text{ ошибок}}$.
Это наш исчерпаемый ресурс на 30 дней.
Как можно тратить этот бюджет?#
Мы можем распределить эти 4320 ошибок равномерно по всему месяцу. Чтобы понять «нормальную» интенсивность ошибок, разделим бюджет на время:
$$\frac{4320 \text{ ошибок}}{43200 \text{ минут}} = 0.1 \text{ ошибки в минуту}$$(Или 1 ошибка каждые 10 минут).
Это — Absolute Rate (абсолютный показатель). У него есть размерность (ошибки/мин). Но это всё еще не Burn Rate.
Два понятия, которые часто путают#
Чтобы не возникало путаницы, важно разделять интенсивность процесса и коэффициент потребления ресурса.
| Характеристика | Absolute Error Rate (Абсолютный показатель) | Burn Rate (Коэффициент сгорания) |
|---|---|---|
| Что измеряет | Фактическую интенсивность ошибок «здесь и сейчас». | Во сколько раз текущее потребление превышает норму. |
| Размерность | Имеет единицы измерения (ошибок/сек, % ошибок). | Безразмерный множитель ($1\times, 14.4\times, 50\times$). |
| Вопрос | «Сколько ошибок произошло за последнюю минуту?» | «Если такая интенсивность сохранится, уложимся ли мы в бюджет?» |
| Интерпретация | Зависит от объема трафика в данный момент. | Универсальна: $>1$ — бюджет тает слишком быстро, $1$ — норма. |
Почему «скорость» — плохое слово?#
В физике скорость ($v = s/t$) всегда привязана к единицам времени (км/ч, м/с). Когда мы называем Burn Rate скоростью, мы подсознательно ищем время в знаменателе.
На самом деле Burn Rate — это моментальный снимок соотношения, а не процесс, растянутый во времени.
- Burn Rate = 1: Мы тратим бюджет ровно с той интенсивностью, которая позволит исчерпать его в последнюю секунду периода (при условии, что такая интенсивность сохранится).
- Burn Rate = 14.4: Мы тратим бюджет в 14.4 раза быстрее плана. При такой нагрузке месячный бюджет сгорит всего за 2 дня ($30 / 14.4 \approx 2.08$).
Главный аргумент: Burn rate — это не про то, «как быстро» что-то движется, а про то, «во сколько раз» мы отклонились от нормы потребления.
Формулы#
Универсальный расчет коэффициента сгорания:
$$\text{Burn Rate} = \frac{\text{Фактическая доля ошибок (за интервал)}}{\text{Допустимая доля ошибок (по SLO)}}$$Пример: Если за последние 5 минут у нас 2% ошибок при SLO 99.9% (допустимо 0.1%):
$$\text{Burn Rate} = \frac{0.02}{0.001} = 20\times$$Важные нюансы#
1. Burn Rate возможен только при наличии бюджета#
Безразмерность — необходимое, но не достаточное условие. Для Burn Rate нужен исчерпаемый ресурс.
- Сравнение $\text{Latency p99} / \text{SLA threshold}$ — это просто относительный коэффициент. Он не показывает сгорание ресурса, так как «время ожидания» само по себе не накапливается и не восстанавливается.
- Однако, если SLO определен как «% запросов быстрее 200 мс», то каждый медленный запрос — это «трата» из бюджета ошибок. В этом случае расчет через доли запросов превращает метрику в настоящий Burn Rate.
2. Скользящее окно и «восстановление» бюджета#
В отличие от денег на счету, бюджет ошибок в SRE обычно считается на скользящем окне (например, последние 30 дней). Это значит, что бюджет не просто сгорает, но и восстанавливается: когда старые инциденты (31-дневной давности) выходят за пределы окна, ваш доступный бюджет снова увеличивается.
3. Проблема малого трафика#
Burn Rate плохо работает на сервисах с низкой нагрузкой. Если у вас 1 запрос в час, то одна случайная ошибка даст Burn Rate в тысячи единиц, что приведет к ложному алерту. Для таких систем используют другие подходы (например, агрегацию за очень большие промежутки времени).
Практический вывод#
Правильная терминология формирует правильное мышление:
- Не используйте «скорость», если хотите подчеркнуть кратность превышения нормы.
- Называйте это коэффициентом сгорания или множителем.
- Помните, что Burn Rate универсален: значение $14.4\times$ одинаково критично и для сервиса с миллионом RPS, и для сервиса с сотней RPS, что делает его идеальной метрикой для настройки умных алертов.
А как этот безразмерный множитель превращается в язык разговора с бизнесом про деньги — в статье «Надёжность строится в диалоге с бизнесом» .
Если у тебя есть вопросы, комментарии и/или замечания – заходи в чат , а так же подписывайся на канал .
О способах отблагодарить автора можно почитать на странице “Донаты ”.