SLO, бюджеты ошибок и алерты, которые не кричат впустую

SLI, SLO и бюджет ошибок, который ты тратишь

Надёжность — это не ощущение; это число, и у числа три слоя. SLI (Service Level Indicator) — это измеренное отношение хороших событий ко всем валидным: доля запросов, обслуженных корректно. Два канонических SLI: доступность = ответы не-5xx / все ответы и латентность = запросы быстрее 300мс / все запросы. Всегда отношение в [0, 1], потому что сырой счёт ничего не значит без знаменателя. SLO (Service Level Objective) — это цель для этого отношения за окно — скажем, 99.9% доступности за скользящие 28 дней. Бюджет ошибок — это то, что осталось: 1 − SLO. При 99.9% бюджет равен 0.1%, что за 30 дней даёт ~43 минуты разрешённого отказа (при 99.95% это ~22 мин; при 99% — просторные ~7.2 часа). Этот крошечный остаток и есть вся суть — он превращает надёжность в величину, которую ты тратишь. Жги его медленно весь месяц — и всё в порядке; сожги половину одним плохим деплоем — и ты замораживаешь рискованные изменения, пока он не восстановится. Бюджет — это контракт между «деплоить быстро» и «оставаться на ногах»: пока ты в бюджете — деплой; как только превысил — работа над надёжностью прыгает в начало очереди.

SLI вычисляется прямо из metric math в CloudWatch — good / total — и алармить надо по результату, а не по прокси.

# SLI доступности как metric math: good (не-5xx) / valid (все) запросы.
# m1 = общий счёт запросов, m2 = счёт 5xx; expr = (m1 - m2) / m1.
aws cloudwatch put-metric-alarm \
  --alarm-name checkout-availability-slo \
  --comparison-operator LessThanThreshold \
  --threshold 0.999 \
  --evaluation-periods 5 --datapoints-to-alarm 5 \
  --treat-missing-data breaching \
  --metrics '[
    { "Id": "total", "MetricStat": { "Metric": { "Namespace": "MyApp/Checkout", "MetricName": "Requests" }, "Period": 300, "Stat": "Sum" }, "ReturnData": false },
    { "Id": "errors", "MetricStat": { "Metric": { "Namespace": "MyApp/Checkout", "MetricName": "HTTP5xx" }, "Period": 300, "Stat": "Sum" }, "ReturnData": false },
    { "Id": "sli", "Expression": "(total - errors) / total", "Label": "availability", "ReturnData": true }
  ]' \
  --alarm-actions <sns-topic-arn>

Компромисс: SLO — это осознанное обещание, а не 100%. Гнаться за 100% бесконечно дорого и бессмысленно — твои пользователи уже теряют запросы на собственном капризном Wi-Fi задолго до того, как узким местом станет твой сервис. Каждая девятка примерно умножает стоимость; выбирай наименьшую цель, при которой пользователи довольны, потому что каждая ненужная девятка — это деньги и скорость, которые ты сохраняешь. Режим отказа: SLO без знаменателя (аларм по сырому счёту ошибок) ломается в худший момент. Пятьдесят ошибок — катастрофа при 100 req/s и погрешность округления при 100k req/s — аларм по счёту пейджит на всплеске трафика и молчит во время малотрафичной аварии. Отношения масштабируются с нагрузкой; счётчики — нет.

RED, USE и четыре золотых сигнала

Всё измерить нельзя, поэтому измеряй те немногие сигналы, что отображаются в боль пользователя. Два фреймворка делят пространство. RED — для request-driven сервисов: Rate (запросов/сек), Errors (упавших запросов/сек), Duration (распределение латентности, смотришь по p99, а не по среднему). RED отвечает на «обслуживаются ли пользователи, быстро и корректно?» USE — для ресурсов: Utilization (насколько занят: CPU %, mem %), Saturation (сколько в очереди/перегрузе: глубина run-queue, ожидание пула соединений), Errors (ошибки устройства/драйвера). USE отвечает на «не вот-вот ли опрокинется этот CPU, диск или пул соединений?» Гугловские четыре золотых сигнала — латентность, трафик, ошибки, насыщение — это та же идея в дистилляте: первые три — это RED, насыщение — несущая половина USE.

# RED для сервиса: p99-латентность (Duration) — релевантная для SLO статистика.
# Алармь по перцентилю, никогда по Average, которое прячет медленный хвост.
aws cloudwatch put-metric-alarm \
  --alarm-name checkout-p99-latency \
  --namespace MyApp/Checkout --metric-name LatencyMs \
  --extended-statistic p99 --period 60 \
  --threshold 500 --comparison-operator GreaterThanThreshold \
  --evaluation-periods 3 --datapoints-to-alarm 3 \
  --treat-missing-data breaching \
  --alarm-actions <sns-topic-arn>

Компромисс: RED и USE дополняют друг друга, а не взаимозаменяемы. RED говорит, что пользователям больно; USE часто говорит, почему (растёт насыщение → растёт латентность). Дисциплина в том, чтобы пейджить по RED (симптом, обращённый к пользователю) и держать USE на дашбордах для диагностики — навесить пейдж на каждую USE-метрику — это ровно способ заново собрать шумный CPU-аларм из Hook. Режим отказа: измерять всё — это шум. Команда, рисующая триста метрик и пейджащая по трети из них, не имеет сигнала — когда важно всё, не важно ничего, и единственная реальная авария тонет в той же струе, что и каждый рутинный всплеск.

Симптом против причины: алертируй по тому, что чувствует пользователь

Это сердцевина, и именно здесь большинство систем алертинга ошибается. Пейджи по симптомам — тому, что пользователь реально испытывает: error rate вырос, p99-латентность выросла, burn rate SLO высок. Не пейджи по причинам — CPU 90%, один хост упал, диск наполняется, рестарт пода. Причины срабатывают постоянно без всякого влияния на пользователя: CPU достигает 90% на каждом деплое, а сервис при этом совершенно исправен, так что CPU-пейдж — гарантированная машина ложных алармов. А у ложных алармов есть накапливающаяся цена — усталость от алертов. Когда пейджит каждый деплой, дежурный усваивает, что пейджер не значит ничего, мьютит канал и пропускает единственную реальную аварию (ровно как в Hook). Цена шумного алерта — не прерывание; она в том, что он уничтожает доверие к каждому будущему алерту.

Senior-техника — это multi-window, multi-burn-rate алертинг. Burn rate — это насколько быстро ты тратишь бюджет ошибок относительно SLO; burn rate 1 тратит весь месячный бюджет ровно за месяц, так что всё выше 1 — слишком быстро. Ставишь два уровня: fast-burn алерт (например, burn 14.4× = 2% 30-дневного бюджета сожжено за 1 час, подтверждённый на коротком окне) → пейдж сейчас, потому что при таком темпе весь месячный бюджет уйдёт за ~2 дня. И slow-burn алерт (например, ~3× за 6 часов, ~10% бюджета) → заведи тикет, без подъёма в 3 ночи, потому что у тебя есть дни на реакцию. Часть с двумя окнами подавляет всплески: быстрый алерт требует, чтобы прожиг держался и на длинноватом окне (ловит реальное), и на коротком (подтверждает, что это всё ещё происходит прямо сейчас), так что единичный всплеск на 90 секунд не пейджит. Числа, которые важны: SLO 99.9% = бюджет ~43 мин/мес; пейдж по burn rate 14.4× = действуй сейчас; опросы стабильно дают долю ложных срабатываний дежурного около 50%+ при алертинге по причинам — половина всех пейджей будит кого-то впустую.

Проводка на AWS без воссоздания шума

CloudWatch даёт примитивы, и три из них держат пейджер честным. Композитные алармы комбинируют дочерние алармы булевым правилом — ALARM(p99High) AND ALARM(errorRateHigh) или ALARM(slo) AND NOT ALARM(deployInProgress) — так что одна первопричина, подтверждённая двумя симптомами, пейджит один раз вместо четырёх связанных алармов, а известный деплой подавляет пейдж целиком. Аларм на отсутствие данных — это страж живучести: мёртвый сервис не эмитит ничего, так что аларм с --treat-missing-data notBreaching молча никогда не сработает, когда то, что он сторожит, опрокинется — ровно наоборот. Для heartbeat/liveness-аларма ставишь --treat-missing-data breaching, чтобы тишина тебя пейджила. Полосы anomaly detection обучают ожидаемый диапазон по истории и алармят на отклонениях, что бьёт плоский порог для трафика с дневной или недельной сезонностью. Действия маршрутизируются через SNS → PagerDuty / Slack, и — без вариантов — ссылка на runbook идёт в описание аларма, чтобы пейдж, будящий кого-то в 3 ночи, говорил ему, что делать.

// Композитный аларм: пейдж только когда реальный обращённый к пользователю симптом
// подтверждён И мы не в середине деплоя. Один пейдж на первопричину вместо четырёх.
{
  "AlarmName": "checkout-user-pain-page",
  "AlarmRule": "(ALARM(\"checkout-p99-latency\") OR ALARM(\"checkout-error-rate\")) AND NOT ALARM(\"deploy-in-progress\")",
  "AlarmActions": ["arn:aws:sns:us-east-1:123456789012:pagerduty-critical"],
  "AlarmDescription": "Нарушение SLO на чекауте, обращённое к пользователю. Runbook: https://runbooks.internal/checkout-slo"
}

Режим отказа (два способа победить самого себя): аларм с treat-missing-data = notBreaching на критичном сервисе — это молчаливое слепое пятно: в день, когда сервис умрёт и не эмитит метрик, аларм навечно зависнет в INSUFFICIENT_DATA и никогда не запейджит. А некомпозитный CPU-аларм на каждый хост — это машина шума из Hook: он пейджит на каждый деплой, приучает людей его игнорировать, и доверие, которое он сжигает, утягивает за собой настоящие алерты. Решение о маршрутизации «пейдж или тикет» — это вся игра: быстрый прожиг и подтверждённые симптомы → пейджи человека; медленный прожиг и одиночные причины → тикет, который прочитают в понедельник.