Chương 53. Alerting và SLO

Ba chương trước ta nói về:

• Logs.
• Metrics.
• Tracing.

Chúng giúp ta nhìn thấy hệ thống.

Nhưng nhìn thấy chưa đủ.

Production còn cần biết:

Khi nào phải gọi người xử lý?
Khi nào chỉ ghi nhận để xem sau?
Khi nào lỗi nhỏ chưa cần đánh thức ai?
Khi nào người dùng thật đang bị ảnh hưởng?

Đó là bài toán alerting.

Chương này cũng nói về SLO.

SLO giúp ta trả lời:

Hệ thống cần tốt đến mức nào là đủ?

Thông điệp chính của chương:

> Alert tốt là alert cần hành động. SLO tốt là mục tiêu vận hành gắn với trải nghiệm thật của người dùng. Nếu báo động quá nhiều, team sẽ tê liệt. Nếu không có SLO, ta không biết hệ thống đang đủ tốt hay chưa.

---

53.1. Một tình huống: 3 giờ sáng, bạn có nên bị gọi dậy không?

Hãy tưởng tượng 3 giờ sáng.

Điện thoại reo.

Alert nói:

CPU worker-7 = 92%.

Bạn bật dậy, mở laptop.

Nhưng rồi thấy:

Worker vẫn xử lý job bình thường.
Queue không backlog.
User không bị ảnh hưởng.
CPU cao trong 2 phút rồi giảm.

Alert này có đáng gọi bạn dậy không?

Có thể không.

Bây giờ tình huống khác:

Oldest grading job age > 20 phút.
80% bài nộp chưa có điểm trong 10 phút.
Worker fail rate tăng mạnh.

Alert này đáng gọi hơn.

Vì nó nói:

User thật đang chờ.
Hệ thống không hoàn thành việc chính.

Alert tốt không phải là báo mọi thứ bất thường.

Alert tốt báo khi cần hành động.

---

53.2. Alert là gì?

Alert là tín hiệu nói:

Có chuyện cần người hoặc hệ thống phản ứng.

Alert có thể gửi qua:

• Email.
• Slack.
• SMS.
• Phone call.
• Pager/on-call tool.
• Incident management tool.

Nhưng bản chất không nằm ở kênh gửi.

Bản chất nằm ở câu hỏi:

Người nhận alert có biết cần làm gì không?
Nếu không làm gì, user hoặc hệ thống có bị ảnh hưởng không?

Nếu câu trả lời là không, alert đó có thể chỉ nên là dashboard hoặc log.

Không phải alert.

---

53.3. Alert tốt phải cần hành động

Một alert tốt thường có ba yếu tố:

1. Có vấn đề thật.
2. Có mức độ khẩn rõ.
3. Có hành động tiếp theo.

Ví dụ alert tốt:

Grading queue oldest job age > 10 phút trong 5 phút.
Ảnh hưởng: học sinh đang chờ điểm lâu.
Hành động: kiểm tra worker count, AI provider latency, retry rate, queue backlog.
Runbook: link.

Alert kém:

Something is wrong.

Hoặc:

CPU high.

mà không nói service nào, ảnh hưởng gì, cần làm gì.

Alert không có hành động sẽ dần bị bỏ qua.

---

53.4. Alert fatigue là gì?

Alert fatigue là khi team nhận quá nhiều alert đến mức tê liệt.

Lúc đầu ai cũng đọc.

Sau đó alert quá nhiều, nhiều cái không quan trọng.

Team bắt đầu:

• Mute alert.
• Bỏ qua alert.
• Tắt notification.
• Không tin hệ thống alert nữa.

Đây là tình trạng rất nguy hiểm.

Vì khi alert thật sự quan trọng đến, nó bị chìm trong tiếng ồn.

Alert fatigue thường đến từ:

• Alert quá nhạy.
• Alert theo từng lỗi nhỏ.
• Alert không cần hành động.
• Alert lặp lại liên tục cùng một nguyên nhân.
• Không có severity.
• Không có runbook.

Alerting cũng cần thiết kế.

Không phải cứ có metric là tạo alert.

---

53.5. Báo động theo triệu chứng thay vì từng lỗi nhỏ

Một nguyên tắc rất thực tế:

> Alert theo triệu chứng ảnh hưởng user, không chỉ theo từng nguyên nhân kỹ thuật nhỏ.

Ví dụ nguyên nhân nhỏ:

Một request AI timeout.
Một worker restart.
Một query chậm.
Một request 500.
CPU tăng trong 1 phút.

Những thứ này có thể xảy ra bình thường.

Triệu chứng đáng báo hơn:

Tỉ lệ job chấm thất bại tăng cao.
Queue wait time vượt 10 phút.
API 5xx rate > 5%.
95% request /submissions chậm hơn 2 giây.
File upload success rate tụt dưới 98%.

Triệu chứng gần với trải nghiệm user hơn.

Nếu một lỗi nhỏ không ảnh hưởng user và tự hồi phục, không nhất thiết phải gọi người.

---

53.6. Nhưng nguyên nhân kỹ thuật vẫn cần dashboard

Không alert từng lỗi nhỏ không có nghĩa là bỏ qua chúng.

Ta vẫn cần dashboard và metrics cho nguyên nhân:

• CPU.
• Memory.
• DB connections.
• Slow query.
• AI timeout.
• Worker restarts.
• Retry count.

Khi alert triệu chứng xảy ra, ta dùng dashboard nguyên nhân để điều tra.

Ví dụ alert:

Queue oldest job age > 10 phút.

Sau đó dashboard giúp xem:

Worker count giảm?
AI latency tăng?
Retry tăng?
Database chậm?
Submission rate tăng?

Alert nói:

Cần xử lý.

Dashboard giúp:

Xử lý từ đâu.

---

53.7. Severity

Không phải alert nào cũng cùng mức độ.

Có thể chia:

Critical:
  User bị ảnh hưởng nghiêm trọng, cần xử lý ngay.

Warning:
  Có dấu hiệu xấu, cần xem sớm nhưng không nhất thiết đánh thức người.

Info:
  Ghi nhận sự kiện đáng chú ý.

Ví dụ:

Critical:

API 5xx rate > 20% trong 5 phút.
Grading queue wait > 30 phút.
Database không nhận connection.

Warning:

Queue wait > 5 phút.
AI timeout tăng nhẹ.
Database connection > 80%.

Info:

Deploy production hoàn tất.
Feature flag bật cho 10% user.

Severity giúp người nhận biết mức phản ứng.

---

53.8. SLI là gì?

SLI là Service Level Indicator.

Nói dễ hiểu:

SLI là chỉ số đo chất lượng dịch vụ.

Ví dụ với web API:

Tỉ lệ request thành công.
p95 latency.

Ví dụ với AI Judge:

Tỉ lệ bài được chấm thành công.
Tỉ lệ bài có kết quả trong 5 phút.
Tỉ lệ upload file thành công.
Tỉ lệ teacher dashboard load dưới 2 giây.

SLI tốt nên gần trải nghiệm user.

CPU không phải SLI tốt cho user.

CPU là metric nguyên nhân.

SLI là chỉ số chất lượng mà user cảm nhận hoặc hệ thống cam kết.

---

53.9. SLO là gì?

SLO là Service Level Objective.

Nói dễ hiểu:

SLO là mục tiêu cho SLI.

Ví dụ:

99.5% API requests thành công trong 30 ngày.
95% submission được chấm trong 5 phút.
99% file upload hoàn tất trong 1 phút với file dưới 20MB.
Teacher dashboard p95 dưới 2 giây.

SLO trả lời:

Đủ tốt là bao nhiêu?

Không có SLO, ta chỉ nói mơ hồ:

Hệ thống phải nhanh.
Hệ thống phải ổn.

Nhanh là bao nhiêu?

Ổn là bao nhiêu?

SLO làm kỳ vọng cụ thể hơn.

---

53.10. SLA là gì?

SLA là Service Level Agreement.

Nó thường là cam kết chính thức với khách hàng, có thể có hậu quả hợp đồng.

Ví dụ:

Uptime 99.9% mỗi tháng.
Nếu không đạt, khách được credit.

SLO thường là mục tiêu nội bộ hoặc mục tiêu vận hành.

SLA là cam kết bên ngoài.

Nói ngắn:

SLI:
  chỉ số đo.

SLO:
  mục tiêu ta muốn đạt.

SLA:
  cam kết chính thức với khách hàng.

Đừng hứa SLA trước khi bạn có khả năng đo và vận hành SLO tương ứng.

---

53.11. Ví dụ SLI/SLO cho AI Judge

Một SLI tốt:

time_to_grade_seconds

Nó đo:

Từ lúc student nộp bài đến lúc grading result available.

Một SLO có thể là:

95% bài nộp được chấm trong 5 phút trong 30 ngày.

SLI khác:

grading_success_rate

SLO:

99% grading jobs kết thúc thành công hoặc có lỗi rõ ràng cho user trong 30 ngày.

Điểm hay:

SLO này đo điều user quan tâm.

User không quan tâm CPU worker.

User quan tâm bài có kết quả đúng hạn không.

---

53.12. SLO không cần hoàn hảo 100%

Một sai lầm là đặt:

100% request thành công.
100% bài chấm trong 1 phút.

Nghe hay, nhưng thường không thực tế.

Hệ thống thật có:

• Lỗi mạng.
• Deploy.
• External provider outage.
• File lớn.
• User input xấu.
• Traffic spike.

SLO nên tham vọng nhưng thực tế.

Ví dụ:

95% bài chấm trong 5 phút.
99% API requests thành công.
99.5% file upload thành công.

Không phải vì ta thích lỗi.

Mà vì reliability luôn có chi phí.

100% thường cực kỳ đắt hoặc bất khả thi.

---

53.13. Error budget là gì?

Error budget là phần lỗi/chậm được phép trong SLO.

Ví dụ SLO:

99% request thành công trong 30 ngày.

Điều đó nghĩa là bạn có 1% ngân sách lỗi.

Nếu tháng này dùng hết error budget rất nhanh, hệ thống đang không ổn.

Khi error budget còn nhiều, team có thể chấp nhận thay đổi nhanh hơn.

Khi error budget gần hết, nên giảm rủi ro:

• Dừng rollout lớn.
• Tập trung fix reliability.
• Tối ưu bottleneck.
• Giảm deploy rủi ro.

Error budget giúp cân bằng:

Ship nhanh

và:

Giữ ổn định

---

53.14. SLO giúp tranh luận bớt cảm tính

Không có SLO, các cuộc nói chuyện dễ thành:

App có vẻ chậm.
Tôi thấy ổn.
User phàn nàn nhiều.
Chắc vẫn chấp nhận được.

Có SLO:

Mục tiêu: 95% bài chấm trong 5 phút.
Tuần này chỉ đạt 88%.

Cuộc nói chuyện chuyển thành:

Chúng ta đang không đạt mục tiêu.
Cần ưu tiên reliability trước tính năng mới.

Hoặc:

SLO vẫn đạt, lỗi lẻ tẻ chưa cần panic.

SLO giúp team quyết định bằng số liệu.

---

53.15. Alert theo SLO

Alert tốt có thể dựa trên SLO.

Ví dụ:

SLO: 95% bài chấm trong 5 phút.
Alert: trong 15 phút gần đây, tỉ lệ bài chấm quá 5 phút vượt ngưỡng đáng kể.

Hoặc:

SLO: API 99% success.
Alert: error budget đang bị đốt quá nhanh.

Alert theo SLO thường tốt hơn alert từng lỗi nhỏ.

Vì nó hỏi:

Người dùng có đang nhận dịch vụ dưới mức mục tiêu không?

Đây là triệu chứng thật.

---

53.16. Multi-window alert

Một kỹ thuật hay dùng là alert theo nhiều cửa sổ thời gian.

Ví dụ:

Lỗi tăng rất mạnh trong 5 phút:
  cần phản ứng nhanh.

Lỗi tăng vừa phải nhưng kéo dài 1 giờ:
  cũng cần xử lý.

Nếu chỉ nhìn 5 phút, có thể bỏ qua lỗi kéo dài âm ỉ.

Nếu chỉ nhìn 1 giờ, phát hiện sự cố lớn quá chậm.

Không cần đi sâu công thức.

Chỉ cần hiểu:

> Alert tốt cần phát hiện cả cháy lớn nhanh và cháy âm ỉ kéo dài.

---

53.17. Alert theo queue

Với AI Judge, queue alert rất quan trọng.

Alert kém:

queue_length > 1000

Vì queue length 1000 có thể ổn nếu worker xử lý rất nhanh.

Alert tốt hơn:

oldest_grading_job_age > 10 phút

Vì nó gắn với user chờ.

Hoặc:

time_to_grade p95 > 5 phút

Đây là SLI gần trải nghiệm thật.

Queue length vẫn hữu ích để điều tra.

Nhưng alert nên ưu tiên thời gian chờ và SLO.

---

53.18. Alert theo external provider

AI provider có thể lỗi.

Nhưng không phải cứ một timeout là gọi người.

Alert nên nhìn theo tỉ lệ và ảnh hưởng:

Gemini timeout rate > 10% trong 10 phút.
Gemini rate limit errors tăng mạnh.
AI call p95 latency > 120s.

Và cần nối với triệu chứng:

Grading queue wait cũng đang tăng?
Grading success rate có giảm?

Nếu AI timeout tăng nhẹ nhưng retry thành công và user không bị ảnh hưởng, có thể warning.

Nếu AI outage làm bài không chấm được, critical.

---

53.19. Alert theo database

Database alert cần cẩn thận.

Một số alert đáng có:

Database unavailable.
Connection usage > 90% kéo dài.
Disk usage > 85%.
Replication lag cao.
Lock wait cao kéo dài.
Slow query tăng sau deploy.

Nhưng nếu CPU lên 80% trong 2 phút rồi xuống, chưa chắc phải gọi người.

Hãy ưu tiên:

Database ảnh hưởng request/job thế nào?

Nếu DB connection gần max và API 5xx tăng, đó là critical hơn nhiều.

Metric nguyên nhân cộng với triệu chứng user giúp alert chính xác hơn.

---

53.20. Alert theo cost

Với AI product, cost alert rất quan trọng.

Ví dụ:

AI cost per hour tăng 3 lần so với baseline.
Token usage tăng bất thường sau deploy.
Retry làm số AI calls/job tăng.
Một tenant vượt quota ngày.

Cost incident không luôn làm user thấy lỗi ngay.

Nhưng có thể làm doanh nghiệp mất tiền rất nhanh.

Alert cost nên đi với:

• Quota.
• Rate limit.
• Dashboard usage.
• Kill switch/feature flag.

Nếu AI call bị retry storm, cost alert có thể cứu rất nhiều tiền.

---

53.21. Runbook là gì?

Runbook là hướng dẫn xử lý khi alert xảy ra.

Ví dụ alert:

Grading queue oldest job age > 10 phút.

Runbook nên nói:

1. Mở dashboard queue.
2. Kiểm tra worker_active_count.
3. Kiểm tra AI provider latency/timeout.
4. Kiểm tra retry rate.
5. Kiểm tra deploy gần nhất.
6. Nếu worker chết, restart/scale worker.
7. Nếu AI provider rate limit, giảm concurrency hoặc bật fallback.
8. Cập nhật status cho user nếu sự cố kéo dài.

Khi incident xảy ra, người xử lý dễ căng thẳng.

Runbook giúp bắt đầu đúng chỗ.

---

53.22. Alert không có runbook thường yếu

Alert nói:

Something wrong with queue.

Người nhận hỏi:

Mở dashboard nào?
Metric nào cần xem?
Có được scale worker không?
Scale tối đa bao nhiêu?
Nếu AI provider lỗi thì làm gì?
Thông báo user ở đâu?

Nếu không có câu trả lời, alert gây hoảng hơn là giúp.

Một alert tốt nên có link:

Dashboard
Logs query
Runbook
Recent deploys

Không cần hoàn hảo từ đầu.

Nhưng mỗi incident nên cải thiện runbook.

---

53.23. On-call và trách nhiệm

Alert phải có người nhận.

Nếu alert gửi vào một channel đông người nhưng không ai chịu trách nhiệm, nó có thể bị bỏ qua.

On-call nghĩa là có người hoặc nhóm chịu trách nhiệm phản ứng trong một khoảng thời gian.

Không phải mọi team nhỏ đều cần hệ thống on-call phức tạp.

Nhưng vẫn cần rõ:

Nếu production chết, ai nhận?
Nếu queue backlog, ai xử lý?
Nếu AI cost spike, ai có quyền tắt flag?

Alert không có owner là tiếng ồn.

---

53.24. Khi nào không nên alert?

Không nên alert khi:

• Không cần hành động.
• Lỗi tự hồi phục nhanh và không ảnh hưởng user.
• Metric quá nhiễu.
• Alert trùng với alert khác rõ hơn.
• Người nhận không thể làm gì.
• Alert chỉ để "biết cho vui".

Ví dụ:

Một job retry lần 1.

Nếu retry thành công và không ảnh hưởng SLO, không cần alert.

Có thể log/metric.

Nhưng không cần đánh thức người.

Hãy tiết kiệm sự chú ý của team.

Sự chú ý cũng là tài nguyên.

---

53.25. Alert và escalation

Không phải alert nào cũng cần gọi điện ngay.

Có thể có cấp:

Info:
  ghi vào channel.

Warning:
  báo trong giờ làm hoặc notification nhẹ.

Critical:
  gọi on-call ngay.

Ví dụ:

Queue wait > 5 phút:
  warning.

Queue wait > 20 phút:
  critical.

Escalation giúp phản ứng tương xứng với mức độ ảnh hưởng.

Nếu mọi thứ đều critical, không có gì critical.

---

53.26. Maintenance window

Có lúc hệ thống thay đổi có kế hoạch:

• Deploy lớn.
• Migration.
• Database maintenance.
• Provider maintenance.

Trong thời gian đó, một số alert có thể bắn.

Cần có cách:

• Mute có kiểm soát.
• Ghi nhận maintenance window.
• Không tắt alert vĩnh viễn.
• Có người theo dõi sau maintenance.

Mute alert là con dao hai lưỡi.

Mute xong quên bật lại là lỗi rất thật.

---

53.27. AI Judge: SLO đề xuất ban đầu

Một AI Judge có thể bắt đầu với SLO đơn giản:

API:
  99% request API không lỗi 5xx trong 30 ngày.

Submission:
  99% submission được ghi nhận thành công nếu file hợp lệ.

Grading:
  95% bài nộp được chấm trong 5 phút.

File upload:
  99% file upload dưới 20MB hoàn tất trong 1 phút.

Dashboard:
  95% teacher dashboard load dưới 2 giây.

Các con số này chỉ là ví dụ.

SLO thật phải dựa vào:

• Sản phẩm.
• Kỳ vọng user.
• Chi phí.
• Hạ tầng.
• Độ khó bài chấm.
• Giới hạn AI provider.

Quan trọng là có mục tiêu đo được.

---

53.28. AI Judge: alert đề xuất ban đầu

Một bộ alert ban đầu:

API 5xx rate cao.
POST /submissions error rate cao.
Oldest grading job age > 10 phút.
Grading failed rate cao.
Dead letter jobs > 0.
Worker active count thấp bất thường.
AI provider timeout/rate limit cao.
Database connection usage > 90%.
File upload failure rate cao.
AI cost/hour tăng bất thường.

Những alert này gắn với:

• User không dùng được app.
• Bài không được chấm.
• Worker/AI/database có vấn đề.
• Chi phí mất kiểm soát.

Đó là những thứ đáng biết sớm.

---

53.29. AI Judge: alert không nên quá sớm

Không nên alert kiểu:

Mỗi job fail gửi một message.
Mỗi AI timeout gửi một message.
Mỗi 403 gửi một message.
Mỗi worker restart gửi một message.

Những sự kiện này nên thành metrics/logs.

Alert khi chúng thành triệu chứng:

Job fail rate cao.
AI timeout rate cao.
Permission deny tăng bất thường.
Worker restart liên tục và capacity giảm.

Alert theo tỉ lệ và ảnh hưởng sẽ ít ồn hơn nhiều.

---

53.30. AI Judge: runbook queue backlog

Runbook đơn giản cho queue backlog:

Alert:
  oldest_grading_job_age > 10 phút.

Kiểm tra:
  submission rate có tăng không?
  worker_active_count có giảm không?
  worker error/retry có tăng không?
  AI provider latency/timeout/rate limit thế nào?
  database connection/slow query có bất thường không?
  deploy gần nhất lúc nào?

Hành động:
  nếu worker thiếu và quota còn: tăng worker/concurrency.
  nếu AI rate limit: giảm concurrency, bật backoff/fallback.
  nếu retry storm: tạm dừng retry hoặc sửa lỗi gây retry.
  nếu database nghẽn: giảm dashboard/report nặng, xem slow query.
  nếu sự cố kéo dài: thông báo trạng thái cho user/teacher.

Runbook không cần dài.

Nó cần giúp người xử lý đi đúng hướng trong 5 phút đầu.

---

53.31. AI Judge: runbook cost spike

Alert:

AI cost/hour tăng 3 lần so với baseline.

Kiểm tra:

Số submission có tăng thật không?
Retry per job có tăng không?
Prompt/model version vừa đổi không?
Output tokens có tăng không?
Tenant nào tạo cost?
Có bug loop/retry không?

Hành động:

Bật quota/limit nếu chưa bật.
Tắt feature flag pipeline mới nếu nghi ngờ.
Giảm retry.
Giảm concurrency nếu provider lỗi.
Chặn tenant/key abuse nếu có.
Rollback prompt/model config nếu cần.

Cost alert phải có hành động nhanh.

Nếu không, mỗi phút đều tốn tiền.

---

53.32. Những lỗi alerting phổ biến

Một số lỗi hay gặp:

Alert theo từng lỗi nhỏ thay vì triệu chứng user.
Alert quá nhạy, bắn rồi tự hết.
Không có severity.
Không có owner.
Không có runbook.
Alert trùng lặp nhiều nơi.
Alert dựa trên average thay vì p95/error rate.
Không alert queue/worker, chỉ alert web API.
Không alert cost.
Mute alert rồi quên bật lại.
SLO đặt 100% phi thực tế.

Alerting tốt là hệ thống bảo vệ sự chú ý của team.

Không phải hệ thống spam team.

---

53.33. Checklist alerting và SLO

Hỏi:

• Alert này có cần hành động không?
• Nếu không ai xử lý, user có bị ảnh hưởng không?
• Người nhận có biết làm gì không?
• Có link dashboard/log/runbook không?
• Alert này là triệu chứng hay nguyên nhân nhỏ?
• Severity là gì?
• Ai là owner?
• Có alert trùng không?
• Có quá nhạy không?
• SLO nào liên quan?
• SLI có đo đúng trải nghiệm user không?
• Error budget có bị đốt nhanh không?
• Có alert cho cost không?
• Có alert cho queue/worker không?

Nếu một alert không qua được các câu hỏi này, nên sửa hoặc bỏ.

---

53.34. Bảng chọn nhanh

| Tình huống | Alert tốt hơn | |---|---| | Một AI request timeout | Không alert, log/metric | | AI timeout rate tăng cao | Warning/Critical tùy ảnh hưởng | | Một job retry | Không alert | | Job fail rate cao | Alert | | Queue length cao | Xem thêm oldest job age | | Oldest job age vượt SLO | Alert | | CPU tăng ngắn hạn | Thường không alert | | CPU cao + latency/error tăng | Alert | | Một 403 | Log/metric | | 403 tăng bất thường | Security warning | | Cost tăng bất thường | Alert | | Deploy hoàn tất | Info event |

---

53.35. Tóm tắt bằng AI Judge

Với AI Judge, alert tốt không phải:

Mỗi timeout gọi người.
Mỗi job fail gọi người.
Mỗi worker restart gọi người.

Alert tốt là:

Bài nộp không được chấm đúng thời gian.
Tỉ lệ chấm lỗi tăng.
Queue chờ quá lâu.
AI provider lỗi trên diện rộng.
Database làm API/job lỗi.
Chi phí AI tăng bất thường.

SLO giúp nói rõ:

95% bài được chấm trong 5 phút.
99% submission hợp lệ được ghi nhận.
99% API không lỗi 5xx.

Khi SLO bị đe dọa, alert có ý nghĩa.

Khi alert có runbook, người xử lý biết bắt đầu từ đâu.

---

53.36. Kết luận của chương

Alerting là nghệ thuật bảo vệ sự chú ý.

Nếu alert quá ít, hệ thống hỏng mà không ai biết.

Nếu alert quá nhiều, team mệt và bỏ qua cả alert quan trọng.

SLO giúp ta định nghĩa "đủ tốt" bằng số liệu gần trải nghiệm user.

SLI là chỉ số đo.

SLO là mục tiêu.

SLA là cam kết chính thức.

Error budget giúp cân bằng tốc độ thay đổi và độ ổn định.

Thông điệp cần nhớ:

> Alert tốt là alert cần hành động, gắn với triệu chứng có ý nghĩa, có owner, có severity, và có runbook. SLO tốt giúp ta biết hệ thống có đang phục vụ người dùng ở mức đã hứa hay không.

Ở chương tiếp theo, ta sẽ nói về các failure modes phổ biến: retry storm, thundering herd, cascading failure, queue overload, database overload, external provider outage, partial outage và graceful degradation.