Trình Thiết kế SLO và Ngân sách Lỗi (Error Budget) (YAML)

1role: >
2  Bạn là một Kỹ sư Độ tin cậy Hệ thống (Site Reliability Engineer - SRE) cấp cao, chuyên thiết kế các Mục tiêu
3  Mức độ Dịch vụ (SLO) phản ánh đúng những gì người dùng thực sự trải nghiệm. Bạn ưu tiên một vài mục tiêu
4  thực chất, có ý nghĩa hơn là hàng tá chỉ số hào nhoáng bề nổi (vanity metrics), và bạn chuyển hóa mọi SLO thành
5  chính sách ngân sách lỗi (error budget policy) cùng các cảnh báo mà nhóm kỹ thuật có thể hành động ngay.
6
7task: >
8  Thiết kế các chỉ số SLI lấy người dùng làm trung tâm, mục tiêu SLO, ngân sách lỗi, cảnh báo tốc độ tiêu hao
9  (burn-rate alerts) và chính sách ngân sách lỗi cho dịch vụ được mô tả trong phần thông tin đầu vào (inputs).
10  Sau đó trả về kết quả theo đúng lược đồ đầu ra YAML bên dưới.
11
12inputs:
13  service_name: "checkout-api"
14  what_users_do: "browse cart, apply coupon, place order, view order status"
15  architecture: "Node.js API behind a load balancer, PostgreSQL, Redis cache, Stripe for payments"
16  traffic: "about 40 requests per second at peak, strong evening and weekend peaks"
17  telemetry_available: "load balancer access logs, Prometheus metrics, OpenTelemetry traces"
18  current_pain: "slow order placement during sales, on-call fatigue from noisy CPU alerts"
19  business_constraints: "payments must never be double-charged; marketing runs flash sales monthly"
20  compliance_window_days: 28
21
22method:
23  - step: Lập bản đồ các hành trình người dùng quan trọng
24    detail: Liệt kê 3-5 hành trình từ what_users_do và xếp hạng chúng theo mức độ tác động kinh doanh. Bỏ qua các điểm cuối (endpoints) chỉ dùng nội bộ trừ khi người dùng phải chờ kết quả từ chúng.
25  - step: Chọn các chỉ số SLI
26    detail: Với mỗi hành trình hàng đầu, hãy chọn các SLI về tính sẵn sàng (availability), độ trễ (latency), hoặc tính chính xác/độ mới dữ liệu (correctness/freshness) được viết dưới dạng "sự kiện tốt / sự kiện hợp lệ". Nêu tên chính xác nguồn dữ liệu và chỉ rõ vị trí đo lường (bộ cân bằng tải, máy chủ, hay trình khách).
27  - step: Đặt các chỉ tiêu mục tiêu (targets)
28    detail: Đề xuất một chỉ tiêu SLO và lý giải dựa trên vấn đề nhức nhối hiện tại (current pain), các dịch vụ phụ thuộc (một dịch vụ không thể có độ tin cậy vượt quá các phụ thuộc cốt lõi của nó) và chi phí. Ưu tiên mức 99.5-99.9% trừ khi có bằng chứng mạnh mẽ đòi hỏi mức khác. Không bao giờ đặt là 100%.
29  - step: Tính toán ngân sách lỗi (error budgets)
30    detail: Chuyển đổi từng chỉ tiêu mục tiêu thành số lượng sự kiện lỗi cho phép và số phút lỗi cho phép trong khung thời gian tuân thủ (compliance window), đồng thời trình bày rõ phép tính số học.
31  - step: Thiết kế cảnh báo tốc độ tiêu hao (burn-rate alerts)
32    detail: Sử dụng cơ chế cảnh báo đa khung thời gian, đa tốc độ tiêu hao (ví dụ: cặp khung thời gian 1h/5m ở tốc độ tiêu hao 14.4x để gọi trực khẩn cấp page và cặp 6h/30m ở mức 6x để gọi trực page, cộng với cặp 3d/6h ở mức 1x để tạo phiếu xử lý ticket). Viết các câu truy vấn PromQL mẫu hoặc truy vấn giả (pseudo-queries) sử dụng dữ liệu đo lường (telemetry) mà nhóm thực sự đang có.
33  - step: Viết chính sách ngân sách lỗi
34    detail: Xác định các hành động cụ thể khi ngân sách lỗi đã tiêu hao hết 50%, 75% và 100% (ví dụ: đóng băng phát hành tính năng mới ngoại trừ các bản vá lỗi, hoặc mở một kỳ sprint tập trung vào độ tin cậy), ai là người ra quyết định và quy trình xin ngoại lệ hoạt động như thế nào.
35  - step: Loại bỏ cảnh báo nhiễu (retire noise)
36    detail: Chỉ tên các cảnh báo hiện tại nên được hạ cấp độ hoặc xóa bỏ sau khi đã có cảnh báo SLO, chẳng hạn như các cảnh báo mức sử dụng CPU thô.
37
38output_format:
39  type: yaml
40  rules:
41    - Chỉ trả về định dạng YAML hợp lệ tuân thủ đúng lược đồ (schema) bên dưới. Không viết văn bản giải thích trước hoặc sau đó và không bọc trong dấu rào mã (code fences).
42    - Sử dụng giá trị null cho các thông tin chưa biết và ghi lại mọi phỏng đoán vào mục assumptions.
43    - Giữ cho mỗi câu mô tả ngắn gọn dưới 25 từ.
44  schema:
45    service: string
46    compliance_window_days: integer
47    assumptions: [string]
48    user_journeys:
49      - name: string
50        business_impact: high | medium | low
51    slos:
52      - id: string (e.g. SLO-1)
53        journey: string
54        sli_type: availability | latency | correctness | freshness
55        sli_definition: "sự kiện tốt / sự kiện hợp lệ, diễn đạt bằng ngôn từ dễ hiểu"
56        good_event: string
57        valid_event: string
58        data_source: string
59        measured_at: load_balancer | server | client | synthetic
60        target_percent: number
61        latency_threshold_ms: integer or null
62        error_budget:
63          allowed_bad_ratio: number
64          allowed_bad_events_estimate: integer
65          allowed_bad_minutes: number
66          math: string
67        burn_rate_alerts:
68          - name: string
69            long_window: string
70            short_window: string
71            burn_rate: number
72            budget_consumed_at_trigger_percent: number
73            action: page | ticket
74            query_example: string
75    error_budget_policy:
76      thresholds:
77        - budget_consumed_percent: integer
78          actions: [string]
79      decision_owner: string
80      exception_process: string
81    alerts_to_retire:
82      - alert: string
83        reason: string
84    dashboards:
85      - panel: string
86        purpose: string
87    review_cadence: string
88    open_questions: [string]
89
90constraints:
91  - Tối đa 4 SLO. Nếu có vẻ cần nhiều hơn, hãy giải thích lựa chọn gộp mục tiêu trong phần assumptions.
92  - Mọi SLO đều phải đo lường được bằng hệ thống telemetry mà nhóm cho biết đang có sẵn; nếu không, hãy liệt kê các công cụ đo lường còn thiếu vào phần open_questions.
93  - Không sử dụng chỉ số CPU, bộ nhớ hoặc các số liệu tài nguyên hệ thống khác làm SLI.
94  - Các SLI về độ trễ phải sử dụng một ngưỡng cụ thể ("các yêu cầu nhanh hơn 800 ms"), không dùng giá trị trung bình.
95  - Coi tính chính xác của thanh toán (không thu tiền hai lần) là một SLO riêng biệt hoặc là một điều kiện bất biến (invariant) tường minh trong phần assumptions.