Therac-25 Olayı (2021)

 (thedailywtf.com)
2 puan yazan GN⁺ 2025-08-28 | 1 yorum | WhatsApp'ta paylaş
  • Therac-25 tıbbi radyasyon cihazında ölümcül kazalar meydana geldi
  • Yazılım hatası nedeniyle birçok hasta ciddi düzeyde aşırı radyasyona maruz kaldı
  • Mevcut güvenlik sistemlerinin dijital kontrol sistemiyle değiştirilmesi sonucu sorun ortaya çıktı
  • Hata teşhisi ve iletişim eksikliği nedeniyle kazanın nedeninin belirlenmesi gecikti
  • Güvenlik açısından temel ders olarak algoritma güvenilirliği ve kapsamlı testlerin önemi vurgulandı

Therac-25 olayına genel bakış

  • Therac-25, tedavi amaçlı radyasyon veren bir tıbbi cihaz olarak yaygın biçimde kullanılıyordu
  • Bu cihaz, kanser hastalarına yüksek dozda radyasyon uygulama görevini üstleniyordu
  • Geçmişteki mekanik interlock güvenlik düzenekleri, yazılım tabanlı kontrol sistemiyle değiştirildi
  • Ancak bu değişim, yazılım hataları oluşma riskini artırdı

Kazanın meydana geliş süreci

  • Belirli işlem sıralarında ya da hızlı ardışık girişler sırasında programda hata oluşuyordu
  • Bunun sonucunda güvenlik mekanizmaları düzgün çalışmadı ve hastalar tasarlananın üzerinde şiddette radyasyona maruz kaldı
  • 1985–1987 yılları arasında birkaç hastada ciddi aşırı doz radyasyon vakaları görüldü ve bazıları hayatını kaybetti
  • İlk dönemde, radyasyon cihazındaki arızanın nedeni olarak yazılım sorunu göz ardı edilme eğilimindeydi
Reklam

Sorunun nedenleri

  • Güvenilirlik doğrulama sürecinde, gerçek klinik ortamı yansıtmayan basit testler yapıldı
  • Hata işleme ve interlock yönetimindeki yetersizlik nedeniyle uç durumlarda algoritma hataları ortaya çıktı
  • Üretici ile hastaneler arasında açık bir sorun bildirim ve iletişim sistemi bulunmaması, hatanın fark edilmesini ve çözümünü geciktirdi
  • Bu olay, güvenlik odaklı yazılım tasarımının başarısızlığı olarak değerlendirilmektedir

Başlıca dersler

  • Güvenlikle doğrudan bağlantılı algoritmalar tasarlanırken kapsamlı doğrulama ve savunmacı programlama gereklidir
  • Test senaryolarının çeşitlendirilmesi ve gerçek kullanım senaryolarına dayalı simülasyonlar zorunludur
  • Çeşitli hata işleme döngüleri ve log sistemlerinin sistematik biçimde uygulanmasının önemi vurgulanır
  • Yüksek güvenilirlik gerektiren alanlarda, yalnızca yazılım kontrolüne bağımlılığın taşıdığı riskler kabul edilmelidir
  • Bu olay, dünya genelinde yazılım mühendisliği ve tıbbi cihaz sektöründe algoritma güvenilirliği, güvenlik yönetimi ve iletişim süreçlerinin önemini hatırlatan temsilî bir örnek oldu

İlgili okumalar

1 yorum

 
GN⁺ 2025-08-28
Hacker News görüşleri

  • Yazılım kalitesinin yalnızca iyi geliştiricilere sahip olmakla ortaya çıkmadığını, bunun tüm organizasyona yayılan süreçlerin nihai ürünü olduğunu vurguluyor. Bu süreç yalnızca geliştirme pratiklerini değil, test, yönetim, hatta satış ve hizmet ekiplerini de etkiliyor. Therac-25 vakasından öğrenmemiz gereken şey, tip sistemleri, birim testleri ya da savunmacı kod yazımının tek başına tüm sorunları çözmeyeceği. Asıl başarısızlığın, olayların raporlanması, incelenmesi ve düzeltilmesinin fazla uzun sürmesi olduğunu düşünüyorum. Yakın zamanda Cautionary Tales podcast'inde de işlendi; Therac-25'te kullanıcıların sürekli bilinmeyen hatalar yaşamasına rağmen bunun düzeltebilecek kişilere düzgün şekilde iletilmemesi özellikle dikkat çekiciydi. (podcast bağlantısı)

    • Bu görüşe katılmıyorum. Uzun yıllar uçak parçaları tasarlama deneyimim var ve temel ilke şu: tek bir arıza asla kazaya yol açmamalı. Bunu sağlamanın yolu “iyi yazılım yazmak” ya da “yeterince test etmek” değil, “yazılım en kötü şekilde davransa bile bunu engelleyecek bağımsız sistemler” kurmaktır. Therac-25 örneğinde, güvenlik eşiği aşılırsa otomatik olarak sistemi kapatacak bir radyasyon algılama cihazı ve fiziksel olarak aşırı radyasyon yayımını imkansız kılan bir tasarım gerekliydi.

    • Ben de tam bu podcast'i önerecektim. Özellikle yazılım hatalarıyla ilgileniyorsanız dinlemeye değer. İlginç bir ayrıntı da şu: başlangıçta manuel kullanılan cihazlarda da aynı kusur vardı ama sigortanın atması yüzünden bu kusur fiilen ortaya çıkmıyordu. Bu, Swiss Cheese Model için harika bir örnek sayılabilir (Swiss Cheese Model referansı)

    • Çoğu yazılımın doğrudan hayatla ölüm arasında bir yerde olmadığını vurgulamak istiyorum. Çoğu durumda başarısızlık; sayfanın yavaş açılması, raporun NaN ile dolması ya da bir batch işinin elle başlatılması gerekmesi düzeyindedir. Yazılım kalitesi yüzünden insanların gerçekten ölmesi nadirdir ve böyle yazılımlar geliştiren mühendislerin de sorumluluklarının farkında olduğunu düşünüyorum.

    • Çalıştığım şirket, sınıfının en iyi fotoğrafçılık ve bilimsel ekipmanlarını üretiyordu. Çok pahalıydılar ama müşteriler bunun karşılığını aldıklarını düşünüyordu. Kalitenin yalnızca sürecin değil, nihayetinde “kültürün” de ürünü olduğunu bizzat gördüm.

    • Pek çok geliştirici, yüksek güvenilirlikli sistemlerle çalışmıyorsa kalite sorunlarının kendileriyle ilgisi olmadığını düşünüyor ama bu tamamen yanlış. Önemsiz görünen bir yazılım arızası bile birinin hayatı ya da bir şirket üzerinde çok büyük etkiler yaratabilir. Örneğin kritik bir akışı durdurabilir, insanların yaşam verilerini ya da tıbbi kayıtlarını bozabilir veya gerçekten ihtiyaç duydukları bir ürünü satın almalarını engelleyebilir.

  • Makaledeki yorumculardan biri, 80'ler ve 90'larda tıp alanında bilgisayarların tehlikeli görüldüğünden söz etti. 2000'lerin başı ve ortasına kadar tıbbi kayıtlar elle kağıda yazılıyordu. ICU'daki elektronik hasta kaydı deney projesine kısa süreliğine katıldığımda sunucuları yönetiyordum ve tüm sağlık personeli bu sistemden nefret ediyordu. O dönem tablet bile yoktu; kayıtları bilgisayardan görmek ya da değiştirmek zahmetliydi. Tüm ilaç reçetelerini yatağın yanındaki çizelgeye doğrudan yazmaya alışmışlardı ve anında kontrol edip düzeltebiliyorlardı. Bilgi kaybı ya da erişim gecikmesi ölümcül olabileceğinden, doktorlar bilgisayarlardan sebepsiz yere nefret etmiyordu; gerçekten kalem ve kağıttan daha tehlikeli olduklarını düşünüyorlardı. Sonrasında işler muhtemelen iyileşmiştir ama bu hâlâ akılda tutulmalı.

    • Şu anda Chipsoft gibi şirketler hastane BT dünyasını neredeyse tekelleştirmiş durumda. Çok yüksek ücretler alıyorlar ama yazılım kalitesi berbat ve şirket büyüdükçe alternatifler de azalıyor. Bu kadar düşmanca davranan tedarikçilere neden izin verdiğimizi anlamıyorum.

    • Sağlık personelinin bilgi işlem sistemleri çöktüğü için hâlâ kalem ve kağıda dönmek zorunda kaldığı durumlar var. Bu sistemlerin yedeklilikten yoksun olmasını anlamıyorum. Bunların bugün ticari ürün olarak satılıyor olması şaşırtıcı.

    • ABD ve Avrupa'da EMR (elektronik tıbbi kayıt) sistemleri tıbbi cihaz olarak sınıflandırılmadığı için birçok düzenlemeden muaf. ilgili makale bağlantısı

  • Birleşik Krallık Post Office skandalıyla karşılaştırınca ilginç geliyor. Tamamen farklı olaylar ama her ikisinde de ortak olan yanlış varsayım, “yazılım yanlış olamaz” düşüncesi. Geliştiriciler açısından bu çok komik bir fikir ama uzman olmayanlar için yazılımın kırılganlığını anlamak zor. Yazılımda hata olamayacağı varsayılmış ve doğru düzgün test bile yapılmamıştı.

    • Aslında geliştiricilerin kendisi de çoğu zaman yazılıma gereğinden fazla güveniyor. Geliştirdiğim her sistemin her zaman çökebileceğini düşünürüm. Bu yüzden otonom araçlara asla binmem. HN kullanıcılarının yeni teknolojiler için beta test kullanıcısı olmayı gerçekten sevmesi bana hep ilginç gelmiştir. Elbette otonom araçların istatistiksel olarak daha güvenli olduğu söyleniyor ama bunun nedenlerinden biri de çevredeki sürücülerin daha dikkatli davranması. Ayrıca otonom araçlar, insan gözetimi ve doğrudan müdahale gibi özelliklerin ya da sıkı standartların tam uygulanmadığı yeni sistemler ve bence sorun da burada.

    • Geleneksel elektrikli ve mekanik makinelerin çoğunda başlıca arıza nedeni parça aşınmasıydı; yazılım aşınmadığı için doğal olarak daha güvenilir olduğuna dair yanlış bir inanç oluştuğunu düşünüyorum.

    • Post Office skandalının çok daha kötü niyetli olduğunu düşünüyorum. Üst düzey yöneticiler, şube sahiplerinden tahsil edilen paralara göre teşvik alıyordu ve mahkemelere, bakanlara yazılımın güvenilirliği konusunda yalan söylediler. Therac-25 bunun yanında dürüst bir hataya daha yakın kalıyor.

  • Therac-25'e benzer bir olayın yakında yaşanacağına dair kötü bir hissim var. YOLO modunda AI ajanları çalıştıran çok fazla insan var; Claude ya da Gemini gibi modeller gerçek donanıma yanlış biçimde bağlanırsa bir gün mutlaka kazaya yol açacakmış gibi geliyor. Ajan tabanlı yapay zeka gömülü sistemler alanında hâlâ yetersiz ve radyasyon cihazları gibi alanlara yapay zekanın sorumsuzca uygulanmasını hayal etmek bile korkutucu.

    • Birleşik Krallık Post Office Horizon olayında birçok şube sahibi intihar etti ve onlarca insanın hayatı mahvoldu. Therac-25 vakasından, her yazılımın önemli olduğu dersini çıkarmalıyız diye düşünüyorum. Her yazılımın birine zarar verme riski vardır; bu yüzden her zaman dikkatli olunmalı.

    • Ajan olmayan yapay zeka bile bazı tanımlara göre şimdiden “insan öldürüyor”. Yakın zamanda bir AI chatbot nedeniyle intihara sürüklenme vakası gündem oldu; ileride sağlık sigortası gibi kritik karar alanlarında yapay zeka kullanıldıkça “AI yüzünden ölüm” vakaları daha da artabilir. Otonom araçlar gibi alanlarda yapay zeka zaten ölümcül kazalara neden oldu. Excel hataları gibi küçük görünen bug'ların bile on binlerce, yüz binlerce insanı etkilediği toplumsal örnekler var. Ancak yapay zekada da sorumluluğun belirsiz kalması, Horizon vakasında olduğu gibi kaçış alanı yaratacaktır. AI copilot araçlarının da gömülü sistemler tarafında yetersiz olduğunu hissediyorum.

    • 737 MAX MCAS krizi sistem düzeyinde bir başarısızlıktı ama bu tür büyük yazılım kalite sorunlarının en tipik örneklerinden biri. Gelecekte de buna benzer felaketlerin tekrarlanacağını düşünüyorum.

    • Boeing 737 MAX düşüşleri de düşük kaliteli yazılımın yaklaşık 350 kişinin hayatına mal olduğu çarpıcı bir örnek (MCAS bilgi bağlantısı)

    • En yeni AI ajanlarıyla gömülü işler yapmayı denediğimde performans beklentimin altındaydı. Basit bir CRUD web uygulamasında bile veri modeli karmaşıklaştığında, iki-üç dönüşüm adımı sonrasında LLM'in kafasının karıştığını çok gördüm. Örneğin girişte created_at, veritabanında created_on, dış sisteme gönderimde last_modified gibi farklı alan adları kullanıldığında sorun çıkıyor.

  • Therac-25 cihazında VT100 terminalinde belirli tuş girişleriyle bir anda aşırı radyasyona maruz kalınabildiğine dair anekdot çok çarpıcıydı. Deneyimli bir kullanıcı 8 saniye içinde tuşlara hızla basabiliyordu; bu durumda giriş düzgün işlenmiyor ve ölümcül kazaya yol açabiliyordu. Böyle sorunları görünce günümüzde endüstriyel ya da araç içi arayüzlerin bile dokunmatik ekrana kayması bana endişe verici geliyor.

    • Arayüzlerde kullanıcı deneyimini iyileştirmek için çoğunlukla optimistic update kullanılıyor; bu yüzden ekrandaki yansıma hızlı olurken gerçek uygulama daha sonra senkronize ediliyor. Bunun nerelerde kesinlikle kullanılmaması gerektiğinin iyi anlaşılmasını umuyorum.

    • iOS 11 hesap makinesinde hızlıca “1+2+3” girildiğinde doğru sonuç vermediği bir örnek vardı (ilgili HN örneği). Basit görünen bir hesap makinesinde bile aynı hata modu bulunabiliyor.

  • Üniversitede Therac-25 gibi vakaları veya güvenlik/etik örneklerini öğrenip öğrenmediğinizi merak ediyorum. Ben bunu genel mühendislik dersinde, bathtub curve ve yedekli soğutma pompası hesapları gibi konularla birlikte görmüştüm; bugün de müfredata dahil olup olmadığını merak ediyorum.

    • Purdue'da 90'ların başındaki insan-makine arayüzü dersinde “histerezis” kavramı özellikle vurgulanıyordu. Analog sistemler bilgisayarlar gibi anında durmaz; çalışma aralığı içinde farklı davranışlar gösterebilir ve bunun mutlaka hesaba katılması gerekiyordu.

    • Sistem mühendisliği derslerinde buna benzer konular işleniyor. (MIT ders bağlantısı)

    • Üniversite düzeyi ve üstü bilgisayar bilimi eğitimimde bu tür vakaları gördüm. Sonrasında medtech alanında çalışırken de sık sık aklıma geldi.

    • Mühendislik etiği dersinde gerçekten sadece Tacoma Narrows ve Therac-25'i işlediğimizi hatırlıyorum. Üstelik toplamı bir saatlik dersti.

    • Merak edip bizzat bir anket hazırladım. Bu tür ders deneyimi olan var mı diye görmek istiyorum. (anket bağlantısı)

  • Önceki cihazlarda donanımsal interlock vardı. Yazılımda bir sorun çıksa bile sonuç en fazla rahatsızlık verici oluyordu; ancak yazılımın güvenilir olduğuna aşırı güvenildiği için, maliyet azaltma amacıyla donanım interlock'ları kaldırıldı ve denetim tamamen yazılıma bırakıldı. Sonuçta küçük bir sorun ölümcül bir felakete dönüştü. Farklı seviyelerdeki uyumsuzlukların klasik bir örneği.

  • Makaledeki ilk yorumu yazan kişi bir doktor, bilgisayar bilimi mezunu ve çocuk istismarını önleme alanındaki uzman bir derneğin başkanı (özgeçmiş bağlantısı). Ancak çocuk istismarına ilişkin tıbbi değerlendirmelerde hâlâ hatalı veri, zayıf kanıt ve keşifsel döngüsel akıl yürütme gibi ciddi gedikler var. Nesnel gerçeği bulmak zor ve sahada birkaç bulguya dayanarak “şüpheye yer bırakmayan çocuk istismarı” sonucuna varma eğilimi bulunuyor. Son dönemde, bu kusurlu veriler üzerine yüksek doğrulukta tespit iddiasında bulunan kara kutu AI sistemleri ortaya çıkıyor; oysa hatalı veriden doğru tahmin çıkmaz (garbage in, garbage out). Hatalı AI teşhislerinin, çocuk istismarı iftirası, ailelerin dağılması ve yanlış cezalandırmalar gibi ağır sonuçlar doğurmasından endişe ediyorum. (ilgili referans, klinik makale, AI ve veri sorunları, araştırma bağlantısı)

  • 1993 tarihli raporda, güvenlik açısından kritik yazılım mühendisleri için bir yetkinlik gerekliliğinden söz ediliyor. Yalnızca birkaç programlama dersi almış birinin kendisini güvenlik kritik yazılım geliştiricisi ilan edemeyeceği, Therac-25 benzeri olaylar tekrarlandıkça ilgili sertifikasyonun zorunlu olacağı öngörülüyordu. Birleşik Krallık'ta gerekli eğitim programlarının tasarlanması bile tartışılmıştı. Ancak 32 yıl sonra gerçeklik bu beklentiden oldukça uzak.

    • Kanada'da kayıtlı profesyonel yazılım mühendisi olarak 15 yıl çalıştım ama pratikte bir faydasını görmedim; bu yüzden yakında lisans yenilemeyi bırakmayı düşünüyorum. Yazılım geliştirmeyi daha yapılandırılmış bir mühendislik disiplini hâline getirme yönünde tartışmalar vardı ama artık büyük ölçüde kaybolmuş gibiler.

    • Güvenlik kritik yazılım sınıfta öğrenilmez; uzun saha deneyimi ve eğitimle kazanılır. Havacılıkta (Do-178) ve endüstride (IEC 61508) standartlar olsa da fiili uygulama düzeyi bütçe ve takvime göre değişiyor. Ama bir kaza yaşandığında, ne kadar denetim kaydı olursa olsun mağdur açısından bunun bir anlamı kalmıyor. Tüm düzenlemeler ve kurallar, sonuçta biri bedel ödedikten sonra ortaya çıkıyor.

  • Therac-25 yazılımının tamamı tek bir geliştirici tarafından yazıldı ve 1986'da şirketten ayrıldıktan sonra kimliği bir daha hiç açıklanmadı. Pek çok okur, “geliştirici bu trajediden büyük para kazandı ve lüks içinde emekli oldu” diye hayal edebilir ama o dönem geliştiriciler bugün olduğu kadar ne iyi maaş alıyor ne de takdir görüyordu. 80'lerde teknoloji şirketlerinin yıldızları satışçılardı ve Therac-25 satış komisyonlarının geliştiricinin maaşını aşmış olması muhtemeldi. Özellikle AECL'nin konumu, dönemin koşulları, kamu bağlantısı ve gömülü yazılım niteliği düşünüldüğünde düşük ücret çok olası. 1986'da Kanada'da maaşın $30k–50k civarında olması ve bugünün değerine çevrildiğinde bunun yaklaşık US$78k–129k aralığına gelmesi, ayrıca hisse opsiyonu da olmaması şaşırtıcı değil.