Vì sao chúng tôi đưa quy tắc bồi thường vào sản phẩm thay vì giấu trong kịch bản hỗ trợ

Tiến độ triển khai (cập nhật 2026-07-09): bài viết mô tả thiết kế đầy đủ của hệ thống bồi thường. Quy tắc và thuật toán áp dụng như trong bài; hiện tại bồi thường theo hình thức gửi yêu cầu — liên hệ hỗ trợ để nộp, chúng tôi duyệt thủ công theo thuật toán công khai rồi ghi vào số dư (cách gửi yêu cầu). Giám sát tự động đã hoạt động; tính toán, ghi có tự động và email hàng tháng đang triển khai từng bước — trước đó, các mô tả về ghi có hoàn toàn tự động và email hàng tháng trong bài là trạng thái mục tiêu.

SLA trên thị trường trông thế nào

Đọc văn bản SLA của mười dịch vụ API phổ biến, chúng gần như giống hệt nhau:

• Cam kết độ khả dụng (thường 99,9% / 99,95%)
• Một bảng ánh xạ thời gian ngừng hoạt động sang tỷ lệ bồi thường (5%–50% phí tháng)
• Một điều khoản “người dùng phải tự khiếu nại kèm bằng chứng”
• Một điều khoản “loại trừ bất khả kháng”

Các văn bản này thực sự được dùng bao nhiêu? Chúng tôi hỏi vài đồng nghiệp: gần như bằng không. Phản ứng đầu tiên của người dùng khi gặp sự cố là đổi nhà cung cấp, không phải đọc SLA.

Lý do rất đơn giản: chi phí của quy trình khiếu nại cao hơn khoản bồi thường có thể nhận. Đăng nhập, mở ticket, tải ảnh chụp màn hình, chờ 7 ngày làm việc xét duyệt, cuối cùng may ra nhận được phiếu 15% phí tháng — tính cả thời gian thì lỗ.

Việc chúng tôi đã làm

Chúng tôi biến bồi thường từ “một tài liệu lúc có sự cố mới lục ra” thành logic tự động trong sản phẩm — quy tắc, tính toán và ghi có đều không cần bạn thao tác gì.

1. Tháng dương lịch + nhóm SKU + ba bậc bồi thường

Sau khi mỗi tháng dương lịch (UTC+8) đóng lại, chúng tôi tính bồi thường độc lập theo từng nhóm SKU của tháng đó (Claude / Claude Code / GPT / Gemini / Qwen / một nhóm mô hình Trung Quốc giảm 50% / Doubao) dựa trên độ khả dụng:

• ≥ 99% — không bồi thường
• 98% – 99% — 2% giá trị đơn của SKU đó trong tháng
• 95% – 98% — 5%
• < 95% — 10% (trần tháng cũng là 10%)

Tính bậc độc lập nghĩa là: nếu tháng này Claude 96% / GPT 99,5% / Gemini 100%, chỉ phần Claude được bồi thường 5%; các SKU khác giữ nguyên. Vì sao không dùng công thức liên tục hay bậc trung gian mịn hơn? Vì cả khách hàng lẫn BD đều phải nhẩm được trong đầu. Mỗi lần giải thích với khách “96,3% của bạn ứng với 5pp + 0,3 × X” là phí thời gian. Ba bậc nhảy còn củng cố mốc mục tiêu “giữ 95%” — oncall tự biết đó là sàn.

2. Tự quyết toán cuối tháng — bạn không cần phát hiện sự cố

Sau khi chạy xong cuối tháng, 9h ngày 3 tháng sau mọi khách hàng bị ảnh hưởng nhận một email: độ khả dụng tháng theo từng nhóm SKU, số tiền bồi thường, chi tiết tính toán. Số tiền trước tiên vào tài khoản chờ — bạn thấy trong email và trên dashboard, nhưng chưa dùng được. Trong cửa sổ khiếu nại 7 ngày (ngày 3–10 tháng sau), bạn hoặc chúng tôi có thể phản đối cách tính; khi cửa sổ đóng mà không có khiếu nại được chấp nhận, số tiền tự động thành số dư dùng được. Quá cửa sổ thì mặc định chấp nhận. Mỗi khoản bồi thường ≥ ¥5000 trước tiên bị đóng băng 24 giờ để vận hành rà soát (chống lỗi dashboard bồi nhầm), rà soát đạt rồi mới vào tài khoản chờ.

Mẫu cực nhỏ không kích hoạt bồi thường: một SKU dưới 100 lượt gọi/tháng, hoặc một SKU có dưới 1000 mẫu toàn nền tảng/tháng, theo quy tắc không kích hoạt bồi thường tháng đó — “94%” tính từ 50 lượt gọi nhiễu thống kê quá lớn, không thể làm căn cứ bồi thường. Phạm vi SLA không đổi, chỉ là trường hợp này không có khoản chi tính được.

3. Tiêu chí thất bại chỉ tính các lỗi cứng chúng tôi chịu trách nhiệm — và ở đây có sự căng thẳng

Chỉ ba loại yêu cầu này được tính vào tử số “không khả dụng”:

• Máy chủ thượng nguồn trả 5xx (500/502/503/504)
• Thượng nguồn không trả byte đầu trong 60 giây (quá hạn)
• Gateway của chúng tôi trả 5xx (sập tầng định tuyến / tính phí)

Giới hạn tần suất chủ động, 401 / 429 từ thượng nguồn, 4xx phía client, hết số dư đều không tính. Đây là lựa chọn gây tranh cãi, và chúng tôi phải nói rõ sự căng thẳng:

Client có thể gặp “rõ ràng không dùng được mà con số SLA vẫn 99%” — ví dụ một key của bạn chạm giới hạn QPS (chúng tôi trả 429, mời thử lại), hoặc token của một tài khoản thượng nguồn hết hạn và chúng tôi đang chuyển. Bạn cảm thấy “dịch vụ không ổn định”, nhưng con số SLA không nhúc nhích.

Chúng tôi chọn tiêu chí này không phải để bảo vệ con số, mà vì chỉ các lỗi cứng ở gateway của chúng tôi + máy chủ thượng nguồn mới là điều mà ngữ nghĩa SLA có thể chịu trách nhiệm. Giới hạn tần suất là chính sách sản phẩm (ghi trong tài liệu tích hợp); 4xx phía client là lỗi tầng yêu cầu; nhét hai loại này vào độ khả dụng sẽ biến SLA thành con số mà chính chúng tôi cũng không hiểu nổi. Với các vấn đề giới hạn / 401 / 429 thực sự ảnh hưởng việc chạy code của bạn, chiến lược của chúng tôi là oncall chủ động xem cảnh báo + chuyển kênh trong 30 giây, không phải chờ ticket của bạn.

4. Trừ cửa sổ bảo trì có ràng buộc, không được dùng để làm đẹp con số

Bảo trì có kế hoạch có thể trừ khỏi mẫu số, nhưng chỉ khi đồng thời thỏa ba điều kiện: thông báo ≥ 7 ngày + mỗi lần ≤ 4h + cộng dồn tháng ≤ 8h. Phần vượt 8h quay lại mẫu số tính là sự cố; bảo trì do thượng nguồn chủ động (dù báo trước) không được trừ — đó là vấn đề của thượng nguồn, không phải của chúng tôi. Quy tắc này cố ý viết chặt, để vận hành không biến cửa sổ bảo trì thành công cụ làm đẹp SLA.

Cái giá của cách làm này

• Phải mô hình hóa lại dự báo tài chính — bồi thường giờ là chi phí thực, không còn là “lời hứa sẽ không được thực hiện”. Chúng tôi lập tỷ lệ quỹ dự phòng bồi thường theo dữ liệu sự cố lịch sử, khoảng 0,4% doanh thu.
• Ngưỡng độ chính xác giám sát nâng lên — nếu phán đoán sai sự cố là đang tặng tiền cho người dùng. Thuật toán phán định sự cố của chúng tôi được review code hai người và chạy shadow một tháng trước khi ra mắt.
• Không thể nói dối về sự cố — trước đây có thể nói “dao động ngẫu nhiên”; giờ hóa đơn ghi rõ số tiền bồi thường trắng đen, thiếu trung thực là tự tát mặt mình.

Vì sao viết bài này lúc này

Gần đây trò chuyện với vài đội, chúng tôi thấy kỳ vọng về SLA của dịch vụ API đã rất thấp — “viết ra cũng vô dụng thôi”. Điều chúng tôi muốn nói là: SLA không nhất thiết là văn bản pháp lý; nó có thể chính là sản phẩm. Không phải chúng tôi thông minh, chỉ là chuẩn của ngành quá thấp.

Nếu bài này khiến bạn nghĩ “à, hóa ra có thể làm vậy”, thế là đủ.