SLO, SRE-практики и Postmortem

Зачем знать на Middle 3: На Senior-уровне инженер не просто пишет код — он отвечает за надёжность сервиса в проде. Это значит уметь: определить SLI («что мы измеряем»), назначить SLO («какой target»), отслеживать error budget, корректно реагировать на инцидент, провести blameless postmortem. Без формальных SLO команда либо «оптимизирует latency бесконечно», либо «терпит до взрыва». Google SRE Book — это де-факто стандарт; в 2026 году к нему добавились OpenSLO, sloth, Pyrra, multi-window multi-burn-rate alerts. От Go-инженера Middle 3 ожидают, что он сам пишет PromQL для SLO, конфигурирует burn-rate alerts, и держит свою часть on-call.

Содержание

1. Концепция: SLI / SLO / SLA / Error Budget
2. Production-deep dive: methods, tools, alerts, runbooks, postmortems
3. Gotchas (10+)
4. Real cases: Google, Honeycomb, GitLab
5. Вопросы (25+)
6. Practice
7. Источники

---

1. Концепция

1.1 SLI, SLO, SLA

                      Customer perspective
                              │
                              ▼
                          ┌───────┐
                          │  SLA  │  контрактное обязательство (с штрафами)
                          └───┬───┘   "99.5% per month or 10% refund"
                              │
                              ▼
                          ┌───────┐
                          │  SLO  │  внутренний target (более строгий)
                          └───┬───┘   "99.9% requests succeed"
                              │
                              ▼
                          ┌───────┐
                          │  SLI  │  measurement
                          └───────┘   "% requests with status<500 in 5min window"

• SLI (Service Level Indicator) — измеримый показатель качества (latency, availability, error rate).
• SLO (Service Level Objective) — внутренний target по SLI (например, 99.9% за 28 дней).
• SLA (Service Level Agreement) — контракт с клиентом (часто 99.5%, с штрафами за невыполнение). Обычно SLA < SLO (есть запас).

1.2 Error Budget

Error budget = 100% – SLO
SLO = 99.9% → error budget = 0.1%
За 30 дней (43200 минут): 0.1% × 43200 = 43.2 минуты «можно лежать»

Идея Google SRE: error budget — это бюджет на нестабильность. Если потратили — нельзя делать рискованные релизы. Если осталось — можно экспериментировать.

   ┌──────────────────────────────────────────┐
   │ Error budget at month start: 43.2 min    │
   │ Spent: 12.7 min                          │
   │ Remaining: 30.5 min (70%)                │
   │                                          │
   │ ████████████████░░░░░░░░░  (consumed)    │
   │                                          │
   │ Decision: continue feature work          │
   └──────────────────────────────────────────┘

   vs.

   ┌──────────────────────────────────────────┐
   │ Error budget at month start: 43.2 min    │
   │ Spent: 41.0 min                          │
   │ Remaining: 2.2 min (5%)                  │
   │                                          │
   │ ████████████████████████░  (consumed)    │
   │                                          │
   │ Decision: feature freeze, reliability    │
   │           work only                      │
   └──────────────────────────────────────────┘

1.3 Типы SLI

1. Availability — successful_requests / total_requests.
2. Latency — % requests faster than threshold. Часто: % requests < 200ms.
3. Throughput — bytes_processed / time.
4. Quality — % degraded responses (fallback вместо нормального ответа).
5. Freshness (для batch / pipelines) — now() - last_successful_run.
6. Correctness — % requests с корректным результатом.
7. Coverage — % успешно обработанных items в batch.

1.4 The Four Golden Signals (Google)

1. Latency — время на request.
2. Traffic — RPS.
3. Errors — error rate.
4. Saturation — насколько загружен ресурс (CPU, memory, queue depth).

1.5 RED method (Weaveworks)

Для request-driven сервисов:

• Rate (RPS),
• Errors (error rate),
• Duration (latency P50/P95/P99).

1.6 USE method (Brendan Gregg)

Для ресурсов (CPU, disk, network):

• Utilization (% busy),
• Saturation (queue depth),
• Errors (error count).

---

2. Production-deep dive

2.1 Определение SLO

Хороший SLO — user-centric, achievable, specific, measurable:

Признак	Плохой SLO	Хороший SLO
User-centric	”CPU < 80%"	"99.9% запросов checkout успешны в течение 30 дней”
Specific	”Быстро"	"P95 latency < 300ms”
Achievable	”100% availability"	"99.95% за 28-дневное rolling window”
Measurable	”Хорошее UX”	sum(rate(http_status{code!~"5.."}[5m])) / sum(rate(...))

2.2 Multi-window Multi-burn-rate alerts

Стандартный подход Google SRE для критичных алертов:

Burn rate = (consumed budget / time) / (allowed budget / total time)

Например, при SLO 99.9% за 30 дней, error budget = 0.1% = 43.2 минуты. Если за 1 час сгорело 6.5 минут — burn rate = (6.5/1h) / (43.2/30*24) ≈ 108x — катастрофа.

Альерт-конфигурация (популярная схема):

Window	Burn rate	Triggers (consumed of budget)	Severity
1h + 5m	14.4x	2% за 1h	Page!
6h + 30m	6x	5% за 6h	Page
24h + 2h	3x	10% за 24h	Ticket
3d + 6h	1x	10% за 3d	Ticket

Логика: коротко-окошный alert ловит «горим прямо сейчас», длинно-окошный ловит «горим медленно но устойчиво». Двойное окно (5m + 1h) уменьшает false-positive.

PromQL пример:

(
  sum(rate(http_requests_total{code=~"5.."}[5m]))
  /
  sum(rate(http_requests_total[5m]))
) > (14.4 * 0.001)
and
(
  sum(rate(http_requests_total{code=~"5.."}[1h]))
  /
  sum(rate(http_requests_total[1h]))
) > (14.4 * 0.001)

2.3 Инструменты

sloth

sloth — popular SLO generator. Описываете SLO в YAML, sloth генерит Prometheus rules (recording + alerting):

version: prometheus/v1
service: checkout
labels:
  team: payments
slos:
  - name: requests-availability
    objective: 99.9
    sli:
      events:
        error_query: sum(rate(http_requests_total{job="checkout",code=~"5.."}[{{.window}}]))
        total_query: sum(rate(http_requests_total{job="checkout"}[{{.window}}]))
    alerting:
      name: CheckoutHighErrorRate
      page_alert:
        labels: { severity: page }
      ticket_alert:
        labels: { severity: ticket }

sloth generate → готовые PrometheusRule с recording rules для каждого окна и multi-burn-rate alerts.

Pyrra

Pyrra — альтернатива sloth, как Kubernetes operator. CRD ServiceLevelObjective. UI с графиками burn rate.

OpenSLO

OpenSLO — vendor-neutral спецификация формата SLO. Чтобы можно было переключаться между sloth, Pyrra, Nobl9 без переписывания.

apiVersion: openslo/v1
kind: SLO
metadata: { name: checkout-availability }
spec:
  service: checkout
  indicator:
    metadata: { name: availability }
    spec:
      ratioMetric:
        good:  { metricSource: { type: prometheus, spec: { query: "..." } } }
        total: { metricSource: { type: prometheus, spec: { query: "..." } } }
  objectives:
    - target: 0.999
  timeWindow:
    - duration: 30d
      isRolling: true

Nobl9

Commercial SaaS, full-featured: SLO, error budget, reports, integrations.

2.4 Error Budget Policy

Документ, который команда подписывает заранее. Пример:

1. Если за последние 30 дней потратили > 100% бюджета:
   - feature work заморожен (только bugfix и reliability)
   - все commits проходят через 2-х reviewers
   - on-call rotation удваивается

2. Если потратили > 50%:
   - canary releases на 5% → 25% → 100% по 24 часа
   - chaos engineering exercises приостановлены

3. Если потратили < 25%:
   - можно делать рискованные эксперименты
   - chaos drills поощряются

4. Действия по предотвращению накопления:
   - Pre-mortem за неделю до больших релизов
   - Postmortem обязателен после любого SEV1/SEV2

2.5 Постмортемы (Blameless Postmortem)

Шаблон Google SRE:

# Postmortem: <inc name>

**Date**: 2026-05-15
**Authors**: Alice, Bob
**Status**: Final
**Severity**: SEV2

## Summary
1-2 предложения о том, что случилось.

## Impact
- 87% checkout requests failed for 14 minutes
- Estimated revenue loss: $42k
- Affected users: 18k EU
- Error budget consumed: 32%

## Timeline (UTC)
- 09:14 — deploy v1.4.2 to prod (rolling, 10% canary)
- 09:17 — error rate spike on canary; auto-rollback NOT triggered (alert misconfigured)
- 09:21 — canary promoted to 100% (deploy pipeline does not check error rate after 5 min)
- 09:24 — first user reports via Twitter
- 09:26 — on-call paged (5m delay due to alert threshold)
- 09:30 — incident commander declared SEV2
- 09:34 — root cause identified (regression in payment SDK call)
- 09:38 — rollback initiated
- 09:42 — traffic recovered

## Root Cause
v1.4.2 enabled a new HTTP timeout in payment-sdk
(50ms → 5ms typo). Critical path call to payment gateway
exceeded 5ms in 87% requests, causing cascading failures.

## What went well
- Rollback completed in 4 minutes
- Communicator team posted Twitter update at 09:32

## What went wrong
- Canary auto-rollback не сработал (alert misconfigured)
- Deploy не проверял error budget burn rate
- Code review не поймал typo
- Тесты не покрывали timeout regression

## Action Items
| #  | Title                                                   | Owner | Due        | Severity |
|----|---------------------------------------------------------|-------|------------|----------|
| 1  | Fix canary auto-rollback alert                          | Alice | 2026-05-20 | P0       |
| 2  | Add error budget burn rate check to deploy pipeline     | Bob   | 2026-05-30 | P0       |
| 3  | Add integration test for payment-sdk timeout regression | Carol | 2026-06-01 | P1       |
| 4  | Document timeout values in payment-sdk README           | Carol | 2026-05-25 | P2       |
| 5  | Run game day: simulate payment-gateway latency spike    | Dan   | 2026-06-15 | P2       |

## Lessons Learned
1. Single-source-of-truth для critical timeouts (constant file)
2. Canary needs both error rate AND latency gates
3. Twitter monitoring as early-warning signal

Ключевое: blameless — фокус на системе, не на людях. «Alice deployed a typo» → «Code review process didn’t catch the regression; we improve the system to make this kind of typo impossible».

2.6 Incident Management

Severity Levels

SEV	Описание	Response
1	Полный outage / data loss / security breach	All-hands, 24/7, page execs
2	Major degradation (>50% users)	All-hands, page on-call
3	Limited degradation	On-call business hours
4	Minor (affects few users)	Triage in business hours
5	Informational / non-impacting	Issue tracker

Roles

• Incident Commander (IC) — координатор, принимает решения, делегирует. Не выполняет техническую работу.
• Communicator — сообщает в Slack, Twitter, status page, customer-support.
• Operations (Ops Lead) — техническая работа (debug, rollback, mitigation).
• Scribe — пишет timeline в realtime для postmortem’а.

Playbooks (Runbooks)

# Runbook: checkout-api 5xx spike

## Pre-checks (parallel)
1. Check deploy: was there a deploy in last 15 min?
   `kubectl rollout history deploy/checkout-api`
2. Check downstream: payment-gateway status
   `curl http://payment-gateway-status/health`
3. Check infrastructure: node status, network errors
   Grafana dashboard "infra-overview"

## If recent deploy
   `kubectl rollout undo deploy/checkout-api`
   Wait 2 min, check error rate.

## If payment-gateway issue
   Enable circuit breaker: `kubectl annotate ...`
   Show stale data fallback (graceful degradation)

## If infra
   Page #infra channel
   Drain affected nodes: `kubectl drain node-X`

2.7 On-call Rotation

• Cycle — обычно 1 неделя.
• Coverage — 24/7 для критичных сервисов.
• Tiers — primary, secondary, tertiary (escalation).
• Hand-off — Monday morning sync: open incidents, recent changes, hot areas.
• Pager Fatigue — мониторинг паге-time, false positives. Если on-call просыпается > 2x за ночь без real issue — fix alerts.

В 2026 крупные компании ставят SLO на on-call опыт: «среднее < 1 page/неделю», «нет ночных pages для не-SEV1/2». PagerDuty, Opsgenie, Grafana OnCall — типичные tools.

2.8 Alert design

Хороший alert:

• Actionable — есть runbook, что делать.
• Symptom-based — алерт на симптом (users affected), а не на cause (CPU=100% — может быть OK).
• Multi-window — burn rate.
• Доступен через mute, snooze, ack.

Плохой alert:

• “Disk > 80%” без runbook.
• “Hourly cron failed” — но никто не знает, что делать.
• “CPU > 80%” — это нормально на peak.

2.9 SLO-driven development

1. Spec → SLI/SLO.
2. Implementation.
3. CI gates: смотрит historic burn rate, не дает деплой если burn > X.
4. Production: alerts + dashboards.
5. Quarterly: review SLO, что менять.

2.10 Practical PromQL recipes

Availability SLI

# Good events: успешные ответы (status < 500)
sum by (service) (rate(http_requests_total{code!~"5.."}[5m]))

# Total events: все ответы
sum by (service) (rate(http_requests_total[5m]))

# Availability ratio за 28 дней (rolling window)
1 - (
  sum by (service) (increase(http_requests_total{code=~"5.."}[28d]))
  /
  sum by (service) (increase(http_requests_total[28d]))
)

Latency SLI (% requests < 300ms)

# Histogram approach (точный)
sum by (service) (rate(http_request_duration_seconds_bucket{le="0.3"}[5m]))
/
sum by (service) (rate(http_request_duration_seconds_count[5m]))

# Quantile approach
histogram_quantile(0.95, sum by (le, service) (rate(http_request_duration_seconds_bucket[5m])))

Error budget remaining

# Сколько 5xx за окно
sum(increase(http_requests_total{code=~"5.."}[28d]))
# Сколько всего
sum(increase(http_requests_total[28d]))
# SLO 99.9% → бюджет 0.001
# Remaining (нормализованный, 0..1)
1 - (
  sum(increase(http_requests_total{code=~"5.."}[28d]))
  /
  (sum(increase(http_requests_total[28d])) * 0.001)
)

Burn rate (нормализованный)

# burn = (actual error rate) / (allowed error rate)
(
  sum(rate(http_requests_total{code=~"5.."}[1h]))
  /
  sum(rate(http_requests_total[1h]))
)
/ 0.001

Значение >= 14.4 → fast burn alert.

2.11 Recording rules (масштабирование Prometheus)

Сложные SLO-запросы тяжёлые. Сохраняем промежуточные значения:

groups:
  - name: slo:checkout
    interval: 30s
    rules:
      - record: slo:checkout:availability:5m
        expr: |
          sum(rate(http_requests_total{job="checkout", code!~"5.."}[5m]))
          /
          sum(rate(http_requests_total{job="checkout"}[5m]))

      - record: slo:checkout:burn_rate:1h
        expr: |
          (1 - slo:checkout:availability:5m) / 0.001

      - alert: CheckoutFastBurn
        expr: |
          slo:checkout:burn_rate:1h > 14.4
          and
          slo:checkout:burn_rate:5m > 14.4
        for: 2m
        labels: { severity: page }
        annotations:
          summary: "Checkout burning error budget fast (14.4x)"
          runbook: "https://wiki/runbooks/checkout"

2.12 Tracking SLO compliance over time

Помимо текущего availability, важно видеть тренд:

   Grafana dashboard: SLO compliance

   ┌────────────────────────────────────────────────┐
   │ checkout-api availability (rolling 28d)        │
   │                                                │
   │ 99.99% ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─    │
   │ 99.95% ────────────●───────────●─────────●    │
   │ 99.90% ─SLO─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─   │
   │ 99.85% ───────────────────────────────────    │
   │       Jan  Feb  Mar  Apr  May  Jun  Jul       │
   └────────────────────────────────────────────────┘

   ●─── ниже SLO ─── надо разбираться

2.13 Quarterly SLO review

Каждый квартал:

1. Достигли ли SLO? Если все 4 квартала — да, и burn rate низкий — повысить SLO (улучшаем customer experience).
2. Не достигли систематически? Понизить SLO до реалистичного уровня или провести reliability sprint.
3. Метрики устарели? Пользовательский путь поменялся (новая feature), может пора менять SLI.
4. Алерты шумят? Тюнить thresholds, добавлять deduplication.

2.14 Reliability culture

SRE — это не только tools, это культура:

• Toil reduction: повторяющиеся ручные операции → автоматизируем. Toil budget ≤ 50% времени.
• Embedded SREs: SRE рядом с product teams, не в отдельной башне.
• Production readiness review (PRR): новые сервисы проходят ревью перед запуском (SLO, runbook, alerts, dashboards, rollback plan).
• Documentation: runbooks, architecture diagrams, RCA — обязательная часть delivery.
• Learn from failure: monthly «failure friday», читаем postmortems других компаний (Google, GitLab, AWS).

2.15 Production Readiness Review (PRR)

PRR — checklist’обзор сервиса перед запуском в production. Включает:

## SLO
- [ ] SLI определён (PromQL формула)
- [ ] SLO target согласован с product/business
- [ ] Error budget policy документирована

## Alerts
- [ ] Burn-rate alerts настроены (fast + slow)
- [ ] Каждый alert имеет runbook
- [ ] On-call rotation назначен

## Dashboards
- [ ] Service-level dashboard (RED metrics)
- [ ] Dependency dashboard
- [ ] Resource dashboard (USE)

## Logging
- [ ] Structured logs (JSON / OTel)
- [ ] trace_id в каждой записи
- [ ] No PII в логах (audit)

## Tracing
- [ ] OTel instrumented
- [ ] All RPC paths имеют spans
- [ ] Sampling rate согласован с volume

## Resilience
- [ ] Timeouts everywhere (нет infinite-blocking calls)
- [ ] Circuit breakers на downstream'ы
- [ ] Rate limiting на ingress
- [ ] Graceful degradation hooks

## Operations
- [ ] Health endpoints (/healthz, /readyz)
- [ ] Graceful shutdown (SIGTERM → drain → exit)
- [ ] HPA + PDB сконфигурированы
- [ ] Resource requests/limits заданы

## Deploy
- [ ] CI/CD автоматизирован
- [ ] Canary / blue-green / rolling
- [ ] Rollback < 5 минут

## Disaster Recovery
- [ ] Backup стратегия для state
- [ ] RTO/RPO документированы
- [ ] DR drill проведён

Без PRR-зелёного света сервис в продакшен не запускается.

2.16 Toil tracking

Toil — повторяющаяся, ручная, автоматизируемая работа, которая не растёт по value по мере роста сервиса. Примеры:

• Ручной restart сервиса при OOM.
• Создание JIRA tickets для каждого alert’а.
• Копирование dashboards для новой команды.
• Reset password для сотрудников.

Google рекомендует: toil ≤ 50% of SRE time. Если выше — заморозить feature work, автоматизировать.

Способ tracking — простой счётчик в Slack/Linear: «эту неделю я провёл 12 часов в toil». Раз в квартал — анализ, что автоматизировать.

2.17 Customer-facing SLOs (status page)

Внешний SLO ≠ внутренний. Внешний публикуется на status page (status.example.com):

• Прозрачный, понятный пользователю.
• Иногда даже более строгий, чем внутренний (если есть SLA с штрафами).
• Updates вручную или auto (StatusPage.io, Atlassian StatusPage, instatus, OneUptime).

Хороший status page включает:

• Current status (operational / degraded / outage).
• Historical incidents.
• Subscription (email/SMS/webhook).
• Component-level breakdown.

---

3. Gotchas

Gotcha 1: ⚠️ “99.9% доступности” без определения «доступности»

Что считается успехом — status < 500? status < 400? А timeouts? А partial responses? Без формального SLI спор бесконечен. Всегда определяйте SLI на уровне промкуэри.

Gotcha 2: ⚠️ Слишком высокий SLO

99.999% (пять девяток) = 5 минут в год. Если бизнес-метрика не требует — это деньги на ветер. У 90% SaaS реальная потребность 99.9%-99.95%.

Gotcha 3: ⚠️ Calendar window vs Rolling window

«99.9% в месяце» — что значит? Calendar (1 января — 1 февраля)? Rolling (последние 30 дней)? Calendar легче читать, но в начале месяца «budget reset» — соблазн потратить впустую. Rolling — текущее состояние. Большинство практик идёт к rolling 28 дней.

Gotcha 4: ⚠️ Burn rate alerts ловят бурю, но не штиль

Если сервис лежит 60 минут — burn alert сработает. Если сервис «дёргает» по 10s каждые 10 минут — totally burned за день, но burn rate за час малый. Используйте multi-window: длинно-окошный 24h ловит этот случай.

Gotcha 5: ⚠️ Метрики на стороне клиента vs сервера

«% successful requests» от сервера может говорить 99.9%, но клиенты не подключились вовсе (network outage, DNS). Включайте synthetic monitoring (Pingdom, Datadog Synthetics, blackbox-exporter) для внешнего SLI.

Gotcha 6: ⚠️ Composite SLO неточен

Если сервис зависит от 5 microservices, каждый 99.9% — общая availability ≤ 99.5%. Если SLO requires 99.9% — нужны каждый ≥ 99.99%. Не подставляйте «99.9% для всех» — посчитайте.

Gotcha 7: ⚠️ Postmortem без action items

Documents без owner, due, и трекинга превращаются в кладбище. Каждый action item — Jira ticket, owner, deadline. Quarterly review.

Gotcha 8: ⚠️ Blame culture

«Кто это сломал?» убивает блеймлесс. Замените на «Что в системе позволило это случиться?». Если кто-то deleted prod DB — это плохой UX (нет confirmations, нет permissions); человек сделал, что система ему разрешила.

Gotcha 9: ⚠️ Severity inflation

«Всё SEV2!» — теряем сигнал. Defining объективные критерии (например: SEV1 — > 50% requests failing > 5 min) помогает.

Gotcha 10: ⚠️ Алерты на partial outage

«5xx > 5%» на cluster — но один namespace показывает 90% errors. Aggregate alerts маскируют. Группируйте по namespace, service.

Gotcha 11: ⚠️ Latency в среднем — обман

Среднее latency ≠ user-experienced latency. P50/P95/P99 — стандарт. P99.9 для критичных сервисов.

Gotcha 12: ⚠️ Историческое сравнение

«Сегодня P95 = 300ms» — это плохо или нормально? Сравнивайте с прошлой неделей в то же время. Anomaly detection лучше, чем абсолютные пороги.

---

4. Real cases

4.1 Google

Google SRE Book — основа дисциплины. В Google каждый сервис имеет SLO, error budget policy. Если services идёт мимо SLO 2 квартала — feature freeze, prod-fixing forced.

4.2 Honeycomb

Honeycomb (observability vendor) — pioneer высоко-кардинальной observability и burn-rate alerting. Их blog — учебник про SLO и SRE.

4.3 GitLab

GitLab open-source’нул свой slo-monitoring и handbook. Каждый сервис в GitLab.com имеет SLO с public dashboard. Их error budget policy.

4.4 Российская финтех

Реальная кейс (анонимно). Кардинальные правила:

• SEV1 = page CEO в 03:00.
• After-incident review обязательно в течение 5 рабочих дней.
• Postmortem публичный (внутри компании).
• Action items с deadline в Jira; неисполнение — повторный postmortem. В первый год — 18 SEV1; через два года — 2 SEV1.

4.5 Большой e-commerce: error budget freezes

Команда checkout сожгла 100% budget на 12-й день. Feature work заморозили на 2 недели. Команда снизила timeouts, исправила retry storms, добавила circuit breakers. Следующий месяц — 30% budget. Уроки: error budget policy реально работает.

---

5. Вопросы

1. Что такое SLI, SLO, SLA — и в чём отличия?
2. Что такое error budget и как он считается?
3. Что такое The Four Golden Signals?
4. Чем RED method отличается от USE method?
5. Какие типы SLI бывают (availability, latency, …)?
6. Чем calendar window отличается от rolling window?
7. Что такое burn rate?
8. Что такое multi-window multi-burn-rate alert?
9. Какие популярные комбинации windows и burn rates?
10. Что такое sloth и какие правила он генерирует?
11. Чем Pyrra отличается от sloth?
12. Что такое OpenSLO?
13. Чем Nobl9 отличается от open-source?
14. Что такое Error Budget Policy?
15. Что такое blameless postmortem?
16. Перечислите ключевые секции postmortem’а.
17. Что такое Incident Commander и какие у него обязанности?
18. Что такое Communicator, Ops Lead, Scribe?
19. Какие SEV-уровни обычно используют?
20. Что такое runbook (playbook)?
21. Что такое pager fatigue и как с ним бороться?
22. Чем «symptom-based» alert отличается от «cause-based»?
23. Зачем нужен synthetic monitoring помимо server-side метрик?
24. Как считать composite SLO (несколько зависимых сервисов)?
25. Что такое action items в postmortem и как их трекать?
26. Как организовать on-call rotation (cycle, hand-off, escalation)?
27. Какие риски ставить SLO 99.999%?
28. Что такое pre-mortem?
29. Как проверять error budget в CI/CD pipeline?
30. Что такое SLO-driven development?

---

6. Practice

1. Определите SLI/SLO. Для существующего HTTP-сервиса напишите формальный SLI на PromQL (availability + latency P95).
2. sloth manifest. Напишите sloth YAML, сгенерируйте PrometheusRule.
3. Burn-rate alerts. Сконфигурируйте multi-window multi-burn-rate alerts в Prometheus.
4. Error budget dashboard. Сделайте Grafana dashboard, показывающий: total budget, consumed, remaining, projected exhaustion.
5. Synthetic monitoring. Поднимите blackbox-exporter, добавьте external check.
6. Postmortem template. Создайте Markdown template, который команда будет использовать.
7. Симуляция инцидента. Симулируйте 5xx spike (chaos), проведите имитационный инцидент: IC, Communicator, Ops Lead.
8. Action items tracking. Свяжите postmortem с Jira/Linear/GitHub Issues, добавьте due dates.
9. Error budget policy. Напишите policy для своей команды.
10. Quarterly SLO review. Проведите ретроспективу: SLO достигли? пересматриваем?

---

7. Источники

1. Google SRE Book — основа.
2. Google SRE Workbook — практические рекомендации.
3. Implementing SLOs (Google).
4. Alerting on SLOs (Google) — multi-window multi-burn-rate.
5. sloth docs.
6. Pyrra.
7. OpenSLO spec.
8. Honeycomb: Honey, I shrunk the burn.
9. “The Site Reliability Workbook” — O’Reilly.
10. “Seeking SRE” (David N. Blank-Edelman, ed.) — O’Reilly.
11. GitLab SRE Handbook.
12. PagerDuty Incident Response Guide — open guide.
13. Atlassian Incident Management Handbook.
14. Learning from Incidents (LFI) — community.