Bài 4 — SLO và Alert: biến quan sát thành cảnh báo hữu ích

Dashboard đẹp nhưng không ai ngồi nhìn 24/7. Bạn cần alert tự đánh thức đúng người khi có vấn đề thật — và im lặng khi mọi thứ ổn. Bí quyết là gắn alert vào SLO (Service Level Objective) thay vì vào từng con số rời rạc.

SLO, SLI, error budget

• SLI (indicator): thứ bạn đo, ví dụ "tỷ lệ request được trả lời đúng trong 5s".
• SLO (objective): mục tiêu cho SLI, ví dụ "99% request/tháng đạt SLI".
• Error budget: phần được phép hỏng, ở đây là 1%. Còn budget thì cứ phát hành; hết budget thì đóng băng tính năng mới để lo ổn định.

Với agent, SLO nên gồm cả chất lượng, không chỉ uptime: "≥ 95% câu trả lời không bị guardrail chặn và không bị user leo thang".

Ví dụ bộ SLO

SLO-1 Availability : 99.5% request trả lời thành công / 30 ngày
SLO-2 Latency      : 95% request p95 ≤ 5s
SLO-3 Quality      : ≤ 3% request bị user leo thang lên người thật
SLO-4 Cost         : chi phí ngày ≤ 1.2× trung bình 7 ngày

Alert dựa trên triệu chứng, không dựa trên nguyên nhân

Hãy cảnh báo theo thứ user cảm nhận (symptom), ví dụ "tỷ lệ lỗi vượt ngưỡng", thay vì hàng chục alert theo nguyên nhân ("CPU cao", "queue dài") gây nhiễu. Dùng cửa sổ đốt cháy budget (burn-rate) để phân biệt sự cố gấp và rò rỉ chậm.

# alert.yaml — cảnh báo theo tốc độ đốt error budget
- alert: HighErrorBurn
  expr: error_rate_5m > 0.05 and error_rate_1h > 0.02
  for: 5m
  severity: page          # gọi người trực ngay
- alert: CostSpike
  expr: cost_1h > 1.5 * cost_baseline_1h
  for: 10m
  severity: ticket        # tạo ticket, không gọi lúc 3h sáng
- alert: GuardrailBlockSurge
  expr: guardrail_block_rate_15m > 0.08
  for: 15m
  severity: page

Khung tư duy: mỗi alert phải trả lời 3 câu

• Ai bị ảnh hưởng? Nếu không ai, đừng gọi người dậy.
• Cần hành động gì ngay? Alert không có runbook là alert vô dụng.
• Gấp thật không? "page" cho gấp, "ticket" cho việc xử lý trong giờ hành chính.

Các bước làm

• Chọn 3–5 SLI phản ánh trải nghiệm user (availability, latency, quality, cost).
• Đặt SLO và error budget cho mỗi SLI theo mức chấp nhận của nghiệp vụ.
• Viết alert theo burn-rate, phân tầng page vs ticket để tránh mệt mỏi vì báo động.
• Gắn runbook vào mỗi alert: các bước xử lý cụ thể, kể cả cách rollback.
• Diễn tập một lần: cố tình gây lỗi ở staging để kiểm tra alert có kêu đúng người.

Checklist alert

• [ ] Mỗi SLO có error budget và chính sách khi hết budget.
• [ ] Alert theo triệu chứng, không spam theo nguyên nhân.
• [ ] Có phân tầng page vs ticket rõ ràng.
• [ ] Mỗi alert kèm runbook có bước rollback.
• [ ] Đã diễn tập ít nhất một lần và alert kêu đúng.

Sai lầm thường gặp

• Alert vào ngưỡng tĩnh vô nghĩa ("CPU > 80%") không liên quan trải nghiệm agent.
• Quá nhiều alert. Đội trực chai lì (alert fatigue) và bỏ lỡ cái quan trọng.
• Alert không có runbook. Người bị gọi dậy lúc 3h sáng không biết làm gì.
• Quên SLO chất lượng. Agent "up" nhưng trả lời rác thì SLO uptime vẫn xanh một cách dối trá.

Khi alert kêu, bạn cần rút lui nhanh. Bài sau là về rollback và kill switch.