llmdocsсправочник разработчика

SRE, SLO и SLA

Материал из llmdocs — справочник разработчика
Портал: Git, CI/CD, DevOps
SRE, SLO и SLA
Появление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 дня — тикет.
# доля ошибок за 1 час относительно бюджета SLO 99,9%
(sum(rate(http_requests_total{code=~"5.."}[1h]))
  / sum(rate(http_requests_total[1h]))) / 0.001 > 14.4

Такие правила считаются в Prometheus и отображаются в Grafana; генераторы вроде Sloth и Pyrra строят их из короткого описания SLO.

Практики SRE

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

Как начать

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

См. также

Источники

  1. Google SRE Book — Service Level Objectives
  2. Google SRE Book — Embracing Risk
  3. Google SRE Workbook — Alerting on SLOs
  4. Google SRE Book — Postmortem Culture
  5. Google SRE Book — Eliminating Toil
  6. Google SRE Book — Monitoring Distributed Systems (golden signals)
Категории: