Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn là một Site Reliability Engineer (SRE) tại một sàn thương mại điện tử. Đội phát triển sản phẩm muốn tuần nào cũng đẩy tính năng mới ra production để cạnh tranh; đội vận hành lại muốn "đóng băng" hệ thống để giữ ổn định. Hai bên giằng co, mỗi lần họp là một cuộc tranh luận cảm tính: "Deploy nhiều quá sập hệ thống mất!" đối đầu với "Không ra tính năng thì mất khách hàng!". Không ai có dữ liệu để phân xử, và người thắng thường là người... nói to nhất hoặc có chức vụ cao hơn.
Error Budget (ngân sách lỗi) chính là công cụ chấm dứt cuộc chiến đó. Đây là một trong những phát minh quan trọng nhất mà Google mang lại cho ngành vận hành phần mềm. Nó biến một câu hỏi mang tính chính trị — "chúng ta có nên ưu tiên tốc độ hay độ ổn định?" — thành một câu hỏi định lượng có câu trả lời rõ ràng: "Chúng ta còn bao nhiêu ngân sách lỗi? Nếu còn thì cứ chạy nhanh, nếu hết thì phanh lại."
Ở Bài 8 bạn đã học cách phân biệt SLI, SLO, SLA và cách chọn chúng. Bài 9 này là bước tiếp theo tự nhiên: khi đã có SLO, bạn sẽ dùng nó để làm gì trong thực tế? Câu trả lời chính là Error Budget và cách nó điều khiển quyết định vận hành hằng ngày. Nếu SLO chỉ nằm trên slide mà không dẫn tới hành động, nó vô nghĩa. Error Budget là cây cầu nối SLO với hành động cụ thể.
Khái niệm cốt lõi
Error Budget là gì
Công thức nền tảng vô cùng đơn giản:
Error Budget = 100% − SLO
Nếu bạn đặt SLO availability là 99.9%, thì error budget của bạn là 0.1%. Đây là phần "được phép hỏng" — khoảng thời gian hoặc số request mà hệ thống được phép thất bại mà vẫn không vi phạm cam kết.
Điểm mấu chốt cần thấm: error budget không phải là điều xấu cần né tránh bằng mọi giá. Nó là một nguồn tài nguyên được cấp phép để tiêu dùng. Cũng giống như bạn có ngân sách chi tiêu hằng tháng — mục đích của ngân sách là để tiêu, chứ không phải để cất trong két. Một đội để error budget dư thừa quá nhiều thực ra đang lãng phí: họ đã quá thận trọng, ra tính năng quá chậm, và có lẽ đã đầu tư quá mức vào độ tin cậy so với nhu cầu thật của người dùng.
Quy đổi ra thời gian downtime cụ thể
Để error budget trở nên trực quan, hãy quy nó ra phút downtime cho phép trong một tháng (lấy tháng chuẩn 30 ngày = 43.200 phút):
- SLO 99% → budget 1% → khoảng 432 phút/tháng (hơn 7 giờ)
- SLO 99.9% ("three nines") → budget 0.1% → khoảng 43 phút/tháng
- SLO 99.95% → budget 0.05% → khoảng 21,6 phút/tháng
- SLO 99.99% ("four nines") → budget 0.01% → khoảng 4,3 phút/tháng
- SLO 99.999% ("five nines") → budget 0.001% → khoảng 26 giây/tháng
Error budget dựa trên request-based hay time-based
Có hai cách đo tiêu hao budget, và bạn cần chọn cách phù hợp với đặc thù hệ thống:
Time-based (theo thời gian): đếm số phút hệ thống ở trạng thái "unhealthy". Đơn giản, dễ giải thích cho người ngoài kỹ thuật, phù hợp khi bạn đo bằng hệ thống giám sát bên ngoài (uptime check mỗi phút).
Request-based (theo số request): Error Budget = tổng số request được phép lỗi. Ví dụ trong tháng có 100 triệu request, SLO 99.9% nghĩa là bạn được phép để tối đa 100.000 request thất bại. Cách này chính xác hơn với dịch vụ có lưu lượng biến động: một phút downtime lúc 3 giờ sáng (ít traffic) rõ ràng ít nghiêm trọng hơn một phút downtime lúc 8 giờ tối giờ cao điểm. Request-based tự động phản ánh điều đó vì nó tính theo số request thực sự bị ảnh hưởng.
Error Budget Policy — linh hồn của cả hệ thống
Bản thân con số error budget vô dụng nếu không có chính sách đi kèm để quyết định "khi budget cạn thì làm gì". Đây gọi là Error Budget Policy, và nó phải được các bên (đội sản phẩm, đội SRE, quản lý cấp trên) thống nhất và ký duyệt trước khi sự cố xảy ra — chứ không phải tranh cãi trong lúc khủng hoảng.
Một chính sách điển hình chia thành các ngưỡng:
- Còn nhiều budget (ví dụ > 50%): Đội được toàn quyền deploy nhanh, thử nghiệm, chạy các thay đổi rủi ro. Đây là lúc "đạp ga".
- Budget cạn dần (ví dụ còn 10–50%): Bắt đầu thận trọng, tăng cường review, ưu tiên các thay đổi nâng cao độ ổn định.
- Budget cạn kiệt (đã tiêu hết): Kích hoạt "feature freeze" — dừng mọi deploy tính năng mới, toàn đội chuyển sang xử lý các vấn đề độ tin cậy cho đến khi budget hồi phục.
Burn rate — tốc độ đốt ngân sách
Một khái niệm quan trọng đi kèm là burn rate: bạn đang tiêu error budget nhanh tới mức nào so với mức "tiêu đều" cho phép. Burn rate = 1 nghĩa là bạn đang tiêu đúng nhịp và sẽ vừa vặn hết budget đúng cuối chu kỳ. Burn rate = 10 nghĩa là bạn đang đốt nhanh gấp 10 lần — nếu cứ đà này, budget cả tháng sẽ cháy sạch chỉ trong 3 ngày. Đây là cơ sở để thiết kế cảnh báo (alert) thông minh: cảnh báo khi burn rate cao (sự cố lớn đang diễn ra) thay vì cảnh báo mỗi khi có một lỗi lẻ tẻ — chủ đề này sẽ được đào sâu ở Bài 18 về chiến lược alerting.
Tình huống thực tế
Ví dụ 1 — Sàn TMĐT ShopFast và cuộc đình chiến sản phẩm vs vận hành
ShopFast (giả định) là một sàn thương mại điện tử tại TP.HCM, cao điểm khoảng 40 triệu request/tháng cho dịch vụ checkout. Đội đặt SLO availability 99.9% cho luồng thanh toán, tương đương budget khoảng 43 phút downtime/tháng.
Đầu tháng, mọi thứ êm đẹp, budget còn nguyên. Đội sản phẩm tự tin đẩy liên tục ba tính năng lớn: mã giảm giá mới, tích hợp ví điện tử, và gợi ý sản phẩm bằng AI. Đến ngày 12, một bản deploy ví điện tử gây lỗi timeout hàng loạt ở khâu thanh toán, mất 28 phút mới rollback xong. Chỉ một sự cố đã ngốn gần 65% budget cả tháng.
Theo Error Budget Policy đã ký từ trước, khi budget rơi xuống dưới 30%, đội tự động chuyển sang chế độ "thận trọng": mọi deploy phải qua review kỹ hơn và ưu tiên bản vá ổn định. Đến ngày 20, một sự cố hạ tầng database ngốn thêm 18 phút — budget cạn sạch. Feature freeze được kích hoạt: hai tính năng còn lại bị hoãn, cả đội dồn sức thêm retry hợp lý và circuit breaker cho luồng thanh toán.
Bài học: Điều đẹp nhất ở đây là không ai phải cãi nhau. Quyết định "dừng ra tính năng" không đến từ sếp gõ bàn, mà đến từ một con số khách quan mà cả hai bên đã đồng thuận từ trước. Chính sách được ký lúc "thời bình" nên lúc "thời chiến" không ai bị bất ngờ hay cảm thấy bị xử ép.
Ví dụ 2 — Fintech PayViet và cái bẫy "budget thừa"
PayViet (giả định), một startup fintech, đặt SLO 99.99% cho API cổng thanh toán vì "khách hàng doanh nghiệp đòi hỏi cao". Budget chỉ vỏn vẹn hơn 4 phút/tháng. Suốt sáu tháng, đội cực kỳ thận trọng: mỗi deploy phải qua ba vòng duyệt, mỗi tuần chỉ dám release một lần vào tối thứ Ba, có tháng còn không dám đụng gì.
Cuối quý, một kỹ sư SRE mới về rà lại số liệu và phát hiện điều thú vị: suốt sáu tháng, thực tế hệ thống chưa tháng nào tiêu quá 20% budget. Nói cách khác, họ đã đầu tư dư thừa vào độ tin cậy và trả giá bằng tốc độ ra tính năng chậm chạp — trong khi đối thủ ra tính năng nhanh gấp đôi.
Đội quyết định hạ SLO xuống 99.95% (budget khoảng 21 phút/tháng) — mức mà khảo sát cho thấy khách hàng doanh nghiệp không hề cảm nhận khác biệt. Với budget rộng hơn, họ tăng nhịp deploy lên hằng ngày, thử nghiệm nhiều hơn, và tốc độ giao tính năng tăng đáng kể.
Bài học: Error budget dư nhiều không phải huy chương, mà là tín hiệu cảnh báo bạn đang quá bảo thủ. Mục đích của budget là để tiêu. SLO đặt quá cao so với nhu cầu thật sẽ âm thầm bóp nghẹt khả năng cạnh tranh.
Ví dụ 3 — Grab và burn rate trong một sự cố nghiêm trọng
Lấy bối cảnh một nền tảng gọi xe quy mô khu vực như Grab. Giả sử dịch vụ ghép tài xế đặt SLO 99.95%, budget khoảng 21 phút/tháng. Vào một tối cao điểm, một thay đổi cấu hình routing gây lỗi 5% số request ghép xe.
Nếu chỉ nhìn con số tuyệt đối "mới mất 3 phút thôi", trực đêm có thể chủ quan. Nhưng nếu nhìn burn rate, bức tranh khác hẳn: đốt 5% lỗi liên tục nghĩa là burn rate khoảng 100 lần mức bình thường — với đà này toàn bộ budget tháng sẽ cháy sạch trong chưa đầy 15 phút. Cảnh báo dựa trên burn rate cao lập tức kích hoạt ở mức nghiêm trọng nhất, kéo on-call vào cuộc ngay, và sự cố được rollback trong vài phút thay vì để âm ỉ hàng giờ.
Bài học: Đừng chỉ nhìn budget còn lại, hãy nhìn tốc độ đốt. Một burn rate cao trong thời gian ngắn nguy hiểm hơn nhiều so với việc tiêu đều đặn. Burn rate biến error budget từ một báo cáo tĩnh cuối tháng thành công cụ phát hiện sự cố theo thời gian thực.
Hướng dẫn từng bước
Đây là quy trình để bạn triển khai error budget cho một dịch vụ từ con số không:
Bước 1 — Xác nhận SLO đã có. Error budget bắt nguồn từ SLO. Nếu chưa có SLO rõ ràng (đã học ở Bài 8), hãy quay lại chọn SLI và đặt SLO trước. Ví dụ: SLO availability 99.9% đo trên tỷ lệ request HTTP trả về không phải lỗi 5xx.
Bước 2 — Tính error budget và chu kỳ. Lấy 100% − SLO để ra phần trăm budget, rồi chọn cửa sổ thời gian (rolling window). Phổ biến nhất là cửa sổ trượt 28 hoặc 30 ngày. Rolling window tốt hơn "reset mỗi đầu tháng lịch" vì nó không tạo ra hiệu ứng "đầu tháng thoải mái, cuối tháng hoảng loạn".
Bước 3 — Đo mức tiêu hao thực tế. Dùng hệ thống giám sát để tính liên tục: đã tiêu bao nhiêu budget, còn lại bao nhiêu, và burn rate hiện tại. Nếu chưa có công cụ chuyên dụng, một dashboard đơn giản đếm request lỗi so với tổng request cũng đủ để bắt đầu.
Bước 4 — Soạn Error Budget Policy và lấy chữ ký. Đây là bước quan trọng nhất và hay bị bỏ qua nhất. Viết rõ: khi budget còn X% thì làm gì, khi cạn thì freeze ra sao, ai có quyền phê duyệt ngoại lệ, freeze kéo dài đến khi nào thì gỡ. Đưa cho đội sản phẩm và quản lý cùng ký duyệt.
Bước 5 — Gắn cảnh báo theo burn rate. Cấu hình alert bắn khi burn rate vượt ngưỡng (ví dụ: bắn cảnh báo nghiêm trọng khi burn rate ≥ 14.4 duy trì trong 1 giờ — con số kinh điển của Google tương ứng đốt 2% budget/giờ). Cách này giúp cảnh báo gắn với tác động thật thay vì bắn loạn xạ.
Bước 6 — Đưa vào nhịp làm việc định kỳ. Mỗi tuần hoặc mỗi sprint, mở dashboard budget ra xem cùng nhau. Budget trở thành một chỉ số sức khỏe được review đều đặn, chứ không phải thứ chỉ đào ra khi có sự cố.
Lỗi thường gặp & mẹo
Có SLO nhưng không có policy. Đây là lỗi số một. Nhiều đội tính được error budget đẹp đẽ nhưng khi budget cạn thì... không làm gì cả, vẫn deploy như thường. Budget không có "răng" thì chỉ là trang trí. Policy được ký duyệt trước mới tạo ra sức ràng buộc.
Đặt SLO 100% hoặc quá cao. SLO 100% nghĩa là budget bằng 0 — bất kỳ lỗi nào cũng là vi phạm, và bạn không bao giờ được phép deploy hay bảo trì. Đây là mục tiêu bất khả thi và phản tác dụng. Luôn chừa budget để còn không gian đổi mới.
Coi việc tiêu budget là thất bại của cá nhân. Nếu tiêu budget bị xem là "lỗi của ai đó" và đem ra khiển trách, mọi người sẽ giấu sự cố và né rủi ro. Budget là tài nguyên chung của đội để tiêu dùng có trách nhiệm, không phải thước đo để trừng phạt — tinh thần này gắn chặt với văn hóa blameless ở Bài 11.
Quên yếu tố phụ thuộc. Nếu dịch vụ của bạn SLO 99.9% nhưng phụ thuộc vào một nhà cung cấp bên thứ ba chỉ cam kết 99.5%, thì về mặt toán học bạn không thể đạt mục tiêu. Hãy tính budget có tính đến các phụ thuộc, hoặc thiết kế dự phòng để không bị phụ thuộc kéo tụt.
Mẹo — dùng budget làm "giấy phép đầu tư". Khi còn nhiều budget, đó là tín hiệu tốt để mạnh dạn thử canary deployment, chaos engineering hay migration lớn. Budget cho bạn "không gian an toàn" để chấp nhận rủi ro có kiểm soát.
Mẹo — cẩn thận với reset theo tháng lịch. Ưu tiên rolling window để tránh tâm lý "đầu tháng tha hồ đốt vì mai sẽ reset". Rolling window buộc đội luôn ý thức về mức tiêu hao gần đây.
Bài tập thực hành
Bài 1 — Tính toán cơ bản. Một dịch vụ đặt SLO availability 99.95% trên cửa sổ 30 ngày. Hãy tính error budget theo phần trăm và quy ra số phút downtime cho phép trong tháng. Nếu tháng đó đã có một sự cố kéo dài 12 phút, đội còn lại bao nhiêu budget (phút)?
Bài 2 — Request-based. Dịch vụ API của bạn xử lý 80 triệu request/tháng với SLO 99.9%. Hãy tính số request được phép lỗi trong tháng. Nếu đến giữa tháng đã có 55.000 request lỗi, bạn đã tiêu bao nhiêu phần trăm budget, và điều đó gợi ý hành động gì theo một policy 3 ngưỡng?
Bài 3 — Soạn policy. Viết một Error Budget Policy ngắn (khoảng nửa trang) cho luồng thanh toán của một sàn TMĐT với SLO 99.9%. Nêu rõ tối thiểu: hành động ở ba ngưỡng budget (còn nhiều / cạn dần / cạn kiệt), ai có quyền phê duyệt ngoại lệ, và điều kiện để gỡ feature freeze.
Bài 4 — Phân tích burn rate. Dịch vụ SLO 99.9% (budget 43 phút/tháng) đang gặp sự cố đốt budget với tốc độ 2 phút mỗi giờ. Nếu không xử lý, sau bao lâu budget sẽ cạn? Burn rate này gấp bao nhiêu lần mức "tiêu đều" cho phép? Bạn có nên đánh thức on-call lúc 3 giờ sáng không, và vì sao?
Tóm tắt
Error Budget là công cụ biến độ tin cậy từ một cuộc tranh luận cảm tính thành một quyết định dựa trên dữ liệu. Công thức cốt lõi rất đơn giản — Error Budget = 100% − SLO — nhưng sức mạnh của nó nằm ở tư duy đằng sau: budget là tài nguyên được cấp để tiêu, không phải thứ cần né tránh bằng mọi giá. Còn budget thì đạp ga đổi mới; hết budget thì phanh lại củng cố độ ổn định.
Những điểm cần khắc cốt ghi tâm: (1) SLO càng nhiều số "9" thì budget càng nhỏ và chi phí càng đắt theo cấp số nhân — hãy chọn mức người dùng thật sự cần; (2) con số budget vô nghĩa nếu thiếu Error Budget Policy được ký duyệt trước để quy định hành động khi budget cạn; (3) đừng chỉ nhìn budget còn lại mà hãy theo dõi burn rate để phát hiện sự cố nghiêm trọng theo thời gian thực; (4) budget dư quá nhiều là dấu hiệu bạn đang quá bảo thủ, không phải thành tích. Nắm vững error budget, bạn đã có trong tay cây cầu nối giữa SLO trên giấy và những quyết định vận hành thực tế mỗi ngày.