Những con số ‘xui xẻo’ gây thảm họa. Một lỗi kỹ thuật đơn giản đến ngạc nhiên có thể làm tê liệt hệ thống máy tính điều khiển máy bay, tàu vũ trụ và các thiết bị tối tân khác – khi chúng nhầm lẫn trong cách đọc hiểu những con số khổng lồ.
Thứ Ba ngày 4/6/1996 được nhớ đến như một ngày đen tối của Cơ quan Không gian Âu châu (ESA). Chuyến bay đầu tiên của tàu vũ trụ không người lái Ariane 5 mang theo bốn vệ tinh khoa học cực kỳ đắt tiền đã bùng cháy trong khói lửa chỉ sau khi phóng đi 39 giây. Thiệt hại ước tính lên đến 370 triệu đô la Mỹ.
Vì sao? Không phải do hỏng hóc kỹ thuật, cũng chẳng phải do âm mưu phá hoại nào. Chỉ do một lỗi phần mềm đơn giản. Máy tính đã xử lý sai một thuật toán khi nhận được “đề bài” là một con số khổng lồ, lớn hơn so với khả năng “tư duy” của mình!
Nhưng máy tính làm sao có thể bị “khớp” với những con số lớn như vậy? Các lỗi này có lẽ chính là lời đáp cho một loạt các thảm hoạ, rủi ro trong những năm gần đây, như tên lửa phóng tàu vũ trụ nổ tung, các tàu thăm dò không gian mất tích, hay hoả tiễn bắn nhầm mục tiêu.
Vậy các lỗi này là gì, vì sao lại xảy ra?
Để dễ hiểu thì ta hãy hình dung thế này: nếu tổng quãng đường cần đi dài 105.350 dặm nhưng đồng hồ đo chỉ có con số tối đa là 99.999 dặm. Công-tơ-mét sau khi chạy tới số tối đa sẽ “quay” về 00.000 rồi đếm tiếp 5.350 dặm còn lại. Số liệu ở cuối chặng đường được thể hiện trên công-tơ-met sẽ là 5.350 dặm, hoàn toàn thiếu chính xác so với quãng đường thực đã đi. Đây chính là nguyên nhân khiến tàu vũ trụ Ariane 5 chịu số phận hẩm hiu ngay trong chuyến xuất hành đầu tiên.
Về mặt kỹ thuật, hiện tượng này được gọi là “tràn số”, nghĩa là con số cần ghi lại quá lớn so với khả năng lưu trữ của hệ thống máy tính, do đó khiến máy tính tính toán và đưa ra lời đáp sai.
Không phóng được tàu đi
Một cuộc điều tra đầy đủ về vụ tai nạn Ariane 5 xác định được rằng tàu sử dụng một phần phần mềm phiên bản cũ vốn dùng cho tàu Ariane 4.
Do tên lửa thế hệ mới có tốc độ cao hơn nhiều so với khả năng ghi nhận của phần mềm cũ, phần mềm cũ đã không thể xử lý được dữ liệu. Hậu quả là nó tự đánh sập mình và chỉ vài giây sau, tên lửa tối tân khi ấy trong giây lát đã tan tành thành tro bụi.
Người ta nghi là việc NASA mất liên lạc với tàu thăm dò không gian Deep Impact hồi 2013 cũng là do bị “tràn số”.
Gần đây, tin tức nói một máy bay Boeing 787 có vẻ như đã gặp phải một vấn đề tương tự. Bộ điều khiển phân phối lực đẩy giữa các động cơ sẽ tự động chuyển sang chế độ không an toàn và tắt các động cơ đi nếu chế độ này bị lưu trong bộ nhớ quá 248 ngày. Như vậy, về lý thuyết, các động cơ có thể bị ngắt đột ngột khi đang bay.
Chỉ dẫn của Cơ quan Quản lý Hàng không Liên bang (FFA) nói rằng bộ đếm của phần mềm điều khiển sẽ bị “tràn số” sau một khoảng thời gian nhất định, gây ra trục trặc.
Một số nhà quan sát nghiệp dư đã tính toán ra là 248 ngày (nếu đếm theo đơn vị một phần trăm giây) thì tương đương với con số 2.147.483.647 – đó là con số quan trọng; tuy nhiên FAA và Boeing từ chối bình luận.
Quan trọng thế nào? 2.147.483.647 là giá trị dương cực đại có thể được lưu trữ với một hệ “32bit” vốn được cài trên nhiều hệ thống máy tính. Để so sánh, ta thấy rằng trên tên lửa đẩy Ariane, các phần mềm chỉ sử dụng có “16bit”, do vậy, nhỏ hơn nhiều và chỉ có thể lưu trữ tới giá trị tối đa là 32.767.
Giới hạn khó hiểu
Những con số là vô hạn, vậy tại sao người ta lại phải lấy một số hữu hạn nào đó để lưu trữ trong các hệ thống máy tính?
Câu trả lời là các máy tính thường được tối đa hoá hiệu năng cho mọi tác vụ. Trước đây, chi phí lưu trữ tốn kém hơn nhiều, trong lúc việc xử lý các dữ liệu lớn cần tốn thời gian hơn nhiều so với ngày nay.
Nếu chúng ta đặt mức trần cho khả năng lưu trữ và khả năng xử lý con số thì các phần mềm sẽ vận hành mượt mà hơn.
Hệ thống điều khiển tên lửa đòi hỏi phải xử lý số liệu cực kỳ nhanh chóng, cho nên việc tính toán và đề ra mức trần đương nhiên là cần thiết. Nhưng kẹt nỗi không phải lúc nào người ta cũng nhìn ra vấn đề đối với việc cần tính toán để đặt mức trần tới đâu mới là thích hợp, và vụ tai nạn Ariane 5 chính là một ví dụ của việc tính toán sai.
“Chúng ta phải thừa nhận rằng phần mềm luôn luôn phản ánh thực tế,” Bill Scherlis, chuyên gia phần mềm tại Đại học Carnegie Mellon giải thích. “Chúng ta luôn phải cân nhắc giữa một bên là chi phí cần thiết để tạo sản phẩm đạt độ chính xác cao và một bên là hiệu quả sử dụng”.
Nhà toán học Douglas Arnold từ Đại học Minnesota đã đưa sự cố tàu Ariane 5 vào trang web “Một số thảm họa do các phép tính tồi tệ”.
Arnold cũng nhắc tới một vụ xảy ra trong cuộc chiến vùng Vịnh 1991, khi hoả tiễn Patriot của Mỹ đã không đánh chặn được một tên lửa Scud của Iraq tấn công vào doanh trại Hoa Kỳ.
Trong vụ này, lỗi tràn số khiến hệ thống phòng thủ xác định sai đường đi của Scud – khi đó đang di chuyển với tốc độ 1,7 km/giây – và đã tầm quét nhầm vào khoảng không gian cách mục tiêu cần diệt tới hơn 500 mét.
Hậu quả là tên lửa Scud đã bắn trúng trại lính, giết chết 28 binh sĩ và làm 98 người khác bị thương.
Gangnam Style và Youtube
Không phải tất cả trục trặc đều gây ra tai hoạ, nhưng chúng thường tạo ra những hiệu ứng bất ngờ.
Hồi tháng Mười Hai, tin tức nói Gangnam Style, video có số lượt xem lớn nhất mọi thời đại trên Youtube, đã “phá vỡ” bộ đếm của YouTube. Rõ ràng là bộ đếm này được lập trình chỉ đến con số 2.147.483.647 – giá trị tối đa của một bộ nhớ 32bit.
Nhưng đây lại là một dịp cực tốt để YouTube quảng cáo rùm beng. Khi cài đặt lại con số này thì YouTube cũng đồng thời loan báo họ là trang chia sẻ video phổ biến nhất thế giới. Và bây giờ Youtube đưa ra con số tối đa là hơn chín quintillion (chín tỷ tỷ).
Khi nói về chuyện tràn số trước đây, có lẽ mọi người đều ít nhiều nhớ về sự cố Thiên niên kỷ (Y2K), mà lúc đó đã bị thổi phồng. Tuy hầu như không gây trục trặc lớn gì nhưng Y2K cũng đã khiến người ta phải đau đầu.
Sự cố Y2K thật là đơn giản. Khi ta ghi tắt các năm bằng hai chữ số cuối cùng thì năm 1900 sẽ giống như năm 2000, đều được viết là “00”.
Người ta đã lo là điều này sẽ gây ra nhầm lẫn cho các hệ thống máy tính lưu trữ dữ liệu các năm bằng hai số cuối; các lập trình viên được khuyến cáo là phải cập nhật hệ thống trước hoặc đúng ngày 1/1/2000.
Cuối cùng thì chẳng có chuyện gì ghê gớm xảy ra ngoài một vài sự cố thú vị. Ví dụ, một thiết bị phát hiện phóng xạ ở tỉnh Ishikawa, Nhật Bản dừng hoạt động lúc nửa đêm; 150 máy đánh bạc tại một trường đua ở Delaware, Hoa Kỳ bị hỏng; và một số trang web hiển thị ngày mới là “1/1/19100”.
Dập dình đến 12 năm sau, chuyện buồn cười mới lại xảy ra. Một phụ nữ 105 tuổi ở Thụy Điển tên là Anna Eriksson nhận được thư mời nhập học lớp vỡ lòng vì phần mềm đã được thiết kế để gửi thư đến những người sinh ra trong năm “07”. Tất nhiên lập trình này cho những người sinh năm 2007, chứ không phải 1907 như bà Eriksson.
Sự cố thời gian năm 2015?
Theo giải thích của Markus Kuhn, một khoa học gia chuyên về điện toán tại Đại học Cambridge, thì người ta quan tâm đến các lỗi này một phần bởi các hậu quả chúng gây ra là khó lường, và một phần bởi chúng “không phải là không đoán trước được”.
Với Kuhn, sự cố thú vị liên quan tới thời gian trong các hệ thống máy tính thời nay không phải là sự cố tràn số mà chính là điều sẽ xảy ra vào tháng Sáu này.
Năm 2015 sẽ dài hơn một giây so với năm 2014, do đó cần tính toán để điều chỉnh thời gian ghi nhận trên đồng hồ nguyên tử, tức loại đồng hồ do con người chế tạo ra đạt tính chính xác cao nhất hiện nay, tính đến đơn vị giây, cho khớp với thời gian thiên văn, tức thời gian được tính dựa trên vòng quay của Trái Đất.
Đồng hồ nguyên tử có độ chính xác cực kỳ cao, nhưng lại thiếu đồng bộ với thời gian thiên văn. Lý do là bởi Trái Đất đang từ từ quay chậm lại.
Những sự kiện địa chất như động đất có thể làm thay đổi tốc độ quay của Trái Đất, và điều đó đồng nghĩa với việc số lượng các giây dôi ra trong năm nay (giây nhuận) sẽ thay đổi tương ứng với các thay đổi trong tốc độ quay của Trái Đất chứ không theo quy luật như trong các năm nhuận.
Lần điều chỉnh gần đây nhất vào năm 2012 đã làm nhiều máy tính bị treo. Nhưng theo Kuhn thì giờ đây chúng ta chuẩn bị ứng phó với những chuyện này tốt hơn xưa.
Nhưng dù chúng ta có làm gì đi chăng nữa thì nhất định các con số và phép tính sẽ luôn luôn ẩn chứa hiểm họa khiến máy tính bị “treo”, gây ra trục trặc – hoặc thậm chí tồi tệ hơn nữa.
“Chúng ta đã học được rất nhiều từ kinh nghiệm Y2K và các sự kiện tương tự khác,” Scherlis nhấn mạnh. “Nhưng thực tế chúng ta vẫn luôn phải cân nhắc thiệt hơn để chấp nhận mức độ tương đối chính xác nào mà ta thấy hợp lý nhất. Điều đó sẽ luôn luôn xảy ra.”
