Перейти к содержанию

SLOzy — автоматизация SLO


Предыдущая глава описывает ручную настройку SLO-дашборда для одного сервиса. А теперь честный вопрос: сколько у вас сервисов? Десять? Пятьдесят? Сто?

Умножаем на четыре окна burn rate, три панели, Recording Rules для быстрых запросов и алерты разной критичности. Потом всё это в provisioning YAML, чтобы не потерялось при перезапуске Grafana. А теперь представьте, что сервис обновился — изменился лейбл в Prometheus, и половина дашбордов показывает нули.

На пятьдесят сервисов это сломает неделю жизни. Или две.

SLOzy (slozy.ru, slozy.net) решает эту проблему декларативно: вы описываете SLO в YAML — платформа генерирует всё остальное.

Как это работает

Вы пишете конфигурацию SLO:

apiVersion: slozy/v1
kind: SLO
spec:
  service: payment-gateway
  objective: 99.5
  window: 30d
  indicator:
    promql:
      good: sum(rate(http_requests_total{service="payment-gateway",code=~"2.."}[1m]))
      total: sum(rate(http_requests_total{service="payment-gateway"}[1m]))

Это весь конфиг. SLOzy по нему:

  1. Строит запросы SLI для всех окон burn rate.
  2. Генерирует Prometheus Recording Rules — чтобы Grafana не пересчитывала rate(...[30d]) при каждом открытии дашборда. Recording Rule сохраняет результат в новую метрику, и панель читает её мгновенно.
  3. Создаёт provisioning YAML для Grafana — dashboards с multi-window burn rate, stat-панели error budget, алерты с порогами критичности (warning — горим медленно, critical — горим быстро, budget-exhausted — всё, стоп).
  4. Заливает всё в Grafana через API — без мыши, без ручного импорта JSON.

После этого у вас в Grafana появляется папка с именем сервиса, внутри — готовый SLO-дашборд и алерты, подписанные на Recording Rules.

Зачем это SRE

Инструмент не заменяет SLO-практику — он убирает механическую работу. SRE думает о том, какой порог правильный и какие события считать «хорошими». Машина делает provisioning, синхронизацию и обновление.

Допустим, вы изменили SLO с 99,5% на 99,9%. Без автоматизации — идёте в 50 дашбордов, правите пороги в PromQL вручную, пересчитываете burn rate thresholds, обновляете алерты. С SLOzy — одна строчка в YAML, slozy apply, и через минуту всё пересобрано.

Интеграция в CI/CD

Конфигурации SLO лежат в репозитории рядом с кодом сервиса. Разработчик добавил новый эндпоинт — в том же PR добавляет SLO-конфиг. CI пайплайн вызывает slozy validate (проверка синтаксиса и корректности PromQL), затем slozy apply в тестовую Grafana. SLO-дашборд появляется до того, как код вышел в прод.

Команда видит: «Ага, у нового эндпоинта SLO 99% — значит, он не критичный, можно рисковать». Или: «SLO 99,99% — осторожно, это payments».

SLOzy зашивает культуру надёжности в процесс разработки. Не плакаты на стене, не регламенты в вики, которые никто не читает. Просто инструмент, который делает правильное поведение самым лёгким.



Далее: health-calc — калькулятор доступности