Chỉ vì tiết kiệm giấy, một lệnh hủy in đã khiến tuần làm việc của cả nhóm mainframe đổ bể

Trong thế giới công nghệ, có những sai lầm chỉ tốn vài phút để sửa, nhưng cũng có những sai lầm khiến cả một tuần công việc của nhiều người đổ sông đổ biển. Câu chuyện dưới đây là một ví dụ điển hình từ thời kỳ sơ khai của máy tính mainframe — khi mà một cú nhấp nhầm cũng đủ khiến ba vị sếp cấp cao phải ngồi không chờ đợi.

Bối cảnh: Kỷ nguyên thẻ đục lỗ và máy in giấy

Nhân vật chính của câu chuyện là một kỹ thuật viên được gọi tên là Mark, làm việc tại văn phòng Sperry Univac ở Anh — hãng sản xuất mainframe huyền thoại một thời. Thời điểm đó là giai đoạn của thẻ đục lỗ, lịch trình vận hành thủ công cho các tác vụ và bản in, cùng những cuộn băng từ và đĩa cứng khổng lồ.

Điều đáng chú ý là vào thời kỳ này, không hề có màn hình hiển thị. Khi một chương trình chạy xong, kết quả sẽ được đưa thẳng ra máy in. Tác vụ kiểm kê hàng tuần chạy trên vùng gọi là "bộ nhớ đỉnh" (top memory), tách biệt với vùng nhớ chia sẻ dùng cho các tác vụ nhỏ hơn. Hệ thống được trang bị hai máy in để mỗi nhóm công việc có phương tiện in riêng.

Tác vụ kiểm kê quan trọng và sự giám sát từ nước Mỹ

Một trong những nhiệm vụ của Mark là vận hành tác vụ kiểm kê hàng tuần, kéo dài năm đến sáu ngày, bao gồm cả thời gian in kết quả. Đây là công việc quan trọng đến mức ba vị quản lý đã bay từ Mỹ sang để trực tiếp theo dõi.

Theo lời Mark: "Khi bắt đầu in, phần chính của công việc đã hoàn tất, chúng tôi chỉ cần tiếp tục nạp hơn 20 thùng giấy." Cả nhóm dành riêng một máy in cho tác vụ này để đảm bảo tiến độ.

Sai lầm: Hủy nhầm tiến trình in

Trong lúc mainframe và máy in đang miệt mài chạy tác vụ kiểm kê, một tác vụ nhỏ khác gặp trục trặc.

"Nó tạo ra (có thể) nhiều trang hơn mức cần thiết, và hỏi tôi có muốn in hết không. Tôi kiểm tra với lập trình viên và được cho phép hủy giai đoạn in, nên tôi đã hủy."

Đúng lúc đó, một máy in dừng lại — nhưng đó lại là máy in đang chạy tác vụ kiểm kê, chứ không phải tác vụ nhỏ mà Mark tưởng mình đang hủy.

"Kết quả đầu ra biến mất hoàn toàn. Ngay cả các trang tóm tắt cũng không còn."

Hậu quả: Cả tuần chờ đợi trong bất lực

Phần còn lại của ngày hôm đó, Mark nhận ra rằng ba vị quản lý cấp cao từ Mỹ không thể làm gì khác ngoài việc chờ đợi cho đến khi tác vụ hoàn thành thành công — tức là phải đến tận tuần sau.

Mark rõ ràng cảm thấy vô cùng tồi tệ. Anh kể lại: "Mọi người đều vô cùng thông cảm và không hề có dấu hiệu đổ lỗi." Nhưng kèm theo đó là một chữ "nhưng…" đầy ngụ ý.

Bài học cho người làm công nghệ hôm nay

Câu chuyện tưởng như xa xưa này vẫn còn nguyên giá trị với những ai đang vận hành hệ thống ngày nay:

• Không bao giờ hủy một tiến trình khi chưa xác nhận chính xác nó thuộc tác vụ nào, đặc biệt trong môi trường nhiều tác vụ chạy song song.
• Giao diện dòng lệnh và thiếu màn hình trực quan từng là nguyên nhân của vô số sự cố — điều này cho thấy tầm quan trọng của các công cụ giám sát hiện đại như dashboard, log tập trung và cảnh báo tự động.
• Quy trình phê duyệt chặt chẽ trước các thao tác có rủi ro cao là yếu tố sống còn, đặc biệt khi có nhiều bên cùng chia sẻ tài nguyên hệ thống.

Với các kỹ sư DevOps và quản trị hệ thống tại Việt Nam, câu chuyện này là lời nhắc nhở rằng dù công nghệ có tiến bộ đến đâu, yếu tố con người và quy trình vẫn luôn là mắt xích dễ đứt gãy nhất. Một cú nhấp nhầm trong quá khứ có thể khiến cả tuần đổ bể; ngày nay, một lệnh kill hay rm -rf sai địa chỉ cũng có thể gây ra hậu quả tương tự — chỉ nhanh hơn mà thôi.