SLO (Service Level Objective, цель уровня услуг) — внутренняя измеримая цель надёжности сервиса, которую ставит перед собой команда разработки или DevOps. В отличие от SLA (юридического соглашения с клиентом), SLO — внутренний ориентир, обычно более строгий.
Как работает
SLO формулируется как: «X% запросов обрабатываются быстрее Y мс за период Z». Пример: «95% HTTP-запросов к API отвечают менее чем за 200 мс в течение 30 дней». Для измерения SLO вводится концепция Error Budget — «бюджет ошибок»: допустимое количество нарушений за период.
Если SLA = 99.9% uptime, разумно установить SLO = 99.95%. Разница между SLA и SLO — буфер для реагирования до нарушения клиентских обязательств.
Типы SLI (Service Level Indicators)
SLI — конкретная метрика для измерения SLO:
- Availability — доля успешных запросов:
rate(http_requests_total{code!~"5.."}[5m]) - Latency — процентиль времени ответа:
histogram_quantile(0.95, http_request_duration) - TTFB — время до первого байта для web-сервисов
- Throughput — количество обработанных запросов в секунду
- Error rate — доля ошибочных ответов (5xx, timeout)
История
SLO как практика появились в Google SRE (Site Reliability Engineering) в начале 2000-х и описаны в книге «Site Reliability Engineering» (2016). Авторы книги — Бет Бейер, Крис Джонс, Дженнифер Петофф, Ньял Мерфи. SLO и Error Budget стали ключевыми концепциями SRE-практики: они балансируют между скоростью разработки (изменения = риски для надёжности) и стабильностью. OpenSLO (2021) — открытый стандарт для описания SLO в YAML.
Error Budget и управление рисками
SLO 99.9% за 30 дней = Error Budget 0.1% × 30 × 24 × 60 = 43.2 минуты допустимого downtime. Пока бюджет не исчерпан — можно деплоить изменения. При исчерпании бюджета — заморозка деплоев до восстановления. Это формализует компромисс между velocity разработки и надёжностью.
В Grafana Error Budget визуализируется через Grafana SLO (plugin) или вручную через PromQL: 1 - avg_over_time(slo_compliance[30d]).
На что обращать внимание
SLO без измерения — декларация. Нужна надёжная инфраструктура мониторинга с хранением исторических данных минимум на период SLO. Слишком агрессивные SLO (99.999%) для небольших команд недостижимы без огромных инвестиций в отказоустойчивость. Начинайте с реалистичных целей на основе исторических данных. Инцидент, нарушающий SLO, требует post-mortem для предотвращения повторения.
Практический пример SLO для веб-сервиса
Для VPS с Nginx-сайтом разумные начальные SLO:
- Availability SLO: 99.5% запросов успешны (не 5xx) за 30 дней
- Latency SLO: p95 время ответа < 500 мс за 30 дней
- TTFB SLO: p50 TTFB < 200 мс
PromQL для Availability SLI:
sum(rate(nginx_http_requests_total{status!~"5.."}[5m]))
/
sum(rate(nginx_http_requests_total[5m]))Дашборд SLO в Grafana показывает текущее значение, тренд и оставшийся Error Budget. При скорости сжигания бюджета > 1 (тратится быстрее, чем восполняется) — алерт дежурному. При скорости > 5 — Page (будить ночью).