SLOzy — платформа управления SLO¶
В этой книге мы много говорили про SLO, error budget, burn rate и SLO как код. Вы, возможно, задавались вопросом: «Звучит красиво, но как это внедрить на практике? Неужели нужно писать YAML вручную, считать burn rate в голове и обновлять дашборды руками?»
SLOzy — платформа, которая превращает теорию SLO в ежедневную практику. Она берёт рутину (создание манифестов, расчёт burn rate, генерация дашбордов, алертинг) и автоматизирует её, освобождая инженеров для инженерной работы, а не перекладывания YAML-файлов. Точно так же, как мы говорили в главе «Toil: враг номер один» — ручной труд нужно уничтожать.
Проблема, которую решает SLOzy¶
Внедрение SLO в компании обычно выглядит так:
- Прочитали книгу (эту или любую другую). Загорелись. Продуктологи всем наобещали.
- Попробовали написать SLO вручную. Получилось криво. PromQL-запросы сложные, burn rate — тёмный лес.
- Потратили неделю на настройку дашборда в Grafana. Ещё неделю — на алерты в Prometheus и Alertmanager.
- Через месяц обнаружили, что никто не смотрит на дашборд, алерты кричат в пустоту, а SLO — просто число на бумаге.
- Продуктологи ругаются.
SLOzy закрывает разрыв между «мы знаем, что такое SLO» и «у нас работает система управления SLO».
Что умеет¶
Создание SLO через генератор¶
Вместо написания YAML вручную — пошаговый генератор. Выбираете тип метрики (availability, latency, throughput), задаёте целевое значение (99.9%), указываете PromQL-запрос, выбираете пороги burn rate — и SLO готов. Генерируются не только OpenSLO-манифест, но и готовые конфигурации: Prometheus alert rules, Alertmanager config, Grafana-дашборды (подробнее про формат OpenSLO — в главе OpenSLO). Всё это скачивается одним ZIP-архивом и кладётся в ваш репозиторий.
Мониторинг SLO в реальном времени¶
Дашборды обновляются автоматически. Вы видите текущий burn rate, остаток error budget, статус каждого SLO — живьём, без ручного обновления страницы. Если у вас 20 сервисов и по 3 SLO у каждого — уследить за ними вручную невозможно. SLOzy делает это за вас.
GitOps-интеграция¶
SLO — это код (см. главу «SLO как код»). SLOzy синхронизируется с вашим GitHub-репозиторием: каждое изменение SLO автоматически коммитится как YAML-файл. А когда кто-то меняет YAML в репозитории — SLOzy валидирует его и подтягивает изменения. Это двусторонняя синхронизация, которая закрывает классическую проблему «у нас SLO в YAML, но никто их не обновляет».
Алертинг на основе burn rate¶
Мы обсуждали burn rate в главе «Принципы качественного алертинга». SLOzy считает burn rate автоматически и шлёт уведомления, когда бюджет ошибок сжигается слишком быстро. Поддерживаются email, Slack, Telegram, Mattermost и вообще любой webhook. Правила алертинга настраиваются визуально — те самые пресеты 2x/1h, 6x/6h, 10x/5m, о которых мы говорили.
Команды и RBAC¶
В реальной компании SLO — это не дело одного инженера. Продакт согласует цели, SRE настраивает метрики, разработчики смотрят на дашборды. SLOzy поддерживает организации, команды и роли (Admin, Editor, Viewer). Каждый участник видит только свои SLO. Audit log фиксирует все изменения — кто, когда и зачем поменял целевое значение.
Версионирование¶
Каждое изменение SLO сохраняется как отдельная версия. Можно посмотреть, каким было SLO месяц назад, сравнить diff и при необходимости откатиться. Это тот же подход, что в Git, но без необходимости знать команды git diff — всё через веб-интерфейс.
Архитектура (для тех, кому интересно)¶
SLOzy — self-hosted продукт. Разворачивается на вашей инфраструктуре: Docker Compose для небольших команд, Kubernetes — для продакшена.
Компоненты:
- slozy-web — API-сервер на Go. Отвечает за CRUD SLO, авторизацию, GitOps, дашборды.
- slozy-ingestor — воркер, который раз в минуту опрашивает Prometheus, считает burn rate и error budget, обновляет кэш и шлёт алерты.
- PostgreSQL — основная база: SLO, пользователи, команды, метрики, audit log.
- Redis — кэш для снижения нагрузки на Prometheus (до 60–80% запросов отдаются из кэша).
- Nginx — reverse proxy, SSL-терминация, rate limiting.
Данные не покидают вашу инфраструктуру. SLOzy не шлёт телеметрию наружу (опциональный phone-home для проверки лицензии — и только если вы его включите).
Как это соотносится с тем, что мы обсуждали¶
| Концепция из книги | Как это в SLOzy |
|---|---|
| SLI / SLO / SLA (глава «SLA vs SLO vs SLI») | Мастер создания SLO с выбором типа метрики |
| Error Budget (глава «Error Budget») | Автоматический расчёт и визуализация остатка |
| Burn rate (глава «Принципы алертинга») | Автоматический расчёт с пресетами алертов |
| SLO как код (глава «SLO как код») | GitOps-синхронизация с GitHub |
| Дашборды (глава «Создание дашбордов для SLO») | Автоматическая генерация Grafana-дашбордов |
| Рутину — уничтожать (глава «Toil») | Генератор вместо ручного написания YAML, автогенерация конфигов |
| Командная работа (глава «Единая команда») | Организации, команды, RBAC, audit log |
Для кого¶
- SRE-команды, которые устали настраивать SLO вручную и хотят быстро внедрить практику.
- Platform-инженеры, которым нужна «кнопка создания SLO» для всех сервисов в компании.
- Tech lead'ы, которым важно, чтобы команда смотрела на SLO, а не на CPU-графики.
- Продакт-менеджеры, которые наконец-то хотят понять, что происходит с надёжностью, без погружения в PromQL.
Try before you buy¶
SLOzy работает 14 дней в триал-режиме (все функции, до 25 SLO). Развёртывание через Docker Compose занимает 15 минут — ровно столько, сколько нужно, чтобы склонировать репозиторий, скопировать .env.example в .env и запустить docker-compose up -d.
Подробнее — на slozy.net и в документации.