Best Practices for Real-time Machine Learning: Alerting

Nubank · 2022 · 3. Quy mô lớn · Độ khó: Dễ — bài gốc

Bài tổng hợp thực hành từ nhiều năm vận hành model real-time ở Nubank, không kể một hệ thống cụ thể; mọi nhận định là theo Nubank.

Bối cảnh

• Model real-time chấm điểm theo yêu cầu, nên gặp mọi lỗi của phần mềm thường (latency tăng vì tải dồn, sập vì upstream, deploy hỏng) cộng thêm lỗi riêng của ML: feature thiếu hoặc hỏng, phân phối dân số đổi đột ngột. Khác biệt chính: model có thể hỏng âm thầm, vẫn trả dự đoán sai mà không có exception nào.

Thay đổi chính

• Tách alerting khỏi monitoring: alert để hành động nhanh, khung giờ/phút, người nhận bị động; monitoring để hiểu và điều tra, khung ngày/tuần/tháng, người xem chủ động mở dashboard. Việc đầu tiên khi nhận alert thường là mở dashboard so dữ liệu ngắn hạn với trung hạn.
• Phần vận hành thường vẫn áp dụng: lỗi hệ thống, latency, scale (CPU, RAM), logging và tracing tập trung, lịch on-call.
• Quy tắc viết alert:
  • Chuẩn hoá kênh, định dạng và loại số liệu (trung bình, percentile, đếm).
  • Ghi cả giá trị kỳ vọng và khung thời gian: "kỳ vọng 100–150, nhận 250 trong 30 phút qua" chứ không chỉ "giá trị là 250".
  • Hành động được: kèm link tới DLQ, playbook, cấu hình scale, feature flag hay kênh Slack.
  • Dễ chỉnh: alert của model sẽ lỗi thời khi phân phối đổi, thành quá nhạy (alert fatigue) hoặc quá cùn; ai cũng phải chỉnh được ngưỡng, snooze, tắt, ack ngay từ alert.
  • Theo người nhận: cùng một sự việc, engineer nhận tỉ lệ timeout, người làm ML nhận latency lấy feature, người làm sản phẩm nhận "ít khách được duyệt vay hơn bình thường".
  • Ack và theo dõi được: ai đang xử lý, lúc nào bắn, có phải báo giả, đã giảm thiểu thế nào; dữ liệu này dùng để tìm thủ phạm hay gặp.
• Mẹo: alert cho sự vắng mặt của sự kiện (service chết thì không có log để tính trung bình) bằng heartbeat; test alert bằng cách hạ ngưỡng giả; tính mùa vụ (ngày/đêm, cuối tuần) bằng ngưỡng cỡ mẫu tối thiểu (chỉ bắn khi tỉ lệ điểm > 0,9 vượt 20% và có ít nhất 10.000 mẫu); ở quy mô hàng triệu request mỗi ngày, tính alert trên mẫu ngẫu nhiên (ví dụ 10%) để giảm chi phí, miễn phân phối đủ lớn.

Vì sao

• Alert là sự kiện hiếm và hỗn loạn; thông tin người trực cần đầu tiên nên nằm sẵn trong alert, và hệ phải cho biết đã có người nhận việc để không ai giẫm chân nhau.

Bài học cho SWE

• Với hệ có thể sai mà không lỗi, metric trên output (phân phối điểm) là alert hạng nhất, không chỉ metric sức khoẻ.
• Một alert tốt trả lời trước câu hỏi "bình thường là bao nhiêu, trong khung nào, làm gì tiếp".
• Thiếu dữ liệu cũng là tín hiệu; cần cơ chế heartbeat để bắt nó.

Liên quan

• Nền tảng ML (feature, training, serving, giám sát model) · Xử lý sự cố và on-call
• Cùng công ty: Nubank 2019 · Nubank 2023
• Cùng bài toán: DoorDash 2021 · SoundCloud 2019