Quyền truy cập nhóm vào số dư dùng chung chỉ tiện cho đến tháng đầu tiên mà số tiền chi thực tế lệch so với kỳ vọng. Một tài khoản chung không phân chia theo nhân viên và công việc sẽ không trả lời được câu hỏi ai đã chi ngân sách vào việc gì, trừ khi bạn mở lịch sử giao dịch và đọc từng dòng. Bài viết này phân tích cách giới hạn chi tiêu bằng khóa, ngưỡng và hướng, cũng như cách nhanh chóng tìm ra tiến trình đang đốt tiền nhanh hơn các tiến trình còn lại.
Vì sao số dư dùng chung không có giới hạn hao hụt âm thầm
Một số dư cho cả nhóm chỉ hoạt động tốt cho đến lần sai sót đầu tiên. Khi có nhiều nhân viên hoặc nhiều tiến trình tự động cùng kết nối vào đó, tiền bị trừ song song, và bạn chỉ nhận ra sau khi sự việc đã xảy ra, lúc số dư gần về 0. Số dư dùng chung không phân tách chỉ trả lời câu hỏi "còn lại bao nhiêu", chứ không trả lời câu hỏi "ai đã chi".
Vấn đề càng nghiêm trọng hơn vì chi phí qua API không cần xác nhận ở từng bước: một script chạy liên tiếp một nghìn lượt kích hoạt sẽ bị trừ tiền cho đúng một nghìn lượt kích hoạt liên tiếp đó, và người biết đầu tiên không phải tác giả của script mà là người không còn đủ số dư cho một việc gấp. Cần có giới hạn không phải vì không tin tưởng nhân viên, mà vì không ai có thể theo dõi bộ đếm chi tiêu theo thời gian thực.
Khóa riêng với hạn mức khác nhau: phân chia công việc và nhân viên
Cách làm hiệu quả là không dùng một khóa API cho cả nhóm, mà tạo một khóa riêng cho từng nhân viên hoặc từng công việc: đăng ký hàng loạt, giám sát, môi trường thử nghiệm. Mỗi khóa có hạn mức chi tiêu riêng, nên sự cố của một tiến trình không chặn các tiến trình khác và không ngốn ngân sách dành cho công việc khác. Cách thiết lập khóa và các tham số của khóa được mô tả trong tài liệu API.
Việc chia theo khóa cũng giải quyết vấn đề trách nhiệm: nếu chi tiêu của một khóa cụ thể vượt quá mức bình thường, bạn thấy ngay tiến trình hoặc nhân viên nào gây ra mà không cần đọc lại toàn bộ lịch sử chung từng dòng. Bạn có thể vô hiệu hóa một khóa bị lộ hoặc đang chạy sai mà không phải dừng các công việc còn lại của nhóm.
Ngưỡng chi tiêu theo ngày và theo tháng
Một hạn mức duy nhất cho cả kỳ thanh toán sẽ không bắt được tình trạng đốt tiền nhanh: nếu ngưỡng tháng là năm trăm đơn vị quy ước, còn một tiến trình bị lỗi tiêu hết số tiền đó trong ba giờ, thì hạn mức tháng chỉ dừng nó khi ngân sách đã về 0. Ngưỡng theo ngày phát hiện vấn đề ngay trong ngày, chứ không phải vào cuối tháng.
Cách làm hiệu quả là đặt cả hai ngưỡng cùng lúc: ngưỡng ngày giới hạn tốc độ đốt tiền trên từng khóa, còn ngưỡng tháng giới hạn tổng ngân sách của một công việc hoặc một nhân viên trong kỳ. Hạn mức ngày nên đặt dư ra so với khối lượng công việc thông thường, đừng đặt sát, nếu không nó sẽ chặn cả công việc hợp lệ vào những ngày cao điểm.
Theo dõi theo hướng và cảnh báo khi chạm ngưỡng
Hướng là một cặp cụ thể gồm quốc gia và dịch vụ, và chi tiêu hầu như không bao giờ phân bổ đều: thường chỉ một hai hướng chiếm phần ngân sách lớn một cách không cân xứng. Việc theo dõi chi tiêu theo từng hướng, chứ không chỉ theo tổng số tiền, giúp bạn nhanh chóng thấy tổ hợp nào đang kéo ngân sách xuống, trước khi nó trở thành vấn đề cho toàn bộ số dư.
Cảnh báo chỉ kích hoạt khi hạn mức đã cạn thì không còn tác dụng, vì công việc đã dừng. Cách làm hiệu quả là thông báo theo hai bậc: lần đầu ở mức 70–80% ngưỡng được cấp để bạn kịp xử lý, lần hai ở mức 95%, khi đã đến lúc dừng thủ công các tiến trình không quan trọng. Cả hai ngưỡng nên được đặt ở cấp khóa, chứ không phải cấp số dư chung, nếu không cảnh báo lại đến quá muộn.
Kịch bản điển hình: vòng lặp thử lại trên hướng đã chết ngốn hết ngân sách trong vài giờ
Sự cố thường gặp diễn ra như sau: một hướng hôm qua còn trả mã ổn định bỗng nhiên không gửi được SMS nữa, do nhà mạng đổi tuyến hoặc hướng đó tạm thời ngừng hoạt động ở nhà cung cấp. Tiến trình tự động thử lại khi kích hoạt bị hủy không phân biệt được "một lần xui" với "hướng đã chết": nó đặt số lại hết lần này đến lần khác, và mỗi lần thử đều bị trừ vào số dư.
Nếu khóa không có hạn mức ngày, vòng lặp như vậy có thể tiêu hết ngân sách dự kiến cho một tuần chỉ trong vài giờ. Vì thế, trong lịch sử giao dịch, mỗi tuần bạn nên xem không chỉ tổng chi tiêu mà cả chuỗi hủy liên tiếp trên cùng một hướng: ba đến năm lần hủy liên tiếp trên một cặp quốc gia - dịch vụ là tín hiệu để dừng hướng đó, chứ không phải thử lại.
Câu hỏi thường gặp
Nên tạo bao nhiêu khóa cho một nhóm?
Mức tham khảo là một khóa cho mỗi nhân viên hoặc mỗi tiến trình độc lập, thay vì dùng ngay một khóa chung cho cả nhóm. Việc chia nhỏ chỉ có ý nghĩa khi mỗi khóa tương ứng với một phạm vi trách nhiệm, chứ không trở thành hình thức.
Phải làm gì nếu hạn mức của khóa cạn giữa chừng một công việc?
Nâng hạn mức một lần cho khóa cụ thể thường nhanh và an toàn hơn so với gỡ bỏ hoàn toàn giới hạn: như vậy vấn đề của một tiến trình không lan sang các khóa khác của nhóm. Nếu hạn mức luôn quá chật với một công việc đang hoạt động, bạn nên cân nhắc nâng lên, chứ không nên tắt kiểm soát hoàn toàn.
Làm sao phân biệt chi tiêu tăng đột biến thông thường với tình trạng đốt tiền trên hướng đã chết?
Mức tăng đột biến thông thường được phân bổ giữa nhiều hướng và dịch vụ khác nhau. Còn đốt tiền là khi chi tiêu tập trung vào một cặp quốc gia - dịch vụ với tỷ lệ cao các lượt bị hủy hoặc thất bại liên tiếp, điều này có thể thấy trong lịch sử giao dịch của chính ngày hôm đó.
Toàn bộ lịch sử trừ tiền theo từng khóa và từng hướng nằm trong mục lịch sử giao dịch: ở đó bạn thấy khóa nào và hướng nào cần dừng trước tiên. Một khoản chi tiêu ngầm khác của nhóm là các số nhàn rỗi trong thời gian thuê, được phân tích trong bài rà soát kho số điện thoại.