Chung

Khi lập trình tồi trở nên chết người

Khi lập trình tồi trở nên chết người


We are searching data for your request:

Forums and discussions:
Manuals and reference books:
Data from registers:
Wait the end of the search in all databases.
Upon completion, a link will appear to access the found materials.

Khi chương trình của một hệ thống quan trọng bị trục trặc nghiêm trọng, nếu chúng ta không may mắn, lỗi có thể gây ra thiệt hại đáng kể về tài sản, mất giá trị cổ phiếu hoặc chi phí quản lý khác dẫn đến một thảm họa không cần thiết — chưa kể đến công việc của lập trình viên. Tuy nhiên, đôi khi hậu quả có thể không thể tưởng tượng được. Hôm nay, chúng ta cùng nhìn lại một số trường hợp nổi tiếng chứng minh việc lập trình tồi trở nên nguy hiểm dễ dàng như thế nào.

Therac-25: Tất cả đều là sơ suất

Bất cứ ai đã học khoa học máy tính ở cấp đại học đều đã nghe nói về báo cáo Therac-25. Đây là một nghiên cứu điển hình lớn được các giáo sư đưa ra cho sinh viên như một lời cảnh báo thảm khốc về những gì có thể xảy ra khi các lập trình viên bất cẩn; cụ thể là mọi người có thể và sẽ chết.

Therac-25 là một máy xạ trị được chế tạo vào năm 1982 để điều trị các dạng ung thư nặng. Được chế tạo dựa trên các mẫu trước đó, Therac-6 và Therac-20, Therac-25 sử dụng cấu hình chế độ kép, một chế độ cho liều bức xạ điện tử nhẹ hơn và liều thứ hai, mạnh hơn đáng kể, mạnh hơn hàng trăm lần.

Các nhà thiết kế của các mô hình trước đó đã nhận ra sự nguy hiểm của việc sử dụng sai cài đặt và đã xây dựng các cơ chế an toàn phần cứng có thể ngăn ngừa quá liều bức xạ ngẫu nhiên. Do đó, chương trình chạy máy có thể dựa vào các khóa liên động của phần cứng để bảo vệ khỏi việc định cấu hình máy không chính xác.

Vì vậy, khi các nhà lập trình cho Therac-25 sao chép mã cũ từ các máy cũ hơn và sử dụng lại trong máy mới, họ không hề biết rằng phần mềm bị lỗi trong mã cũ gần như không nghiêm ngặt như họ nghĩ. . Và bởi vì lập trình viên cho các máy ban đầu, một lập trình viên tự học không được đào tạo chính quy, không để lại bình luận nào trong mã của mình như lẽ ra phải có, các lập trình viên của Therac-25 không có cách nào biết rằng về cơ bản của họ là một máy khác. Họ thậm chí còn không bận tâm đến việc kiểm tra đầy đủ mã cũ trên máy mới, điều này sẽ cho thấy sự khác biệt.

Quan trọng nhất, lập trình viên ban đầu đã không tính đến “tình trạng chủng tộc” giữa hai cài đặt liều lượng khác nhau. Nếu kỹ thuật viên bỏ lỡ thao tác nhấn phím, họ có thể vô tình hướng dẫn máy sử dụng một cài đặt, sau đó là hướng dẫn sử dụng cài đặt kia ngay lập tức. Bất kể hướng dẫn nào đến máy trước là cách máy được đặt, bất kể kỹ thuật viên định làm gì và họ sẽ không biết sự khác biệt.

Vì vậy, thay vì bắn một vụ nổ bức xạ lớn vào một tấm kim loại sẽ phát tán tia X trên một khu vực rộng hơn như người ta tưởng tượng, Therac-25 đôi khi sẽ bắn một bệnh nhân toàn thân bằng một chùm bức xạ hẹp hàng trăm lần mạnh hơn dự định — đủ mạnh để gây bỏng phóng xạ cho nhiều người và trong ít nhất năm trường hợp đã biết, đã giết chết họ.

Tên lửa Patriot không bắn được

Trong cuộc sống, những sai lầm tưởng chừng như đơn giản lại ít khi nguy hiểm. Trong lập trình, những sai lầm đơn giản nhất thường là nguyên nhân của những thảm họa lớn, và một trong những sai lầm phổ biến nhất thuộc loại này là lạm dụng số học dấu phẩy động.

Vấn đề với số dấu phẩy động là chỉ có quá nhiều dung lượng trống để biểu diễn giá trị được lưu trữ trong bộ nhớ và nếu giá trị bạn cần lưu trữ lớn hơn dung lượng khả dụng, máy sẽ cắt số đó để đưa vào bộ nhớ. Việc cắt các chữ số lủng lẳng đó ở cuối chuỗi số 0 có vẻ không có gì to tát, nhưng đối với một máy tính thực hiện hàng triệu thao tác mỗi giây, những loại sai lầm này sẽ tăng lên.

Vào ngày 25 tháng 2 năm 1991, giữa Chiến tranh vùng Vịnh lần thứ nhất, một khẩu đội tên lửa Patriot của quân đội Hoa Kỳ ở Dharan, Suadi Arabia đã hoạt động trong 100 giờ mà không cần khởi động lại. Tổ hợp Patriot là một phần trong lực lượng phòng thủ của Quân đội Hoa Kỳ chống lại các tên lửa SCUD di động đang được Quân đội Iraq sử dụng và chương trình chịu trách nhiệm theo dõi các tên lửa SCUD đang đến dựa trên một loạt các tính toán sẽ dự đoán vị trí tên lửa được theo dõi trong khoảng thời gian tiếp theo như một hàm của vận tốc và thời gian của nó.

Vì chương trình điều khiển pin Patriot phải theo dõi thời gian đã trôi qua để xác định quỹ đạo của SCUD, cứ mỗi phần mười giây chương trình sẽ truy vấn thời gian kể từ khi khởi động từ đồng hồ hệ thống và đồng hồ trả về phần mười giây kể từ khi bắt đầu. -up dưới dạng số nguyên. Để chuyển số này thành giây để thực hiện các phép tính của họ, các lập trình viên đã nhân số nguyên này với 1/10, phạm phải một lỗi lập trình cấp độ sinh viên năm nhất giữa cuộc chiến.

Dấu thời gian được lưu trữ trong khối bộ nhớ 24 bit, vì vậy bất kỳ số nhị phân nào lớn hơn 24 bit đều phải được cắt bớt để phù hợp. 1/10 là một biểu diễn nhị phân không kết thúc, vì vậy việc cắt số ở 24 bit sẽ dẫn đến độ lệch 0,000000095 giây.

Cộng tất cả các lỗi này lại với nhau trong hơn 100 giờ chương trình đã chạy và thời gian chương trình đang sử dụng chênh lệch 0,34 giây so với các hệ thống khác.

Vì vậy, khi tổ hợp Patriot nhặt và theo dõi một tên lửa SCUD đang bay đến vào ngày 25 tháng 2, nó đã dự đoán vị trí nó sẽ xuất hiện trong khoảng thời gian tiếp theo bằng cách tạo tam giác với hai tín hiệu radar, một phản ánh đúng thời gian và một có sai số 0,34 giây. Nó nghiền nát các con số và nhìn vào tọa độ nó mong đợi để tìm SCUD, nhưng chỉ có một bầu trời trống rỗng.

Giả sử SCUD đã vượt ra ngoài tầm bắn, chiếc Patriot đã không bắn khi SCUD lao qua và nhanh chóng đâm vào doanh trại mà khẩu đội Patriot được cho là bảo vệ, khiến 28 người thiệt mạng và khoảng 100 người khác bị thương.

Ảo tưởng kỹ thuật số

Sai lầm trong mã hóa có thể gây chết người, nhưng việc không thiết kế đúng cách và kiểm tra kỹ lưỡng phần mềm trước khi nó được sử dụng cũng có thể gây tử vong giống như việc vô tình sử dụng sai số học dấu phẩy động.

Đó là trường hợp ở thành phố Panama, Panama, khi các bác sĩ tại Viện Ung thư Quốc gia đang sử dụng phần mềm y tế do Công ty Multidata Systems International của Mỹ xây dựng. Phần mềm này là một nỗ lực sau khi đưa ra thị trường để giữ cho thiết bị X quang Cobalt-60 cũ và lỗi thời của viện hoạt động.

Thêm vào đó là trang thiết bị kém chất lượng, các bác sĩ đã làm việc quá sức, căng thẳng và phụ thuộc quá nhiều vào phần mềm của Multidata để xác định liều lượng bức xạ phù hợp nhằm cung cấp cho bệnh nhân chiến đấu với căn bệnh ung thư nghiêm trọng.

Một phần của quá trình là xem mô hình của bệnh nhân trên màn hình và chặn mô lành bằng các tấm kim loại để bảo vệ nó khỏi bức xạ, vẽ các “khối” hình chữ nhật trực tiếp lên mô hình trên màn hình. Trước sự bức xúc của các bác sĩ Viện, phần mềm chỉ cho phép các bác sĩ vẽ từ 4 khối trở xuống.

Các bác sĩ khẳng định họ cần khối thứ năm, vì vậy họ đã xem qua tài liệu để tìm cách giải quyết. Một bác sĩ phát hiện ra rằng họ có thể “đánh lừa” phần mềm nếu họ vẽ cả năm khối thành một khối lớn với một lỗ khoét ở trên cùng, nơi hình chữ nhật lớn và hình cắt nhỏ hơn nằm chung một cạnh.

Những gì họ không biết là chương trình của phần mềm được thiết kế để đọc các khối theo một cách nhất định và tính toán liều lượng thích hợp dựa trên những gì được vẽ. Thật ngạc nhiên, chương trình của họ không tính đến cách ai đó có thể vẽ các hình có các cạnh chồng lên nhau chính xác, được vẽ trên màn hình theo cùng một hướng, theo chiều kim đồng hồ hoặc ngược chiều kim đồng hồ.

Khi được vẽ cùng nhau như thế này, chương trình đọc các hình dạng như một đường thẳng liên tục và mất trí khi cố gắng tìm ra hình dạng thực sự là gì, giống như tạo cho nó một ảo ảnh quang học? Bằng cách nào đó, điều đó không ngăn nó tính toán liều lượng, dựa trên hình dạng này nó không hiểu.

Bác sĩ đã lấy số liệu về liều lượng và trong 7 tháng sử dụng cùng một kỹ thuật, liều lượng tăng gấp đôi so với những gì đáng lẽ phải có và số người đã dùng quá liều.

Trong số 28 người mà chúng tôi biết đã sử dụng thuốc quá liều dựa trên lập trình cẩu thả trong phần mềm của Multidata, 8 người trong số họ đã chết và những người còn lại bị thương nặng do các phương pháp điều trị mà họ nhận được. Xét rằng tất cả các bệnh nhân tại viện đều đang chiến đấu với một căn bệnh khó chữa và chết người, không có cách nào để biết có bao nhiêu người nữa bị ốm hoặc chết bởi những con số liều lượng sai lầm do phần mềm của Multidata đưa ra.

Tầm quan trọng của các Quy trình và Thực tiễn Tốt nhất trong Lập trình

Không ai có thể buộc tội các lập trình viên có một công việc dễ dàng. Học cách lập trình các thiết bị kỹ thuật cao và phức tạp cần cả đời làm việc để làm đúng, và ngay cả những lập trình viên giỏi nhất vẫn viết mã lỗi.

Đó là lý do tại sao các quy trình và phương pháp hay nhất đã được phát triển để ứng phó với những thảm họa như thế này, bởi vì điều mà các lập trình viên giỏi nhất không bao giờ để ý đến là lỗi có thể biến thành thảm họa nhanh đến mức nào và việc lập trình tồi, cẩu thả và cẩu thả dễ giết chết như thế nào. chính những người mà họ định giúp đỡ.


Xem video: Ảo tưởng Capgras - khi NGƯỜI THÂN là KẺ GIẢ MẠO? SPIDERUM. THE MERC. Tâm Lý Học (Có Thể 2022).