Preview Bản nháp chờ review — title, nội dung, link có thể sửa trước khi bỏ nhãn.

“99.9% uptime” trên slide marketing không giúp on-call. Cần SLI đo được, SLO mục tiêu, và error budget — phần được fail trong cửa sổ (tuần / tháng).

Series reliability (retry, shed, breaker) đều tiêu hoặc bảo vệ budget. Bài này nối chúng với quyết định ship/feature.

SLI / SLO / budget (gọn)

SLI  — chỉ số: % request HTTP < 300 trong 30 ngày
                 (hoặc availability, freshness lag…)
SLO  — mục tiêu: 99.9% → được fail 0.1%
Budget — “còn bao nhiêu % fail” trước khi cháy SLO

Hết budget → ưu tiên reliability, chậm feature risk

Chọn SLI sát user (checkout success), không chỉ “ping 200”.

Retry đốt budget thế nào

  • Retry thành công: user OK, SLI có thể vẫn xanh — nhưng dependency chịu N× load → rủi ro cascade (budget họ và sau đó cả bạn).
  • Retry fail hết: user fail + thời gian dài + inventory — tự hại.
  • Multi-hop retry: amplification — 1 user click → nhiều fail nội bộ trước 1 fail ngoài.

Policy: retry ở một tầng; jitter; max gắn timeout budget.

Shed: “mua” sống bằng error

Load shedding tăng error rate có chủ đích để tránh latency collapse (mọi request 30s = trải nghiệm zero).

  • SLI “success rate” xấu tạm; SLI “good experience under load” có thể tốt hơn nếu định nghĩa kèm latency.
  • Nên có multi-window: availability + latency SLO riêng.

Breaker fail-closed

Mở breaker → fail nhanh → error tăng, dependency được thở. Đúng hướng budget dài hạn; sai nếu threshold flap ( fail modes).

Quyết định thực dụng

Còn budget nhiều  → ship feature, chấp nhận risk vừa
Budget mỏng      → freeze risky deploy, fokus toil/retry storm
Budget âm         → incident reliability mode

Hỏi: thay đổi này (retry×3, hedge, prefetch↑)
     tăng fail user hay tăng load dependency bao nhiêu?

Một câu

Mỗi retry / mỗi nhận thêm load là đánh cược error budget.
Shed và breaker đổi error ngắn hạn lấy hệ còn sống — nói to với product.