Những sự cố kỹ thuật nghiêm trọng nhất trong lịch sử thế giới

Lịch sử phát triển của khoa học – kỹ thuật nhân loại không chỉ được ghi dấu bằng những phát minh vĩ đại, mà còn bởi những sự cố kỹ thuật nghiêm trọng khiến thế giới phải nhìn lại cách chúng ta thiết kế, kiểm soát và tin tưởng vào công nghệ.

Từ vấn đề Y2K làm cả thế giới lo lắng trước năm 2000, đến thảm họa hạt nhân Three Mile Island, lỗi phần mềm tên lửa Ariane 5, hay khủng hoảng Boeing 737 MAX — mỗi sự cố là một bài học sâu sắc về giới hạn của con người trong thời đại công nghệ.

1. Sự cố kỹ thuật Y2K (1999–2000) – Cơn ác mộng của kỷ nguyên số

Mô tả sự cố

Sự cố Y2K (Year 2000 Problem) là lỗi máy tính xuất phát từ việc hệ thống chỉ lưu năm bằng hai chữ số cuối, khiến năm 2000 bị hiểu thành 1900. Khi lịch chuyển sang ngày 01/01/2000, các chương trình không phân biệt được năm mới, gây ra nguy cơ rối loạn dữ liệu trên toàn cầu.

Nguyên nhân kỹ thuật

• Lưu trữ năm chỉ bằng hai chữ số để tiết kiệm bộ nhớ.
• Khi năm 1999 + 1 → hệ thống đọc thành 1900 thay vì 2000.
• Gây lỗi trong tính toán thời gian, đặc biệt ở ngân hàng, hàng không và năng lượng.

Hậu quả

• Lo sợ thảm họa toàn cầu: người dân tích trữ thực phẩm, tiền mặt.
• Thiệt hại dự kiến hàng trăm tỷ USD.
• Thực tế: nhờ chuẩn bị kỹ, chỉ xảy ra lỗi nhỏ như bảng điện tử ở Pháp hiển thị “1900” thay vì 2000.

Cách xử lý

• Các chính phủ đầu tư hàng trăm tỷ USD nâng cấp phần mềm, đặc biệt là Mỹ (~100 tỷ USD).
• Ban hành chuẩn lập trình mới yêu cầu lưu năm bằng 4 chữ số.

Bài học

• Tầm quan trọng của phòng ngừa lỗi hệ thống trước khi quá muộn.
• Dự báo lỗi tương tự sẽ xảy ra vào năm 2038 trên các hệ thống Unix 32-bit.

2. Lỗi phần mềm tên lửa Ariane 5 (1996)

Mô tả sự cố

Ngày 4/6/1996, tên lửa Ariane 5 của châu Âu phát nổ chỉ 37 giây sau khi phóng, phá hủy 4 vệ tinh khoa học trị giá 370 triệu USD.

Nguyên nhân kỹ thuật

• Phần mềm tái sử dụng từ Ariane 4, nhưng giá trị vận tốc của Ariane 5 vượt quá giới hạn 16-bit.
• Khi chuyển đổi số thực 64-bit sang số nguyên 16-bit, tràn số (overflow) xảy ra.
• Hai máy tính (chính và dự phòng) chạy cùng mã lỗi → cả hệ thống sập.

Hậu quả

• Tên lửa nổ tung, mất toàn bộ vệ tinh.
• Tổn thất kinh tế và uy tín nặng nề cho ESA.

Cách xử lý

• ESA thành lập ủy ban điều tra độc lập.
• Sửa lỗi tràn số, bổ sung cơ chế xử lý ngoại lệ, mở rộng kiểm thử giá trị cực đại.
• Sau đó Ariane 5 phóng lại thành công (1997).

Bài học

• Không nên tái sử dụng mã nguồn nếu chưa kiểm chứng phù hợp.
• Cần thiết kế hệ thống dự phòng độc lập, tránh lỗi đồng thời.

3. Thảm họa hạt nhân Three Mile Island (1979)

Mô tả sự cố

Tại nhà máy điện hạt nhân Three Mile Island (Mỹ), lò phản ứng số 2 (TMI-2) tan chảy một phần lõi do chuỗi lỗi kỹ thuật và con người.

Nguyên nhân kỹ thuật

• Van xả áp khẩn cấp bị kẹt mở, trong khi tín hiệu báo “đã đóng”.
• Nước làm mát thất thoát, lõi phản ứng bị lộ ra ngoài.
• Thiết kế bảng điều khiển gây nhầm lẫn, dẫn đến vận hành sai.

Hậu quả

• Tan chảy ~50% lõi lò phản ứng.
• Phóng xạ rò rỉ nhỏ, không có người chết trực tiếp, nhưng 140.000 người sơ tán.
• Thiệt hại ~1 tỷ USD, ngành hạt nhân Mỹ đình trệ nhiều thập kỷ.

Cách xử lý

• Tổng thống Jimmy Carter lập Ủy ban điều tra Kemeny.
• Thành lập INPO (Viện vận hành năng lượng hạt nhân) nâng cao đào tạo.
• Nâng cấp giao diện vận hành, quy trình cảnh báo, và mô phỏng đào tạo.

Bài học

• Hệ thống phức tạp có thể sụp đổ bởi nhiều lỗi nhỏ cộng hưởng.
• Phải thiết kế để chịu lỗi con người, và thông tin hiển thị cần rõ ràng.

4. Sự cố giao dịch tự động Knight Capital (2012)

Mô tả sự cố

Ngày 1/8/2012, phần mềm giao dịch tự động của Knight Capital Group (Mỹ) bị lỗi, gửi lệnh mua bán khổng lồ bất thường khiến giá 150 cổ phiếu chao đảo.

Nguyên nhân kỹ thuật

• Cài đặt phần mềm mới xung đột với mã thử nghiệm cũ (test code).
• Hệ thống không có cơ chế ngắt tự động (kill switch).

Hậu quả

• Công ty lỗ 440 triệu USD trong 45 phút.
• Cổ phiếu giảm 75%, Knight buộc phải sáp nhập với Getco năm 2013.

Cách xử lý

• SEC yêu cầu thiết lập “cầu dao tự động” ngắt giao dịch bất thường.
• Ban hành Quy tắc 15c3-5 buộc công ty kiểm thử kỹ hệ thống.
• Knight cải thiện quy trình cập nhật phần mềm đồng bộ.

Bài học

• Rủi ro công nghệ tài chính (FinTech) có thể gây sập thị trường.
• Quản trị rủi ro phải đi cùng đổi mới – cần giám sát thời gian thực và thử kịch bản xấu.

5. Sự cố kỹ thuật sập mạng viễn thông AT&T (1990)

Mô tả

Ngày 15/1/1990, mạng điện thoại đường dài của AT&T sập suốt 9 giờ trên toàn nước Mỹ, khiến hơn 50 triệu cuộc gọi không thực hiện được.

Nguyên nhân kỹ thuật

• Lỗi logic trong phần mềm nâng cấp: lệnh break đặt sai vị trí.
• Khi một tổng đài khởi động lại, tín hiệu “sẵn sàng” bị hiểu sai → reset dây chuyền giữa 114 tổng đài.

Hậu quả

• Tê liệt toàn quốc trong 9 tiếng.
• Thiệt hại khoảng 60 triệu USD.
• Gây hoang mang và điều tra từ FCC.

Cách xử lý

• Gỡ bản nâng cấp lỗi, triển khai dần từng phần.
• Thêm kiểm thử tải cao và cơ chế chặn tín hiệu lặp.
• FCC yêu cầu diễn tập khôi phục mạng định kỳ.

Bài học

• Một dòng code sai có thể kéo sập cả hạ tầng quốc gia.
• Phải mô phỏng tình huống bất thường và triển khai theo giai đoạn.

6. Sự cố kỹ thuật máy xạ trị Therac-25 (1985–1987)

Mô tả

Máy xạ trị Therac-25 gây ra 6 vụ chiếu xạ quá liều, khiến ít nhất 3 bệnh nhân tử vong do lỗi phần mềm.

Nguyên nhân kỹ thuật

• Lỗi race condition trong phần mềm điều khiển.
• Bỏ cơ chế an toàn phần cứng để giảm chi phí.
• AECL phớt lờ cảnh báo ban đầu, cho rằng lỗi do vận hành.

Hậu quả

• 6 bệnh nhân bị chiếu xạ quá liều, 3 người tử vong.
• Gây khủng hoảng niềm tin vào thiết bị y tế tự động.

Cách xử lý

• Thu hồi toàn bộ máy, viết lại phần mềm và thêm khóa liên động cơ khí.
• FDA nâng chuẩn thiết bị y tế: yêu cầu cơ chế an toàn vật lý độc lập.
• Ngành y tế áp dụng kiểm thử phần mềm chặt chẽ hơn.

Bài học

• Không được phụ thuộc hoàn toàn vào phần mềm trong hệ thống cứu người.
• Nhà sản xuất phải lắng nghe phản hồi thực tế và không tự tin thái quá.

7. Khủng hoảng Boeing 737 MAX (2018–2019)

Mô tả

Hai vụ rơi máy bay Lion Air 610 (Indonesia) và Ethiopian Airlines 302 (Ethiopia) khiến 346 người thiệt mạng. Nguyên nhân chính: lỗi hệ thống MCAS (Maneuvering Characteristics Augmentation System).

Nguyên nhân kỹ thuật

• MCAS dựa vào chỉ một cảm biến góc tấn (AoA).
• Khi cảm biến hỏng, hệ thống liên tục đẩy mũi máy bay chúi xuống.
• Phi công không biết về MCAS do Boeing giấu thông tin để giảm chi phí huấn luyện.

Hậu quả

• Toàn bộ 737 MAX (~400 chiếc) bị cấm bay gần 2 năm.
• Boeing thiệt hại hơn 20 tỷ USD, bị kiện và phạt 2,5 tỷ USD.
• Uy tín sụp đổ, nhiều lãnh đạo bị sa thải.

Cách xử lý

• Boeing thiết kế lại MCAS, sử dụng 2 cảm biến AoA.
• Giới hạn kích hoạt 1 lần, thêm quyền kiểm soát cho phi công.
• FAA siết chặt quy trình chứng nhận, yêu cầu huấn luyện lại phi công.
• 737 MAX được cho bay lại từ 2021 sau khi khắc phục.

Bài học

• An toàn phải trên hết, không đánh đổi vì lợi nhuận.
• Minh bạch thông tin, giám sát độc lập là yếu tố sống còn.
• Thiết kế phải theo nguyên tắc “fail-safe” – giả định cảm biến có thể hỏng.

8. Bảng tổng hợp các sự cố kỹ thuật nghiêm trọng

Kết luận

Các sự cố kỹ thuật trong lịch sử cho thấy rằng một lỗi nhỏ trong phần mềm hay thiết kế có thể dẫn đến hậu quả khổng lồ. Từ bài học Y2K đến Boeing 737 MAX, điểm chung là con người thường đánh giá thấp rủi ro kỹ thuật cho đến khi thảm họa xảy ra.

Công nghệ càng phát triển, trách nhiệm của con người càng lớn. Minh bạch, kiểm thử độc lập, và tư duy “phòng ngừa trước khi sửa lỗi” là ba nguyên tắc bất biến để thế giới kỹ thuật tiến bước an toàn hơn.

Nguồn tham khảo:

• Wikipedia: Year 2000 Problem
• Wikipedia: Ariane Flight V88
• Raygun Blog – 11 of the Most Costly Software Errors
• NRC – Three Mile Island Accident Report
• FAA Boeing 737 MAX Recertification Summary

Please leave this field empty

Xin chào 👋
Rất vui được gặp bạn.

Hãy đăng ký để nhận thông báo về các bài post mới của mình nhé.

Mình không spam mail đâu.

Check your inbox or spam folder to confirm your subscription.