задать измеримые цели надёжности через error budget
SLO, SLI и error budget для платформенных команд: минимальный контракт на надёжность
11 минут
Дашборды и количество алертов не определяют надёжность. В статье — как небольшой platform-команде выбрать один–два пользовательских SLI, задать SLO на 30 дней с error budget, настроить burn-rate алерты и связать политику бюджета с решениями о релизах.
Почему больше алертов не означает лучшую надёжность
Команды, которые наращивают мониторинг, часто получают сотни порогов и всё равно пропускают сбои, видимые пользователям. Проблема структурная: инфраструктурные метрики описывают компоненты, а надёжность — это успех критичных пользовательских сценариев в согласованных границах. Service Level Indicator (SLI) количественно описывает поведение на уровне сценария. Service Level Objective (SLO) задаёт цель на скользящем окне. Error budget — допустимый объём «плохих» событий до нарушения цели. Так надёжность превращается из размытой цели в измеримый контракт между platform- и product-инженерией.
Выберите один–два SLI, привязанных к пользовательским сценариям
Не определяйте SLI для каждого микросервиса. Возьмите минимальный набор, отражающий доверие клиентов: availability (успешные запросы к валидным), latency (доля запросов быстрее порога) или freshness (возраст последнего успешного прогона для асинхронных процессов). Свяжите каждый SLI с одним критичным путём — checkout, login или синхронизация API — и измеряйте на периметре (ingress, gateway или synthetic probe), чтобы повторы балансировщика не скрывали боль пользователя. Если уже есть дашборды пользовательского воздействия из observability baseline, используйте те же ряды как источник SLI, а не дублируйте метрики.
Задайте SLO и error budget на окне 30 дней
Типичная стартовая цель для API — 99,9% availability за 30 скользящих дней. Звучит строго, но error budget — около 43 минут «плохих» событий в месяц: хватает на мелкие всплески, но заставляет реагировать, когда инциденты накапливаются. Зафиксируйте цель простым языком: владелец, какие окружения учитываются, исключаются ли окна обслуживания. Храните определение в Git (OpenSLO или внутренняя YAML-схема), чтобы изменения проходили review как код приложения. Манифест ниже задаёт один SLI availability и цель для HTTP API.
apiVersion: openslo/v1
kind: SLO
metadata:
name: api-availability
spec:
service: public-api
budgetingMethod: Occurrences
objectives:
- target: 0.999
displayName: 99.9% availability (30d)
indicator:
metadata:
name: api-availability-sli
spec:
ratioMetric:
good:
metricSource:
type: Prometheus
metricType: counter
query: sum(rate(http_requests_total{status!~"5.."}[5m]))
total:
metricSource:
type: Prometheus
metricType: counter
query: sum(rate(http_requests_total[5m]))Настройте burn-rate алерты вместо статических порогов
Статические алерты по error rate вспыхивают при деплоях и молчат при медленном «сжигании» всего месячного бюджета за неделю. Multi-window burn-rate сравнивает краткое и длинное окно с бюджетом — по мотивам практики Google SRE. Эскалируйте page при быстром burn (например 14,4× бюджета за час) и ticket при медленном (например 6× за шесть часов). Привяжите алерты к runbook с владельцем и первым шагом mitigation. Правила Prometheus ниже — recording rule для SLI availability и пример fast-burn алерта; подстройте окна и коэффициенты под свою цель SLO.
groups:
- name: slo-recording
rules:
- record: sli:http_availability:ratio
expr: |
sum(rate(http_requests_total{job="api",status!~"5.."}[5m]))
/
sum(rate(http_requests_total{job="api"}[5m]))
- alert: SLOAvailabilityBudgetBurnFast
expr: |
(1 - sli:http_availability:ratio) > (14.4 * 0.001)
for: 2m
labels:
severity: page
annotations:
summary: Fast burn of API availability error budgetСвяжите SLO с темпом релизов и приоритетами
Пока error budget в избытке, можно поставлять фичи и принимать обычный операционный риск. Когда бюджет на исходе, замедлите feature work и инвестируйте в надёжность: обновления зависимостей, настройка retry, вынос кэша, хаос-эксперименты для проверки мер. Это не тотальный deploy freeze, а сигнал приоритизации, понятный product-менеджерам. Сопоставьте его с метриками delivery из release-пайплайна: при высоком lead time рискованный пятничный деплой хуже, чем перенос некритичного изменения. Если бюджет здоров, а change failure rate растёт, проблема скорее в качестве пайплайна, а не в слишком мягком SLO.
Опишите лёгкую политику error budget
Одностраничная политика лучше тяжёлого процесса. Три зоны: green (осталось больше 50% бюджета — обычная поставка), yellow (25–50% — review рискованных изменений), red (меньше 25% или бюджет исчерпан — стоп некритичных релизов, разбор инцидентов, hardening). Укажите, кто может дать exception и на сколько; каждое исключение — в тикете, чтобы видеть связь с повторными инцидентами. Раз в квартал пересматривайте цели: SLO, который никто не нарушает, слишком мягкий; SLO, который нарушают каждую неделю, перестают воспринимать всерьёз.
Закрывайте цикл после инцидентов без тяжёлых postmortem
После каждого события с влиянием на пользователей задайте три вопроса: сколько минут error budget потратили, был ли burn-алерт вовремя, соответствуют ли запросы SLI реальности? Обновляйте recording rules, дашборды и runbook в том же спринте, а не в месячном отчёте. Если повторные burn указывают на одну зависимость, вынесите хаос-эксперимент или нагрузочный тест в регулярный пайплайн, чтобы проверить исправление при отказе. Со временем SLO становится общим языком переговоров о скорости и стабильности, а не спором о том, достаточно ли шумный мониторинг.
SLO работают только если телеметрия отражает влияние на пользователя — опирайтесь на сигналы и практики алертинга из гайда по observability для небольших платформенных команд.
Когда error budget исчерпан, политика релизов не менее важна, чем мониторинг — дополните подход диагностикой узких мест release-пайплайна.