SLO и бюджет ошибок: что ревьюить в инфраструктуре

При SLO 99,9% сервис может потратить примерно 43 минуты недоступности за 30-дневный период и формально остаться в цели. Но это работает только при корректном SLI, едином окне измерения и понятном правиле, что считать ошибкой. На ревью нужно проверять не саму красивую цифру, а цепочку от пользовательского запроса до решения о релизе, откате или заморозке изменений.

Сначала проверьте, чью надёжность измеряет SLO

SLO описывает целевой уровень качества сервиса за определённое время. Например: 99,9% успешных запросов к API за календарный месяц. Такое определение уже содержит четыре решения: что считается запросом, что считается успехом, за какой период идёт расчёт и какие компоненты входят в область измерения.

На ревью попросите показать источник данных. Это может быть балансировщик, API-шлюз, клиентская телеметрия, журнал приложения или система мониторинга. Источник должен соответствовать пользовательскому пути. Если SLO строится только по ответам приложения, но DNS, TLS, балансировщик или база данных регулярно недоступны, метрика создаёт ложное ощущение надёжности.

Формулировка замечания

• «SLI измеряет ответы приложения после прокси, но не учитывает ошибки на уровне прокси. Покажите, почему эти запросы исключены и как пользовательский сбой попадёт в бюджет».
• «В запросах с несколькими операциями не определено, считается ли частичный ответ успешным. Нужен явный критерий результата».
• «В метрике смешаны интерактивные запросы и фоновые задачи. Их задержки и последствия различаются, поэтому общий SLO может скрыть деградацию одной из групп».

Хороший SLO отвечает не на вопрос «насколько быстро работает система», а на вопрос «какой пользовательский сбой мы готовы принять и как долго».

SLI — измеряемый показатель качества, например доля успешных запросов или перцентиль задержки. SLO — целевое значение SLI за заданное окно. SLA — внешнее обязательство перед клиентом, обычно с описанными последствиями нарушения. Эти термины нельзя использовать как взаимозаменяемые.

Ревьюйте не среднее, а форму метрики

Средняя задержка почти бесполезна для SLO: несколько очень медленных запросов могут исчезнуть внутри большого количества быстрых. Для пользовательских API чаще проверяют долю запросов быстрее установленного порога или распределение задержки по перцентилям. При этом сам перцентиль не показывает, сколько запросов было исключено из расчёта, поэтому рядом должна быть численность выборки.

Проверьте следующие детали:

• есть ли минимальный объём трафика для расчёта;
• разделены ли регионы, зоны, версии API и критичные типы операций;
• не исключаются ли ошибки по HTTP-коду, маршруту или клиенту без документированного основания;
• не подменяется ли доля успешных запросов доступностью инфраструктурного компонента;
• видит ли команда свежие данные и умеет ли отличить отсутствие трафика от отсутствия ошибок.

Последний пункт особенно важен для редких операций. Сервис без запросов может выглядеть успешным, хотя проверить его фактически не удалось. Для таких компонентов нужны синтетические проверки или отдельный контроль минимального числа наблюдений.

Проверьте математику бюджета ошибок

Бюджет ошибок — допустимая доля или продолжительность нарушения SLO за выбранное окно. При доступности 99,9% и 30-дневном месяце это около 43 минут. Для 99,99% — около 4 минут 19 секунд. Расчёт зависит от длины окна, а календарный месяц не всегда содержит одинаковое число минут, поэтому система должна явно фиксировать период.

На ревью ищите не только итоговое число, но и формулу:

• какое значение SLO используется — 99,9%, 99,95% или другое;
• какие события уменьшают бюджет — ошибки, тайм-ауты, превышение задержки, потеря данных;
• учитываются ли запланированные работы и аварийные исключения;
• как пересчитывается бюджет при скользящем окне;
• кто отвечает за сверку с первичным источником телеметрии.

Если формула существует только в дашборде, а документация команды говорит другое, это дефект процесса. Разработчик должен понимать, почему после одной аварии бюджет уменьшился именно на такую величину.

Что должно быть видно на дашборде

Ревьюйте скорость расходования, а не только остаток

Остаток бюджета отвечает на вопрос «сколько уже потрачено». Для управления изменениями важнее burn rate — скорость, с которой бюджет расходуется относительно допустимой. Если текущая скорость сохранится, команда может потратить месячный бюджет за часы, даже когда на графике ещё остаётся 80%.

В ревью алертов проверьте несколько временных окон. Короткое окно помогает быстро заметить аварию, длинное — не реагировать на единичный всплеск. Конкретные пороги нельзя переносить между сервисами без проверки: они зависят от SLO, объёма трафика, стоимости ошибки и времени реакции команды.

• Алерт на быстрый расход должен вести к немедленной диагностике и, возможно, остановке релизов.
• Алерт на устойчивое медленное расходование должен создавать задачу на устранение причины, а не только уведомление.
• Каждый алерт должен иметь владельца, уровень срочности и понятное действие после срабатывания.

Формулировка замечания: «Алерт сообщает о нарушении SLO, но не показывает, за сколько времени будет исчерпан бюджет. Добавьте скорость расходования и правило реакции либо объясните, почему для этого сервиса достаточно абсолютного остатка».

Проверьте связь бюджета с релизами

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

В политике релизов должны быть описаны как минимум три состояния:

1. Бюджет в норме. Релизы идут по обычной процедуре, но дефекты надёжности всё равно попадают в бэклог.
2. Бюджет расходуется быстро. Усиливаются проверки, ограничивается размер изменения, назначается владелец расследования.
3. Бюджет исчерпан. Команда прекращает необязательные рискованные изменения и работает над восстановлением надёжности. Исключения должны быть названы заранее: например, исправление уязвимости или предотвращение потери данных.

Ревьюйте не строгость запрета, а его исполнимость. Кто нажимает кнопку остановки? Что происходит с уже запущенным релизом? Как снимается ограничение? Если ответ звучит как «решим по ситуации», процесс не защищает систему от повторения инцидента.

Где подход ломается

Редкий или новый сервис

При малом трафике несколько неудачных запросов резко меняют процент. Нельзя делать далеко идущие выводы без минимального объёма наблюдений. На старте полезнее связать SLO с синтетическими сценариями и отдельно отмечать статистическую неопределённость.

Сложные пользовательские операции

Один пользовательский сценарий может пройти через несколько сервисов. Если каждый компонент имеет собственный SLO, их простое сложение даёт неверную картину: пути могут быть независимыми, резервируемыми или вызываться не на каждом запросе. На ревью нужен верхнеуровневый SLI пользовательского сценария и объяснение, какой вклад в качество вносит каждый компонент.

Потеря данных важнее доступности

Сервис может отвечать с кодом 200 и при этом записывать неверные данные. Доступность не заменяет корректность, свежесть и целостность. Для таких систем нужны отдельные показатели и бюджеты риска; нельзя закрыть проблему увеличением SLO доступности.

Неправильная кардинальность

Разбиение метрик по URL, клиентам и идентификаторам помогает искать источник деградации, но чрезмерная кардинальность увеличивает стоимость хранения и обработки телеметрии. На ревью проверьте, какие измерения нужны для решения инцидента, а какие только раздувают систему наблюдаемости.

Конкретный чек-лист ревью

Перед утверждением SLO пройдите по этой последовательности:

1. Откройте пользовательский сценарий и назовите его ожидаемый результат.
2. Найдите исходное событие, из которого строится SLI, и сравните его с реальным путём запроса.
3. Проверьте исключения: коды ответов, тайм-ауты, отмены клиентом, технические работы и отсутствие трафика.
4. Пересчитайте бюджет вручную для выбранного окна.
5. Сравните дашборд с журналом или трассировкой на одном известном запросе.
6. Попросите показать алерт при быстром расходовании и инструкцию, которая запускается после него.
7. Проверьте, что релизный процесс действительно учитывает состояние бюджета.
8. Назначьте владельца SLO и дату пересмотра после изменения архитектуры или пользовательского сценария.

Что настроить после ревью

Начните с одного критичного пользовательского пути, а не с каталога из десятков целей. Зафиксируйте SLI, формулу бюджета, источник данных, владельца и реакцию на расходование. Затем свяжите график бюджета с релизами и в течение нескольких окон измерения сравнивайте расчёт с реальными инцидентами. После этого пересмотрите порог: SLO должен отражать цену сбоя для пользователя и бизнеса, а не быть круглым числом, выбранным до появления данных.