Error budget мониторинг: где ломается обратная связь
Ошибки в сервисе есть всегда — вопрос в том, сколько их допустимо. Если предел не измеряется, надёжность сервиса обсуждают на ощущениях: один инженер считает нормой сбой на каждую десятую сотню запросов, другой — единичные падения. Спор о качестве релиза превращается в спор о вкусах.
Лимит ошибок сервиса закрывает именно эту дыру. Он задаёт долю запросов, которую за период допустимо потерять или испортить, и превращает её в остаток: пока бюджет не израсходован, релизы идут с высокой скоростью; когда остаток на нуле, изменения останавливают и разбираются с причинами отказов. Решение перестаёт зависеть от переговорного веса участников.
Ломается это на разрозненных метриках. Частота ошибок живёт в одном дашборде, задержки — во втором, недоступность — в третьем, и общий счёт никто не ведёт. Error budget мониторинг подразумевает свод этих источников в одну величину — иначе бюджет выглядит здоровым, а пользователи уходят с медленных страниц, где формально отказов не было.
Второй сбой — пороговые тревоги, выставленные по старой интуиции. Порог, который срабатывает на каждое колебание, обесценивает дежурство: инженер привыкает закрывать уведомление не глядя, и настоящий инцидент теряется в шуме. Тревога должна опираться на скорость выгорания бюджета, а не на статичное число.
Разбираем, как выстроить такую обратную связь на Prometheus и Grafana: от согласования целевого уровня до правил, которые сами останавливают релиз.
Что даёт управляемый лимит ошибок на сервисе
Лимит ошибок выводится из целевого уровня доступности: сервису разрешено потратить определённую долю неудачных запросов за окно наблюдения, и этот остаток становится общим счётчиком для разработки и эксплуатации. Пока запас положительный, релизы идут обычным ритмом; когда он тает, изменения начинают конкурировать за право на выкат.
Тревоги привязываются не к единичным всплескам, а к скорости исчерпания остатка, поэтому короткий сбой не поднимает дежурного, а устойчивая деградация сигналит до того, как сервис уйдёт ниже целевого уровня. Доля ложных тревог падает, а время реакции на отказ перестаёт быть ощущением и становится величиной: видно, сколько проходит от первого отклонения до вмешательства и на каком шаге теряется больше всего.
Очередь релизов тоже подчиняется правилу: при исчерпанном лимите сначала восстанавливают надёжность и только потом катят функциональность. Так уходит класс отказов, который раньше возникал от накопления мелких незамеченных деградаций — каждая по отдельности ниже порога, а вместе они выводят сервис за целевой уровень.
Результат считается в долях: снижение доли неудачных запросов, сокращение ручных разборов, меньше тревог, которые закрывают без действий. Расчёт остатка и скорости его выгорания живёт в Prometheus и выводится на общую доску — инженеры видят запас в часах и обсуждают решения, а не то, «плохо ли сейчас».
Режимы расчёта: окно, скорость и строгость
Режим расчёта определяет, насколько быстро система замечает деградацию и как трактуется остаток бюджета. В Prometheus бюджет считается правилом записи поверх счётчиков успешных и ошибочных ответов, а панель в Grafana лишь отображает уже посчитанное значение — поэтому строгость сигнала задаётся здесь, а не в дашборде.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Скользящее окно | Непрерывный поток запросов, нужно ловить деградацию за минуты | Короткий всплеск сжигает бюджет; результат зависит от глубины хранения метрик |
| Календарный период | Отчётность и планирование: месяц или квартал с обнулением | В начале периода бюджет всегда полный, ошибки первых часов забываются |
| Бюджет по запросам | Сервисы, где важна доля успешных ответов | Не видит медленные ответы, если они формально завершились успешно |
| Бюджет по времени | Пользовательские сессии, доступность по минутным интервалам | Требует аккуратной агрегации интервалов, чувствителен к коротким обрывам |
| Сводный лимит на несколько сервисов | Общий бюджет платформы и приоритизация между командами | Один сервис способен выесть бюджет соседей — нужны правила расщепления и квоты |
На практике режимы комбинируют: скользящее окно даёт оперативный сигнал дежурному, календарный период — основу для разбора итогов, а сводный лимит удерживает общий расход. Расхождение между бюджетом по запросам и по времени — хороший индикатор: доля ошибок в норме, а пользователи жалуются на недоступность, значит проблема в таймаутах и ретраях, а не в кодах ответа.
Внедрение: от аудита метрик до регламента мониторинга
Работа идёт в шесть этапов и начинается не с графиков, а с инвентаризации того, что уже собирается. Порядок принципиален: бюджет ошибок считается из тех же данных, по которым срабатывают оповещения, иначе дежурный видит расхождение между панелью и сигналом и перестаёт доверять обеим цифрам.
- Аудит метрик. Разбираем источники: какие показатели уже есть, где пробелы, какие дублируют друг друга, где кардинальность растёт быстрее, чем польза. На выходе — список рабочих SLI по каждому сервису и перечень того, что придётся добавить.
- Схема расчёта. Фиксируем окно (скользящие 30 дней), целевой уровень доступности, определение «плохого» события и правила агрегации по сервисам. Агрегаты считаются заранее, а не на каждый запрос панели, — иначе дашборд с десятком сервисов начинает тормозить и врёт по времени.
- Правила и пороги. Настраиваем многоуровневые оповещения: предупреждение при выгорании четверти бюджета, тревога — при половине, остановка релизов — при исчерпании. Порог на скорость выгорания ловит быстрый провал раньше, чем его покажет суточный график.
- Проверка на исторических данных. Прогоняем схему на прошедших инцидентах: поймали бы сигналы, сколько было ложных, совпали ли пороги с реальной деградацией. Пороги калибруем по факту, а не по интуиции.
- Регламент дежурства. Описываем действия при каждом уровне: кого будить, что смотреть в первую очередь, когда замораживать выкатку. Регламент согласуем с теми, кто ходит в дежурство, — документ, написанный без них, не работает.
- Передача и обучение. Разбираем с командой живые сценарии, договариваемся о разборе каждого срабатывания. После этого схема живёт сама: правила и пороги пересматриваются по итогам квартала.
Что остаётся в репозитории после сдачи работ
После сдачи работ у вас остаётся работающий контур контроля надёжности, а не набор разрозненных настроек. Все артефакты лежат в вашем репозитории и вашем контуре: команда может открыть любой из них, увидеть, откуда берётся каждая цифра, и изменить поведение системы без нас.
- Конфигурации правил — исходники записи метрик и вычисляемых выражений для бюджета ошибок, разложенные по сервисам и окружениям, с версионированием и осмысленными именами.
- Схема расчёта — документ, где зафиксировано, какие события считаются сбоем, как они нормируются на общий объём запросов и на каком окне усредняются. При разборе инцидента логику не приходится угадывать.
- Политики оповещений — пороги, группировка и маршруты: что уходит дежурному сразу, что ждёт подтверждения, что попадает только в отчёт.
- Инструкция дежурному — пошаговый разбор: как читать график выгорания бюджета, какие решения принимать при разной скорости расхода, куда эскалировать и что фиксировать после.
- Регламент пересмотра уровней — периодичность и критерии: когда цель по надёжности ужесточают, когда ослабляют, кто принимает решение и как оно фиксируется в истории.
- Шаблоны дашбордов — панели под отдельный сервис и сводка по всем, с одинаковой логикой расчёта, чтобы новая команда не рисовала свой вариант с нуля.
- Проверки правил — набор тестов, которые ловят битые выражения и пустые выборки до выката, а не в момент инцидента.
Кейс: сервис платежей, тревоги и время реакции
Платёжный сервис с непрерывным потоком транзакций: несколько дежурных в смене, все тревоги валятся в один общий канал, error budget никто не считал. Правила тревог настраивались по порогам «на глаз» и не пересматривались — сигналов становилось больше, а доверия к ним меньше.
Что было
Больше половины срабатываний закрывались как ложные: короткий всплеск задержки, единичные ошибки на одном экземпляре, шум от фоновых задач. Дежурная смена уходила в ручные разборы — 5-6 за смену, из них полезных единицы. Время обнаружения измерялось десятками минут: настоящий отказ тонул в потоке ложных, а часть отказов всплывала уже по обращению клиентов.
Что изменили
Привязали тревоги к бюджету ошибок: для платёжного API зафиксировали цели по доступности и времени ответа, и сигнал теперь считается по скорости расхода бюджета в окне, а не по одиночному всплеску. Развели уведомления на два класса — те, что будят дежурного, и те, что разбираются в рабочее время. Сбор метрик и правила тревог перенесли в Prometheus и Grafana, каждый ночной сигнал разбирается на дежурной смене.
| Показатель | До | После |
|---|---|---|
| Доля ложных тревог | ~70% | ~15% |
| Время обнаружения | десятки минут | 2-4 минуты |
| Пропущенные отказы | находили по жалобам | единицы за квартал |
| Ручные разборы за дежурство | 5-6 | 1-2 |
Отдельный эффект — предсказуемость смены: дежурный знает, что ночной сигнал означает реальный расход бюджета, а не шум. Отказы стали находить до обращений клиентов, а разбор срабатывания превратился в короткую процедуру вместо расследования.
Чем SLO отличается от SLA и что настраивать первым?
Разница проста, но путают её чаще всего остального. SLA — обязательство перед заказчиком: зафиксировано в договоре, имеет измеримую формулировку и прописанные последствия нарушения. SLO — внутренний целевой уровень, по которому команда принимает решения о релизах и приоритетах.
Порядок настройки один: сначала внутренние цели, затем договорные. SLO задают строже SLA, чтобы между ними остался запас — отклонения гасятся внутри команды и не превращаются в нарушение обязательств. Обратный порядок даёт обещание без данных: непонятно, какой запас реально есть и выдержит ли его инфраструктура.
Error budget — количественное выражение SLO: сколько недоступности или доли неуспешных запросов допустимо потратить за окно. Пока бюджет цел, релизы идут обычным темпом; бюджет подошёл к границе — приоритет смещается на надёжность. В Prometheus это правила подсчёта успешных запросов и остатка бюджета, в Grafana — панель расхода и алерты на скорость выгорания, а не на одиночный сбой.
Последствия нарушения тоже разные, и смешивать их нельзя. Нарушение SLO — событие внутреннее: остановка релизов, возврат усилий в надёжность, пересмотр нереалистичной цели. Нарушение SLA — внешнее: обязательства и всё, что за ними закреплено. Поэтому сначала измеряют себя, а уже потом обещают.
Частые технические сомнения перед внедрением
Сомнения перед внедрением бюджета ошибок касаются обычно не инструмента, а того, насколько честно данные отражают реальность сервиса. Ниже — ситуации, которые встречаются чаще всего, и то, как мы закрываем их при настройке контроля в Prometheus и Grafana.
Часть метрик приходит с перебоями — расчёт будет занижен?
Бюджет считаем по тем окнам, где данные есть, а пропуски помечаем отдельным признаком и не сворачиваем в «ноль ошибок». Если интервал выпал целиком, он исключается из знаменателя — иначе доступность в отчёте выглядит лучше, чем её видели пользователи.
Показатель шумит: всплески не связаны с реальными сбоями?
Шум давим не порогом «на глаз», а на уровне определения показателя: убираем служебные проверки, технические ответы и внутренние запросы между сервисами, а агрегируем на окне, которое переживает одиночный всплеск. Тогда расход бюджета отражает потери пользователей, а не фоновую активность.
Сервисом пользуются несколько команд — чей это бюджет?
Бюджет привязываем к владельцу сервиса, но расход размечаем по потребителям: каждая команда видит свою долю сгорания. Спор «кто просадил доступность» решается по данным, а не на общей встрече.
Пороги задали формально — контроль превратится в отчётность?
Уровни берём от фактического поведения сервиса за прошедший период, а не от желаемого. Пересматриваем их по расписанию — после крупных изменений в архитектуре или когда бюджет стабильно не расходуется вовсе.
Обсудим вашу задачу и вернёмся с планом работ
Чтобы оценка была предметной, а не «на глаз», нам нужен короткий разбор вашей инфраструктуры: как собираются метрики, где хранятся, кто и как реагирует на срабатывания. Опишите задачу в свободной форме — вернёмся с оценкой объёма и планом работ, разбитым по этапам.
Что уточняем на созвоне:
- источники метрик и текущая схема сбора — Prometheus, экспортёры, агенты на узлах;
- перечень сервисов и их владельцы: для кого считаем error budget и по каким SLI;
- окна и политика расчёта: скользящее окно, пороги выгорания, что считаем недоступностью;
- текущие алерты и дежурства — какие срабатывания шумят, какие пропускаются;
- доступы и ограничения: контуры, закрытые сети, права на изменение правил и дашбордов;
- требования к отчётности — сводки для руководства, периодичность, глубина истории;
- формат передачи: репозиторий с конфигурацией, runbook, обучение дежурной смены.
По итогам фиксируем состав команды под задачу — кто отвечает за правила записи, кто за дашборды и алерты, кто за передачу знаний. План согласуем до старта, чтобы вы видели промежуточные результаты на каждом этапе, а не только финальный отчёт.
Расскажите, что сейчас болит: шумные алерты, отсутствие бюджета на надёжность или разрозненные дашборды. Этого достаточно, чтобы мы вернулись с планом и оценкой.
