SLO-дашборды¶

SRE — это инженерия надёжности, а не угадайка. И начинается она с простой штуки: обещания.

Что такое SLO и SLI¶

Представьте службу доставки. Вы обещаете клиенту: «Заказ придёт за три дня». Это и есть SLO — Service Level Objective. А теперь вы меряете реальность: из 1000 заказов 970 доехали до двери за трое суток, 30 опоздали. Процент успешных доставок — 97%. Это ваше SLI, Service Level Indicator.

SLI — это то, что вы реально измеряете. SLO — порог, ниже которого вы говорите: «У нас проблемы».

В мире сервисов всё так же. SLI = доля успешных HTTP-запросов (коды 2xx и 3xx от общего числа). SLO = 99,5% за 30 дней. Переступили порог — объявляем инцидент и останавливаем релизы.

Почему не 100%? Потому что 100% стоит как самолёт. Каждая лишняя девятка после 99,9% удваивает стоимость инфраструктуры и замедляет разработку. SLO — это сознательный компромисс между надёжностью и скоростью.

Error budget — ваш запас прочности¶

Если SLO = 99,5%, то допустимый уровень ошибок = 0,5%. Это ваш error budget.

Аналогия: вы даёте курьеру 1000 рублей в месяц на штрафы за опоздания. Одно опоздание — минус 10 рублей. Пока в кошельке есть деньги — всё по плану. Кончились — стоп, никаких новых заказов, пока не разберёмся с логистикой.

Так и с сервисом: пока error budget не исчерпан — катим релизы, экспериментируем, ломаем и чиним. Исчерпан — фризим разработку, все силы на стабилизацию (хаха, очень смешно, ни разу не видел, чтобы это работало в российских компаниях).

Burn rate — скорость сжигания бюджета¶

Если за час вы сожгли 0,1% error budget (при месячном бюджете 0,5%) — это нормально, укладываетесь. Но если за час ушло 2% — это пожар. Вы сожжёте весь бюджет за 15 минут, а не за месяц.

Burn rate показывает, с какой скоростью вы тратите запас прочности. И здесь возникает главная инженерная задача: как заметить и пожар, и тление?

Multi-window burn rate: два окна — две истории¶

Одно окно не работает. Смотрите:

Короткое окно — 1 час. Если за час сожгли 2% error budget — это всплеск ошибок. Но если смотреть только часовое окно, вы получите кучу false positive: кратковременный скачок таймаута базы данных не стоит будить команду в три ночи.

Длинное окно — 30 дней. Если за месяц медленно, по 0,02% в день, утекает бюджет — вы увидите проблему только на 25-й день, когда всё уже плохо. Слишком поздно.

Решение — смотреть в оба окна одновременно:

Часовое окно ловит всплеск: burn rate > 14.4 означает, что за час вы сожгли 2% месячного бюджета. Формула PromQL:

sum(rate(http_requests_total{code=~"5.."}[1h]))
  /
sum(rate(http_requests_total[1h]))
  >
(1 - 0.995) * 14.4

Тридцатидневное окно ловит тление: burn rate > 1 означает, что вы идёте точно по границе исчерпания бюджета. Формула:

sum(rate(http_requests_total{code=~"5.."}[30d]))
  /
sum(rate(http_requests_total[30d]))
  >
(1 - 0.995) * 1

На практике добавляют промежуточные окна — 6 часов, 3 дня — для градации срочности. Четыре окна с разными порогами burn rate дают полную картину: от «посмотри утром» до «вставай прямо сейчас».

Собираем SLO-дашборд в Grafana¶

Панель первая — Error Budget Remaining. Stat-панель с оставшимся процентом бюджета:

1 - (
  sum(rate(http_requests_total{code=~"5.."}[30d]))
    /
  sum(rate(http_requests_total[30d]))
) / (1 - 0.995)

Результат умножаем на 100 — получаем проценты. Thresholds: зелёный > 50%, жёлтый 20–50%, красный < 20%. В красной зоне — time range background заливается красным через grafana panel settings → Thresholds → Color scheme.

Панель вторая — Burn Rate 1 hour. Time series. Показывает мгновенную скорость горения. Тонкая линия — порог 14.4 (alert level). Если график пробил порог — всплеск.

Панель третья — Burn Rate Average Multi Window. Таблица, где каждая строка — окно (1h, 6h, 24h, 30d), столбцы — текущий burn rate и порог. Видно сразу: часовое окно красное, а месячное ещё зелёное — локальная авария, не системная.

Почему это работает¶

SRE не про «сделать сервис идеальным». Это про «знать, когда он перестаёт быть достаточно хорошим». SLO-дашборд — не приборная панель самолёта. Это счётчик в такси: едешь и видишь, сколько ещё можно позволить себе ошибок, прежде чем клиент выйдет и уедет на метро.

Без SLO-дашборда вы тушите пожары наугад. С ним — знаете, какой пожар тушить первым, а какой вообще не пожар, а плановая деградация.

И если у вас 50 микросервисов, то строить под каждый такой дашборд руками — занятие на месяц. Но об этом — следующая глава.

Далее: SLOzy — автоматизация SLO