От сигналов к надёжности: SLO, ранбуки и постмортемы

Оригинал: From Signals to Reliability: SLOs, Runbooks and Post-Mortems

Все примеры конфигураций, шаблоны и правила оповещений находятся в репозитории kubernetes-observability.

Вы можете построить идеальную наблюдаемость системы. Развернуть OpenTelemetry, добавить телеметрию безопасности, внедрить непрерывное профилирование. Инструментировать каждый сервис. Собирать все метрики, логи и трассировки. Создать красивые информационные дашборды Grafana.

И все равно испытывать трудности во время инцидентов.

Недостающий элемент — не технический. Он организационный. Когда во время инцидентов срабатывают алерты, ваша команда должна мгновенно ответить на четыре вопроса:

1. «Насколько это серьёзно?»
2. «Какие действия нам следует предпринять?»
3. «Кого необходимо привлечь к решению?»
4. «Когда это будет устранено?»

Без целевых показателей уровня обслуживания (Service Level Objectives, SLO) оценка серьезности становится субъективной. Разные инженеры будут по-разному оценивать, является ли 5% ошибок приемлемым или это катастрофа? Без процедур (runbooks) реагирование на инциденты превращается в импровизацию. Каждый инженер руководствуется собственной моделью мышления, что приводит к несогласованности и непоследовательности результатов. Без структурированного анализа последствий (postmortems) после инцидента команды устраняют симптомы, но упускают первопричины, снова и снова натыкаясь на одни и те же проблемы.

Разрыв между наблюдаемостью и надёжностью заключается не в сборе большего количества данных. А в предоставлении командам инструментов для систематического анализа этих данных. SLO определяют понимание того, что значит «работает». Процедуры (runbooks) формализуют коллективные знания об устранении проблем. Постмортемы позволяют организации извлекать уроки из неудач.

В этой статье речь пойдёт о человеческих системах, которые превращают наблюдаемость в надёжность. Вы узнаете, как определять уровни обслуживания SLO, которые влияют на принятие решений, создавать процедуры (runbooks), которые расширяют знания команды, структурировать разбор полётов (postmortems), которые способствует улучшениям, и внедрять эти практики в инженерную культуру без добавления бюрократии.

Почему одной наблюдаемости недостаточно для предотвращения инцидентов

Вы построили наблюдаемость (observability) всего.

Но наблюдаемость не равнозначна надежности.

Рассмотрим платежный сервис, обрабатывающий транзакции. Ваш стек наблюдаемости показывает:

• Скорость запросов: 1200 запросов/сек

• Уровень ошибок: 2.3%

• P99 задержка: 450 мс

• Загрузка CPU: 65%

• Активные подключения к БД: 180

Это хорошо или плохо? Без чётко сформулированных целей вы лишь гадаете. Одни команды начали бы паниковать при 2.3% ошибок. Другие не стали бы будить инженера, пока этот показатель не достигнет 15%. Решение становится политическим, а не системным.

Что еще хуже, когда срабатывают алерты, инженерам приходится импровизировать. Алерт говорит «высокая задержка», но не сообщает вам, следует ли перезапускать поды, масштабироваться горизонтально, проверять базу данных или откатывать последнее развертывание. Каждый инцидент превращается в исследовательский проект.

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

SLO, runbooks и postmortems решают эти проблемы. Они преобразуют наблюдаемость из пассивного сбора данных в активное повышение надежности. Я видел, как команды сокращали свое среднее время до решения (MTTR) на 60% в течение трех месяцев после внедрения этих практик, не потому что они собирали больше данных, а потому что они знали, как действовать на их основе.

Показатели Уровня Обслуживания (Service Level Indicators) определяют то, что действительно важно

Показатели Уровня Обслуживания (SLI) — это конкретные метрики, которые измеряют надежность с точки зрения пользователя. Не внутренние метрики, такие как загрузка CPU или память. Не инфраструктурные метрики, такие как количество подов. А поведение, с которым сталкиваются клиенты, — то, что пользователи реально испытывают.

Четыре золотых сигнала (Four Golden Signals) предоставляют исходную структуру: задержка (как быстро), трафик (какой объем), ошибки (сколько ошибок) и насыщение (насколько заполнены ваши критические ресурсы — CPU, память, пулы потоков/подключений, глубина очереди, диск/сетевой ввод-вывод). Они применимы почти к любому сервису, но вам нужно конкретизировать их для вашей конкретной рабочей нагрузки.

Для REST API вашими SLI могут быть:

• Доступность: процент запросов, возвращающих статускоды 2xx или 3xx

• Задержка: 99-й процентиль времени ответа для успешных запросов

• Пропускная способность: запросов в секунду, которые служба может обработать

Для конвейера данных ваши SLI другие:

• Актуальность: время между созданием данных и их доступностью в хранилище

• Корректность: процент записей, обработанных без ошибок качества данных

• Полнота: процент ожидаемых исходных записей, присутствующих на выходе

Ключевой момент — измерять то, что испытывают пользователи, а не то, что делает инфраструктура. Пользователям не важно, используют ли ваши поды 80% CPU. Им важно, прошла ли их оплата успешно и сколько времени это заняло.

Реализуйте SLI для доступности, используя данные из OpenTelemetry. Если вы задали namespace: traces.spanmetrics, как указано выше, метрики спанов (span-metrics) будут доступны в Prometheus как traces_spanmetrics_*. Если вы используете другое пространство имен, скорректируйте названия метрик соответствующим образом. Пример запроса:

# Availability SLI: percentage of successful requests
sum(rate(traces_spanmetrics_calls_total{
  service_name="checkout-service",
  status_code=~"2..|3.."
}[5m]))
/
sum(rate(traces_spanmetrics_calls_total{
  service_name="checkout-service"
}[5m]))

Для оценки задержки используйте квантили гистограммы из метрик длительности инструментированных запросов. При настройке namespace: traces.spanmetrics гистограмма длительности доступна как traces_spanmetrics_duration_bucket с сопровождающими метриками _sum и _count:

# Latency SLI: 99th percentile response time
histogram_quantile(
  0.99,
  sum by (le) (
    rate(traces_spanmetrics_duration_bucket{
      service_name="checkout-service",
      status_code=~"2.."
    }[5m])
  )
)

Коннектор spanmetrics в OpenTelemetry Collector автоматически генерирует эти метрики из трассировок. Вы инструментируете код один раз и получаете как детализированные трассировки для отладки, так и агрегированные метрики для SLO. Названия метрик зависят от заданного пространства имен коннектора, а точки в Prometheus преобразуются в подчеркивания (например, traces.spanmetrics → traces_spanmetrics).

Пример конфигурации, согласующей используемые ниже имена метрик:

connectors:
  spanmetrics:
    namespace: traces.spanmetrics

service:
  pipelines:
    traces:
      receivers: [otlp]
      exporters: [spanmetrics]
    metrics:
      receivers: [spanmetrics]
      exporters: [prometheusremotewrite]

Не пытайтесь создавать SLI для всего сразу. Начните с 2-3 показателей для ваших наиболее критичных пользовательских сценариев. Для e-commerce-платформы это, вероятно: просмотр товаров, добавление в корзину и оформление заказа. Для каждого сценария определяются SLI доступности и задержки. В итоге всего шесть. Управляемое количество.

Избегайте показушных метрик, маскирующихся под SLI. «Среднее время ответа» -это ужасный SLI, потому что он скрывает выбросы. Один запрос, выполняющийся 30 секунд, в то время как 99 других занимают 100 мс, в среднем даст 400 мс, что выглядит приемлемо, но означает ужасный пользовательский опыт. Вместо этого используйте процентили. P50, P95, P99.

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

Показатели Уровня Обслуживания (SLO) превращают метрики в целевые показатели надежности

groups:
- name: checkout-service-slo
  interval: 30s
  rules:
  # Availability SLI
  - record: sli:availability:ratio_rate5m
    expr: |
      sum(rate(traces_spanmetrics_calls_total{
        service_name="checkout-service",
        status_code=~"2..|3.."
      }[5m]))
      /
      sum(rate(traces_spanmetrics_calls_total{
        service_name="checkout-service"
      }[5m]))      

  # Latency SLI (percentage of requests under threshold)
  - record: sli:latency:ratio_rate5m
    expr: |
      sum(rate(traces_spanmetrics_duration_bucket{
        service_name="checkout-service",
        le="1000"
      }[5m]))
      /
      sum(rate(traces_spanmetrics_duration_count{
        service_name="checkout-service"
      }[5m]))      

# Current error rate vs error budget rate
# If this exceeds 1.0, you're burning budget faster than planned
(1 - sli:availability:ratio_rate5m) / (1 - 0.995)

groups:
- name: checkout-service-slo-alerts
  rules:
  # Fast burn: 14.4x burn rate over 1 hour AND 2 minutes
  - alert: CheckoutServiceErrorBudgetFastBurn
    expr: |
      (1 - sli:availability:ratio_rate5m{service_name="checkout-service"}) / (1 - 0.995) > 14.4
      and
      (1 - sli:availability:ratio_rate5m{service_name="checkout-service"}) / (1 - 0.995) > 14.4 offset 2m      
    for: 2m
    labels:
      severity: critical
      team: payments
    annotations:
      summary: "Checkout service burning error budget at 14.4x rate"
      description: "At current error rate, monthly error budget will be exhausted in {{ $value | humanizeDuration }}. Current availability: {{ $labels.availability }}%"
      runbook_url: "https://runbooks.internal/payments/checkout-error-budget-burn"

  # Slow burn: 6x burn rate over 6 hours
  - alert: CheckoutServiceErrorBudgetSlowBurn
    expr: |
      (1 - avg_over_time(sli:availability:ratio_rate5m{service_name="checkout-service"}[6h])) / (1 - 0.995) > 6      
    for: 15m
    labels:
      severity: warning
      team: payments
    annotations:
      summary: "Checkout service burning error budget at 6x rate"
      description: "Error budget consumption is elevated. Review recent changes."
      runbook_url: "https://runbooks.internal/payments/checkout-error-budget-burn"

# [Service Name] - [Alert Name]

## Summary
One-sentence description of what this alert means and user-facing impact.

## Severity
Critical / Warning / Info

## Diagnosis
1. Check current SLO status: [Grafana dashboard link]
2. Review recent traces: {service_name="checkout-service", status="error"}
3. Correlate with deployments: [ArgoCD/Flux dashboard link]
4. Review metrics: [Grafana dashboard link]

## Mitigation
1. Rollback: `kubectl rollout undo deployment/checkout-service -n production`
2. Scale up: `kubectl scale deployment/checkout-service --replicas=10 -n production`
3. Disable feature: `kubectl set env deployment/checkout-service FEATURE_X=false`

## Escalation
- On-call engineer (15 min) → Service owner → Incident commander → Executive
- Contact: [PagerDuty link]

## Investigation
After mitigation: Check traces, [profiling data](/posts/ebpf-parca-observability/), [audit logs](/posts/kubernetes-security-observability/) and database logs.

annotations:
  summary: "{{ $labels.service_name }} error rate above threshold"
  description: "Current error rate: {{ $value }}%. SLO allows 0.5%."
  runbook_url: '{{ $labels.runbook_url }}'
  dashboard: 'https://grafana.internal/d/service-overview?var-service={{ $labels.service_name }}'
  traces: 'https://grafana.internal/explore?queries=[{"datasource":"tempo","query":"{{ $labels.service_name }}","queryType":"traceql"}]'

# Incident: [Brief description]

**Date**: [Date] | **Duration**: [Duration] | **Severity**: [Critical/High/Medium]  
**Commander**: [Name] | **Responders**: [Names]

## Impact
- Users affected: [Number/Percentage]
- Revenue impact: [Amount if applicable]
- SLO impact: [Error budget consumed]

## Timeline
Key events: Alert fired → Investigation began → Discovery → Mitigation → Recovery → Resolution

## Root Cause
What changed, why it caused the problem, why safeguards didn't prevent it.

## What Went Well / Poorly
**Well**: Fast detection, effective collaboration, good tooling use  
**Poorly**: Missing alerts, unclear ownership, inadequate testing, manual processes

## Action Items
| Action | Owner | Priority | Due Date | Status |
|--------|-------|----------|----------|--------|
| [Specific improvement] | [Team] | P0-P2 | [Date] | [Status] |

**P0**: Prevents similar incidents | **P1**: Improves detection/mitigation | **P2**: Nice to have

## Lessons Learned
System-level insights, team practice changes, observability gaps identified.