🔖SLA, SLO и SLI простыми словами - часть 2

5. Как начать измерять качество

1. Определяем критичные сценарии. Например: авторизация, поиск, оплата.
2. Назначаем целевые значения. Например: “95% запросов успешны, время ответа ≤ 300 мс”.
3. Собераем метрики. Prometheus + Grafana отлично подойдут.
4. Визуализирем расход бюджета. Сделайте график: горизонталь - дни, вертикаль - процент стабильности. Если линия ползёт вниз - вы “сжигаете” бюджет.
5. Ну и настроиваем алерты через генератор SLO. Например, sloth или любой другой.

https://sloth.dev - это инструмент, который позволяет описывать SLO декларативно и автоматически генерировать правила для Prometheus и Alertmanager. Вместо того чтобы писать PromQL-выражения руками, вы описываете цели в YAML (пример с официального сайта):

version: "prometheus/v1"
service: "myservice"
labels:
  owner: "myteam"
  repo: "myorg/myservice"
  tier: "2"
slos:
  # We allow failing (5xx and 429) 1 request every 1000 requests (99.9%).
  - name: "requests-availability"
    objective: 99.9
    description: "Common SLO based on availability for HTTP request responses."
    sli:
      events:
        error_query: sum(rate(http_request_duration_seconds_count{job="myservice",code=~"(5..|429)"}[{{.window}}]))
        total_query: sum(rate(http_request_duration_seconds_count{job="myservice"}[{{.window}}]))
    alerting:
      name: MyServiceHighErrorRate
      labels:
        category: "availability"
      annotations:
        # Overwrite default Sloth SLO alert summmary on ticket and page alerts.
        summary: "High error rate on 'myservice' requests responses"
      page_alert:
        labels:
          severity: pageteam
          routing_key: myteam
      ticket_alert:
        labels:
          severity: "slack"
          slack_channel: "#alerts-myteam"

Из этого Sloth сам создаёт нужные PrometheusRule и алерты с множителями согласно https://sre.google/workbook/alerting-on-slos/#6-multiwindow-multi-burn-rate-alerts. SLO становятся кодом, который можно версионировать, ревьюить и катить, интегрировав генератор с CICD процессы.

9. Что в итоге

Тимлид в такой экосистеме уже не “смотрит на алерты”, а управляет балансом между скоростью и надёжностью. Он помогает команде использовать бюджет ошибок осознанно и видеть, как изменения влияют на SLO.

- Мониторинг говорит, жив ли сервис. SLO - как живёт ваш продукт.
- SLO, SLI и SLA делают качество измеримым.
- Бюджет ошибок даёт свободу для экспериментов.
- Sloth и подобные генераторы делают SLO воспроизводимыми, как код.
- Тимлид управляет не метриками, а зрелостью команды.

Заключение

Стабильность - это не когда “ничего не ломается”, а когда даже если ломается - понятно почему. Когда у команды есть цифры, на которые можно опереться, и смелость что-то менять, не боясь зажечь алерт. Вот тогда можно сказать: “да, всё работает - и работает хорошо”.

#observability #slo #sli