SLO, Error Budget, Burn-Rate Alerting

1. Định nghĩa

Quan hệ: SLA < SLO < hiện tại. SLA luôn lỏng hơn SLO; SLO luôn lỏng hơn measurement hiện tại (để có buffer fix).

Source: Beyer et al., Site Reliability Engineering, O’Reilly 2016, Chapter 4. sre.google/sre-book/service-level-objectives

2. SLI selection theo service type

Google SRE Workbook Chapter 2 phân service thành 4 loại, mỗi loại có metric chuẩn:

2.1 SLI quality criteria

Mỗi SLI phải pass 3 test:

1. Measurable — có metric thật từ system, không phải khái niệm trừu tượng.
2. User-side — đo từ phía user (load balancer log, RUM, synthetic probe). Đo từ phía app server miss network drop.
3. Proportional — SLI giảm khi user pain, không giảm khi user OK.

2.2 Anti-pattern: CPU làm SLI

CPU không proportional với user pain:

• CPU 80%, latency 150ms → user OK, nhưng SLI báo “không OK”.
• CPU 30%, deadlock, latency 5s → user khổ, nhưng SLI báo “OK”.

CPU là saturation signal, không phải user happiness metric. Giữ cho capacity dashboard, không dùng làm SLI.

2.3 Latency: percentile selection

Default cho user-facing service: p99.

2.4 Availability: status code accounting

3. SLO target ladder

3.1 Số 9 và downtime budget

30-day window:

3.2 Cost ladder

Mỗi tier thêm 1 số 9 thường nhân chi phí infra + ops headcount lên 3-10×:

Source: Beyer et al., Chapter 4, “The Nines of Availability.”

4. Error budget

$$ \text{budget} = (1 - \text{SLO}) \times \text{total_events} $$

4.1 Đơn vị budget

4.2 Ví dụ tính budget

SLO 99.9%, traffic 1M req/day, 30-day window:

budget = 0.001 × 1M × 30 = 30,000 request fail / month

Convert sang downtime equivalent (nếu sự cố 100% fail tại 12 req/s peak):

downtime budget = 30,000 / 12 = 2,500s ≈ 41 phút / tháng

4.3 Burn-down chart

% budget
consumed
100% ┤                                ╱─── exhausted
     │                          ╱────╱
 75% ┤                    ╱────╱
     │              ╱────╱   ← burn rate ≈ 1.5 (normal range)
 50% ┤        ╱────╱
     │  ╱────╱
 25% ┤─╱
     │
   0%└────┬────┬────┬────┬────┬────┬─── day
        D5   D10  D15  D20  D25  D30

Slope = burn rate. Slope 1.0 nghĩa là đốt budget đúng tốc độ baseline.

Source: Google SRE Workbook Chapter 2 “Implementing SLOs.” sre.google/workbook/implementing-slos

5. Burn rate

$$ \text{burn_rate} = \frac{\text{error_rate trong window}}{1 - \text{SLO}} $$

5.1 Burn rate → time to exhaust

Với SLO 99.9%, 30-day window:

5.2 Tại sao burn rate hơn raw error rate

Raw “5% error rate” không trả lời “có nên page không”:

• SLO 99% → 5% error → burn rate 5 → vừa phải.
• SLO 99.9% → 5% error → burn rate 50 → page ngay.

Burn rate normalize theo SLO → 1 ngưỡng dùng được cho mọi service.

5.3 Burn rate trên Prometheus

(
  sum(rate(http_requests_total{status=~"5..|429"}[1h]))
  / sum(rate(http_requests_total[1h]))
) / (1 - 0.999)

6. Single-window alert failure modes

Không có window đơn perfect: short = noisy, long = chậm + dính lâu sau khi hết sự cố.

7. Multi-Window Multi-Burn-Rate (MWMBR)

Source: Google SRE Workbook Chapter 5 “Alerting on SLOs,” Section 6. sre.google/workbook/alerting-on-slos

7.1 Công thức

Alert fire khi CẢ HAI condition true cùng lúc:

1. Long window burn rate ≥ T (sự cố đủ lớn để đáng action)
2. Short window burn rate ≥ T (sự cố vẫn đang diễn ra ngay bây giờ)

Quy tắc tỉ lệ: short window ≈ long / 12.

7.2 Tier table chuẩn Google SRE

Công thức derive threshold:

$$ T = \frac{\text{budget_fraction}}{\text{window_fraction_of_SLO_period}} $$

Ví dụ Tier 1: muốn 2% budget burned in 1h → T = 0.02 / (1h / 720h) = 14.4.

7.3 Recovery behavior

Khi sự cố hết:

• Short window về dưới threshold trong ~5 phút → AND condition false → alert stop.
• Long window vẫn còn cao thêm 30-60 phút, nhưng AND đã false → không spam.

Đây là lý do AND quan trọng: alert recover nhanh.

7.4 Prometheus implementation

groups:
- name: slo-alerts
  rules:
  - alert: SLO_BurnRate_Tier1
    expr: |
      (
        sum(rate(http_requests_total{status=~"5..|429"}[1h]))
        / sum(rate(http_requests_total[1h]))
      ) / (1 - 0.999) >= 14.4
      AND
      (
        sum(rate(http_requests_total{status=~"5..|429"}[5m]))
        / sum(rate(http_requests_total[5m]))
      ) / (1 - 0.999) >= 14.4      
    labels: {severity: page, tier: "1"}
    annotations:
      summary: "Burn rate ≥ 14.4 over both 1h and 5m windows"
      runbook: "https://runbooks.example.com/slo-burn"

  - alert: SLO_BurnRate_Tier2
    expr: |
      (sum(rate(http_requests_total{status=~"5..|429"}[6h]))
       / sum(rate(http_requests_total[6h]))) / (1 - 0.999) >= 6
      AND
      (sum(rate(http_requests_total{status=~"5..|429"}[30m]))
       / sum(rate(http_requests_total[30m]))) / (1 - 0.999) >= 6      
    labels: {severity: page, tier: "2"}

  - alert: SLO_BurnRate_Tier3
    expr: |
      (sum(rate(http_requests_total{status=~"5..|429"}[3d]))
       / sum(rate(http_requests_total[3d]))) / (1 - 0.999) >= 1
      AND
      (sum(rate(http_requests_total{status=~"5..|429"}[6h]))
       / sum(rate(http_requests_total[6h]))) / (1 - 0.999) >= 1      
    labels: {severity: ticket, tier: "3"}

8. Khi nào dùng SLO-based vs anomaly detection

Metric X
├── Proportional với user pain?
│   ├── YES → SLI candidate → SLO-based MWMBR alert
│   └── NO → continue
├── Saturation signal (CPU, mem, queue, FD count)?
│   ├── YES → ticket alert (low priority) hoặc capacity dashboard, không page
│   └── NO → continue
└── Leading indicator (drift, gradual change)?
    └── YES → anomaly detection (W1) trên metric, alert ticket khi sustained

9. Bài tập

9.0 Setup

Download pack:

wget https://learning-notes-dz2.pages.dev/aiops-w3/lab/w3-d1-pack.zip
unzip w3-d1-pack.zip -d w3-d1-pack/
cd w3-d1-pack/

Install deps + generate 3-day synthetic data (chạy 1 lần, ~30s, output ~300MB):

uv venv --python 3.12
uv pip install pyyaml
uv run python generate_data.py

9.1 Cấu trúc pack

w3-d1-pack/
├── generate_data.py          # sinh 3-day synthetic log (đã chạy ở §9.0)
├── docker-compose.yml        # Prometheus 2.50 + Alertmanager 0.27 + Grafana 10.4
├── configs/                  # prometheus.yml + alertmanager.yml
├── scripts/
│   ├── compute_baseline.py   # extract baseline SLI từ log
│   ├── validate.py           # compare alert rules với incident_window.csv
│   └── prometheus_replay.sh  # (optional) push metric vào Prometheus
├── sample-solution/          # SLO + alert YAML mẫu — tham khảo, KHÔNG copy
└── data/                     # sinh sau khi chạy generate_data.py
    ├── access_log.jsonl      # ~2M event nginx access log
    ├── db_query_log.jsonl    # ~170k pg_stat_statements sample
    ├── frontend_rum.jsonl    # ~520k RUM page load event
    ├── topology.yaml         # service map: frontend → api → db
    └── incident_window.csv   # 5 ground-truth incident

Stack giả định: 3-tier service — React frontend (CDN) + FastAPI 4-instance + Postgres primary/replica. Peak ~15 req/s sampled traffic, e-commerce context.

Log schema (mỗi dòng 1 JSON event):

// access_log.jsonl
{"ts": "2026-06-01T00:00:00+00:00", "method": "GET", "path": "/api/orders",
 "status": 200, "latency_ms": 142}

// db_query_log.jsonl
{"ts": "2026-06-01T00:00:00+00:00", "query": "SELECT ...",
 "duration_ms": 38, "success": true, "rows": 17}

// frontend_rum.jsonl
{"ts": "2026-06-01T00:00:00+00:00", "page": "/products",
 "dom_ready_ms": 1240, "js_error": false, "network_error": false}

incident_window.csv (ground truth, dùng để validate):

incident_id,layer,severity,start_utc,end_utc,fail_rate_multiplier
1,api,tier1,2026-06-01T03:00:00+00:00,2026-06-01T03:08:00+00:00,100

9.2 Bước 1 — Compute baseline

uv run python scripts/compute_baseline.py --data data/ --out baseline.json

Output:

{
  "frontend": {"success_rate_p50": 0.992, "success_rate_p99": 0.974, "events_per_day": 171428},
  "api":      {"success_rate_p50": 0.997, "success_rate_p99": 0.989, "events_per_day": 714285},
  "db":       {"success_rate_p50": 0.999, "success_rate_p99": 0.996, "events_per_day": 114285}
}

Dùng baseline.json làm input cho mọi quyết định ở step sau.

9.3 Bước 2 — Viết slo_spec.yaml

Schema bắt buộc (mỗi service 1 entry, tổng 3 entry):

version: 1
services:
  - name: <frontend|api|db>
    sli:
      name: <ví dụ frontend_availability>
      kind: <availability|latency|freshness|throughput>
      formula: "<mô tả plain text: numerator / denominator>"
      promql_good: "<promql đếm event thoả SLO>"
      promql_total: "<promql đếm tổng event>"
      source: <log file path hoặc Prometheus metric>
    slo:
      target: <float ∈ [0.9, 0.9999]>     # e.g. 0.999 = 99.9%
      window_days: 30
    budget:
      total_events_per_month: <int>        # từ baseline.json × 30
      allowed_failures_per_month: <int>    # = (1 - target) × total
      downtime_minutes_equivalent: <int>   # = allowed_failures / req_per_minute

9.4 Bước 3 — Viết burn_rate_alerts.yaml

3 tier MWMBR cho mỗi service → tổng 9 alert rule. Template §7.4.

Verify syntax:

promtool check rules burn_rate_alerts.yaml
# Expected: 9 rules found, 0 errors

9.5 Bước 4 — Validate trên replay data

bash scripts/prometheus_replay.sh           # replay 7-day log vào Prometheus
python scripts/validate.py \
  --rules burn_rate_alerts.yaml \
  --truth data/incident_window.csv \
  --baseline-rule "error_rate > 0.01 for 5m" \
  --out validation_report.json

Output schema:

{
  "static_baseline": {"fired": 43, "tp": 4, "fp": 39, "fn": 0, "mttd_p50_s": 252},
  "your_mwmbr":      {"fired": 6,  "tp": 4, "fp": 2,  "fn": 0, "mttd_p50_s": 287},
  "noise_reduction_pct": 86.0,
  "mttd_delta_s": 35,
  "verdict": "pass"
}

Acceptance: noise_reduction_pct ≥ 70 AND mttd_delta_s < 60 AND your_mwmbr.fn = 0.

Nếu fail → tune threshold, đổi window size, hoặc đổi SLO target. Iterate.

9.6 Bước 5 — Viết DESIGN.md

Trả lời 5 câu hỏi, mỗi câu 100-200 từ, bắt buộc reference số từ baseline.json hoặc validation_report.json:

1. SLI choice cho frontend. Tại sao chọn metric X thay vì Y? Frontend RUM cho 4 candidate signal (page load time, DOM ready, JS error rate, network error rate). Chọn cái nào, vì sao loại 3 cái còn lại?
2. SLO target cho api. Tại sao 99.9% chứ không 99% hoặc 99.99%? Cost của mỗi tier (§3.2) so với baseline hiện tại 99.7% (từ baseline.json).
3. Latency threshold p99. Bạn cut latency ở mốc nào (200ms? 500ms? 1s?)? Plot distribution latency 7-day (text/table OK), defend choice.
4. 4xx exclusion. Tại sao loại 4xx ra khỏi error count (trừ 429)? Có log endpoint nào có rate 4xx > 5% mà không phải hệ thống lỗi không? Reference data.
5. MWMBR tuning. Dùng Google default (14.4, 6, 1) hay tune? Nếu tune, dựa vào ảnh hưởng đến noise_reduction_pct và fn thế nào?

9.7 Bước 6 — Viết SUBMIT.md

# W3-D1 Submission — <your name>

## 3 thứ tôi học được
1. ...
2. ...
3. ...

## 1 thứ vẫn chưa rõ
...

## 1 trade-off trong SLO decision của tôi mà tôi không chắc
...

## Validation report
- noise_reduction_pct: __%
- mttd_delta_s: __s
- false_negative: __
- verdict: __

9.8 Acceptance checklist

• slo_spec.yaml parse được, có đủ 3 service, target ∈ [0.9, 0.9999]
• burn_rate_alerts.yaml có 9 rule, promtool check rules pass với 0 error
• validation_report.json đạt acceptance ở §9.5 (noise ≥ 70%, MTTD delta < 60s, FN = 0)
• DESIGN.md trả lời cả 5 câu, mỗi câu có ít nhất 1 số từ baseline/validation
• SUBMIT.md đủ 4 section

10. Anti-patterns

11. Deliverable summary

Đường dẫn nộp: aiops-<tên>/w3/d1/.

12. References