[Google-SRE-bản dịch tiếng việt]-SRE – Embracing Risk và Error Budget

📑 Mục Lục

1. Tư duy về độ tin cậy không tuyệt đối
2. Đo lường độ sẵn sàng và rủi ro
3. Xác định độ chịu rủi ro của dịch vụ
4. Error Budget là gì?

Tư duy về độ tin cậy không tuyệt đối

SRE không nhằm tạo ra hệ thống 100% không bao giờ lỗi. Mức độ tin cậy cực cao sẽ gây chậm trễ tính năng, tăng chi phí và thường vượt xa trải nghiệm thực tế người dùng cần. Vì vậy, Google chọn cách cân bằng giữa rủi ro ngừng dịch vụ và tốc độ phát triển.

Đo lường độ sẵn sàng và rủi ro

Độ sẵn sàng thường được mô tả bằng số "chín" – ví dụ 99.9%%, 99.99%%. Mỗi mức này cho phép một lượng thời gian gián đoạn không mong muốn trong năm.

Tuy nhiên, Google dùng cách đo dựa trên tỉ lệ yêu cầu thành công (request success rate) thay vì thời gian gián đoạn, để phản ánh đúng hơn thực tế hoạt động liên tục theo khu vực và tải trọng.

Ví dụ: Với 2.5 triệu request/ngày và mục tiêu 99.99%%, thì có thể chấp nhận tối đa 250 lỗi/ngày.

Xác định độ chịu rủi ro của dịch vụ

SRE cùng đội phát triển sẽ xác định các yếu tố:

• Mức độ tin cậy cần thiết
• Dịch vụ có trực tiếp tạo ra doanh thu không?
• Có cạnh tranh trong thị trường không?
• Là dịch vụ miễn phí hay trả phí?

Ví dụ:

• Gmail for Work có mục tiêu cao hơn YouTube vì phục vụ doanh nghiệp.
• Ads cần đo độ tin cậy gắn với tiền, nên mức độ "đáng đầu tư" rất rõ ràng.

Dịch vụ hạ tầng như Bigtable được phân tầng:

• Cụm latency thấp: phục vụ request online.
• Cụm throughput cao: phục vụ phân tích batch. Điều này giúp tối ưu chi phí.

Error Budget là gì?

Error Budget = phần "được phép lỗi" của một dịch vụ trong một quý, dựa trên Service Level Objective (SLO).

Ví dụ:

• SLO: 99.99%% thành công ⇒ cho phép 0.01%% lỗi trong quý.
• Nếu đã dùng 70%% ngân sách lỗi, nhóm phát triển cần thận trọng đẩy code.

Lợi ích:

• Cân bằng giữa độ tin cậy và tốc độ ra mắt.
• Tránh mâu thuẫn giữa SRE và dev team.
• Tăng tính minh bạch và ra quyết định theo dữ liệu.