Привет, %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, что делает его идеальной метрикой для настройки умных алертов.
Если у тебя есть вопросы, комментарии и/или замечания – заходи в чат, а так же подписывайся на канал.
О способах отблагодарить автора можно почитать на странице “Донаты”.