Sự cố nhỏ trong mã lệnh, hậu quả xóa sạch dữ liệu

Một câu chuyện công nghệ từ đầu thập niên 1980 đang thu hút chú ý vì cho thấy chỉ một ký tự sai cũng có thể gây ra thảm họa dữ liệu. Nhân vật chính là một kỹ thuật viên 21 tuổi, được gọi là “Miller”, người chịu trách nhiệm vận hành một hệ thống mainframe — dòng máy tính cỡ lớn chuyên xử lý khối lượng công việc tập trung của doanh nghiệp. Trên hệ thống này, mỗi người dùng được cấp một máy ảo, tức môi trường máy tính chạy độc lập bên trong hạ tầng vật lý chung, cùng một ổ đĩa ảo để lưu dữ liệu.

Kịch bản dọn dẹp cuối ngày được viết để tiết kiệm tài nguyên

Công ty của Miller có quy trình tắt các máy ảo vào cuối ngày làm việc để giải phóng tài nguyên cho các tác vụ chạy ban đêm. Vì vậy, anh đã tự viết một backup script — kịch bản tự động sao lưu dữ liệu — nhằm gắn từng ổ đĩa người dùng, sao lưu nội dung sang một ổ đĩa tạm, rồi xóa ổ cũ để dọn hệ thống. Về nguyên tắc, đây là một dạng cleanup routine, tức quy trình dọn dẹp tự động sau khi hoàn tất công việc.

Điểm yếu nằm ở ổ đĩa tạm và cách hệ thống gán ký tự

Vấn đề phát sinh vì hệ thống mainframe khi đó gán ký tự ổ đĩa theo thứ tự từ A đến Z. Miller không thể biết trước ổ tạm sẽ được cấp ký tự nào, nên anh viết thêm một đoạn mã để yêu cầu tạo ổ đĩa tạm và ghi nhận lại ký tự mà hệ thống trả về. Cách làm này hoạt động bình thường trong nhiều trường hợp, nhưng lại phụ thuộc hoàn toàn vào việc hệ thống còn “chỗ trống” trong bảng ký tự ổ đĩa.

Người dùng mới xuất hiện, bảng ký tự đầy kín và lỗi bắt đầu

Đúng ngày xảy ra sự cố, công ty vừa cấp thêm tài khoản cho một người dùng mới. Việc đó khiến toàn bộ 26 ký tự ổ đĩa từ A đến Z đều đã được sử dụng. Khi kịch bản của Miller yêu cầu tạo ổ đĩa tạm, thao tác này thực tế đã thất bại. Tuy nhiên, thay vì trả về error code — mã lỗi dùng để báo cho chương trình biết rằng thao tác không thành công — hệ thống lại trả về một dấu hoa thị (*).

Dấu * biến lệnh xóa thành thảm họa toàn hệ thống

Trong nhiều ngữ cảnh tin học, dấu hoa thị là wildcard, tức ký tự đại diện cho “mọi thứ” hoặc “tất cả”. Đó chính là điều đã xảy ra. Kịch bản của Miller tiếp tục chạy lệnh xóa mà không nhận ra ký tự nhận được không phải tên ổ đĩa hợp lệ. Kết quả là thay vì xóa một ổ cụ thể, lệnh đã áp dụng dấu * như một chỉ định xóa toàn bộ. Theo lời kể của Miller, hậu quả là “mọi tập tin, toàn bộ dữ liệu và toàn bộ mã nguồn” đều bị xóa sạch.

Thiếu giám sát, thiếu kiểm tra chéo và không có quy trình an toàn

Điều khiến câu chuyện trở nên đáng suy ngẫm không chỉ là lỗi kỹ thuật, mà còn là cách phần mềm quan trọng được đưa vào vận hành. Miller thừa nhận anh đã tự viết toàn bộ mã nguồn trong thời kỳ chưa có peer review — quy trình đồng nghiệp rà soát mã để phát hiện lỗi — cũng chưa có DevOps theo nghĩa hiện đại, tức tập hợp thực hành kết nối phát triển phần mềm với vận hành hệ thống nhằm tăng độ ổn định và kiểm soát triển khai. Nói cách khác, một lập trình viên rất trẻ đã được giao viết mã ảnh hưởng trực tiếp đến dữ liệu sản xuất mà gần như không có lớp bảo vệ nào.

Sự cố xảy ra lúc 3 giờ sáng, cả đội phải chờ khôi phục

Vấn đề bị phát hiện vào khoảng 3 giờ sáng, khi đội vận hành ca đêm chạy chương trình và nhận được thông báo “file not found”. Miller sau đó phải dành trọn ngày thứ Bảy để lần ra nguyên nhân và khôi phục hệ thống. Công việc restore — tức phục hồi dữ liệu từ bản sao lưu — kéo dài suốt một ngày, trong khi khoảng 20 nhân sự khác gần như phải ngồi chờ hệ thống hoạt động trở lại.

Bài học vẫn còn nguyên giá trị trong kỷ nguyên hiện đại

Dù câu chuyện diễn ra từ năm 1981, thông điệp của nó vẫn rất thời sự với ngành CNTT hiện nay. Các hệ thống hiện đại có thể đã thay mainframe bằng hạ tầng đám mây, container hay máy ảo tiên tiến hơn, nhưng rủi ro cốt lõi vẫn không đổi: tự động hóa thiếu kiểm tra có thể nhân rộng sai sót với tốc độ cực nhanh. Một script sao lưu hoặc script dọn dẹp nếu không được kiểm thử kỹ, không có cơ chế chặn lệnh nguy hiểm và không được giám sát đúng mức vẫn có thể gây mất dữ liệu trên diện rộng.

Từ một lỗi cá nhân đến bài toán quản trị kỹ thuật

Miller nói đây là “bài học đau đớn” đã theo ông hơn 40 năm. Nhưng nhìn rộng hơn, đây không chỉ là sai lầm của một cá nhân trẻ tuổi. Câu hỏi lớn hơn là vì sao một tổ chức lại để mã quan trọng đi vào môi trường production — tức hệ thống vận hành thực tế đang phục vụ công việc hàng ngày — mà thiếu quy trình kiểm duyệt, thiếu xử lý lỗi rõ ràng và thiếu cơ chế xác nhận trước khi xóa dữ liệu. Trong thế giới công nghệ, nhiều thảm họa không bắt đầu từ một lỗi lớn, mà từ một giả định nhỏ chưa từng được kiểm chứng.

Danh mục máy quét mã vạch

Máy quét mã vạch - Quét mã Qr - Quét mã vạch sản phẩm.

DÒNG MÁY CÓ DÂY

máy quét mã vạch không dây

DÒNG MÁY KHÔNG DÂY

DÒNG MÁY KIỂM KHO PDA

DÒNG MÁY FITMOUNT