SLA, SLO, SLI простыми словами и с примерами / Habr

Большинство инженеров начинают путь с простой задачи - сделать так, чтобы ничего не падало. И в этом нет ничего плохого. Мы ставим мониторинг, настраиваем алерты и радуемся когда всё «зеленое».

Но спустя пару месяцев пользователи начинают жаловаться:

«Поиск выдает результаты через 5 секунд»
«Платежи проходят с задержкой»
«Интерфейс зависает при большом количестве данных»

Идешь смотреть, а метрики в норме, инфраструктура стабильна, но пользователю от этого не легче. И тут проблема в том, что мы не умеем измерять, насколько хорошо она работает с точки зрения опыта конечного пользователя.

И в этой точке важно начинать приходить к пониманию от «горит или нет» к пониманию, как горит. Мониторинг обычно отвечает на вопрос: «жив ли сервис» и даже «на сколько сервису плохо», но не отвечает на вопрос о влиянии этого самого «сервису плохо» на бизнес.

Пример: В одном интернет‑магазине серверы не перегружены, ошибок 500 нет, но продажи упали на 7%. Оказалось, при переходе к оплате страница грузилась по 6–7 секунд и пользователи просто уходили. С точки зрения мониторинга — всё «зелёное». С точки зрения бизнеса — потеря денег.

Тогда возникает вопрос, а что значит «система работает работает хорошо»? Чтобы говорить о качестве, нужно зафиксировать, что вообще считается «хорошим». Для этого инженеры используют три понятия:

SLA (Service Level Agreement) — «обещание» пользователю. Например: «Сервис доступен 99,9% времени».
SLO (Service Level Objective) — цель, к которой стремится команда. Например: «99,95% запросов выполняются за ≤ 200 мс».
SLI (Service Level Indicator) - конкретный измеряемый показатель. Например: “latency P99”, “ошибки 5xx”, “успешные транзакции”.

Пример: API биллинга установил SLO: 99,9% запросов быстрее 150 мс. Однажды latency вырос до 400 мс — не авария, но выход за цель. Виноваты оказались обновления сервиса и после фикса всё вернулось в норму.

Но ведь раз у нас есть цель 99.9, то значит сервис какое то время может сбоить. И тут мы подошли еще к одному термину. Любая система допускает небольшой процент сбоев. Этот процент — бюджет ошибок. Если SLA 99,9%, то за год допустимо примерно 8 часов простоя.

И вот тут важно понять, что бюджет ошибок — это не KPI, а инструмент. Он даёт право на риск. Это возможность для команды использовать бюджет в своих интересах. Бюджет ошибок помогает решать — где стоит рисковать, а где пора стабилизировать.

Примеры: Команда внедряет новый алгоритм рекомендаций. Есть риск, что новая система снизит продажи или перегрузит сервера запросами. Команда видит, что у них есть в бюджете ошибок время на эксперименты и они решаются катить изменения, чтобы проверить новую фичу. Таким образом вместо того чтобы доводить всё до идеала — они могут просто «освоить бюджет» не выходя за рамки бютжета. И если всё прошло гладко, то у них еще есть запас на следующие эксперименты.

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

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

Мы же любим все автоматизировать и поэтому не хотим описывать все выражения руками. И тут нам на помощь приходят генераторы 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 и алерты с множителями согласно Google SRE Book.

Результат работы генератора

---
# Code generated by Sloth (dev): https://github.com/slok/sloth.
# DO NOT EDIT.

groups:
- name: sloth-slo-sli-recordings-myservice-requests-availability
  rules:
  - record: slo:sli_error:ratio_rate5m
    expr: |
      (sum(rate(http_request_duration_seconds_count{job="myservice",code=~"(5..|429)"}[5m])))
      /
      (sum(rate(http_request_duration_seconds_count{job="myservice"}[5m])))
    labels:
      cmd: examplesgen.sh
      owner: myteam
      repo: myorg/myservice
      sloth_id: myservice-requests-availability
      sloth_service: myservice
      sloth_slo: requests-availability
      sloth_window: 5m
      tier: "2"
  - record: slo:sli_error:ratio_rate30m
    expr: |
      (sum(rate(http_request_duration_seconds_count{job="myservice",code=~"(5..|429)"}[30m])))
      /
      (sum(rate(http_request_duration_seconds_count{job="myservice"}[30m])))
    labels:
      cmd: examplesgen.sh
      owner: myteam
      repo: myorg/myservice
      sloth_id: myservice-requests-availability
      sloth_service: myservice
      sloth_slo: requests-availability
      sloth_window: 30m
      tier: "2"
  - record: slo:sli_error:ratio_rate1h
    expr: |
      (sum(rate(http_request_duration_seconds_count{job="myservice",code=~"(5..|429)"}[1h])))
      /
      (sum(rate(http_request_duration_seconds_count{job="myservice"}[1h])))
    labels:
      cmd: examplesgen.sh
      owner: myteam
      repo: myorg/myservice
      sloth_id: myservice-requests-availability
      sloth_service: myservice
      sloth_slo: requests-availability
      sloth_window: 1h
      tier: "2"
  - record: slo:sli_error:ratio_rate2h
    expr: |
      (sum(rate(http_request_duration_seconds_count{job="myservice",code=~"(5..|429)"}[2h])))
      /
      (sum(rate(http_request_duration_seconds_count{job="myservice"}[2h])))
    labels:
      cmd: examplesgen.sh
      owner: myteam
      repo: myorg/myservice
      sloth_id: myservice-requests-availability
      sloth_service: myservice
      sloth_slo: requests-availability
      sloth_window: 2h
      tier: "2"
  - record: slo:sli_error:ratio_rate6h
    expr: |
      (sum(rate(http_request_duration_seconds_count{job="myservice",code=~"(5..|429)"}[6h])))
      /
      (sum(rate(http_request_duration_seconds_count{job="myservice"}[6h])))
    labels:
      cmd: examplesgen.sh
      owner: myteam
      repo: myorg/myservice
      sloth_id: myservice-requests-availability
      sloth_service: myservice
      sloth_slo: requests-availability
      sloth_window: 6h
      tier: "2"
  - record: slo:sli_error:ratio_rate1d
    expr: |
      (sum(rate(http_request_duration_seconds_count{job="myservice",code=~"(5..|429)"}[1d])))
      /
      (sum(rate(http_request_duration_seconds_count{job="myservice"}[1d])))
    labels:
      cmd: examplesgen.sh
      owner: myteam
      repo: myorg/myservice
      sloth_id: myservice-requests-availability
      sloth_service: myservice
      sloth_slo: requests-availability
      sloth_window: 1d
      tier: "2"
  - record: slo:sli_error:ratio_rate3d
    expr: |
      (sum(rate(http_request_duration_seconds_count{job="myservice",code=~"(5..|429)"}[3d])))
      /
      (sum(rate(http_request_duration_seconds_count{job="myservice"}[3d])))
    labels:
      cmd: examplesgen.sh
      owner: myteam
      repo: myorg/myservice
      sloth_id: myservice-requests-availability
      sloth_service: myservice
      sloth_slo: requests-availability
      sloth_window: 3d
      tier: "2"
  - record: slo:sli_error:ratio_rate30d
    expr: |
      sum_over_time(slo:sli_error:ratio_rate5m{sloth_id="myservice-requests-availability", sloth_service="myservice", sloth_slo="requests-availability"}[30d])
      / ignoring (sloth_window)
      count_over_time(slo:sli_error:ratio_rate5m{sloth_id="myservice-requests-availability", sloth_service="myservice", sloth_slo="requests-availability"}[30d])
    labels:
      cmd: examplesgen.sh
      owner: myteam
      repo: myorg/myservice
      sloth_id: myservice-requests-availability
      sloth_service: myservice
      sloth_slo: requests-availability
      sloth_window: 30d
      tier: "2"
- name: sloth-slo-meta-recordings-myservice-requests-availability
  rules:
  - record: slo:objective:ratio
    expr: vector(0.9990000000000001)
    labels:
      cmd: examplesgen.sh
      owner: myteam
      repo: myorg/myservice
      sloth_id: myservice-requests-availability
      sloth_service: myservice
      sloth_slo: requests-availability
      tier: "2"
  - record: slo:error_budget:ratio
    expr: vector(1-0.9990000000000001)
    labels:
      cmd: examplesgen.sh
      owner: myteam
      repo: myorg/myservice
      sloth_id: myservice-requests-availability
      sloth_service: myservice
      sloth_slo: requests-availability
      tier: "2"
  - record: slo:time_period:days
    expr: vector(30)
    labels:
      cmd: examplesgen.sh
      owner: myteam
      repo: myorg/myservice
      sloth_id: myservice-requests-availability
      sloth_service: myservice
      sloth_slo: requests-availability
      tier: "2"
  - record: slo:current_burn_rate:ratio
    expr: |
      slo:sli_error:ratio_rate5m{sloth_id="myservice-requests-availability", sloth_service="myservice", sloth_slo="requests-availability"}
      / on(sloth_id, sloth_slo, sloth_service) group_left
      slo:error_budget:ratio{sloth_id="myservice-requests-availability", sloth_service="myservice", sloth_slo="requests-availability"}
    labels:
      cmd: examplesgen.sh
      owner: myteam
      repo: myorg/myservice
      sloth_id: myservice-requests-availability
      sloth_service: myservice
      sloth_slo: requests-availability
      tier: "2"
  - record: slo:period_burn_rate:ratio
    expr: |
      slo:sli_error:ratio_rate30d{sloth_id="myservice-requests-availability", sloth_service="myservice", sloth_slo="requests-availability"}
      / on(sloth_id, sloth_slo, sloth_service) group_left
      slo:error_budget:ratio{sloth_id="myservice-requests-availability", sloth_service="myservice", sloth_slo="requests-availability"}
    labels:
      cmd: examplesgen.sh
      owner: myteam
      repo: myorg/myservice
      sloth_id: myservice-requests-availability
      sloth_service: myservice
      sloth_slo: requests-availability
      tier: "2"
  - record: slo:period_error_budget_remaining:ratio
    expr: 1 - slo:period_burn_rate:ratio{sloth_id="myservice-requests-availability",
      sloth_service="myservice", sloth_slo="requests-availability"}
    labels:
      cmd: examplesgen.sh
      owner: myteam
      repo: myorg/myservice
      sloth_id: myservice-requests-availability
      sloth_service: myservice
      sloth_slo: requests-availability
      tier: "2"
  - record: sloth_slo_info
    expr: vector(1)
    labels:
      cmd: examplesgen.sh
      owner: myteam
      repo: myorg/myservice
      sloth_id: myservice-requests-availability
      sloth_mode: cli-gen-prom
      sloth_objective: "99.9"
      sloth_service: myservice
      sloth_slo: requests-availability
      sloth_spec: prometheus/v1
      sloth_version: dev
      tier: "2"
- name: sloth-slo-alerts-myservice-requests-availability
  rules:
  - alert: MyServiceHighErrorRate
    expr: |
      (
          max(slo:sli_error:ratio_rate5m{sloth_id="myservice-requests-availability", sloth_service="myservice", sloth_slo="requests-availability"} > (14.4 * 0.0009999999999999432)) without (sloth_window)
          and
          max(slo:sli_error:ratio_rate1h{sloth_id="myservice-requests-availability", sloth_service="myservice", sloth_slo="requests-availability"} > (14.4 * 0.0009999999999999432)) without (sloth_window)
      )
      or
      (
          max(slo:sli_error:ratio_rate30m{sloth_id="myservice-requests-availability", sloth_service="myservice", sloth_slo="requests-availability"} > (6 * 0.0009999999999999432)) without (sloth_window)
          and
          max(slo:sli_error:ratio_rate6h{sloth_id="myservice-requests-availability", sloth_service="myservice", sloth_slo="requests-availability"} > (6 * 0.0009999999999999432)) without (sloth_window)
      )
    labels:
      category: availability
      routing_key: myteam
      severity: pageteam
      sloth_severity: page
    annotations:
      summary: High error rate on 'myservice' requests responses
      title: (page) {{$labels.sloth_service}} {{$labels.sloth_slo}} SLO error budget
        burn rate is too fast.
  - alert: MyServiceHighErrorRate
    expr: |
      (
          max(slo:sli_error:ratio_rate2h{sloth_id="myservice-requests-availability", sloth_service="myservice", sloth_slo="requests-availability"} > (3 * 0.0009999999999999432)) without (sloth_window)
          and
          max(slo:sli_error:ratio_rate1d{sloth_id="myservice-requests-availability", sloth_service="myservice", sloth_slo="requests-availability"} > (3 * 0.0009999999999999432)) without (sloth_window)
      )
      or
      (
          max(slo:sli_error:ratio_rate6h{sloth_id="myservice-requests-availability", sloth_service="myservice", sloth_slo="requests-availability"} > (1 * 0.0009999999999999432)) without (sloth_window)
          and
          max(slo:sli_error:ratio_rate3d{sloth_id="myservice-requests-availability", sloth_service="myservice", sloth_slo="requests-availability"} > (1 * 0.0009999999999999432)) without (sloth_window)
      )
    labels:
      category: availability
      severity: slack
      slack_channel: '#alerts-myteam'
      sloth_severity: ticket
    annotations:
      summary: High error rate on 'myservice' requests responses
      title: (ticket) {{$labels.sloth_service}} {{$labels.sloth_slo}} SLO error budget
        burn rate is too fast

Как видно из результата работы генератора — у нас появился довольно большой yaml, в котором вся грязная работа сделана уже за вас. И самый частый вопрос бывает «а зачем там мультиокна»? Разберем прямо на этом же примере.

Page‑алерт (срочный): сработает, если оба окна превышают порог 14.4× бюджета на 5m + 1h, или 6× бюджета на 30m + 6h. Это ловит резкие и устойчивые всплески (деплой поломал API, лавина 5xx). Короткий «пшик» на 5 минут не пробьёт, потому что нужно подтвердить на длинном окне пары. Ticket‑алерт (фоново): сработает при более мягкой, но длительной деградации — 3× на 2h + 1d или 1× (то есть ровно бюджет) на 6h + 3d. Это про «тихо растущие» проблемы и регрессии качества.

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

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

Таким образом мы пришли к тому, что стабильность — это не когда «ничего не ломается», а когда даже если ломается — понятно почему. Когда у команды есть цифры, на которые можно опереться, и смелость что‑то менять, не боясь что сработают алерты. Вот тогда можно сказать: «да, всё работает — и работает хорошо».

А на этом у меня всё, надеюсь было полезно и мне удалось объяснить зачем это надо «на самом деле». Также буду рад видеть тебя в своем tg‑канале DevOps Brain.