SLO и бюджеты ошибок

SLO (Service Level Objective) превращает «сервис должен быть надёжным» в число, за которое можно отвечать: 99% запросов успешны за последние 30 дней. Gotcha непрерывно считает это число по уже собираемой телеметрии, показывает, сколько бюджета ошибок осталось, и поднимает алерт, как только бюджет начинает сгорать достаточно быстро, чтобы кончиться.

Страница рассчитана на обе аудитории: менеджеров, которым нужно одно честное число здоровья на сервис, и SRE, которым важно точно знать, когда будить дежурного.

Три понятия

• SLI — индикатор уровня сервиса. Измеряемая доля хороших исходов ко всем: успешные запросы ко всем запросам, быстрые запросы ко всем, успешные проверки ко всем проверкам. Всегда дробь от 0 до 1.
• SLO — цель. Планка, выше которой должен держаться SLI, например 0.99. Вы также выбираете окно, на котором она измеряется (1–90 дней, скользящее окно).
• Бюджет ошибок. Слабина, которую допускает цель: 1 − target. SLO 99% на 30 дней разрешает 1% плохих исходов — этот 1% и есть бюджет. Тратьте его медленно — вы ничего не заметите; истратите за вечер — что-то горит.

Достижение (attainment) — это SLI за всё окно (например, 99,4%). Остаток бюджета — сколько от того 1% ещё есть (100% — не тронут, 0% — истрачен ровно, ниже 0% — перерасход). И то, и другое показано на экране деталей каждого SLO.

Три типа SLI

Тип SLI выбирается при создании SLO. Каждый по-своему отвечает на вопрос «что считать хорошим исходом» и читает свой сигнал.

• Availability и latency — request-based (по запросам): читают те же данные транзакций, что и экран Производительность. Пустой фильтр транзакции — любая транзакция; пустое окружение — любое окружение.
• Uptime — probe-based (по проверкам): читает историю успех/провал одного uptime-монитора. Годится, когда «здоров» правильно определять активной проверкой («эндпоинт отвечает?»).

Скорость сжигания и двухоконный алерт

Скорость сжигания (burn rate) — как быстро бюджет тратится прямо сейчас относительно равномерной траты по всему окну. Burn rate 1 означает, что бюджет кончится ровно в конце окна; burn rate 14,4 — что 30-дневный бюджет истратится примерно за два дня.

Один порог быстрого сжигания — дилемма: проверять его на коротком окне — короткий всплеск разбудит дежурного; на длинном — о реальном сбое узнаешь через часы. Gotcha решает это стандартно — двухоконной проверкой:

• Инцидент открывается, только когда и длинное окно (по умолчанию 60 мин), и короткое (по умолчанию 5 мин) горят на уровне порога (по умолчанию 14,4) или выше. Длинное окно подтверждает, что сжигание устойчиво; короткое — что оно всё ещё идёт. Требование обоих отсекает мгновенные всплески.
• Инцидент закрывается, когда короткое окно остывает ниже порога — острое сжигание закончилось.

При открытии и закрытии инцидента Gotcha уведомляет по тем же каналам алертов, что и остальные оповещения. Список SLO показывает у каждой цели текущее достижение и остаток бюджета; экран деталей добавляет график сжигания бюджета и историю инцидентов.

Скорость сжигания рассчитана на стабильный трафик

Скорость сжигания откалибрована для сервиса под стабильной, непрерывной нагрузкой — когда вопрос «как быстро я трачу бюджет прямо сейчас» вообще имеет смысл. На разреженном или прерывистом трафике сигнал слабеет: в коротком окне может оказаться всего несколько запросов (или ни одного), поэтому единичный сбой резко качает скорость, а когда поток затихает, последняя непустая корзина продолжает изображать «сейчас», пока не придёт свежий трафик. В итоге показатель скорости сжигания может отставать от реальности — он самокорректируется в пределах burn-окна (около часа для длинного окна по умолчанию), как только трафик возобновится, но до этого способен занижать или завышать, насколько быстро вы на самом деле тратите бюджет.

Для сервиса, который законно получает лишь редкие запросы, предпочтите uptime-SLO на мониторе, который проверяет его по фиксированному расписанию: ровный поток проверок даёт формуле скорости сжигания тот непрерывный сигнал, который ей нужен, независимо от того, как редко к сервису обращаются реальные пользователи.

Что бюджет не жжёт

Окна обслуживания исключаются. Любой период, покрытый окном обслуживания проекта, изымается из расчёта каждого SLO — и availability, и latency, и uptime. Плановые работы бюджета не стоят.

Полный отказ request-based SLI — слепая зона, прочитайте это. Availability и latency — доли запросов. Если отказ настолько тяжёлый, что трафик падает до нуля — до сервиса вообще ничего не доходит, — оценивать нечего: «нет запросов» неотличимо от «нет плохих запросов». Бюджет просто перестаёт двигаться, а не сгорает. Это свойство самих request-based SLI, а не ограничение Gotcha.

Для сервиса, где полный отказ с обнулением трафика — как раз тот сбой, который важнее всего, заведите рядом uptime-SLO на мониторе, который активно проверяет сервис. Монитор продолжает проверять, отвечает ли эндпоинт, поэтому полный отказ даёт провальные проверки и жжёт бюджет аптайма даже тогда, когда поток запросов умолк.

Окно и срок хранения

Окно SLO задаётся до 90 дней, но видит назад лишь настолько, насколько реально хранятся данные. Каждая оценка клипует окно по сроку хранения телеметрии (GOTCHA_RETENTION_DAYS для request-based SLI, срок хранения результатов проверок — для uptime): 90-дневное окно на инстансе с 30 днями данных оценивается за 30 дней. Держите окно SLO не длиннее срока хранения, если хотите, чтобы всё окно учитывалось.

Частота оценки

Оценщик пересчитывает каждый включённый SLO с фиксированным интервалом — GOTCHA_SLO_EVAL_INTERVAL, по умолчанию 120 секунд. Уменьшение делает burn-алерты быстрее ценой более частых запросов; увеличение — наоборот.