Monitoring truyền thống trả lời câu hỏi đã biết trước ("CPU có vượt 80% không?"), còn Observability cho phép trả lời câu hỏi CHƯA biết trước khi sự cố xảy ra ("tại sao request này chậm bất thường?") — đây là điểm phân biệt quan trọng nhà tuyển dụng thường hỏi đầu tiên.
"Request chậm nhưng không rõ service nào gây ra, bạn debug thế nào trong hệ thống microservices?" — Đây chính là lúc distributed tracing phát huy giá trị — mỗi request có 1 trace ID xuyên suốt các service, cho phép xem breakdown thời gian xử lý ở từng service (tools phổ biến: Jaeger, Zipkin, hoặc managed như Datadog APM).
"Làm sao thiết kế alerting để tránh alert fatigue (quá nhiều cảnh báo khiến người ta bỏ qua)?" — Alert nên dựa trên tác động thực tế tới người dùng (SLO — Service Level Objective, vd. "error rate > 1% trong 5 phút") thay vì alert mọi biến động nhỏ (vd. CPU tăng 5%). Phân loại mức độ nghiêm trọng rõ ràng — không phải mọi alert đều cần đánh thức người on-call lúc nửa đêm.
SLI, SLO, SLA khác nhau thế nào? — SLI (Service Level Indicator) là chỉ số đo lường thực tế (vd. p99 latency). SLO (Objective) là mục tiêu nội bộ team đặt ra cho SLI đó (vd. p99 latency < 200ms trong 99.9% thời gian). SLA (Agreement) là cam kết với khách hàng, thường có ràng buộc pháp lý/bồi thường nếu vi phạm — SLA thường nới lỏng hơn SLO nội bộ để có biên độ an toàn.
Nếu từng thiết lập dashboard/alerting thật, hãy kể: metric nào được chọn làm SLI chính và lý do, ngưỡng alert được đặt ra sao (dựa trên dữ liệu lịch sử hay ước lượng), và 1 lần hệ thống observability giúp phát hiện/debug sự cố nhanh hơn nhiều so với không có nó.