Infrastructure • 26/08/2026

Hệ thống vẫn chạy tốt, tại sao vẫn phải thay?

CPU vẫn thấp. RAM vẫn còn dư. Traffic chưa chạm trần. Hệ thống vẫn chạy mỗi ngày. Vậy tại sao chúng tôi lại bắt đầu nói đến chuyện thay nó?

Performance Capacity còn dư nhưng Lifecycle Risk có thể tăng
Một hệ thống có thể vẫn đủ sức gánh workload hôm nay, trong khi mức độ đáng tin của nền tảng đã bắt đầu giảm theo vòng đời.

Câu hỏi này từng làm mình nhận ra rằng, trong Infrastructure, “còn chạy được” và “còn nên tiếp tục tin cậy” là hai chuyện rất khác nhau.

Performance Capacity còn dư nhưng Lifecycle Risk có thể tăng
Performance Capacity và Lifecycle Risk có thể đi theo hai hướng hoàn toàn khác nhau.

Những con số rất dễ làm mình yên tâm

Trong một đợt Capacity Assessment năm 2025, mình cùng team nhìn lại nhiều lớp của Network Infrastructure: Firewall, Router, Core, Distribution, Access, Wireless và các đường truyền. Historical monitoring data được dùng để xem CPU, RAM, Bandwidth và Uptime thay vì chỉ nhìn một snapshot tại thời điểm đánh giá.

Kết quả của nhiều thiết bị khá dễ chịu. CPU không cao. RAM còn dư. Bandwidth phần lớn chưa phải bottleneck thường trực. Nếu câu hỏi duy nhất là “thiết bị có đủ sức gánh workload hiện tại không?”, câu trả lời ở nhiều chỗ là: có.

Và đây chính là lúc Capacity Planning dễ dừng quá sớm.

Một graph CPU thấp nói cho mình biết thiết bị chưa bị quá tải. Nó không nói nguồn điện đã chạy bao nhiêu năm. Nó không nói vendor còn phát hành security fix bao lâu. Nó cũng không nói khi một module hỏng, mình còn tìm được replacement part trong thời gian business chấp nhận hay không.

Performance graph rất giỏi kể câu chuyện về workload. Nó gần như im lặng về tuổi đời của nền tảng.

Lifecycle Risk là thứ không hiện màu đỏ trên Dashboard

Khi mở rộng assessment sang lifecycle, bức tranh thay đổi. Một số platform đã đi tới hoặc tiến gần EOS/EOL. Có thiết bị performance vẫn tốt nhưng supportability giảm dần theo thời gian. Và trong lịch sử vận hành, những sự cố phần cứng như nguồn, port hay interface cũng nhắc mình rằng tuổi đời vật lý không thể nhìn qua CPU percentage.

Điều thú vị là những risk này thường không tạo Alert ngay hôm nay.

Không có trigger nào nói: “thiết bị này vẫn chạy tốt, nhưng ba năm nữa việc tìm spare part sẽ khó”. Không có Dashboard đỏ vì software train sắp hết support. Hệ thống vẫn xanh — cho đến ngày một failure biến một rủi ro âm thầm thành incident thật.

Đó là lúc mình thấy Capacity Planning nên có hai chiều: Performance CapacityLifecycle Capacity.

Một chiều hỏi: nó còn đủ sức không?

Chiều kia hỏi: nó còn đủ đáng tin để tiếp tục đặt workload quan trọng lên đó không?

Thay thiết bị không nên là phản xạ trước chữ EOL

Nhưng mình cũng không nghĩ cứ thấy EOL là phải lập tức mua mới.

Infrastructure luôn có giới hạn về budget, change window và nguồn lực triển khai. Một thiết bị hết vòng đời nhưng nằm ở vị trí ít critical, có spare và có phương án bypass có thể mang risk khác hoàn toàn với một thiết bị tương tự đang nằm trên critical path.

Vì vậy lifecycle information chỉ là đầu vào. Engineering decision vẫn phải nhìn thêm business impact, redundancy, failure history, supportability, security exposure và khả năng recovery.

Ma trận kết hợp Performance Capacity và Lifecycle Risk để ra quyết định
Không phải thiết bị cũ nào cũng có cùng mức ưu tiên. Performance và Lifecycle cần được đặt trong cùng một decision model.

Nhìn theo cách này, assessment không còn dẫn tới một danh sách đơn giản kiểu “giữ” và “thay”. Nó dẫn tới roadmap: cái gì chỉ cần theo dõi, cái gì nên tối ưu, cái gì cần budget cho giai đoạn tới và cái gì phải ưu tiên trước.

Mình thích roadmap hơn một danh sách mua sắm vì roadmap thừa nhận một thực tế: Infrastructure modernization là một quá trình, không phải một ngày thay toàn bộ thiết bị.

Thay khi còn chủ động luôn khác với thay trong khủng hoảng

Có một khác biệt rất lớn giữa hai tình huống.

Tình huống thứ nhất: team biết một platform đang già đi, có thời gian đánh giá option, chuẩn bị budget, test configuration, lên maintenance window, viết validation plan và rollback plan.

Tình huống thứ hai: thiết bị chết vào một ngày không ai chọn. Team bắt đầu tìm spare part, kiểm tra compatibility, gọi vendor và thay đổi hệ thống trong lúc business đang chờ service quay lại.

Cuối cùng cả hai đều có thể kết thúc bằng một thiết bị mới.

Nhưng mức rủi ro trên đường đi hoàn toàn khác.

So sánh planned replacement và crisis replacement
Planned replacement không loại bỏ risk; nó cho team nhiều quyền kiểm soát risk hơn.

Đó cũng là lý do mình không xem lifecycle management như chuyện “đồ cũ thì thay”. Với mình, nó gần với risk management hơn.

Mình đang cố mua lại một thứ rất quan trọng cho team vận hành: quyền được lựa chọn thời điểm.

Capacity Planning cuối cùng không chỉ nói về Capacity

Sau đợt assessment đó, điều mình nhớ nhất không phải một con số CPU hay Bandwidth cụ thể.

Mình nhớ sự thay đổi trong câu hỏi.

Từ:

“Hệ thống hiện tại còn chạy nổi không?”

sang:

“Trong một đến vài năm tới, đây còn là nền tảng mà mình muốn business tiếp tục phụ thuộc vào không?”

Câu thứ hai khó hơn vì nó buộc Infrastructure phải nhìn ra ngoài Dashboard: lifecycle, support, security, failure history, recovery capability, budget và cả thời điểm thích hợp để thay đổi.

Một hệ thống có thể hoạt động rất nhẹ hôm nay nhưng mang theo một món nợ vận hành ngày càng lớn cho ngày mai.

Vì vậy, một hệ thống còn chạy được chưa chắc là một hệ thống chúng ta còn nên đặt niềm tin vào.

Ghi lại từ những trải nghiệm thực tế của mình trong quá trình làm Infrastructure — những câu chuyện vẫn còn tiếp tục.

Đọc trước ← Khi Monitoring nói dối

Đọc tiếp → Resilience không chỉ là Uptime