Oncall Bot và giám sát frontend

Vấn đề

Những lượt rời bỏ âm thầm khi chuyển sang bên thứ ba, như bước kiểm tra NFC, chỉ được phát hiện vài ngày sau qua bộ phận chăm sóc khách hàng. Cảnh báo của chúng tôi dựa trên ngưỡng cố định và rất nhiễu, nên mọi người đã quen bỏ qua.

Cách tiếp cận

• Mốc tương đối thay vì ngưỡng cố định. Dịch vụ cảnh báo chạy SQL trên ClickHouse và so sánh mỗi chỉ số với cùng giờ tuần trước. Tỷ lệ chuyển đổi giảm 20% có ý nghĩa rất khác lúc 3 giờ sáng ở Tokyo và giữa trưa ở Berlin, và sự dao động lưu lượng toàn cầu không còn gây báo động giả.
• Cảnh báo đến kèm ngữ cảnh. Khi cảnh báo kích hoạt, nó đăng một thẻ sự cố lên nền tảng chat nội bộ. Sau đó một tiến trình nền thu thập stack trace lỗi frontend gần đây từ ClickHouse, phiên bản cấu hình đang áp dụng từ dịch vụ cấu hình và log triển khai Kubernetes, rồi gửi chúng dưới dạng prompt có cấu trúc tới API LLM doanh nghiệp.
• Bản tóm tắt ngay trong luồng. Bot trả lời bằng một nguyên nhân gốc khả dĩ, ví dụ: tỷ lệ chuyển đổi bước 3 giảm 32% ở Nhật Bản, lỗi con trỏ null trong lớp bọc cầu nối NFC, một thay đổi cấu hình được triển khai 15 phút trước và cổng của nhà cung cấp bị quá thời gian ở backend.

Kết quả

Thời gian phát hiện giảm từ vài giờ hoặc vài ngày xuống dưới 5 phút, thời gian khắc phục tạm thời giảm 65% và cảnh báo sai giảm 80%. Tôi cũng theo dõi tỷ lệ tín hiệu trên nhiễu của cảnh báo (tỷ lệ cảnh báo ứng với sự cố thật) và thời gian trung bình giữa các lần lỗi của các module frontend.

Vì sao làm như vậy

Một cảnh báo thông thường chỉ cho bạn biết có thứ gì đó hỏng. Tự động thu thập dữ liệu và tóm tắt lại sẽ thu hẹp khoảng cách giữa một chỉ số và việc một người thật sự hiểu nó, và đó chính là nơi phần lớn thời gian phản ứng bị tiêu tốn.