SRE простыми словами: SLI, SLO, SLA и бюджет ошибок на примере 99,9%

SLI — это метрика надёжности сервиса, например доля успешных запросов; SLO — цель по этой метрике, например 99,9% успешных запросов за 30 дней; SLA — договор с клиентом, где за невыполнение цели есть последствия. Бюджет ошибок — это 100% минус SLO: при 99,9% сервис может не справляться с 0,1% запросов или времени, и за 30 дней это 43,2 минуты полного простоя.

Эти понятия пришли из SRE (Site Reliability Engineering) — подхода Google к эксплуатации, который описан в двух открытых книгах: «Site Reliability Engineering» и практическом продолжении «The Site Reliability Workbook». Ниже — определения с примерами, расчёт бюджета, алерты на скорость его расхода и что делать, когда бюджет кончился.

Зачем считать надёжность, а не стремиться к 100%

В книге Google SRE 100% названо неправильной целью почти для любого сервиса. Дотянуть до абсолюта невозможно, каждая следующая девятка стоит всё дороже и тормозит выпуск новых функций, а пользователь разницу не заметит. Пример из книги: человек со смартфоном, который сам работает с надёжностью 99%, не отличит сервис на 99,99% от сервиса на 99,999%.

Поэтому SRE договаривается о достаточном уровне надёжности и относится к нему как к минимуму и одновременно к максимуму. Если сервис стабильно надёжнее цели, команда недотратила бюджет: могла выпускать фичи быстрее, чистить технический долг или экономить на инфраструктуре.

SLI, SLO и SLA: определения и примеры

Отличить SLO от SLA помогает вопрос из книги Google: что будет, если цель не выполнена? Если явных последствий нет — ни денег, ни штрафа, — это SLO. SLA обычно мягче внутреннего SLO: запас даёт время починить проблему до того, как она станет нарушением договора.

Каким бывает SLI

SRE Workbook советует считать SLI как отношение хороших событий ко всем учтённым событиям. Тогда он всегда лежит между 0% и 100%, а бюджет ошибок считается просто: 100% минус SLO.

Какие SLI выбирают чаще всего:

• доступность — доля корректных запросов, на которые сервис ответил успешно;
• задержка — доля запросов быстрее порога, например быстрее 300 мс;
• пропускная способность и свежесть данных — для очередей и конвейеров обработки;
• корректность — сервис ответил правильно, а не просто кодом 200;
• сохранность — для хранилищ: данные не теряются.

Задержку описывают перцентилями, а не средним. Среднее прячет хвост: если 1% запросов идёт по пять секунд, среднее почти не изменится, а пользователи это заметят. Поэтому цель звучит как «99% запросов быстрее 100 мс», а не «среднее время ответа 50 мс».

Так выглядят оба SLI в Prometheus. Имена метрик и меток зависят от того, как инструментировано ваше приложение:

# Доступность: доля ответов без 5xx за 28 дней
sum(rate(http_requests_total{job="checkout", code!~"5.."}[28d]))
/
sum(rate(http_requests_total{job="checkout"}[28d]))

# Задержка: доля запросов быстрее 300 мс за 28 дней
sum(rate(http_request_duration_seconds_bucket{job="checkout", le="0.3"}[28d]))
/
sum(rate(http_request_duration_seconds_count{job="checkout"}[28d]))

На больших окнах такие запросы тяжёлые, поэтому в проде их считают через recording rules — заранее вычисленные ряды.

Как выбрать SLO

Советы из главы о SLO книги Google SRE:

• Начинайте с того, что важно пользователям, а не с того, что легко измерить. Загрузка CPU — не SLI: пользователь её не видит.
• Не берите цель из текущих показателей. Иначе можно навсегда привязаться к уровню, который держится только на героизме дежурных.
• Меньше SLO — лучше. Если на цифру ни разу не сослались при обсуждении приоритетов, она не нужна.
• Начните с мягкой цели и ужесточайте. Ослабить слишком строгий SLO сложнее, чем подтянуть мягкий.
• Держите запас. Внутренний SLO строже того, что обещано клиентам.
• Не перевыполняйте. Пользователи привыкают к фактической надёжности, а не к обещанной. Google для этого роняла собственный сервис блокировок Chubby: если за квартал он не опускался ниже цели сам, SRE устраивали плановый простой, чтобы команды не строили сервисы на допущении, что Chubby не падает никогда.

Окно для SLO бывает скользящим или календарным. SRE Workbook считает скользящие четыре недели удачным вариантом по умолчанию: в окне всегда одинаковое число выходных, а авария в последний день месяца не «забывается» первого числа, как не забывают её пользователи. Календарный месяц или квартал удобнее для отчётов и планирования.

Бюджет ошибок: считаем 99,9%

В 30 днях 43 200 минут. Бюджет при SLO 99,9% — 0,1% от них:

$ echo "30*24*60*(1-0.999)" | bc -l
43.200
$ awk 'BEGIN { for (d = 28; d <= 31; d++) printf "%d дн. — %.2f мин\n", d, d*1440*0.001 }'
28 дн. — 40.32 мин
29 дн. — 41.76 мин
30 дн. — 43.20 мин
31 дн. — 44.64 мин

Те самые «43 минуты в месяц» — округлённые 43,2 минуты для месяца в 30 дней. Цифра совпадает с таблицей доступности из книги Google SRE. Для 31-дневного месяца бюджет — 44,6 минуты, для скользящих 28 дней — 40,3 минуты.

Минуты — только удобный способ представить бюджет. Google чаще считает доступность по запросам: распределённый сервис редко лежит целиком, обычно где-то часть запросов обслуживается. Тогда бюджет — число ошибок. Пример из SRE Workbook: миллион запросов за четыре недели при SLO 99,9% дают бюджет в 1 000 ошибок.

Частичная деградация тоже тратит бюджет. При ровном трафике 20 минут, когда падает каждый десятый запрос, стоят столько же, сколько 2 минуты полного простоя, — около 4,6% месячного бюджета. А полный простой на 27 минут — столько сайты клиентов Cloudflare отдавали 502 в 2019 году, см. разбор сбоя Cloudflare, — съест 62,5% бюджета за 30 дней.

Поэтому в постмортеме полезно писать, какую долю бюджета съел инцидент: так видно, насколько он серьёзен, без споров о формулировках.

Burn rate: алерт на скорость расхода бюджета

Алерт «ошибок больше 0,1% десять минут подряд» плох: SRE Workbook показывает, что такой всплеск тратит около 0,02% месячного бюджета, то есть будит дежурного почти по пустякам. Лучше следить за скоростью расхода — burn rate.

Burn rate 1 значит, что бюджет закончится ровно к концу окна. При SLO 99,9% за 30 дней:

Workbook советует начинать с трёх порогов: будить человека, если за час ушло 2% месячного бюджета (burn rate 14,4) или за шесть часов — 5% (burn rate 6), и заводить тикет, если за три дня ушло 10% (burn rate 1). В виде правил Prometheus это выглядит так; job:slo_errors_per_request:ratio_rate1h — recording rule с долей ошибок за час, остальные — за 6 часов и 3 дня:

groups:
  - name: slo-checkout
    rules:
      - alert: CheckoutErrorBudgetBurn
        expr: |
          job:slo_errors_per_request:ratio_rate1h{job="checkout"} > (14.4 * 0.001)
          or
          job:slo_errors_per_request:ratio_rate6h{job="checkout"} > (6 * 0.001)
        labels:
          severity: page
      - alert: CheckoutErrorBudgetSlowBurn
        expr: job:slo_errors_per_request:ratio_rate3d{job="checkout"} > 0.001
        labels:
          severity: ticket

Такой алерт будит только тогда, когда под угрозой обещание пользователям, а не при каждом всплеске. Как устроены дежурства и зачем беречь сон дежурного, разобрано в статье что такое on-call.

Что делать, когда бюджет кончился

Правила пишут заранее, в политике бюджета ошибок, и согласуют её втроём: продакт, разработка и SRE. Если бюджет кончился, а стороны начинают спорить, стоит ли выполнять политику, — значит, её надо пересогласовать, а не нарушить. В SRE Workbook есть пример такой политики:

• если бюджет за предыдущие четыре недели исчерпан, все изменения и релизы замораживаются, кроме исправлений P0 и безопасности, пока сервис не вернётся в SLO;
• команда обязана заняться надёжностью, если бюджет съели баг в коде или ошибка в процедуре самого сервиса;
• фичи можно продолжать, если виновата общая сетевая авария компании, сервис другой команды, которая сама заморозила релизы, или нагрузочные тесты, которые в SLO не входят;
• если один инцидент съел больше 20% бюджета за четыре недели — обязателен постмортем минимум с одной задачей P0 на корневую причину;
• если один класс сбоев съел больше 20% бюджета за квартал — задача P0 попадает в план следующего квартала;
• спор о расчётах решает CTO.

Заморозка работает, потому что изменения — главный источник нестабильности: по оценке в той же политике, на них приходится около 70% сбоев. Книга предлагает и мягкие варианты: замедлить релизы или откатывать их, когда бюджет почти кончился.

Политика — не наказание. В Workbook отдельно сказано, что она даёт команде право заниматься только надёжностью, когда цифры показывают, что это сейчас важнее фич. Это тот же подход, что и в blameless-постмортемах: разбираться с системой, а не искать виноватых.

Если бюджет остаётся, его можно тратить: выпускать чаще, проводить эксперименты и плановые работы. А если команда раз за разом не укладывается в SLO и ничего не может с этим сделать, стоит пересмотреть сам SLO — возможно, он не соответствует тому, что реально нужно пользователям.

Частые ошибки

• SLO 99,999% «потому что так надо». Каждая девятка стоит денег и скорости. Цель должна соответствовать тому, что нужно пользователям.
• SLI по CPU и памяти. Это причины, а не симптомы. Пользователь видит ошибки и задержку.
• Среднее вместо перцентилей. Хвост медленных запросов в среднем не виден.
• SLA равен SLO. Без запаса любая проблема сразу становится нарушением договора.
• Двадцать SLO на сервис. Их никто не смотрит, и ни одно решение на них не опирается.
• SLO без политики. Цифра на дашборде, которая ничего не меняет в том, как команда выпускает релизы.

Как это выглядит на практике

Считать бюджет по формуле просто. Сложнее решить, что делать ночью, когда он тает. В симуляторе DevOps KAI Lab восьмой месяц посвящён мониторингу: в нём есть тикет, где нужно понять, сколько бюджета ошибок осталось у сервиса, и дежурство в ночь распродажи, когда важно отличить угрозу SLO от шума. Начать можно бесплатно — первые задания первого месяца.

Частые вопросы

Чем SLO отличается от SLA? SLO — внутренняя цель команды. SLA — договор с клиентом, в котором прописаны последствия, обычно деньги. Если за невыполнение цели ничего не будет, это SLO. SLA обычно мягче SLO, чтобы оставался запас.

Сколько это — 99,9% доступности в минутах? 43,2 минуты за 30 дней, 44,6 минуты за 31 день, 40,3 минуты за скользящие 28 дней и 8,76 часа за год. Для 99,99% — 4,32 минуты за 30 дней.

Бюджет ошибок считается по времени или по запросам? Можно и так, и так. По времени проще объяснять, по запросам точнее: частичная деградация и неравномерный трафик учитываются честно. В книге Google SRE приведены обе формулы, а для распределённых сервисов Google использует долю успешных запросов.

Нужен ли SLO небольшой команде? Да, если у сервиса есть пользователи и дежурства. Хватит одного-двух SLO на доступность и задержку и простой политики: что делаем, когда бюджет кончился. Это полезнее десятка алертов на CPU.

Что такое burn rate? Скорость расхода бюджета ошибок относительно SLO. Burn rate 1 — бюджет кончится ровно к концу окна, 10 — за десятую часть окна. Алерты на burn rate будят дежурного, когда под угрозой обещание пользователям.

Источники

• Google. Site Reliability Engineering, глава 3: Embracing Risk — почему 100% — неправильная цель, доступность по времени и по запросам, бюджет ошибок.
• Google. Site Reliability Engineering, глава 4: Service Level Objectives — определения SLI, SLO и SLA, перцентили, выбор целей, история с Chubby.
• Google. Site Reliability Engineering, приложение A: Availability Table — допустимый простой для каждого уровня доступности.
• Google. The Site Reliability Workbook: Implementing SLOs — SLI как доля хороших событий, окна, согласование политики.
• Google. The Site Reliability Workbook: Alerting on SLOs — burn rate, пороги и правила алертов.
• Google. The Site Reliability Workbook: Example Error Budget Policy — пример политики бюджета ошибок.