Posted inDevOps

Vượt xa con số 100% Uptime: Hướng dẫn thực tế về Error Budget

DevOps tutorial - IT technology blog
DevOps tutorial - IT technology blog

Bản hòa ước giữa Dev và Ops

Developer sống để đẩy code. Team vận hành (Ops) sống vì sự ổn định. Hai mục tiêu này thường xung đột với nhau, tạo ra một cuộc kéo co không hồi kết mỗi khi triển khai. Google đã giải quyết sự căng thẳng này bằng cách giới thiệu khái niệm Error Budget (Ngân sách lỗi). Thay vì theo đuổi mức uptime 100%—một ảo tưởng cực kỳ tốn kém—chúng ta xác định chính xác mức độ thất bại mà hệ thống có thể chấp nhận được.

Từ kinh nghiệm thực chiến của mình, tôi nhận ra rằng Error Budget không chỉ là một chỉ số. Nó là một bản hợp đồng xã hội. Nó quy định khi nào bạn có thể đi nhanh và khi nào bạn phải dừng lại để củng cố nền tảng. Nó biến cuộc tranh luận “Chúng ta có nên release không?” thành một quyết định dựa trên dữ liệu.

Toán học trong 5 phút: Quy đổi các con số “9” thành phút

Trước khi chạm vào dashboard, bạn cần nắm vững các phép tính cơ bản. Error Budget đơn giản là phần dư ra từ Service Level Objective (SLO) của bạn.

Công thức: Error Budget = 100% - SLO%

Hãy xem xét SLO về độ khả dụng 99,9% trong chu kỳ 30 ngày. Ngân sách lỗi của bạn là 0,1%. Trong thời gian thực tế, nó sẽ như sau:

  • Tổng thời gian hàng tháng: 43.200 phút.
  • Thời gian downtime cho phép: 43,2 phút.

Nếu một đợt triển khai lỗi mất 15 phút để rollback, bạn vừa tiêu hết 35% ngân sách tháng. Nếu bạn chạm mức 0 vào ngày thứ 20, bản hòa ước sẽ có hiệu lực: Bạn phải dừng mọi đợt phát hành tính năng mới và dành 100% nỗ lực kỹ thuật cho độ tin cậy (reliability) cho đến khi ngân sách được reset.

Chọn những chỉ số thực sự quan trọng

Bạn không thể có ngân sách nếu thiếu Service Level Indicator (SLI). Trong khi nhiều team theo dõi “server uptime”, đó thường chỉ là một chỉ số hình thức. Một server có thể đang “chạy” trong khi API lại trả về lỗi 500 cho mọi người dùng. Thay vào đó, hãy tập trung vào Tỷ lệ yêu cầu thành công (Request Success Rate) hoặc Độ trễ (Latency).

1. Availability SLI

Chỉ số này đo lường tỷ lệ yêu cầu thành công trên tổng số yêu cầu hợp lệ. Trong Prometheus, bạn có thể tính tỷ lệ thành công trong 30 ngày qua bằng truy vấn này:

sum(rate(http_requests_total{status=~"2..|3.."}[30d])) 
/
sum(rate(http_requests_total[30d]))

2. Latency SLI

Chậm cũng giống như chết. Nếu trang thanh toán mất 10 giây để tải, người dùng sẽ rời đi. Một SLO điển hình có thể là: “90% yêu cầu phải hoàn thành dưới 500ms.” Mỗi yêu cầu tốn 501ms sẽ ngốn một phần nhỏ ngân sách của bạn.

sum(rate(http_request_duration_seconds_bucket{le="0.5"}[30d])) 
/
sum(rate(http_request_duration_seconds_count[30d]))

Theo dõi Burn Rate: Hệ thống cảnh báo sớm

Đợi đến khi ngân sách chạm mức 0% là công thức dẫn đến thảm họa. Bạn cần theo dõi Burn Rate—tốc độ tiêu thụ ngân sách cho phép. Burn rate bằng 1 nghĩa là bạn sẽ hết ngân sách vừa đúng vào cuối tháng. Burn rate là 14,4 nghĩa là một cuộc khủng hoảng; bạn sẽ mất 2% toàn bộ ngân sách tháng chỉ trong một giờ.

Tôi đề xuất một chiến lược cảnh báo phân tầng. Dùng Slack cho những biến động nhỏ, nhưng hãy để dành PagerDuty cho các mức burn rate cao. Nếu burn rate trong 1 giờ vượt quá 14, ai đó cần phải thức dậy và kiểm tra log ngay lập tức.

Ví dụ về logic cảnh báo (Prometheus)

groups:
- name: ErrorBudgetAlerts
  rules:
  - alert: HighErrorBudgetBurn
    expr: |
      (sum(rate(http_requests_total{status="500"}[1h])) / sum(rate(http_requests_total[1h]))) 
      > (1 - 0.999) * 14.4
    for: 5m
    labels:
      severity: critical
    annotations:
      summary: "Cảnh báo tiêu thụ ngân sách nghiêm trọng: Đang tiêu tốn 2% ngân sách tháng mỗi giờ."

Chính sách: Chuyện gì xảy ra khi ngân sách bằng 0?

Theo dõi ngân sách thì dễ. Thay đổi hành vi mới là phần khó. Một văn hóa SRE hiệu quả đòi hỏi một chính sách đã được phê duyệt mà tất cả mọi người—từ CEO đến dev thực tập—đều phải tôn trọng. Chính sách này thường bao gồm ba trụ cột:

  1. Đóng băng tính năng (Feature Freeze): Khi hết ngân sách, việc triển khai sẽ dừng lại. Chỉ các bản vá bảo mật và sửa lỗi độ tin cậy mới được đưa lên production.
  2. Hậu kiểm không đổ lỗi (Blameless Post-Mortems): Bất kỳ sự cố nào tiêu tốn hơn 10% ngân sách (khoảng 4 phút cho SLO 99,9%) đều xứng đáng được điều tra kỹ lưỡng.
  3. Trả nợ độ tin cậy (Reliability Debt Repayment): Team chuyển trọng tâm sang các công việc tồn đọng về độ tin cậy, như thêm circuit breaker hoặc cải thiện độ phủ của test tự động.

Những bài học xương máu từ thực tế

Cái giá đắt đỏ của những con số 9 bổ sung

Tôi đã thấy nhiều quản lý yêu cầu 99,99% (bốn số 9) mà không nhận ra rằng nó chỉ cho phép 4,3 phút downtime mỗi tháng. Nếu người dùng của bạn đang dùng kết nối 4G chập chờn, họ sẽ không nhận thấy sự khác biệt giữa 99,9% và 99,99%. Tuy nhiên, chi phí hạ tầng của bạn có khả năng sẽ tăng gấp ba để đạt được mục tiêu đó. Thay vào đó, hãy dùng ngân sách để chấp nhận những rủi ro có tính toán.

Bảo trì không phải là một ngoại lệ miễn phí

Theo tiêu chuẩn SRE của Google, bảo trì định kỳ nên được tính vào ngân sách lỗi. Điều này nghe có vẻ khắc nghiệt, nhưng nó hiệu quả. Nó buộc các team phải xây dựng hệ thống hỗ trợ cập nhật cuốn chiếu (rolling update) và di trú không gây gián đoạn (zero-downtime migration). Nếu nó ảnh hưởng đến người dùng, nó sẽ ảnh hưởng đến ngân sách.

Trực quan hóa những gì đang bị đe dọa

Đừng giấu những con số này trong bảng tính. Hãy dùng Grafana để đưa biểu đồ “Ngân sách còn lại” (Budget Remaining) lên màn hình lớn trong văn phòng. Nhìn thấy dòng chữ đỏ rực “Còn lại 0,05%” là một cách mạnh mẽ để thống nhất sự tập trung của cả team mà không cần nói một lời. Nó biến độ tin cậy từ một cuộc tranh luận cảm tính thành một sứ mệnh chung.

Share:
Tags: