«Сервис должен работать всегда» не цель, а лозунг: стопроцентная надёжность бесконечно дорога и не нужна, потому что пользователь всё равно не отличит 99.99% от 100% на фоне своего мобильного интернета. SRE предлагает договориться о числе и тратить разницу между 100% и этим числом осознанно.
Три термина
- SLI (Service Level Indicator): измеряемый показатель качества с точки зрения пользователя. Обычно доля «хороших» событий:
хорошие / все. - SLO (Service Level Objective): цель для SLI на окне времени. «99.9% запросов к API за 30 дней успешны».
- SLA (Service Level Agreement): договор с клиентом с последствиями (компенсации, штрафы). SLA всегда мягче внутреннего SLO, чтобы команда успела среагировать до денежных потерь.
Как выбрать SLI
SLI описывает опыт пользователя, а не состояние серверов. Типичные:
- Доступность: доля запросов без ошибок сервера (5xx и таймауты). 4xx обычно не считают: это ошибки клиента.
- Задержка: доля запросов быстрее порога, например быстрее 300 мс. Именно доля, а не «p99 < 300 мс»: доля складывается и превращается в бюджет.
- Свежесть (для конвейеров данных): доля данных, обновлённых не позже N минут.
- Корректность, полнота для пакетных задач.
Где мерить: чем ближе к пользователю, тем честнее (балансировщик, синтетика, клиентская телеметрия), но тем больше шума от сети клиента. Часто берут метрики балансировщика или входного шлюза.
# SLI доступности за 30 дней
sum(rate(http_requests_total{job="api",status!~"5.."}[30d]))
/ sum(rate(http_requests_total{job="api"}[30d]))
# SLI задержки: доля запросов быстрее 300 мс
sum(rate(http_request_duration_seconds_bucket{job="api",le="0.3"}[30d]))
/ sum(rate(http_request_duration_seconds_count{job="api"}[30d]))
На практике тяжёлые запросы на 30 дней заменяют recording rules или готовыми генераторами SLO-правил (Sloth, Pyrra).
Сколько это «девяток»
| SLO | Простой за 30 дней | Простой за год (365 дней) |
|---|---|---|
| 99% | 7 ч 12 мин | 3.65 дня |
| 99.5% | 3 ч 36 мин | 1.83 дня |
| 99.9% | 43.2 мин | 8.76 ч |
| 99.95% | 21.6 мин | 4.38 ч |
| 99.99% | 4.32 мин | 52.56 мин |
Каждая девятка в 10 раз уменьшает допустимый простой и обычно заметно увеличивает стоимость: резервирование, дежурства, процессы выкатки.
Бюджет ошибок
Бюджет ошибок = 1 - SLO. При SLO 99.9% и 10 миллионах запросов в месяц можно «потратить» 10 000 неудачных. Бюджет переводит спор «стабильность или фичи» в цифры:
- бюджет есть: выкатываем, экспериментируем, делаем рискованные миграции;
- бюджет кончился: заморозка рискованных изменений, приоритет надёжности, пока бюджет не восстановится.
Это и есть политика бюджета ошибок (error budget policy), её заранее согласуют продукт, разработка и SRE. Без политики SLO остаётся красивым дашбордом.
Окно
- Скользящее (последние 30 дней): честно отражает опыт пользователей, удобно для алертов.
- Календарное (месяц): удобно для отчётов и SLA, но в начале месяца бюджет «обнуляется».
Burn rate
Скорость расходования бюджета: burn rate = текущая доля ошибок / (1 - SLO). Burn rate 1 тратит бюджет ровно к концу окна. На нём строятся алерты (подробнее в модуле про алертинг): быстрое сгорание будит человека, медленное создаёт тикет.
Зависимости
Если запрос последовательно проходит через сервисы с доступностью 99.9% и 99.95%, итоговая доступность не выше 99.9% × 99.95% ≈ 99.85%. Нельзя обещать SLO выше, чем позволяют критичные зависимости, без резервирования, кешей или деградации. Наоборот, две независимые реплики по 99% каждая вместе дают 1 - 0.01 × 0.01 = 99.99%, если отказы действительно независимы.
Как внедрять
- Выбрать 1-3 пользовательских сценария (вход, поиск, оплата).
- Определить SLI и где мерить.
- Посмотреть историю: какая надёжность была за последние месяцы, и поставить SLO чуть ниже реальной, но не ниже того, что устраивает пользователей.
- Согласовать политику бюджета.
- Настроить дашборд и алерты по burn rate.
- Пересматривать SLO раз в квартал.
Частые ошибки
- SLO 100% или «пять девяток» на всё.
- SLI по CPU и памяти вместо опыта пользователя.
- SLO без политики: бюджет кончился, а выкатки идут как обычно.
- SLA равен внутреннему SLO: нет запаса.
- Слишком много SLO: никто за ними не следит.
Что спросят на собесе
- Чем отличаются SLI, SLO и SLA, пример каждого.
- Сколько минут простоя в месяц даёт 99.9%.
- Что такое бюджет ошибок и что делать, когда он кончился.
- Как выбрать SLI для API и для конвейера данных.
- Как зависимости влияют на достижимый SLO.