Lỗi Google trên máy tính: nguyên nhân và cách khắc phục

Tác giả: Trường Thịnh ComputerĐăng ngày 24/04/2026Cập nhật 06/11/2026

Mô hình Error Budget Policy là một “khung kỷ luật” giúp doanh nghiệp cân bằng giữa độ tin cậy dịch vụ (reliability) và tốc độ phát hành tính năng (innovation/release velocity). Nội dung dưới đây là một ví dụ chính sách chuẩn, dễ áp dụng cho các hệ thống dịch vụ số, backend, ứng dụng di động và hạ tầng vận hành.

Google

Nội dung trong bài viết

Tổng quan tài liệu (Example Error Budget Policy)

Trạng thái	Đã phát hành
Tác giả	Steven Thurgood
Ngày	2018-02-19
Người review	David Ferguson
Người phê duyệt	Betsy Beyer
Ngày phê duyệt	2018-02-20
Ngày xem lại	2019-02-01

Service Overview (Tổng quan dịch vụ)

Dịch vụ ví dụ (Example Game Service) cho phép người dùng Android và iPhone chơi game cùng nhau. Chu kỳ phát hành:

Đang cần báo giá thiết bị tin học số lượng lớn? Xem mẫu, giá cập nhật và cách chọn tại Báo giá thiết bị tin học số lượng lớn.

Backend được phát hành mới mỗi ngày
Ứng dụng client được phát hành mới hàng tuần

Chính sách này áp dụng cho cả backend và client releases.

Mục tiêu (Goals)

Chính sách Error Budget Policy được thiết kế để:

Bảo vệ khách hàng khỏi tình trạng vi phạm SLO lặp lại
Tạo động lực để đội ngũ cân bằng giữa độ tin cậy và tính năng mới

Không phải mục tiêu (Non-Goals)

Chính sách này không nhằm “trừng phạt” khi SLO bị vi phạm. Việc dừng thay đổi là điều không mong muốn; thay vào đó, chính sách giúp đội ngũ có “quyền ưu tiên” tập trung hoàn toàn vào độ ổn định khi dữ liệu cho thấy reliability quan trọng hơn các hạng mục khác.

Chính sách khi vi phạm SLO (SLO Miss Policy)

Nếu dịch vụ đang vận hành đạt hoặc vượt SLO, các đợt phát hành (bao gồm cả thay đổi dữ liệu) sẽ tiếp tục theo chính sách release hiện hành.
Nếu dịch vụ đã vượt quá error budget trong cửa sổ 4 tuần gần nhất, toàn bộ thay đổi và phát hành sẽ tạm dừng, ngoại trừ:
- Xử lý sự cố P01
- Bản vá bảo mật (security fixes)

Việc tạm dừng này kéo dài cho tới khi dịch vụ quay trở lại trạng thái trong ngưỡng SLO.

Tùy theo nguyên nhân gây vi phạm SLO, đội ngũ có thể phải phân bổ thêm nguồn lực cho reliability thay vì phát triển tính năng.

Khi nào bắt buộc phải tập trung reliability?

Đội ngũ phải ưu tiên reliability nếu:

Lỗi phần mềm hoặc sai sót quy trình khiến dịch vụ tự tiêu hao error budget vượt ngưỡng
Postmortem cho thấy cơ hội để làm “mềm” một hard dependency
Lỗi bị phân loại sai khiến error budget không bị trừ theo đúng thực tế và đáng lẽ đã gây ra vi phạm SLO

Khi nào vẫn có thể làm tính năng không liên quan reliability?

Đội ngũ có thể tiếp tục phát triển tính năng nếu:

Sự cố do vấn đề mạng toàn công ty
Sự cố do một dịch vụ khác (do team khác vận hành), và team đó cũng đã đóng băng phát hành để xử lý reliability
Error budget bị tiêu hao bởi người dùng ngoài phạm vi SLO (ví dụ: load test hoặc đội pentest)
Lỗi bị phân loại sai khiến error budget bị trừ dù không ảnh hưởng người dùng

Chính sách sự cố (Outage Policy)

Nếu một sự cố đơn lẻ tiêu hao hơn 20% error budget trong 4 tuần, đội ngũ bắt buộc thực hiện postmortem. Báo cáo postmortem phải có ít nhất 1 hạng mục hành động P0 để xử lý nguyên nhân gốc (root cause).
Nếu một nhóm/sớp lỗi (một “class of outage”) tiêu hao hơn 20% error budget trong một quý, đội ngũ phải có một hạng mục P0 trong tài liệu kế hoạch theo quý2 để xử lý trong quý kế tiếp.

Chính sách leo thang (Escalation Policy)

Khi có bất đồng giữa các bên về cách tính error budget hoặc các hành động tương ứng, vấn đề cần được escalate lên CTO để ra quyết định.

Bối cảnh (Background)

Error budget là công cụ trong SRE dùng để cân bằng giữa độ tin cậy của dịch vụ và tốc độ đổi mới. Thay đổi (changes) là nguồn bất ổn chính, chiếm khoảng 70% số lần outage; đồng thời, nguồn lực phát triển tính năng thường cạnh tranh trực tiếp với nguồn lực nâng độ ổn định. Vì vậy, error budget đóng vai trò như một “cơ chế điều khiển”, giúp chuyển trọng tâm sang stability đúng thời điểm.

Cách hiểu cơ bản:

Error budget = 1 − SLO
Dịch vụ có SLO 99.9% sẽ có error budget 0.1%

Ví dụ: nếu dịch vụ nhận 1,000,000 request trong 4 tuần, SLO availability 99.9% tương ứng ngân sách lỗi là 1,000 lỗi trong khoảng thời gian đó.

Thông số/điểm quy chuẩn quan trọng (bullet)

Cửa sổ đánh giá error budget: 4 tuần
Điều kiện đóng băng phát hành: Vượt error budget trong 4 tuần trước đó
Ngoại lệ vẫn được phép thay đổi: P0 và security fixes
Ngưỡng bắt buộc postmortem theo sự cố đơn lẻ: > 20% error budget / 4 tuần
Ngưỡng theo nhóm lỗi trong 1 quý: > 20% error budget / quý
Cấp xử lý bất đồng: CTO

1P0 là mức ưu tiên cao nhất của bug: toàn bộ nguồn lực tập trung, dừng mọi việc khác cho tới khi khắc phục xong.

2Tại Google, kế hoạch theo quý được công khai và các team bị ràng buộc trách nhiệm theo kế hoạch.

[Previous

Appendix A – Example SLO Document

](/workbook/slo-document/)

[Next

Appendix C – Results of Postmortem Analysis

](/workbook/postmortem-analysis/)

Kết luận & gợi ý triển khai thực tế

Chính sách Error Budget Policy giúp đội ngũ có tiêu chuẩn rõ ràng để ra quyết định: khi hệ thống ổn định thì tăng tốc phát hành, khi độ tin cậy suy giảm thì ưu tiên reliability một cách có kiểm soát và minh bạch.

Nếu doanh nghiệp của bạn cần tư vấn triển khai quy chuẩn vận hành, tiêu chuẩn SLO/SLI, quy trình postmortem, hoặc tối ưu hệ thống máy chủ – thiết bị mạng phục vụ vận hành dịch vụ, Trường Thịnh Computer sẵn sàng đồng hành.

CÔNG TY TNHH CÔNG NGHỆ THÔNG TIN TRƯỜNG THỊNH