Minor-баг увеличил долю ошибок на 0.05%. Первый инстинкт дежурного — откатить всё немедленно. Но откат под давлением сам по себе вносит риск: новый деплой, новая поверхность для отказа, решение в режиме паники. Опытный SRE сделал другое — посмотрел на остаток error budget. Бюджета на месяц оставалось 98%. Значит, времени на спокойный fix-forward достаточно, и срочный rollback только добавил бы нестабильности. Это не провал — это запланированное несовершенство, ровно то, на что бюджет и рассчитан.
Вся ценность подхода SLO держится на одной идее: прежде чем реагировать на отклонение — посмотри на бюджет. Высокий остаток означает время на вдумчивое исправление. Низкий — митигация сейчас, постмортем потом. Цифра вместо спора.
Бюджет на риск, а не на совершенство
SLI — это измеримая метрика того, что чувствует пользователь: доля успешных запросов, доля запросов быстрее 200 мс. SLO — целевое значение этой метрики на окне (например, 99.9% за 30 дней). А error budget = 1 − SLO — это допустимая «доля плохого». Для 99.9% за месяц бюджет составляет около 43 минут недоступности.
Ключевой сдвиг в мышлении: 43 минуты — это не то, чего нужно стыдиться, а ресурс, который можно тратить. На рискованные релизы, на эксперименты, на миграции. Полное выгорание бюджета — сигнал, а не катастрофа.
Отсюда же следует, что гнаться за «пятью девятками» (99.999%) почти всегда вредно. Стоимость надёжности растёт экспоненциально, а выше 99.9% вы упираетесь в SLO собственных зависимостей — облачного балансировщика, DNS, внешних API. Реалистичные ориентиры приземлённее: внутренний админ-инструмент живёт на 99%, публичный веб — на 99.9%, критичный API — на 99.95%, платежи — на 99.99%. Цель «99.999% и быстрее» не вдохновляет команду, а деморализует её.
Error Budget Policy — рычаг, а не украшение
Сам по себе бюджет — просто число. Силу ему даёт политика: заранее согласованные действия в зависимости от остатка.
- Остаток выше 50% — катим фичи свободно.
- 20–50% — перед продом обязательная выдержка в staging (например, сутки).
- Ниже 20% — заморозка некритичных изменений, фокус на надёжности.
- Бюджет исчерпан — полная заморозка, спринт целиком уходит на reliability.
Главное в этой таблице — она снимает вечный спор «надо ли сейчас фризить». Решение привязано к цифре, а не к громкости голоса в чате. Бизнес получает инструмент управлять трейд-офом «скорость против стабильности», не разбираясь в PromQL.
Но политика без зубов бесполезна. Если бюджет выгорел, а команда продолжает катить фичи, потому что «дедлайн» — бюджет декоративный, и вся конструкция теряет смысл. Policy работает ровно настолько, насколько организация готова ей следовать.
Multi-burn-rate: как бюджет превращается в алерт
Типичная ошибка — повесить алерт «SLO упал ниже 99.9%». Такой порог звонит при потере меньше процента и будит дежурного зря. Гораздо точнее — мерить скорость выгорания бюджета (burn rate) сразу в нескольких окнах.
Логика проста. Если за час мы сожгли 2% месячного бюджета — это критично, оправдан вызов дежурного среди ночи (быстрое выгорание, burn_rate_1h > 14.4 × 0.001, подтверждённое коротким окном 5 минут). Если за 6 часов ушло 5% — серьёзно, но достаточно тикета в рабочее время (медленное выгорание, burn_rate_6h > 6 × 0.001 с подтверждением за 30 минут). Двойное окно — длинное плюс короткое подтверждающее — отсекает ложные срабатывания от случайного всплеска.
Множители 14.4 и 6 — это не магия, а стандартные таблицы из SRE Workbook для SLO 99.9%. Генераторы вроде Sloth выпускают такие правила из короткой YAML-спеки, добавляя recording rules для окон 5m/30m/1h/6h, чтобы Grafana и алерты читали готовые метрики, а не считали тяжёлый PromQL на каждый рендер.
Тот же burn rate работает и как ворота для деплоя: правило «при 10× burn rate останавливаем выкатки» прозрачно для CI/CD. Арифметика убедительна — 10× для 99.9% сжигает месячный бюджет за трое суток; если выкатить регрессию в этот момент, полное выгорание наступит за часы. Это смыкается с политикой: исчерпанный бюджет — полная заморозка, высокий burn rate — упреждающая.
В сумме SLO, error budget и multi-burn-rate — это не три отдельные практики, а одна цепочка: метрика измеряет боль пользователя, бюджет переводит её в ресурс, политика и алерты превращают ресурс в решения. Бюджет становится общим языком, на котором бизнес и инженеры договариваются без паники и без споров.