Источник
Google SRE Workbook
Практический гайд по определению SLI/SLO и работе с error budgets.
SLI / SLO / SLA - это язык, который соединяет бизнес-ожидания и инженерные решения. В этой главе разберём, как формализовать надёжность и почему error budget напрямую влияет на релизы, приоритизацию и стоимость. Если нужен широкий контекст по SRE, начните с вводной главы раздела.
Что такое SLI, SLO и SLA
SLI
Service Level Indicator
Измеримый сигнал качества сервиса: availability, latency, error rate, freshness.
SLO
Service Level Objective
Целевое значение SLI за период. Пример: 99.9% успешных запросов за 30 дней.
SLA
Service Level Agreement
Внешний контракт с последствиями (компенсации, штрафы, условия поддержки).
Почему это важно
Единый язык для product и engineering
SLO переводит "сервис должен быть стабильным" в конкретные числа и правила принятия решений.
Контроль релизного риска
Error budget даёт формальный критерий: ускоряемся или переключаемся на стабилизацию.
Прозрачная приоритизация
Можно обосновать, почему сейчас важнее reliability work, а не новая фича.
Предсказуемые ожидания клиентов
SLA фиксирует границы ответственности, а SLO помогает держаться внутри этих границ.
Калькулятор 1: доступный downtime по SLO
Error budget = 0.100%
Допустимый downtime
43 мин
В секундах
2 592
Ошибок на 1M запросов
1 000
Формула: budget = (1 - SLO) * период. Например, при SLO 99.9% за 30 дней доступно около 43 минут downtime.
Калькулятор 2: burn-rate и остаток бюджета
Наблюдаемый error rate
0.0240%
Burn rate
0.24x
Сожжено в окне
0.03%
Остаток бюджета
84.97%
При текущем темпе бюджет закончится примерно через 106 д 5 ч 0 мин.
Бюджет тратится медленно: хороший запас под релизы.
Как применять в ежедневной работе
- Выберите 1-3 критичных user-journey и определите для них SLI.
- Согласуйте SLO с продуктом и стоимостью отказов.
- Опишите policy: какие релизы допустимы при burn-rate < 1, 1-2, > 2.
- Свяжите алерты и incident response с бюджетом, а не только с инфраструктурными метриками.
Типичные антипаттерны
Мерить SLI только на уровне инфраструктуры (CPU/RAM), а не пользовательского пути.
Ставить SLO 99.999% без связи с реальной стоимостью, архитектурой и ожиданиями бизнеса.
Использовать SLA как внутреннюю инженерную метрику вместо внешнего контрактного уровня.
Игнорировать burn rate и смотреть только на итог месяца, когда бюджет уже сгорел.
Рекомендации
Определяйте 1-3 ключевых user-journey и стройте SLI именно на них.
Привязывайте релизы к error budget policy: есть бюджет - можно рисковать, нет бюджета - stabilisation mode.
Используйте fast+slow burn-rate алерты, чтобы ловить и резкие, и плавные деградации.
Разделяйте внутренние SLO и внешние SLA, чтобы честно управлять ожиданиями пользователей.