# SRE, SLO и SLA

> Site Reliability Engineering — подход Google к эксплуатации через инженерию; SLI, SLO и SLA задают измеримую надёжность, а бюджет ошибок балансирует скорость и стабильность.

Источник: https://llmdocs.ru/wiki/sre-slo-sla/ · обновлено 2026-11-09 · лицензия CC BY-SA 4.0

- **Появление**: Google, 2003 (Бен Трейнор Слосс)
- **Ключевая книга**: Site Reliability Engineering (O'Reilly, 2016)
- **SLI**: показатель уровня обслуживания (что измеряем)
- **SLO**: целевой уровень (внутренняя цель)
- **SLA**: соглашение с клиентом (с последствиями)
- **Бюджет ошибок**: 100% − SLO
- **Практики**: постмортемы без поиска виновных, борьба с рутиной, дежурства
**SRE** (*Site Reliability Engineering*, инженерия надёжности) — подход к эксплуатации сервисов, при котором задачи администрирования решаются методами программной инженерии: автоматизацией, измерениями и явными целями надёжности. Его центральные понятия — **SLI**, **SLO** и **SLA**: что именно измерять, какой уровень считать достаточным и что обещать клиентам. Из них выводится **бюджет ошибок** — допустимый объём ненадёжности, который команда может «потратить» на быстрые релизы и эксперименты.

## История

Подход сложился в Google с 2003 года, когда Бен Трейнор Слосс возглавил команду эксплуатации и, по его словам, поставил вопрос «что будет, если поручить эксплуатацию программистам».[2] В 2016 году Google опубликовала книгу *Site Reliability Engineering*, а затем *The Site Reliability Workbook* — обе бесплатно доступны на sre.google. SRE часто описывают как конкретную реализацию идей DevOps: «class SRE implements DevOps».

## SLI, SLO, SLA

| Термин | Расшифровка | Что это | Пример |
|---|---|---|---|
| **SLI** | Service Level Indicator | измеряемый показатель | доля HTTP-запросов, отвеченных без ошибки 5xx быстрее 300 мс |
| **SLO** | Service Level Objective | целевое значение SLI за период | 99,9% таких запросов за 28 дней |
| **SLA** | Service Level Agreement | договор с клиентом и последствия нарушения | 99,5% в месяц, иначе компенсация 10% стоимости |

SLI лучше всего выражать как отношение «хороших» событий ко всем: `хорошие запросы / все запросы`.[1] Типичные SLI — доступность, задержка (доля запросов быстрее порога, а не среднее), корректность и свежесть данных. Они близки к «золотым сигналам» мониторинга: задержка, трафик, ошибки, насыщение.[6]

SLO всегда строже SLA: внутренняя цель должна сработать как предупреждение задолго до нарушения договора. Ставить SLO 100% бессмысленно — пользователь не отличит 99,99% от 100% из-за собственного интернета, а цена каждой следующей «девятки» растёт многократно.

## Сколько это в минутах

| Доступность | Простой в месяц (30 дней) | В год |
|---|---|---|
| 99% | 7 ч 12 мин | 3,65 дня |
| 99,5% | 3 ч 36 мин | 1,83 дня |
| 99,9% | 43 мин | 8 ч 46 мин |
| 99,95% | 21,6 мин | 4 ч 23 мин |
| 99,99% | 4,3 мин | 52,6 мин |

Если сервис зависит от трёх компонентов с доступностью 99,9% каждый, его итоговая доступность без резервирования — около 99,7%.

## Бюджет ошибок

**Бюджет ошибок** = 100% − SLO. При SLO 99,9% и миллионе запросов в месяц допустимо 1000 неудачных.[2] Пока бюджет не исчерпан, команда свободно выкатывает изменения; если исчерпан — приоритет переходит к стабильности: релизы замораживаются, кроме исправлений, а время уходит на устранение причин сбоев. Так спор «разработка хочет быстрее, эксплуатация — стабильнее» превращается в решение по данным, о котором стороны договорились заранее.

## Алерты по SLO

Вместо алертов на каждый симптом («CPU > 80%») SRE рекомендует оповещать о **скорости сжигания бюджета** (burn rate).[3] Burn rate 1 означает, что бюджет закончится ровно к концу периода; 14,4 — что за час сгорает 2% месячного бюджета. Типичная схема — несколько окон:

- burn rate > 14,4 за 1 час (и за 5 минут) — разбудить дежурного;
- burn rate > 6 за 6 часов — срочно, но в рабочее время;
- burn rate > 1 за 3 дня — тикет.

```promql
# доля ошибок за 1 час относительно бюджета SLO 99,9%
(sum(rate(http_requests_total{code=~"5.."}[1h]))
  / sum(rate(http_requests_total[1h]))) / 0.001 > 14.4
```

Такие правила считаются в [Prometheus](https://llmdocs.ru/wiki/prometheus.md) и отображаются в [Grafana](https://llmdocs.ru/wiki/grafana.md); генераторы вроде Sloth и Pyrra строят их из короткого описания SLO.

## Практики SRE

- **Постмортемы без поиска виновных** (blameless) — после инцидента описывают хронологию, причины и действия по предотвращению; цель — улучшить систему, а не наказать человека.[4]
- **Борьба с рутиной** (toil) — ручная повторяющаяся работа без долговременной ценности; в Google ориентир — не более 50% времени SRE на рутину, остальное — на автоматизацию.[5]
- **Дежурства** с ограниченной нагрузкой, ранбуки и понятная эскалация.
- **Управление изменениями** — постепенные выкладки, канареечные релизы, быстрый откат (см. [CI/CD](https://llmdocs.ru/wiki/ci-cd.md)).
- **Планирование мощности** и нагрузочное тестирование.

## Как начать

1. Выбрать 1–3 пользовательских пути (вход, оформление заказа, API поиска).
2. Определить SLI по уже собираемым метрикам и посмотреть фактические значения за месяц.
3. Поставить SLO чуть ниже текущего уровня и договориться о политике бюджета ошибок.
4. Настроить алерты по burn rate и убрать шумные алерты на причины.
5. Пересматривать SLO раз в квартал.

## См. также

- [Мониторинг и алертинг](https://llmdocs.ru/wiki/monitoring-alerting.md)
- [Prometheus](https://llmdocs.ru/wiki/prometheus.md)
- [Логирование и трассировка (OpenTelemetry)](https://llmdocs.ru/wiki/opentelemetry.md)
- [Бэкапы: правило 3-2-1](https://llmdocs.ru/wiki/backup-3-2-1.md)

## Источники

1. [Google SRE Book — Service Level Objectives](https://sre.google/sre-book/service-level-objectives/)
2. [Google SRE Book — Embracing Risk](https://sre.google/sre-book/embracing-risk/)
3. [Google SRE Workbook — Alerting on SLOs](https://sre.google/workbook/alerting-on-slos/)
4. [Google SRE Book — Postmortem Culture](https://sre.google/sre-book/postmortem-culture/)
5. [Google SRE Book — Eliminating Toil](https://sre.google/sre-book/eliminating-toil/)
6. [Google SRE Book — Monitoring Distributed Systems (golden signals)](https://sre.google/sre-book/monitoring-distributed-systems/)