Прямой ответ
SRE-практика сводится к трём связанным понятиям: SLI — измеримый индикатор качества сервиса с точки зрения пользователя (доля успешных запросов, латентность p95 — не «CPU сервера», а «что видит пользователь»); SLO — целевое значение SLI за период («99.5% запросов успешны за 30 дней» — не 100%, потому что 100% недостижимо и контрпродуктивно); error budget — разрешённая доля неудач (0.5% за месяц — бюджет, который команда тратит на релизы, эксперименты и инциденты). Главная организационная идея: бюджет ошибок — объективный регулятор скорости: бюджет есть — выкатываем быстро (неудачи в пределах допустимого — цена скорости, осознанная), бюджет исчерпан — стоп фич и работа над надёжностью (не по мнению самого громкого, а по арифметике). Это снимает вечный конфликт «фичи против стабильности» — он решается числом, а не должностью. Практический минимум для команды без SRE-отдела: два SLI (доступность и латентность), SLO по ним от реальных ожиданий пользователей (не «99.99 потому что красиво» — каждая девятка стоит экспоненциально дороже), алерты на быстрое сгорание бюджета (не на каждый чих — алерт-дисциплина), и ежемесячный взгляд на остаток бюджета при планировании.
SLI и SLO: как выбрать правильно
Выбор SLI — моделирование опыта пользователя: для API — доля запросов с кодом <500 (или успешных бизнес-исходов — точнее: 200 с пустым результатом из-за бага — «успех» по HTTP, провал по сути) и доля запросов быстрее порога (p95 < 500 мс — «доля быстрых», не «средняя латентность» — среднее прячет хвосты); для интерфейса — загрузка страниц, доля успешных пользовательских сценариев; для фоновых пайплайнов — свежесть данных («данные не старше 15 минут в 99% окон»). Окно измерения — скользящие 30 дней (стандарт; месяц — понятный бизнес-цикл). Выбор значения SLO — от обратного: что заметят пользователи и что обещает бизнес (100% недостижимо — инфраструктура под вами имеет свои SLO; 99.9% = 43 минуты простоя в месяц — реально с одним сервером и деплоями? нет — берите 99.5% и не врите себе); типовые стартовые значения — 99.5–99.9% доступность, 95–99% запросов в пороге латентности. Важные тонкости: SLI измеряется на границе с пользователем (за балансировщиком, не внутри — метрики приложения), плановые работы либо входят в бюджет, либо исключаются по явному правилу (исключения — скользящая дорожка к «SLO выполняется, если не считать плохие дни»), и SLO — публичная внутри команды цифра на дашборде (Grafana: запись-выражение + текущий остаток бюджета), а не документ в вики.
Error budget: механика регулирования скорости
Арифметика: SLO 99.5% за 30 дней → бюджет 0.5% ≈ 3.6 часа полной недоступности (или эквивалент частичных отказов: 5% пользователей час — тот же бюджет). Траты бюджета: инциденты, неудачные релизы, эксперименты (canary с 1% трафика «сжёг» 0.01% — приемлемая цена проверки — стратегии деплоя). Политика (принимается командой заранее, не в момент конфликта): бюджет > 50% — релизы в обычном темпе; < 25% — повышенная осторожность (canary обязателен, релизы в начале недели); исчерпан — фичи-стоп, работа над надёжностью до восстановления (правило действует и на «очень важную фичу к дедлайну» — иначе правило мертво; исключение — только явное решение владельца продукта с записью «осознанно потратили надёжность на X»). Скорость сгорания важнее остатка для алертинга: burn rate 14x (месячный бюджет сгорит за два дня) — алерт немедленно; 2x — предупреждение; единичные ошибки в пределах нормы — тишина (алерт на каждое 500-е уведомление = алерт-фатиг = пропущенный настоящий инцидент). Многооконная схема (быстрое окно 1 час для пейджинга + медленное 6 часов для подтверждения) — стандарт из SRE Workbook: меньше ложных, быстрее настоящие.
Алерты по симптомам и эксплуатационная связка
Алертить — на симптомы для пользователя (SLO-выражения), не на причины (CPU 90% при зелёном SLO — не проблема пользователя; проблема — когда симптом деградирует): paging-алерты — быстрое сгорание бюджета (требует человека сейчас — oncall-практика), ticket-алерты — медленное сгорание (разобрать в рабочее время), всё остальное — дашборды без уведомлений. Каждый пейдж — либо требует немедленного действия (runbook прилагается), либо не должен пейджить — ревизия алертов ежемесячно («сколько раз сработал, сколько раз потребовал действий» — алерты без действий удаляются). Связка с инцидентами: каждый инцидент — потраченный бюджет, постмортем включает «сколько сожгли» и «что снизит вероятность повторной траты» (не «кто виноват» — blameless — инцидент-процесс); повторяющиеся траты одним компонентом — приоритет надёжности обоснован цифрами бюджета, а не ощущениями. Отчётность — простая ежемесячная страница: SLO за окно, остаток бюджета, топ-3 траты, план — этого достаточно владельцу продукта для разговора о балансе скорость/надёжность.
Практический сценарий: SLO без SRE-отдела за неделю
Команда 5 человек, продукт — B2B-API. День 1: выбор SLI — доля 5xx-free запросов (по access-логам nginx — данные уже есть) и доля ответов < 800 мс; день 2: SLO — исторические данные за 3 месяца показывают фактические 99.2% и 93% быстрых — цели 99.5%/95% (амбициозно, но достижимо — не фантазия); день 3: Prometheus-записи (rolling 30d) + Grafana-панель «остаток бюджета» (дашборд команды); день 4: алерты — burn rate 14x/2x многооконные; день 5: политика бюджета записана в runbook (пороги релизной осторожности — таблица из раздела выше); неделя 2: первый эффект — релиз во вторник сжёг 0.3% (баг в новом эндпоинте, откат через час) — бюджет 40% — команда сама притормозила следующий релиз до разбора (без менеджера и совещаний — арифметика сделала работу); месяц 2: SLO вырос до 99.6% — три траты пришлись на один компонент очереди — его надёжность стала обоснованным приоритетом спринта. Итог: минимальный SRE-каркас стоил неделю настройки и дал команде общий язык про надёжность — цифры вместо мнений.
FAQ
SLO, SLA и SLI — в чём разница простыми словами? SLI — что измеряем (факт); SLO — внутренняя цель (стремление, «99.5% для себя»); SLA — контракт с клиентом (обещание с штрафами, всегда мягче SLO: обещаем 99%, целимся 99.5% — запас на случайности); путаница дорогая: SLO = SLA означает работу «на грани штрафа».
Что делать, если продукт должен быть 100% доступен? Никакой SLO не даст 100% (зависимости, деплои, железо) — разговор переводится в «сколько минут простоя в месяц приемлемы для бизнеса» и «что делаем во время неизбежного простоя» (деградация вместо отказа, статус-страница, компенсации) — стратегии отказоустойчивости.
Нужны ли SLO для внутренних инструментов? В облегчённом виде — да: «дэшборд доступен 99% рабочего времени» задаёт уровень поддержки и легитимизирует работу над надёжностью; без цифры внутренний сервис живёт в режиме «починим, когда громко попросят».
Как считать SLO при разной важности запросов? Взвешиванием или раздельными SLI: критичные сценарии (логин, оплата) — отдельный SLO строже общего (платёж 99.9%, справочник 99%); один усреднённый SLO на всё прячет деградацию важного за массой неважного — типичная ошибка первого года.
Источники: Google SRE Book (Service Level Objectives), SRE Workbook (Implementing SLOs) — ссылки в шапке.