📊 Phần 5: Đo lường độ tin cậy với SLI, SLO và Error Budget

📌 Tại sao phải đo độ tin cậy?

Bạn không thể cải thiện điều mình không đo được
Đo lường = hiểu được trải nghiệm người dùng
Giúp đưa ra quyết định kỹ thuật dựa trên dữ liệu (data-driven)

🔍 Khái niệm quan trọng

✅ SLI – Service Level Indicator

Là chỉ số đo lường cụ thể trải nghiệm người dùng
Ví dụ: availability, latency, error rate, throughput
Phải đơn giản – đo được – gắn với hành vi thực tế

✅ SLO – Service Level Objective

Mục tiêu định lượng cho SLI
Ví dụ: "99.9% yêu cầu HTTP thành công trong 28 ngày"
Là cam kết nội bộ cho độ tin cậy dịch vụ

✅ Error Budget

Là phần chênh lệch giữa 100% và SLO
Ví dụ: SLO = 99.9% → có 0.1% lỗi được phép/tháng
Nếu xài hết budget → dừng deploy tính năng, tập trung ổn định

✅ Cách thiết kế SLI/SLO hiệu quả

Bước	Mô tả
1	Hiểu hành vi người dùng chính
2	Định nghĩa SLI phù hợp (VD: latency, lỗi)
3	Đặt SLO dựa vào kỳ vọng người dùng & thực tế hệ thống
4	Đo lường – thu thập bằng Prometheus, logs...
5	Giám sát & cảnh báo nếu vượt quá budget

🔧 Ví dụ SLI/SLO thực tế

Dịch vụ	SLI	SLO
Web API	HTTP success rate	99.9%/28d
Ứng dụng di động	Load time homepage < 1s (95%)	95%/7d
Hệ thống thanh toán	Lỗi giao dịch < 0.1%	99.99%/tháng

📦 Mô hình Error Budget sử dụng trong quản lý sự cố

      [Monitoring]
           ↓
     Đo SLI từ thực tế
           ↓
    So sánh với SLO
           ↓
    → Trong Budget? → ✅ OK, có thể release
    → Hết Budget?   → ⚠️ Tạm dừng release, cải thiện độ tin cậy

✅ Checklist quản lý độ tin cậy

Có ít nhất 1 SLI cho dịch vụ chính
SLO phản ánh đúng trải nghiệm người dùng
Tự động đo SLI bằng logs/metrics
Có dashboard & alert theo error budget
Review SLO định kỳ (theo quý/tháng)

📌 Kết luận:
SLO giúp bạn đặt ranh giới giữa đổi mới và ổn định. Error Budget chính là "cơ chế phanh" để không đánh đổi độ tin cậy lấy tính năng mới một cách mù quáng.

Chương 6 sẽ đi sâu vào postmortem không đổ lỗi – chìa khóa học từ sự cố để cải thiện hệ thống!