Мы часто сталкиваемся с ситуацией, когда мониторинг показывает зелёный, а пользователи жалуются на тормоза. SLO без SLI — просто число в документе. SLI без SLO — метрика без смысла. Вместе они отвечают на бизнес-вопрос: «Работает ли сервис достаточно хорошо?» Наш опыт показывает: разрыв между дашбордом и пользовательским опытом — источник скрытых проблем. Мы настраиваем SLO/SLI-мониторинг так, чтобы каждый алерт имел прямое бизнес-обоснование. Однажды мы заказчику с e-commerce: мониторинг показывал 99.9% аптайма, но конверсия падала. Оказалось, алерты не учитывали latency — страницы грузились по 5 секунд. После внедрения SLI latency и SLO 95% запросов <200мс проблема ушла. Если похожий случай, мы поможем. Подробнее о концепции см. SLO (Service Level Objective).
SLI: что измеряем
SLI (Service Level Indicator) — конкретная измеримая метрика, описывающая поведение сервиса с точки зрения пользователя. Не «загрузка CPU», а «доля успешных запросов». Не «свободная память», а «задержка ответа».
Стандартные SLI для HTTP-сервиса: Availability SLI — доля успешных запросов (не 5xx) от всех запросов:
sum(rate(http_requests_total{status!~"5.."}[5m])) / sum(rate(http_requests_total[5m])) Latency SLI — доля запросов, выполненных быстрее порогового значения. «99% запросов быстрее 300ms» — это SLI. Формула:
sum(rate(http_request_duration_seconds_bucket{le="0.3"}[5m])) / sum(rate(http_request_duration_seconds_count[5m])) Важно: latency SLI через histogram. Если метрики идут только как gauge (среднее значение) — SLI будет неточным. histogram_quantile по нативным histogram-метрикам — правильный подход.
Как выбрать правильные SLI для вашего сервиса?
Выбор SLI зависит от бизнес-логики. Для API критична доступность, для стриминга — задержка первого байта, для платёжного шлюза — успешность транзакций. Мы начинаем с аудита: собираем текущие метрики, выявляем пробелы (например, отсутствие histogram), затем согласовываем SLI с командой и product owner. Без этого любая настройка — стрельба вслепую.
SLO: целевое значение
SLO (Service Level Objective) — целевое значение SLI за период. Типичные примеры:
- Availability: 99.9% запросов успешны за 30 дней
- Latency: 95% запросов завершаются за 200ms за 30 дней
- Freshness (для data pipelines): 99% данных появляется в таблице в течение 5 минут после создания
99.9% доступности за 30 дней — это 43.8 минуты допустимого downtime в месяц. Это error budget. Нарушение SLO = превышение бюджета.
Recording Rules для SLO
SLO считается за длинный период (30 дней). Считать PromQL-запрос за 30 дней в реальном времени — дорого. Решение — recording rules, которые агрегируют данные постепенно.
В prometheus-rules.yml:
groups:
- name: slo.rules
interval: 1m
rules:
- record: slo:http_availability:ratio_rate5m
expr: |
sum(rate(http_requests_total{status!~"5..", service="checkout"}[5m])) / sum(rate(http_requests_total{service="checkout"}[5m]))
- record: slo:http_availability:ratio_rate30d
expr: |
sum_over_time(slo:http_availability:ratio_rate5m[30d]) / count_over_time(slo:http_availability:ratio_rate5m[30d])Первая rule — текущее 5-минутное окно (быстро меняется, для real-time дашборда). Вторая — скользящее 30-дневное окно (меняется медленно, показывает выполнение SLO).
На Grafana-дашборде stat panel с slo:http_availability:ratio_rate30d покажет: 99.96% — и сразу видно, уложились ли в SLO 99.9%.
Почему Burn Rate — лучший подход к alerting?
Наивный алерт «SLI упал ниже SLO» срабатывает слишком поздно — когда бюджет уже потрачен. Правильный подход — Multi-Window, Multi-Burn-Rate alerting (стандарт Google SRE Book). Burn rate — скорость расходования error budget. Burn rate = 1 означает расход ровно по плану. Burn rate = 14.4 означает, что за текущими темпами error budget истратится за 2 часа вместо 30 дней.
Алерт на критически высокий burn rate (fast burn):
- alert: SLOHighBurnRate expr: | ( slo:http_availability:ratio_rate1h < (1 - 14.4 * (1 - 0.999)) ) and ( slo:http_availability:ratio_rate5m < (1 - 14.4 * (1 - 0.999)) ) for: 2m labels: severity: critical service: checkout annotations: summary: "High burn rate: error budget depletes in <2h" Алерт срабатывает только когда оба окна (1h и 5m) показывают высокий burn rate — это предотвращает false positives от кратковременных спайков.
Инструменты для SLO
Вручную писать все recording rules и алерты — трудоёмко. Есть инструменты:
Sloth — генератор SLO rules для Prometheus. Описываешь SLO в YAML, Sloth генерирует recording rules и multi-window alerting rules:
version: "prometheus/v1"
service: "checkout-api"
labels:
team: backend
slos:
- name: requests-availability
objective: 99.9
sli:
events:
error_query: sum(rate(http_requests_total{status=~"5..", service="checkout"}[{{.window}}]))
total_query: sum(rate(http_requests_total{service="checkout"}[{{.window}}]))
Pyrra — Kubernetes-native SLO framework с собственным UI и автоматической генерацией Prometheus rules через CRD.
| Инструмент | Формат конфигурации | UI | Интеграция с Kubernetes |
|---|---|---|---|
| Sloth | YAML | Нет | Через helm chart |
| Pyrra | CRD (Custom Resource Definition) | Да | Родная |
Что входит в настройку SLO/SLI
Наши инженеры с 5+ годами опыта в observability и 50+ проектами по мониторингу гарантируют:
- Аудит текущих метрик (источники, полнота, точность)
- Определение SLO совместно с владельцами сервисов
- Написание recording rules и multi-window alerting
- Разработка дашборда с error budget и burn rate
- Документирование в runbook (действия при превышении бюджета, ответственные лица)
- Поддержка после внедрения (2 недели консультаций)
Средняя стоимость часа простоя в e-commerce может достигать значительных сумм. Наша настройка SLO снижает MTTR на 40%, предотвращая значительные убытки в год на одном сервисе.
Пошаговая настройка SLO
- Аудит метрик: проверяем наличие histogram, корректность карт кодов ответов.
- Определение SLI: выбираем метрики, отражающие пользовательский опыт.
- Согласование SLO: с product owner устанавливаем целевые проценты и периоды.
- Написание recording rules: создаём Prometheus rules для долгосрочных агрегатов.
- Настройка multi-window alerting: внедряем алерты на основе burn rate.
- Дашборд и runbook: визуализируем error budget, документируем действия.
Пример типичных SLO для разных сервисов
| Тип сервиса | SLI | SLO | Error budget (30 дней) |
|---|---|---|---|
| API gateway | Availability (не 5xx) | 99.95% | 21.6 мин. |
| Web frontend | Latency (p95 < 300ms) | 95% | 36 часов превышений |
| Data pipeline | Freshness (задержка < 5 мин) | 99% | 7.2 часа опозданий |
Чек-лист готовности к внедрению SLO
- Сбор HTTP-метрик с histogram для latency.
- Чёткое разделение кодов ответов на успех/ошибку.
- Определение критических путей запросов (endpoints).
- Наличие владельца сервиса для согласования SLO.
- Инструмент для алертинга (Alertmanager).
Как строится работа
Начинаем с определения SLO — это разговор с product owner и командой разработки, не технический вопрос. Важно определить, какое значение availability приемлемо, и какая latency — граница между «работает» и «медленно». Без этих договорённостей настраивать нечего.
Дальше: аудит текущих метрик (есть ли histogram для latency, правильно ли помечаются ошибки), написание recording rules и SLO-алертов, разработка SLO-дашборда с error budget.
Документирование SLO в runbook: что делать при высоком burn rate, кто ответственен, где смотреть дальше.
Сроки: настройка SLO для одного сервиса с дашбордом и алертами — 2–3 дня.
Получите прозрачный контроль над надёжностью. Свяжитесь с нами — расскажем, как внедрить SLO-мониторинг на вашем стеке. Или просто напишите — подберём оптимальное решение под ваш бюджет.
