Một lệnh hủy in khiến cả tuần xử lý trên mainframe đổ sông đổ biển

Một câu chuyện công nghệ mới được chia sẻ đã đưa độc giả quay lại thời kỳ hoàng kim của mainframe – dòng máy tính lớn chuyên xử lý khối lượng công việc khổng lồ cho doanh nghiệp và cơ quan nhà nước. Nhân vật chính, được gọi là Mark, từng làm việc tại văn phòng Anh của Sperry Univac, một tên tuổi lịch sử trong ngành. Đây là thời kỳ của thẻ đục lỗ, băng từ và các đĩa lưu trữ cỡ lớn, khi nhiều hệ thống còn chưa có màn hình để theo dõi trực tiếp. Thay vào đó, kết quả xử lý được gửi thẳng ra máy in, nghĩa là bản in giấy chính là đầu ra quan trọng nhất của cả quy trình.

Công việc Mark phụ trách là hỗ trợ một tác vụ kiểm kê hàng tuần, hay còn gọi là inventory job. Đây là một “job” theo cách gọi của môi trường mainframe, tức một lô tác vụ được hệ thống xếp lịch và chạy tuần tự. Riêng quy trình này mất từ 5 đến 6 ngày để hoàn tất, bao gồm cả thời gian in kết quả. Tác vụ được chạy trong vùng “top memory” – có thể hiểu là một khu vực bộ nhớ ưu tiên, tách biệt với phần bộ nhớ dùng chung cho các khối lượng công việc nhỏ hơn. Hệ thống có hai máy in để phục vụ các nhóm tác vụ khác nhau, giúp tránh xung đột tài nguyên trong môi trường xử lý tập trung.

Mức độ quan trọng của đợt xử lý này được thể hiện rất rõ khi có tới ba quản lý cấp cao bay từ Mỹ sang để trực tiếp quan sát. Khi tác vụ chính bắt đầu in, phần tính toán cốt lõi gần như đã hoàn tất; việc còn lại chủ yếu là liên tục nạp thêm hơn 20 thùng giấy cho máy in chạy không gián đoạn. Vì vậy, nhóm của Mark dành riêng một máy in cho tác vụ kiểm kê, trong khi máy còn lại phục vụ các công việc nhỏ hơn. Trong bối cảnh đó, mọi thao tác vận hành tưởng chừng đơn giản lại mang tính sống còn.

Rắc rối xuất hiện khi một tác vụ nhỏ gặp lỗi và tạo ra số trang in nhiều hơn dự kiến. Hệ thống hỏi Mark có muốn in toàn bộ hay không. Sau khi kiểm tra với lập trình viên phụ trách và nhận được đồng ý, anh quyết định hủy giai đoạn in của tác vụ này. Tuy nhiên, thay vì dừng đúng công việc phụ, lệnh hủy lại tác động đến máy in đang xử lý tác vụ kiểm kê quan trọng. Kết quả là toàn bộ đầu ra in của job chính biến mất hoàn toàn, kể cả các trang tóm tắt. Trong môi trường không có giao diện đồ họa hiện đại, không có cơ chế khôi phục tức thời hay lưu bản xem trước như ngày nay, mất đầu ra in gần như đồng nghĩa với việc phải chạy lại từ đầu.

Sự cố này cho thấy một nghịch lý thú vị của công nghệ cũ: hệ thống được thiết kế để tiết kiệm tài nguyên và tối ưu vận hành, nhưng lại cực kỳ mong manh trước những sai sót thủ công. Mainframe vốn nổi tiếng về độ ổn định, khả năng xử lý giao dịch lớn và vận hành liên tục, song ở thời kỳ đó, quy trình đầu ra vẫn phụ thuộc nặng vào máy in và giấy. Khi một phần của chuỗi này bị gián đoạn, cả chu trình xử lý kéo dài gần một tuần có thể trở nên vô ích. Với ba quản lý cấp cao đứng nhìn, Mark nhanh chóng nhận ra rằng họ sẽ không thể làm gì tiếp theo cho tới khi tác vụ hoàn tất thành công vào tuần sau.

Dù câu chuyện diễn ra từ nhiều thập kỷ trước, bài học của nó vẫn rất quen thuộc với giới công nghệ ngày nay. Chỉ khác là thay vì hủy nhầm lệnh in trên mainframe, kỹ sư hiện đại có thể xóa nhầm dữ liệu đám mây, tắt sai container, hay dừng nhầm tiến trình sản xuất. “Process” hay tiến trình là một chương trình đang chạy; nếu bị kết thúc sai cách, hậu quả có thể lan rộng sang các dịch vụ quan trọng khác. Câu chuyện của Mark nhắc lại rằng trong mọi thời đại công nghệ, từ băng từ đến điện toán đám mây, lỗi vận hành nhỏ vẫn có thể tạo ra tác động khổng lồ nếu hệ thống thiếu lớp bảo vệ, xác nhận rõ ràng và cơ chế khôi phục phù hợp.