Bài 5 — Cảnh báo, Lineage/Audit và giảm MTTR
Phát hiện được vấn đề mới là một nửa. Nửa còn lại: cảnh báo đúng người, điều tra nhanh, khắc phục gọn — và chứng minh được mọi thứ khi bị hỏi. Bài này về alerting, lineage/audit và chỉ số sống còn MTTR (Mean Time To Recovery).
Alerting: ít mà chất
Một hệ thống cảnh báo tệ còn nguy hiểm hơn không có, vì nó tạo alert fatigue — đội ngũ tê liệt, bỏ qua cả cảnh báo thật. Nguyên tắc:
- Cảnh báo phải hành động được (actionable). Nếu nhận alert mà không biết làm gì → đó là noise, phải sửa hoặc bỏ.
- Phân mức nghiêm trọng (severity): P1 (đánh thức người lúc 3h sáng) vs P3 (xem trong giờ hành chính). Đừng để mọi thứ là P1.
- Gắn ngữ cảnh vào alert: dashboard, phiên bản mô hình, feature nghi ngờ, runbook — để người nhận hành động trong giây, không phải giờ.
- Symptom-based ưu tiên hơn cause-based: cảnh báo theo tác động người dùng ("tỷ lệ lỗi checkout tăng") thường hữu ích hơn cảnh báo theo nguyên nhân mơ hồ.
Lineage & Audit: truy vết để giải trình
Lineage = khả năng trả lời: "Dự đoán này đến từ đâu?" Cụ thể phải truy được:
- Phiên bản mô hình nào tạo ra dự đoán (
v2.3), train từ dataset nào, code/commit nào. - Đặc trưng đầu vào tại thời điểm đó (feature values, feature store version).
- Ai đã approve promotion, quality gate cho kết quả gì.
- Tuân thủ (compliance): GDPR, luật tín dụng, y tế... yêu cầu giải thích quyết định tự động. "Vì sao khoản vay của tôi bị từ chối?" phải trả lời được.
- Điều tra sự cố: không có lineage, mỗi incident là một cuộc điều tra mò kim đáy bể → MTTR tăng vọt.
- Niềm tin: khách hàng và cơ quan quản lý tin vào hệ thống giải trình được.
MTTR: chỉ số vận hành sống còn
MTTR = thời gian trung bình từ lúc sự cố xảy ra đến lúc phục hồi. Nó gộp: phát hiện + chẩn đoán + khắc phục. Giảm MTTR nghĩa là tấn công từng phần:
- Phát hiện nhanh hơn → monitoring & alert tốt (Bài 2, 5).
- Chẩn đoán nhanh hơn → lineage + dashboard + runbook.
- Khắc phục nhanh hơn → rollback tự động (Bài 3), mitigation có sẵn.
Khung tư duy: vòng đời incident (Detect → Triage → Diagnose → Mitigate → Resolve → Learn)
- Detect: alert kích hoạt.
- Triage: đúng người, đúng severity, trong bao lâu?
- Diagnose: lineage cho biết mô hình/dataset/feature nào.
- Mitigate: giảm đau ngay (rollback, nới ngưỡng, tắt tính năng).
- Resolve: sửa gốc rễ (retrain qua quality gate).
- Learn: postmortem không đổ lỗi, cập nhật golden set + alert.
Ví dụ cụ thể
3h sáng, tỷ lệ lỗi ở luồng gợi ý tăng. Alert P1 gửi kèm dashboard + link runbook. On-call thấy lineage: mô hình vừa canary lên v4.1 cách đó 40 phút. Runbook chỉ rõ lệnh rollback. Mitigate trong 6 phút (rollback về v4.0). Sáng hôm sau, diagnose kỹ: feature store trả null do đổi schema. Fix, thêm ca này vào golden set + thêm input-health alert. MTTR = 6 phút thay vì 6 giờ — nhờ alert có ngữ cảnh, lineage rõ, rollback tự động.
Checklist alerting, lineage & MTTR
- [ ] Mỗi alert có owner, severity, runbook đính kèm.
- [ ] Loại bỏ alert không hành động được định kỳ.
- [ ] Lineage truy được model version ↔ dataset ↔ code ↔ approver.
- [ ] Có runbook cho các sự cố phổ biến nhất.
- [ ] Đo và theo dõi MTTR như một product metric.
- [ ] Postmortem không đổ lỗi sau mỗi sự cố lớn, cập nhật golden set/alert.
Sai lầm thường gặp
- Mọi alert đều P1 → alert fatigue → bỏ lỡ sự cố thật.
- Cảnh báo không có ngữ cảnh, buộc on-call điều tra từ số 0 lúc 3h sáng.
- Không có lineage, nên mỗi sự cố là một cuộc khảo cổ, MTTR tăng và compliance rủi ro.
- Không đo MTTR, nên không biết mình đang tệ đi hay tốt lên.
- Postmortem đổ lỗi cá nhân, khiến người ta giấu sự cố — độc hại cho văn hóa vận hành.