SLO Framework — SLI, Error Budget & Burn Rate Alerting

Tại sao SLO quan trọng hơn traditional alerting

Traditional alerting có một vấn đề cơ bản: nó alert trên symptoms tức thời, không phải reliability theo thời gian. Một service có P99 latency 2 giây trong 5 phút, rồi trở về bình thường, sẽ trigger (và close) một threshold alert. Nhưng nếu điều này xảy ra 10 lần/ngày, cumulative impact lên users là rất lớn — và threshold alert không capture được điều đó.

SLO framework giải quyết điều này bằng cách:

1. SLI (Service Level Indicator): Đo lường reliability thực tế của service từ góc độ user
2. SLO (Service Level Objective): Mục tiêu reliability cụ thể (ví dụ: 99.9% requests thành công trong 30 ngày)
3. Error budget: Lượng "phép phạm lỗi" còn lại trong compliance period
4. Burn rate alerting: Alert khi error budget đang cạn với tốc độ nguy hiểm

Thay vì "CPU > 80% thì alert", bạn alert "error budget đang cạn 14x nhanh hơn bình thường".

SLI Types trong Cloud Monitoring

Cloud Monitoring hỗ trợ hai kiến trúc SLI: request-based và window-based. Chúng đo lường reliability theo cách fundamentally khác nhau.

Request-based SLI

Đo lường tỉ lệ "good requests" trên tổng số requests. Đây là dạng phổ biến nhất.

Công thức:

SLI value = (số good requests) / (tổng số requests)

Availability SLI (request-based):

requestBased:
  goodTotalRatio:
    goodServiceFilter: |
      metric.type="loadbalancing.googleapis.com/https/request_count"
      AND metric.labels.response_code_class="2xx"
    totalServiceFilter: |
      metric.type="loadbalancing.googleapis.com/https/request_count"

Cách đọc: trong compliance period, bao nhiêu % requests nhận 2xx response.

Latency SLI (request-based):

requestBased:
  distributionCut:
    distributionFilter: |
      metric.type="loadbalancing.googleapis.com/https/total_latencies"
    range:
      max: 100  # milliseconds — "good" = response < 100ms

Cách đọc: trong compliance period, bao nhiêu % requests có latency < 100ms.

Cloud Monitoring yêu cầu metric phải là DELTA + DISTRIBUTION cho latency SLI — vì cần đếm bao nhiêu requests nằm trong latency bucket nhất định.

Quality SLI (request-based):

Cho phép tính weighted goodness — một request có thể "partially good". Ví dụ: search API trả về kết quả nhưng thiếu một số kết quả → partial good.

requestBased:
  goodTotalRatio:
    goodServiceFilter: "..."  # requests with full results
    badServiceFilter: "..."   # requests with errors
    # totalServiceFilter tự động = good + bad

Window-based SLI

Thay vì đo từng request riêng lẻ, window-based SLI đo bao nhiêu thời gian windows đáp ứng tiêu chí "good". Phù hợp cho:

• Services không có request model rõ ràng (batch jobs, stream processing)
• Trường hợp muốn capture "consecutive good minutes" thay vì individual requests

Công thức:

SLI value = (số windows "good") / (tổng số windows)

Mỗi window thường là 1 phút. "Good window" = metric aggregate trong window đó đáp ứng tiêu chí.

windowsBased:
  windowPeriod: 60s  # evaluate mỗi phút
  goodTotalRatioThreshold:
    threshold: 0.9     # window "good" khi metric mean > 90%
    performance:
      goodTotalRatio:
        goodServiceFilter: "..."
        totalServiceFilter: "..."

Khi nào dùng window-based vs request-based:

Request-based SLI là lựa chọn mặc định cho web services. Window-based phù hợp khi:

• Service không có khái niệm "per-request" rõ ràng
• Muốn capture sustained degradation (ví dụ, CPU sustained high → latency sustained high → nhiều windows fail)
• Batch processing: "bao nhiêu batch jobs hoàn thành trong SLA time"

Compliance Period — Rolling vs Calendar

Compliance period là khoảng thời gian SLO được evaluate. Đây là một trong những quyết định quan trọng nhất khi thiết kế SLO.

Rolling window

Cơ chế: Window liên tục dịch chuyển. Tại thời điểm T, Cloud Monitoring evaluate SLI trên dữ liệu từ T - period đến T. Khi T tăng, điểm cũ rơi ra và điểm mới vào.

Rolling 30 ngày:
Ngày 1-30: SLI trên data từ ngày 1-30
Ngày 2-31: SLI trên data từ ngày 2-31  (ngày 1 rơi ra, ngày 31 vào)
...

Ưu điểm:

• Continuous monitoring: bạn biết SLO status mọi lúc
• Không có "reset effect" cuối tháng
• Phù hợp cho continuous improvement

Nhược điểm:

• Khó explain cho stakeholders không hiểu rolling window
• Một incident cũ có thể vẫn ảnh hưởng SLO nhiều tuần sau khi resolve

Supported rolling windows: 1 đến 30 ngày.

Calendar window

Cơ chế: Window reset tại điểm cố định (đầu tuần, đầu tháng). Tất cả incidents trong period đều count, budget reset hoàn toàn vào đầu period mới.

Ưu điểm:

• Dễ align với business cycles (monthly reporting, quarterly planning)
• Rõ ràng khi nào budget "refresh"
• Dễ explain: "trong tháng này, chúng ta đã dùng X% error budget"

Nhược điểm:

• "End of month pressure": Nếu bị nhiều incidents đầu tháng, team biết budget gần hết → pressure cuối tháng để không làm gì rủi ro
• "Start of month false confidence": Đầu tháng mới với budget đầy, team có thể làm rủi ro hơn
• Inconsistent reporting: Tháng với 28 ngày có ít thời gian hơn tháng 31 ngày

Trong thực tế: Hầu hết SRE teams dùng rolling 30 ngày cho operational SLOs. Calendar windows phù hợp hơn cho SLAs (contractual commitments với customers).

Error Budget — Công cụ quyết định thực tế

Error budget = (1 - SLO goal) × total_eligible_events_in_period

Ví dụ cụ thể:

SLO: 99.9% availability trong 30 ngày

• Error budget = 0.1% × tổng requests
• Nếu service nhận 1 triệu requests/ngày × 30 ngày = 30 triệu requests
• Error budget = 0.001 × 30,000,000 = 30,000 requests có thể fail

Ý nghĩa thực tế của error budget:

Error budget không phải "bộ đệm dự phòng để handle failures". Đây là tài nguyên có thể đầu tư cho rủi ro có giá trị:

• Deploy mới: Một deploy với 0.05% failure rate sẽ dùng 500 requests từ budget
• Experiment: A/B test với 1% degradation cho 10% traffic = 0.1% overall = 1% budget/giờ
• Planned maintenance: Downtime có controlled impact

Khi error budget cạn, có hai cách giải thích:

1. Service đang unreliable: Cần freeze feature deploys, focus vào reliability
2. SLO quá ketat: Có thể SLO không reflect actual user expectations → relax SLO

Error budget tracking trong Cloud Monitoring

Cloud Monitoring tự động track error budget cho từng SLO bạn configure. Trong Console, bạn thấy:

• Error budget còn lại (% và thời gian tương đương)
• Error budget burn rate hiện tại
• Projected exhaustion time nếu burn rate không thay đổi

Burn Rate — Toán học đằng sau Multi-Window Alerting

Đây là phần phức tạp nhất nhưng quan trọng nhất của SLO framework.

Burn rate là gì

Burn rate = (tốc độ tiêu thụ error budget thực tế) / (tốc độ tiêu thụ "bình thường" để vừa hết budget cuối period)

Burn rate 1.0 = bạn đang tiêu thụ budget đúng pace để hết vào cuối compliance period. Burn rate 14.4 = bạn đang tiêu thụ nhanh hơn 14.4 lần "bình thường".

Tính toán từ error rate:

Cho SLO 99.9% (0.1% allowed errors) trên 30-day window:

• "Bình thường" budget consumption rate = 0.1% error rate
• Nếu thực tế có 1.44% error rate → burn rate = 1.44 / 0.1 = 14.4

Công thức tổng quát:

burn_rate = (actual_error_rate) / (1 - SLO_goal)

Tại sao single-window alerting thất bại

Vấn đề 1: Single fast window — False positives.

Alert khi error rate > 1% trong 5 phút. Nếu service nhận 1000 requests/phút và có 10 errors trong 1 phút rồi trở về bình thường → alert fire nhưng ảnh hưởng user nhỏ. Noise level cao.

Vấn đề 2: Single slow window — Phát hiện trễ.

Alert khi 2% error budget consumed trong 3 ngày. Tốt cho sustainable burn rate nhưng nếu có incident tiêu thụ 5% budget trong 1 giờ, alert không fire ngay → user impact lớn trước khi phát hiện.

Vấn đề 3: Reset time.

Alert trên 1-giờ window mean: sau khi incident resolve, alert vẫn tiếp tục fire thêm 60 phút trước khi window "drain out" dữ liệu xấu. Noise kéo dài sau khi incident resolve.

Multi-window alerting — Giải pháp

Theo SRE Workbook của Google, giải pháp là kết hợp nhiều windows với nhiều burn rates, với short window là "reset valve":

Loại Alert	Long window	Short window	Burn rate	Budget consumed
Critical (page ngay)	1 giờ	5 phút	14.4x	2%
Critical (page ngay)	6 giờ	30 phút	6x	5%
Warning (ticket)	3 ngày	6 giờ	1x	10%

Tại sao cần cả long và short window:

• Long window: đảm bảo burn rate được sustain, không phải spike ngắn. Giảm false positives.
• Short window: khi incident resolve, short window "nhanh chóng cập nhật" dữ liệu tốt vào window. Sau 5 phút, dữ liệu xấu từ incident đã rơi khỏi short window → alert không còn fire.

Alert chỉ fire khi CẢ HAI điều kiện đúng: long window burn rate > threshold VÀ short window burn rate > threshold. Điều này ngăn false positives từ single old incident.

Triển khai trong Cloud Monitoring với MQL

Cloud Monitoring cung cấp function select_slo_burn_rate trong MQL:

select_slo_burn_rate("projects/PROJECT_ID/services/SERVICE_ID/serviceLevelObjectives/SLO_ID", 1h)

Argument: compliance period window size.

Alert policy multi-window với MQL:

# Fast burn alert (1h window + 5m window)
conditions:
  - conditionMonitoringQueryLanguage:
      query: |
        # Long window: 1 hour burn rate
        select_slo_burn_rate(
          "projects/my-project/services/my-svc/serviceLevelObjectives/my-slo",
          1h
        ) > 14.4
      duration: 0s  # No additional retest window needed — MQL handles it
  - conditionMonitoringQueryLanguage:
      query: |
        # Short window: 5 minute burn rate  
        select_slo_burn_rate(
          "projects/my-project/services/my-svc/serviceLevelObjectives/my-slo",
          5m
        ) > 14.4
      duration: 0s
combiner: AND  # Cả hai phải đúng

Lưu ý quan trọng: Khi dùng MQL conditions, duration thường đặt là 0 vì MQL query đã internally aggregate qua time window. Thêm duration chồng thêm một retest window không cần thiết.

Toán học đằng sau 2% budget trong 1 giờ = 14.4x burn rate

Cho SLO 99.9% trên 30-day window:

• Total budget = 0.1% × 30 days = 43.2 phút downtime tương đương
• 2% budget consumed = 0.002 × 30 days = 86.4 phút trong 30 ngày

Nếu 2% budget bị consumed trong 1 giờ thay vì 30 ngày:

• Pace bình thường: 86.4 phút / 43,200 phút (30 ngày) = 0.2% budget/giờ
• Pace này: 2% budget / 1 giờ = 2%/giờ
• Burn rate = 2% / 0.2% × (30 days / 1 hour conversion) = 14.4x

Kiểm tra: burn rate 14.4 × 30 ngày = 432 ngày → sẽ hết budget sau 30/14.4 ≈ 2.08 ngày nếu tiếp tục. Nhưng 2% budget trong 1 giờ đã đủ nghiêm trọng để page ngay.

Bảng tham khảo nhanh cho SLO 99.9% / 30 ngày:

Burn rate	Error rate tương đương	Budget exhaustion time
14.4x	~1.44%	~2 ngày
6x	~0.6%	~5 ngày
3x	~0.3%	~10 ngày
1x	~0.1%	~30 ngày (đúng pace)

SLI Design — Nguyên tắc chọn đúng SLI

SLI phải đo từ góc độ user

Sai lầm phổ biến: dùng internal system metrics làm SLI.

• ❌ SLI sai: CPU utilization < 70%
• ❌ SLI sai: Pod healthy > 99%
• ✅ SLI đúng: HTTP 2xx responses / total HTTP requests

CPU có thể 90% nhưng users không thấy ảnh hưởng. Ngược lại, CPU 30% nhưng có memory leak dẫn đến OOM → latency tăng → users bị ảnh hưởng.

SLI phải đo những gì users thực sự trải nghiệm.

SLI nên dùng data từ điểm quan sát gần user nhất

Load Balancer metrics tốt hơn application metrics, vì chúng capture 100% requests (kể cả requests bị timeout trước khi đến application).

Nếu có CDN, metrics tại CDN còn tốt hơn — capture ngay cả CDN errors.

Một service thường cần nhiều SLO

Một API service thường cần:

1. Availability SLO: 99.9% requests không bị 5xx
2. Latency SLO: 95% requests respond < 200ms (riêng cho P95)
3. Latency SLO: 99% requests respond < 1s (riêng cho P99)

Các SLO này đo những khía cạnh khác nhau của reliability. Một service có thể fail latency SLO mà không fail availability SLO.

Critical User Journey (CUJ) làm cơ sở cho SLO

Thay vì tạo SLO cho từng API endpoint, tổ chức SLO theo Critical User Journey:

• User authentication journey: Login → token refresh → profile load
• Payment journey: Add to cart → checkout → payment confirmation
• Search journey: Query → results → detail page

Mỗi CUJ có SLO riêng, và SLI aggregate across all endpoints trong journey đó. Điều này reflect trải nghiệm user thực tế tốt hơn per-endpoint SLOs.

Constraints kỹ thuật của SLO trong Cloud Monitoring

Số lượng SLOs:

• Tối đa 500 SLOs per service
• Tối đa 500 services per project

Retention:

• SLO data được giữ 13 tháng
• Compliance period tối đa: 30 ngày (rolling) hoặc monthly (calendar)

Data freshness:

• Error budget display trong Console update mỗi vài phút
• Alert conditions evaluate theo alerting policy period, không real-time

Integration giới hạn:

• Cloud Monitoring SLOs chỉ hoạt động với metrics từ Cloud Monitoring
• Không trực tiếp integrate với Prometheus SLI data (phải import Prometheus metrics vào Cloud Monitoring trước qua GMP)

Anti-patterns

SLO không actionable

Đặt SLO 99.99% cho một service hiện tại đang chỉ deliver 99.5%. Mọi incident đều breach SLO, error budget luôn cạn → team fatigue với việc respond to "SLO breach" alerts.

SLO nên reflect realistic target dựa trên current baseline + small improvement, không phải aspirational target.

Quá nhiều SLOs

50 SLOs cho một service → không ai track được, không ai care. Bắt đầu với 2-3 SLOs cốt lõi, add thêm khi có evidence rằng chúng capture important user experience dimensions.

Không có error budget policy

Error budget chỉ có ý nghĩa nếu có quyết định gắn với nó. Câu hỏi quan trọng: "Khi error budget < 10%, team làm gì?" Nếu câu trả lời là "không có gì thay đổi" thì SLO chỉ là dashboard decoration, không có giá trị operational.

Policy mẫu:

• Error budget > 50%: Feature velocity bình thường
• Error budget 10-50%: Tăng testing, cẩn thận với risky deploys
• Error budget < 10%: Feature freeze, chỉ hotfix và reliability work
• Error budget 0%: Incident-level response, executive notification

Tham khảo chính thức

• SLO Monitoring Overview
• Creating SLOs
• MQL select_slo_burn_rate
• Alerting on SLOs with MQL
• SRE Workbook: Alerting on SLOs
• SRE Book: Service Level Objectives