Khi Monitoring nói dối

Có lúc Dashboard báo hệ thống không đạt Uptime như kỳ vọng. Nhưng khi kiểm tra thiết bị, chúng vẫn chạy. Log cũng không cho thấy downtime tương ứng.

Vậy thứ đang có vấn đề là hệ thống — hay chiếc đồng hồ chúng ta dùng để đo hệ thống?

Trong một đợt Capacity Assessment mà mình tham gia năm 2025, team phải đánh giá nhiều thành phần Network qua CPU, RAM, Bandwidth, Uptime, tình trạng thiết bị và khả năng đáp ứng trong những năm tiếp theo.

Monitoring data là nguồn dữ liệu rất quan trọng. Nếu không có historical data, chúng ta rất dễ vận hành dựa trên cảm giác: “hình như đường truyền này hơi cao”, “switch này chắc vẫn ổn”, hay “mấy tháng rồi chưa thấy user complain”.

Nhưng trong dữ liệu lúc đó có một chuyện khá thú vị. Một số thiết bị Core, Distribution và Firewall có Uptime nhìn trên Monitoring không đạt mức mong muốn. Nếu chỉ nhìn Dashboard, kết luận tự nhiên sẽ là: hệ thống đã từng bị downtime.

Thực tế lại không đơn giản như vậy. Trong một giai đoạn, một số Monitoring sensor bị mất kết nối với probe hoặc trả trạng thái Unknown. Điều này kéo số liệu Uptime xuống dù thiết bị vẫn hoạt động. Team phải cross-check bằng firewall log, switch log và những nguồn quan sát khác để xác nhận không có downtime thực tương ứng.

Mình nhớ tình huống này vì nó làm mình suy nghĩ khá lâu: chúng ta dùng Monitoring để quan sát hệ thống. Nhưng ai đang quan sát chính hệ thống Monitoring?

Dashboard không phải là Reality

Trong Infrastructure, chúng ta thường ra quyết định dựa trên representation của hệ thống. Một graph đại diện cho traffic. Một percentage đại diện cho CPU. Màu xanh đại diện Healthy. Màu đỏ đại diện Incident.

Nhưng tất cả đều đi qua một chuỗi trung gian.

Chỉ cần một mắt xích có vấn đề thì thứ chúng ta nhìn thấy đã bắt đầu lệch khỏi reality. Một Dashboard đẹp và quen thuộc còn dễ tạo ra automation bias: máy nói Down, mình tin là Down; Monitoring nói Uptime thấp, mình mặc nhiên coi đó là availability thực.

Tình huống năm 2025 khiến mình giữ một nguyên tắc đơn giản: Monitoring data là evidence. Nó không phải truth tuyệt đối.

Một phép đo chỉ có giá trị khi hiểu cách nó được tạo ra

Dữ liệu Capacity Assessment được lấy từ nhiều nguồn, trong đó Monitoring cung cấp CPU, RAM và Bandwidth. Mục tiêu không phải chụp một snapshot mà dùng historical data để hiểu mức sử dụng và làm cơ sở planning.

Nhưng sau câu chuyện sensor, mình quan tâm hơn tới câu hỏi: metric này được đo như thế nào?

Một device không trả SNMP có thể nghĩa là device chết. Nhưng cũng có thể SNMP service lỗi, ACL thay đổi, collector mất route, firewall chặn, Monitoring server quá tải hoặc sensor bị stuck. Nhiều nguyên nhân khác nhau có thể tạo ra cùng một biểu hiện: Unknown.

Vấn đề không nằm ở việc Monitoring đôi khi sai. Mọi system đều có thể sai. Vấn đề xuất hiện khi người vận hành quên rằng Monitoring platform cũng là một system.

Cross-check đôi khi quan trọng hơn một Dashboard hoàn hảo

Khi Uptime không khớp với những gì team quan sát trong thực tế, cách giải quyết không phải sửa số liệu để nó “đẹp”. Cách đúng hơn là tìm thêm independent evidence.

Firewall log có ghi interface flap không? Switch log có reload hay mất adjacency không? ISP có ghi nhận outage không? User hoặc application có cùng thời điểm gián đoạn không?

Đây cũng là lý do sau này khi làm Observability, mình không còn quá thích tư duy “hãy đưa tất cả vào một Dashboard”. Mình thích hơn câu hỏi: khi Dashboard này nói có vấn đề, mình có nguồn nào khác để chứng minh hoặc bác bỏ nó?

Centralization giúp vận hành nhanh. Independent evidence giúp chúng ta không bị chính sự centralization đó đánh lừa.

Monitoring tốt không có nghĩa là Alert thật nhiều

Trong cùng đợt đánh giá có thời điểm international bandwidth tăng rất cao do các đợt data transfer lớn lên cloud và hoạt động backup tập trung. Team phải điều phối lại thời gian truyền dữ liệu và làm việc với ISP trong thời gian cao điểm.

Đó là signal thật, nhưng cũng cho thấy threshold chỉ có ý nghĩa khi đặt trong context. Traffic 80% có thể là abnormal congestion, cũng có thể là migration đã được lên kế hoạch. CPU cao có thể là incident, cũng có thể là batch job đúng thiết kế.

Monitoring nói: “Có điều gì đó khác bình thường.” Engineering judgment mới trả lời: “Điều khác thường này có cần hành động không?”

Hệ thống rất nhàn vẫn có thể là Risk

Trong Capacity Assessment, nhiều thiết bị có CPU và RAM trung bình khá thấp. Nhìn thuần performance, chúng vẫn còn nhiều capacity. Nhưng khi đưa lifecycle vào bức tranh, câu chuyện thay đổi.

Một số dòng thiết bị đã EOS/EOL hoặc tiến gần giai đoạn không còn mức security patch, hardware replacement và software support phù hợp. Có nghĩa là một thiết bị có thể CPU thấp, RAM ổn, traffic thấp — và vẫn là Infrastructure risk.

Performance capacity và lifecycle capacity là hai chuyện khác nhau. Capacity cho biết thiết bị có đủ sức gánh workload. Lifecycle đặt câu hỏi khó hơn: mình còn có thể tin rằng thiết bị này sẽ được hỗ trợ khi sự cố thật sự xảy ra hay không?

Sau cùng, mình thay đổi cách nhìn Monitoring như thế nào?

Trước đây mình thường nghĩ mục tiêu của Monitoring là biết thật nhanh khi hệ thống hỏng. Bây giờ mình nghĩ mục tiêu đó chưa đủ.

Một hệ thống Monitoring trưởng thành phải giúp team trả lời được ít nhất ba điều: mình đang nhìn thấy gì; mình tin tín hiệu này đến mức nào; và tín hiệu này có ý nghĩa gì đối với operation.

Nếu không đặt câu hỏi thứ hai, Monitoring platform lỗi có thể tạo ra một incident không tồn tại. Nếu không đặt câu hỏi thứ ba, một platform hoạt động hoàn hảo vẫn có thể tạo ra hàng nghìn Alert mà không giúp engineer ra quyết định tốt hơn.

Chúng ta xây Monitoring để giảm uncertainty. Nhưng nếu không hiểu giới hạn của chính phép đo, Monitoring đôi khi lại tạo ra một loại uncertainty khác — nguy hiểm hơn, bởi nó xuất hiện dưới dạng một con số rất chính xác.

Và một con số chính xác không đồng nghĩa với một sự thật chính xác.