← [Раздел](README.md) · [Главная](../README.md)

# Метрики и SLO

## Цель

Освоить **метрики** для облачных сервисов, методики **RED** и **USE**, а также цепочку **SLI → SLO → SLA** и понятие **error budget** для баланса между скоростью релизов и стабильностью.

## Предварительно

- [Логирование](logging.md)
- Базовая статистика: среднее, перцентиль

## Время

~70 минут

---

## Типы метрик

| Тип | Пример | Вопрос |
|-----|--------|--------|
| **Counter** | `http_requests_total` | Сколько всего? (только растёт) |
| **Gauge** | `queue_depth` | Сколько сейчас? |
| **Histogram** | `http_request_duration_seconds` | Распределение латентности |

В Prometheus-мире имена с суффиксами `_total`, `_bucket`; в других системах — те же идеи.

---

## RED — для request-driven сервисов

| Буква | Метрика | Пример |
|-------|---------|--------|
| **R**ate | Запросов в секунду | `sum(rate(http_requests_total[5m]))` |
| **E**rrors | Доля ошибок | 5xx / все запросы |
| **D**uration | Время ответа | p95 latency |

Минимальный дашборд для каждого HTTP-сервиса в курсе: RED + один график saturation (CPU или pool).

---

## USE — для ресурсов

| Буква | Метрика |
|-------|---------|
| **U**tilization | % CPU, % диска |
| **S**aturation | Длина очереди, ожидание |
| **E**rrors | Ошибки диска, сети |

Применяйте к БД, брокерам, нодам Kubernetes.

---

## SLI, SLO, SLA

| Термин | Определение | Кто задаёт |
|--------|-------------|------------|
| **SLI** (Indicator) | Измеримый аспект качества | Инженеры |
| **SLO** (Objective) | Цель по SLI | Инженеры + продукт |
| **SLA** (Agreement) | Юридическое обещание клиенту | Бизнес |

Пример цепочки:

```text
SLI: доля успешных запросов GET /products с latency < 300 ms
SLO: 99.9% таких запросов за 30 дней
SLA: 99.5% с компенсацией при нарушении (договор)
```

SLO **строже** SLA — буфер на инциденты и плановые работы.

---

## Error budget

Если SLO = 99.9%, то **error budget** = 0.1% запросов могут «провалиться» за окно без нарушения цели.

| Ситуация | Действие |
|----------|----------|
| Бюджет есть | Можно рисковать: эксперименты, частые релизы |
| Бюджет на исходе | Заморозка фич, фокус на надёжность |
| SLO стабильно перевыполняется | SLO завышен — можно ужесточить или ускорить delivery |

Error budget связывает **разработку** и **эксплуатацию** одним языком.

---

## Перцентили, не среднее

Средняя латентность 100 мс может скрывать 10% запросов по 5 с.

Для SLO используйте **p95** или **p99** на критичных endpoint'ах:

```text
SLO: 99% запросов checkout < 800 ms (p99 < 2 s)
```

---

## Метки (labels) и кардинальность

```text
http_requests_total{method="GET", path="/products", status="200"}
```

**Высокая кардинальность** убивает хранилище метрик:

| Плохо | Почему |
|-------|--------|
| `user_id` как label | Миллионы рядов |
| Полный URL с id | То же |
| `path="/users/{id}"` шаблон | OK |

Агрегируйте редкие измерения в логи или трейсы.

---

## Бизнес-метрики

Технические RED + продуктовые:

| Метрика | Зачем |
|---------|-------|
| `orders_created_total` | Падение = баг или внешний платёж |
| `payment_success_rate` | Деньги |
| `signup_completed` | Воронка |

Связывайте алерт на бизнес-метрику с техническими дашбордами.

---

## Пример дашборда (описание)

Страница **Order API**:

1. RPS по методу.
2. Error rate % (4xx отдельно от 5xx).
3. Latency heatmap p50/p95/p99.
4. Saturation: DB connection pool used/max.
5. SLO burn rate за 1 ч и 6 ч.

**Burn rate** — как быстро «сжигается» error budget; быстрый burn → страница on-call.

---

## Чеклист внедрения SLO

- [ ] Выбраны 2–3 критичных user journey
- [ ] SLI измеримы из метрик или логов
- [ ] SLO согласован с продуктом
- [ ] Дашборд и алерт на burn rate
- [ ] Ежеквартальный пересмотр целей

---

## Самопроверка

1. Расшифруйте RED и приведите пример метрики для каждой буквы.
2. Чем SLI отличается от SLO?
3. Что такое error budget и как он влияет на релизы?
4. Почему p95 лучше среднего для latency?

---

## Дальше

→ [Трейсинг и алерты](tracing-i-alerty.md)  
← [Логирование](logging.md)