Sự cố Therac-25 (2021)

 (thedailywtf.com)
2 điểm bởi GN⁺ 2025-08-28 | 1 bình luận | Chia sẻ qua WhatsApp
  • Xảy ra tai nạn nghiêm trọng với máy xạ trị y tế Therac-25
  • Lỗi phần mềm khiến nhiều bệnh nhân bị phơi nhiễm bức xạ quá liều nghiêm trọng
  • Vấn đề phát sinh sau khi thay thế hệ thống an toàn hiện có bằng hệ thống điều khiển số
  • Việc thiếu chẩn đoán lỗi và giao tiếp khiến quá trình xác định nguyên nhân tai nạn bị chậm trễ
  • Nhấn mạnh tầm quan trọng của độ tin cậy thuật toán và kiểm thử kỹ lưỡng như những bài học cốt lõi về an toàn

Tổng quan về sự cố Therac-25

  • Therac-25 từng được sử dụng rộng rãi như một thiết bị y tế xạ trị
  • Thiết bị này đảm nhiệm việc chiếu liều bức xạ cường độ cao cho bệnh nhân ung thư
  • Các cơ chế an toàn interlock cơ khí trước đây đã được thay thế bằng hệ thống điều khiển dựa trên phần mềm
  • Tuy nhiên, sự thay đổi này làm tăng nguy cơ phát sinh lỗi phần mềm

Diễn biến tai nạn

  • Chương trình phát sinh lỗi khi thực hiện theo một số trình tự thao tác nhất định hoặc khi nhập liên tiếp quá nhanh
  • Vì vậy, thiết bị an toàn không hoạt động đúng cách, khiến bệnh nhân bị chiếu xạ với cường độ vượt quá mức thiết kế
  • Trong giai đoạn 1985–1987, đã xảy ra nhiều vụ chiếu xạ quá liều nghiêm trọng đối với một số bệnh nhân, và một số người đã tử vong
  • Ban đầu, nguyên nhân là vấn đề phần mềm thường bị bỏ qua khi xem xét lỗi của máy xạ trị

Nguyên nhân của vấn đề

  • Trong quá trình kiểm chứng độ tin cậy, chỉ thực hiện các bài kiểm thử đơn giản không phản ánh môi trường lâm sàng thực tế
  • Việc xử lý lỗi và quản lý interlock chưa đầy đủ dẫn đến lỗi thuật toán trong các tình huống cực đoan
  • Do thiếu hệ thống báo cáo sự cố và giao tiếp rõ ràng giữa nhà sản xuất và bệnh viện, việc nhận biết và khắc phục lỗi bị chậm trễ
  • Sự cố này được đánh giá là một thất bại của thiết kế phần mềm lấy an toàn làm trung tâm

Những bài học chính

  • Khi thiết kế thuật toán liên quan trực tiếp đến an toàn, cần kiểm chứng kỹ lưỡng và lập trình phòng thủ
  • Bắt buộc phải đa dạng hóa các ca kiểm thử và mô phỏng dựa trên các kịch bản sử dụng thực tế
  • Nhấn mạnh việc triển khai có hệ thống các vòng lặp xử lý lỗi và hệ thống log
  • Trong các lĩnh vực đòi hỏi độ tin cậy cao, cần nhận thức rõ rủi ro khi phụ thuộc hoàn toàn vào điều khiển bằng phần mềm
  • Đây là một ví dụ tiêu biểu nhắc lại tầm quan trọng của độ tin cậy thuật toán, quản lý an toàn và hệ thống giao tiếp trong ngành kỹ nghệ phần mềm và thiết bị y tế trên toàn thế giới

Bài viết liên quan

1 bình luận

 
GN⁺ 2025-08-28
Ý kiến trên Hacker News

  • Điều này nhấn mạnh rằng chất lượng phần mềm không tự nhiên xuất hiện chỉ vì có các lập trình viên giỏi, mà là sản phẩm cuối cùng của một quy trình trải rộng trên toàn tổ chức. Quy trình đó không chỉ ảnh hưởng đến thực hành phát triển mà còn cả kiểm thử, ban lãnh đạo, thậm chí cả bộ phận kinh doanh và dịch vụ. Bài học chúng ta có thể rút ra từ vụ Therac-25 là chỉ riêng hệ thống kiểu, kiểm thử đơn vị hay viết mã phòng thủ thì không thể giải quyết hết mọi vấn đề. Theo tôi, thất bại thực sự nằm ở chỗ đã mất quá nhiều thời gian để báo cáo sự cố, điều tra và khắc phục. Gần đây podcast Cautionary Tales cũng có nói về chuyện này, và điều gây ấn tượng là trên Therac-25, người dùng liên tục gặp các lỗi không rõ nguyên nhân nhưng điều đó lại không được truyền đạt đúng cách tới những người có thể sửa nó. (liên kết podcast)

    • Tôi không đồng ý với ý kiến này. Tôi có nhiều năm kinh nghiệm thiết kế linh kiện máy bay, và nguyên tắc cốt lõi là không được để một lỗi đơn lẻ dẫn thẳng đến tai nạn. Cách thực hiện điều đó không phải là “viết phần mềm chất lượng” hay “kiểm thử đủ nhiều”, mà là có “một hệ thống độc lập có thể ngăn chặn ngay cả khi phần mềm hoạt động theo cách tệ nhất”. Với Therac-25, cần có thiết bị cảm biến bức xạ tự động ngắt khi vượt ngưỡng an toàn, và thiết kế vật lý sao cho không thể phát ra mức bức xạ quá mức.

    • Tôi cũng định giới thiệu podcast đó. Đặc biệt nếu bạn quan tâm đến lỗi phần mềm thì rất đáng nghe. Một chi tiết thú vị là cả thiết bị đời đầu vận hành thủ công cũng có cùng một khiếm khuyết, nhưng do cầu chì bị chập nên khiếm khuyết đó đã không trở thành hiện thực. Đây có thể xem là một ví dụ tuyệt vời của Swiss Cheese Model (tham khảo Swiss Cheese Model)

    • Tôi muốn nhấn mạnh rằng phần lớn phần mềm không gắn trực tiếp với sinh mạng con người. Trong đa số trường hợp, nếu thất bại thì chỉ là trang tải chậm, báo cáo đầy NaN, hoặc phải khởi chạy batch job bằng tay. Hiếm khi vấn đề chất lượng phần mềm thực sự khiến con người tử vong, và tôi nghĩ những lập trình viên làm ra loại phần mềm đó đều hiểu rõ trách nhiệm của mình.

    • Công ty nơi tôi từng làm tạo ra các thiết bị chụp ảnh và thiết bị khoa học với chất lượng hàng đầu. Chúng rất đắt, nhưng khách hàng thấy xứng đáng với số tiền bỏ ra. Tôi đã trực tiếp trải nghiệm rằng chất lượng không chỉ là kết quả của quy trình, mà rốt cuộc xuất phát từ “văn hóa”.

    • Nhiều lập trình viên nghĩ rằng nếu không làm hệ thống độ tin cậy cao thì vấn đề chất lượng không liên quan đến mình, nhưng đó là suy nghĩ hoàn toàn sai. Ngay cả thất bại phần mềm tưởng như nhỏ nhặt cũng có thể gây tác động khổng lồ đến cuộc sống của ai đó hoặc đến một công ty. Ví dụ như chặn một luồng quan trọng, làm hỏng dữ liệu cuộc đời hoặc hồ sơ y tế, hay khiến ai đó không thể thanh toán cho món hàng họ thực sự cần.

  • Một người trong phần bình luận bài báo có nhắc rằng vào thập niên 80~90, trong ngành y khi đó có nhận thức rất mạnh rằng máy tính là thứ nguy hiểm. Ngay cả đến đầu và giữa những năm 2000, hồ sơ y tế vẫn còn được viết tay trên giấy. Khi tôi tham gia ngắn hạn vào một dự án thử nghiệm hồ sơ bệnh án điện tử trong ICU, vai trò của tôi là quản lý máy chủ, và toàn bộ nhân viên y tế đều cực kỳ ghét hệ thống này. Hồi đó còn chưa có cả tablet, nên việc xem hoặc chỉnh sửa ghi chép trên máy tính rất bất tiện. Mọi đơn thuốc đều quen được ghi ngay trên bảng hồ sơ cạnh giường, có thể kiểm tra và sửa ngay lập tức. Mất thông tin hoặc chậm truy cập có thể là chí mạng, nên không phải các bác sĩ ghét máy tính vô cớ, mà họ thực sự cảm thấy nó nguy hiểm hơn bút và giấy. Tôi nghĩ sau này tình hình có lẽ đã khá hơn, nhưng đây vẫn là điều cần ghi nhớ.

    • Bây giờ những công ty như Chipsoft gần như độc chiếm toàn bộ mảng IT bệnh viện. Họ thu mức phí cực kỳ đắt mà chất lượng phần mềm thì tệ hại, và công ty càng lớn thì càng ít lựa chọn thay thế. Tôi không hiểu vì sao chúng ta lại chấp nhận những nhà cung cấp mang tính thù địch như vậy.

    • Vẫn có những trường hợp hệ thống tin học bị sập khiến nhân viên y tế phải quay lại dùng bút và giấy. Tôi không hiểu vì sao những hệ thống này lại không có dự phòng (redundancy). Điều đáng ngạc nhiên là đây chính là các sản phẩm thương mại hiện nay.

    • Ở Mỹ và châu Âu, EMR (hồ sơ bệnh án điện tử) không được phân loại là thiết bị y tế nên tránh được nhiều quy định. liên kết bài viết liên quan

  • So với vụ bê bối Bưu điện Anh thì đây là một đối chiếu thú vị. Hai vụ hoàn toàn khác nhau, nhưng điểm chung là cùng có giả định sai lầm rằng “phần mềm không thể sai”. Với lập trình viên thì đó là ý nghĩ quá buồn cười, nhưng với người không chuyên, tính mong manh của phần mềm rất khó hiểu. Đã từng tồn tại một văn hóa cho rằng phần mềm không thể có lỗi, nên thậm chí cũng không kiểm thử cho đúng mức.

    • Thực ra ngay cả lập trình viên cũng thường quá tin phần mềm. Tôi luôn nghĩ mọi hệ thống mình xây dựng đều có thể sụp đổ bất cứ lúc nào. Đó là lý do tôi sẽ không bao giờ đi xe tự lái. Tôi thấy lạ là người dùng HN dường như rất thích trở thành beta tester cho công nghệ mới. Dĩ nhiên có lập luận rằng xe tự lái an toàn hơn về mặt thống kê, nhưng một phần lý do là do những tài xế xung quanh lái cẩn thận hơn vì chúng. Hơn nữa, xe tự lái là hệ thống mới không có giám sát con người và khả năng can thiệp trực tiếp, hoặc không áp dụng các tiêu chuẩn nghiêm ngặt, và tôi nghĩ đó chính là vấn đề.

    • Tôi cho rằng ở đa số máy móc điện-cơ truyền thống, hỏng hóc chủ yếu đến từ sự hao mòn linh kiện, nên vì phần mềm không bị mòn, người ta mới đi đến niềm tin sai lầm rằng nó đương nhiên đáng tin hơn.

    • Tôi nghĩ vụ bê bối Bưu điện còn mang tính ác ý hơn nhiều. Các lãnh đạo cấp cao nhận incentive dựa trên số tiền thu được từ các chủ điểm giao dịch, và họ cũng nói dối với tòa án cùng các bộ trưởng về độ tin cậy của phần mềm. So với chuyện đó, Therac-25 gần như là một sai lầm thành thật.

  • Tôi có cảm giác một vụ tương tự Therac-25 sẽ sớm xảy ra. Có quá nhiều người đang vận hành AI agent theo kiểu YOLO, nên nếu những mô hình như Claude hay Gemini bị kết nối sai với phần cứng thực tế thì sớm muộn cũng sẽ dẫn đến tai nạn. AI dựa trên agent vẫn còn yếu trong lĩnh vực hệ thống nhúng, và chỉ cần tưởng tượng đến cảnh AI bị áp dụng vô trách nhiệm vào những lĩnh vực như thiết bị xạ trị là đã thấy đáng sợ.

    • Trong vụ Horizon của Bưu điện Anh, nhiều chủ điểm giao dịch đã tự sát và hàng chục cuộc đời bị hủy hoại. Tôi nghĩ bài học từ Therac-25 là mọi phần mềm đều quan trọng. Mọi phần mềm đều có nguy cơ gây hại cho ai đó, nên lúc nào cũng phải cẩn trọng.

    • Ngay cả AI không phải agent, theo một số định nghĩa, cũng đã “giết người”. Gần đây đã có những trường hợp gây chú ý khi chatbot AI dẫn đến tự sát, và nếu sau này AI được dùng trong các lĩnh vực ra quyết định quan trọng như bảo hiểm y tế thì khả năng “chết vì AI” sẽ còn tăng lên nhiều. AI đã gây ra tai nạn chết người ở nhiều nơi như xe tự lái. Ngay cả những lỗi nhỏ như lỗi Excel cũng từng ảnh hưởng xã hội ở quy mô hàng chục nghìn, hàng trăm nghìn người. Nhưng AI cũng sẽ có nhiều khoảng trống để né trách nhiệm như vụ Horizon vì trách nhiệm rất mơ hồ. Tôi cũng cảm thấy các công cụ AI copilot còn yếu trong lĩnh vực nhúng.

    • Sự cố 737 MAX MCAS là một thất bại ở cấp độ hệ thống, nhưng vẫn là ví dụ tiêu biểu cho loại vấn đề chất lượng phần mềm quy mô lớn như thế này. Tôi nghĩ những thảm họa như vậy sẽ còn lặp lại trong tương lai.

    • Tai nạn rơi Boeing 737 MAX cũng là ví dụ điển hình cho việc phần mềm chất lượng kém đã cướp đi sinh mạng của khoảng 350 người (liên kết thông tin MCAS)

    • Khi tôi thử dùng các AI agent mới nhất cho công việc nhúng, hiệu năng thấp hơn kỳ vọng. Ngay cả với một CRUD web app đơn giản, chỉ cần mô hình dữ liệu trở nên phức tạp và qua hai ba bước chuyển đổi là tôi đã thấy LLM bị rối rất thường xuyên. Ví dụ đầu vào là created_at, lưu trữ là created_on, còn gửi sang hệ thống bên ngoài là last_modified, chỉ riêng chuyện tên trường khác nhau như vậy cũng đã thành vấn đề.

  • Giai thoại về việc trên thiết bị Therac-25, chỉ với một chuỗi phím bấm cụ thể trên terminal VT100 là có thể gây ra phơi nhiễm bức xạ quá mức gần như tức thì thật sự gây ấn tượng mạnh. Người dùng có kinh nghiệm có thể gõ rất nhanh trong vòng 8 giây, và trong trường hợp đó đầu vào không được phản ánh đúng cách, dẫn đến tai nạn chết người. Nhìn những vấn đề như vậy, tôi thấy xu hướng ngày nay đưa cả giao diện công nghiệp hay xe cộ sang touchscreen có phần đáng lo.

    • Trong UI, để cải thiện trải nghiệm người dùng, người ta thường dùng optimistic update, vì vậy giao diện phản ánh rất nhanh nhưng thay đổi thực sự lại được đồng bộ sau. Tôi mong mọi người nhận thức đúng ở đâu thì cách này không cần thiết.

    • Trên máy tính iOS 11 từng có trường hợp nếu nhập nhanh “1+2+3” thì kết quả tính ra không đúng (trường hợp HN liên quan). Ngay cả một thứ tưởng như nhỏ nhặt như máy tính bỏ túi cũng có cùng kiểu failure mode này.

  • Tôi tò mò không biết ở đại học có ai từng được học những trường hợp như Therac-25 hoặc các ca liên quan đến an toàn/đạo đức hay không. Cá nhân tôi đã học vụ này trong một môn kỹ thuật đại cương cùng với đường cong bồn tắm và cách tính bơm làm mát dự phòng, và tôi thắc mắc liệu ngày nay những nội dung đó còn nằm trong chương trình học không.

    • Trong một lớp về giao diện máy móc ở Purdue vào đầu những năm 90, khái niệm “hysteresis” (độ trễ phản ứng) đã được nhấn mạnh. Các hệ thống analog không dừng lại tức thì như máy tính và có thể thể hiện nhiều hành vi khác nhau trong phạm vi hoạt động, nên bắt buộc phải tính đến điều đó.

    • Môn kỹ thuật hệ thống có đề cập những chủ đề tương tự. (liên kết lớp học MIT)

    • Tôi đã học về những sự kiện như thế này trong chương trình khoa học máy tính từ bậc đại học trở lên. Sau đó khi làm trong medtech, nó vẫn luôn quay lại trong đầu tôi.

    • Tôi nhớ trong giờ đạo đức kỹ thuật thực sự chỉ học Tacoma Narrows và Therac-25. Thậm chí chỉ gói gọn trong một bài giảng kéo dài 1 giờ.

    • Tò mò quá nên tôi tự tạo một cuộc khảo sát. Muốn biết mọi người có từng học những môn liên quan không. (liên kết khảo sát)

  • Các thiết bị trước đây có hardware interlock. Ngay cả khi phần mềm có vấn đề thì cùng lắm cũng chỉ gây bất tiện, nhưng do quá tự tin rằng phần mềm ổn định nên hardware interlock đã bị loại bỏ để tiết kiệm chi phí, và mọi giám sát đều giao cho phần mềm. Kết cục là một vấn đề nhỏ lại dẫn đến thảm kịch chết người. Đây là ví dụ điển hình cho sự lệch pha ở nhiều vị trí khác nhau.

  • Người viết bình luận đầu tiên dưới bài báo là một bác sĩ đồng thời học khoa học máy tính và là chủ tịch một hiệp hội chuyên ngành liên quan đến phòng chống bạo hành trẻ em (liên kết hồ sơ). Tuy nhiên, trong việc đánh giá y khoa về bạo hành trẻ em hiện nay vẫn còn rất nhiều lỗ hổng do dữ liệu và bằng chứng sai lệch, lập luận vòng tròn mang tính thăm dò, v.v. Rất khó tìm ra sự thật khách quan, và ngoài thực tế có xu hướng chỉ từ một vài dấu hiệu cũng xem là “bạo hành trẻ em không còn nghi ngờ gì nữa”. Gần đây lại xuất hiện các AI kiểu hộp đen tuyên bố phát hiện với độ chính xác cao dựa trên loại dữ liệu không hoàn chỉnh như vậy, nhưng không thể có dự đoán đúng từ dữ liệu sai (garbage in, garbage out). Tôi lo rằng chẩn đoán AI thiếu chính xác có thể dẫn tới những hậu quả nghiêm trọng như bị vu oan bạo hành trẻ em, gia đình tan vỡ, trừng phạt oan sai, v.v. (tài liệu tham khảo liên quan, bài báo lâm sàng, AI và vấn đề dữ liệu, liên kết nghiên cứu)

  • Báo cáo năm 1993 có đề cập đến sự cần thiết của chứng chỉ dành cho kỹ sư phần mềm an toàn trọng yếu. Người ta dự đoán rằng chỉ với vài khóa đào tạo lập trình thì không thể tự xưng là nhà phát triển phần mềm an toàn trọng yếu, và nếu những vụ như Therac-25 tiếp tục lặp lại thì chứng nhận liên quan sẽ trở thành bắt buộc. Ở Anh hiện đã có thảo luận về việc thiết kế chương trình đào tạo bắt buộc. Nhưng 32 năm đã trôi qua, và thực tế hiện nay khác xa kỳ vọng đó.

    • Tôi đã hoạt động 15 năm với tư cách kỹ sư phần mềm chuyên nghiệp có đăng ký ở Canada, nhưng không cảm nhận được lợi ích thực chất nào nên sắp tới sẽ ngừng gia hạn chứng chỉ. Từng có thời gian người ta bàn nhiều về việc biến phát triển phần mềm thành một ngành kỹ thuật có cấu trúc hơn, nhưng giờ có vẻ phần lớn đã lắng xuống.

    • Phần mềm an toàn trọng yếu không phải thứ học được trong lớp học, mà là năng lực tích lũy qua kinh nghiệm thực tiễn dài lâu và đào tạo. Dù có các tiêu chuẩn như hàng không (Do-178), công nghiệp (IEC 61508), mức độ áp dụng thực tế vẫn thay đổi theo ngân sách và tiến độ. Nhưng khi tai nạn xảy ra, dù có để lại kết quả audit đi nữa thì với nạn nhân cũng chẳng có ý nghĩa gì. Mọi quy định và luật lệ rốt cuộc đều được tạo ra sau khi đã có ai đó hy sinh.

  • Toàn bộ phần mềm Therac-25 được viết bởi đúng một lập trình viên, và sau khi ông ấy rời công ty vào năm 1986 thì danh tính chưa bao giờ được công khai. Nhiều độc giả có thể tưởng tượng rằng “lập trình viên đó đã kiếm được rất nhiều tiền từ bi kịch này và nghỉ hưu xa hoa”, nhưng vào thời đó, không giống bây giờ, lập trình viên được trả lương thấp và cũng không được coi trọng lắm. Trong thập niên 80, nhân vật chủ chốt ở các công ty công nghệ là nhân viên bán hàng, và rất có thể hoa hồng bán Therac-25 đã vượt lương năm của lập trình viên. Đặc biệt, vị trí của AECL, bối cảnh thời đại, tính chất bán nhà nước và đặc thù phần mềm nhúng đều là các yếu tố gắn với mức lương thấp. Vào năm 1986, mức lương chỉ khoảng 30.000~50.000 CAD, và quy đổi theo giá trị ngày nay cũng chỉ vào khoảng 78.000~129.000 USD, chưa kể không có stock option.