Anasayfa Öne Çıkan Therac-25 Faciası: Yazılım Hatası Canlar Aldı!
Öne ÇıkanVideo

Therac-25 Faciası: Yazılım Hatası Canlar Aldı!

paylaş
paylaş

Yazılımcılık, birçok kişi tarafından düşük riskli ve rahat bir meslek olarak algılanabilir. Sonuçta, masanızda oturup birkaç satır kod yazıyor ve bunları paketliyorsunuz. Peki, bu kadar basit görünen bir iş gerçekten bu kadar zararsız mı? Birkaç satırda yapılan bir hata çok sayıda kişinin ölümüne sebep olabilir mi? Yazılımcının yapacağı en ufak bir hata gerçekten hayatlara mal olabilir mi?

Size çarpıcı bir hikaye anlatacağım. 1985 yılında, Katy adında bir kanser hastası düzenli olarak radyoterapi almak için bir tedavi merkezine gidiyordu. Yine bir gün, 12 kez tekrarlanacak tedavi için merkeze doğru yola çıktı. Her şey normaldi, daha önce defalarca yapmıştı. Alışkın olduğu şekilde hazırlandı ve tedavi merkezine ulaştı.

Cihazla birlikte Katy’nin üst sol göğsüne 200 rad’lık bir terapi uygulanması gerekiyordu. Bu standart bir dozajdı ve normalde hiçbir şey hissetmemesi gerekiyordu. Ancak makine çalıştırıldığında, Katy büyük bir acı hissetti. Bu acı çok yoğun bir sıcaklık hissiydi ve “Beni yaktınız!” diye teknisyene seslendi. Teknisyen ise böyle bir şeyin mümkün olmadığını, her şeyin normal gittiğini ve tedavinin tamamlandığını söyledi.

Fakat birkaç hafta sonra Katy’nin sol göğsünün tamamen alınması gerekti ve sol kolu felç oldu. Böylece bir şeylerin yolunda gitmediği kesinleşmiş oldu. Bu, bahsedeceğimiz yazılım hatasının ilk kurbanıydı.

Kanser hastalığı, temel olarak hücrelerin kontrolsüz bölünmesiyle ilerleyen bir hastalıktır. Normalde ulaşamayacağımız yerlere, hem çok derinde olması hem de çok küçük olması sebebiyle, radyasyon yardımıyla müdahale ediyoruz. Yüksek enerjili parçacıklar, vücudumuzun içinden geçerek sadece hedef aldığımız noktaya vurarak o kısmı tedavi edebiliyor. Bunu da radyoterapi ile gerçekleştirebiliyoruz. Radyoterapi, 10 kanser hastasının 4’ünde etkili olan oldukça güçlü bir silah. Bugün de yaygın olarak kullandığımız bir teknoloji.

Burada asıl problem tedavi yöntemiyle değil, bu tedaviyi uygulayan cihaz ve onun yazılımındaydı. Therac-25 adı verilen bir makine vardı. Bu makine, AECL Medical tarafından geliştirilip satışa sunulan, oldukça güçlü ve dijital bir cihazdı. Yazılımının da oldukça kuvvetli olduğu iddia ediliyordu. Therac-25’in kullanımı çok kolay olduğu için hızlıca yayılmış ve birçok merkezde kullanılmaya başlanmıştı.

Ancak problem şuydu: Therac-25, Therac-20’nin yazılımını kullanıyordu ve Therac-20 de çok eski bir çalışan tarafından geliştirilmiş bir yazılıma sahipti. Bu yazılım aynen kullanılmıştı, ancak yazılıma ait bir dokümantasyon yoktu. Yazılımla ilgili detaylı bilgisi olan kimse yoktu. Sadece yazılım tamamen otomatik olarak çalıştığı için bir cihazdan diğerine aktarılmıştı. Zaten Therac-20’de düzgün şekilde çalıştığı bilindiği için 25’e de aktarılmış ve bu şekilde kullanılmaya başlanmıştı.

Katy’nin trajik hikayesinden sonra, benzer olaylar yaşanmaya devam etti. Bir başka kadın, rahim ağzı kanseri tedavisinde yine aynı şekilde bir merkeze gitti ve Therac-25 ile tedavi gördü. Kadın, tedavi sırasında kendisini vurulmuş gibi hissettiğini söyledi. Hesaplanan ölçülere göre yaklaşık 17.000 rad’lık bir doz almıştı, ki bu bir insanın alması gereken dozun çok üzerindeydi.

AECL, hemen bir ekip göndererek cihazı inceledi. Mühendisler, kendilerince hatanın nereden kaynaklandığını bulmaya çalıştılar ve bir çözüm getirdiklerini söyleyerek bir yazılım güncellemesi yayınladılar. Tüm makineyi kullanan merkezlere, makinenin artık 5 kat daha güvenli olduğu söylendi.

Ancak bundan sadece bir ay sonra, yine başka bir yerde aynı makine benzer bir olaya sebep oldu. Bu sefer o kadar yüksek bir dozaj olmadığı için sadece yaralanmayla atlatıldı, ama problemin devam ettiği açıkça görülmüş oldu.

Bu olaylar üzerine, Therac-25’i kullanan operatörler kendi aralarında daha fazla iletişime geçmeye başladılar. Belli ki makinenin üreticisi AECL, sorunu çözmek için yeterince çaba göstermiyordu. Operatörler, bir şekilde kendilerini de güvence altına almak için çözüm üretmeye çalışıyorlardı.

İki ay sonra firma bir açıklama daha yaptı. Bu problemlerin kendi cihazları ya da operatörleri kaynaklı olmadığını, bunun mümkün olmadığını, tüm incelemeleri yaptıklarını söyleyerek yine işin içinden sıyrılmaya çalıştılar. Ancak sonraki 12 ayda 3 kişi daha bu cihaz yüzünden hayatını kaybetti.

Therac-25, bugüne göre basit ama o günler için karmaşık bir yazılım kullanıyordu. Yaklaşık 100.000 satırlık bir kod vardı içerisinde. Bu yazılım çalışırken eğer bir hatayla karşılaşırsa, operatörün karşısına bir hata metni çıkarıyordu. Hata 1’den Hata 64’e kadar kodlar vardı. Eğer cihaz herhangi bir problemle karşılaşırsa, kullanıcının karşısına “Hata 1”, “Hata 2”, “Hata 3” gibi kodlar çıkıyordu.

Ancak problem şuydu: Hangi hatanın ne anlama geldiğini kimse bilmiyordu, çünkü dokümantasyon yoktu. Operatörler, yaptıkları açıklamada günde ortalama 4 tane hata gördüklerini, bunu görmeye alıştıklarını söylüyorlardı. Dolayısıyla hata metni gördüklerinde “Tamam” deyip geçiyorlar ve cihazı kullanmaya devam ediyorlardı. Çünkü cihaz çalışmaya devam ediyordu.

Ama asıl problem, “Hata 54″teydi. Tüm bu trajik olaylara sebep olan hata buydu. Diğer hatalar gibi, operatör “Hata 54″ü gördüğünde de tuşa basıp devam ediyordu. Tabii bunu anlayana kadar birkaç hayata daha mal oldu.

Cox isimli bir hasta, kanser tedavisi için yine bir merkeze gitti. 9 kez tedavi alacaktı ve daha önce geçirdiği süreçlere alışmıştı. Dozaj 180 rad’a ayarlandı. Sonra operatör yanlış modu seçtiğini fark etti, hemen düzeltti, ayarları yaptı ve kaydetmek istediğinde cihaz “Hata 54” verdi. Alışkın olduğu için hatayı geçti ve cihazı çalıştırdı. Cox inanılmaz büyük bir ağrı hissetti. İşin kötü tarafı, interkom da iyi çalışmıyordu, operatör hastayı duyamıyordu. Birkaç kez makineyi çalıştırdı ve en sonunda fark ettiklerinde, Adam bayağı acılar içerisinde kıvranıyordu.

Doktorlar hemen ilgilendi, muayene etti, bir tedavi uyguladılar ve eve gönderdiler. Ama maalesef o kadar fazla radyasyon aldıktan sonra başına kötü bir şey gelmemesi imkânsız gibiydi. Birkaç hafta sonra tabii ki tekrar hastaneye geri dönmek zorunda kaldı.

AECL yine kabul etmedi, aşırı doz verilmesinin kendi cihazlarında imkânsız olduğunu söyledi. Ama diğer taraftan operatörler artık “Hata 54” durumunu incelemeye başladılar. Yalnız problem şuydu: “Hata 54″ü istediklerinde üretemiyorlardı. Denemeler yapıyorlar, hangi durumda “Hata 54” çıkıyor diye bakmaya çalışıyorlardı ama bir türlü ortaya çıkmıyordu bu hata.

Bundan bir ay sonra, Kit isimli bir otobüs şoförü yine tedavi için aynı makineyi kullandı. “Hata 54” ve maalesef yine çok yüksek bir dozajla karşı karşıya kaldı. Cox’un ölümünde şöyle bir farklılık oldu: Nihayet artık bunun radyasyon tedavisinden kaynaklı bir ölüm olduğu raporlara geçen ilk ölüm oldu. Öncekiler bir türlü bu şekilde kaydedilememişti çünkü ölüm anında gerçekleşmiyordu. Sonrasında da başka sebepler bulunuyordu. Ama Cox’ta artık bunun radyasyon kaynaklı bir ölüm olduğunu kayda geçirdiler ve hemen arkasından Therac-25’i kapatıp incelemeye aldılar.

Kit kazasından sonra bir operatör ve bir fizikçi doktor bir araya gelerek Therac-25 üzerinde “Hata 54″ü tekrar üretmeye çalıştılar. Çok fazla şey denediler ama bir türlü “Hata 54″ü tekrar üretmeyi başaramadılar. Artık dene-yanıl, dene-yanıl sıkılmışlardı. Sürekli sayfalarla, ayarlarla oynuyorlardı. Derken bir yerde operatör çok hızlı şekilde bazı ayarları değiştirdi, değiştirdi, değiştirdi ve “Kaydet”e bastı. “Hata 54”! Hatayı üretmeyi başarmışlardı.

Tabii burada hatayı üreten o anki tuşun ne olduğunu bildikleri için hatanın da bu olduğunu zannettiler. “Artık listede şu şu hareketi yaptığınız zaman bu hatayı üretiyorsunuz. Dolayısıyla bunu yapmayın” diye bu cihazı kullanan merkezlere uyarı gitti. Ve hatayı engelleme üzerine bir adım atıldığı savunuldu.

Burada fark ettiyseniz, aslında sanki biraz kullanıcı hatasıymış gibi lanse edildi durum. Yani operatör bu listeyi bu şekilde güncellememeliymiş gibi… Ama asıl problem çok daha derindeydi.

Therac-25, mıknatıslarla çalışan bir makineydi. Bu makinede siz bir ayar yaptığınızda, mıknatıslar fiziksel olarak yer değiştiriyordu ve bazı konumlara geliyordu, bazı ayarlar yapılıyordu. Operatör bir ayarlama yapmak istediğinde mıknatıslar hareket etmeye başlıyor ve doğru konuma geliyorlardı. Ancak bunu yapmaları yaklaşık 8 saniye alıyordu.

Problem şuydu: Operatörler bir değişiklik yaptıktan sonra, mıknatıslar gelmeleri gereken konuma 8 saniye içerisinde gelmeden önce operatör yeni bir değişiklik yapıp “Kaydet”e basarsa, yaptığı yeni değişiklik sistem üzerinde algılanmıyordu. Aslında çok basit bir hata… Yani o 8 saniye boyunca sistemin hiçbir girdi almaması gerekiyordu, çünkü bir önceki komutu yerine getirmeye çalışıyordu. Ama sistem daha önce verilen komutu yerine getirmek üzere hareket ediyorsa ve o arada yeni bir komut gelirse “Hata 54” üretiyordu.

Yani “Ben şu an bir değişiklik yapıyorum. Bana dokunma, yaptığın son değişikliği almadım” anlamına geliyordu. Ama bu uyarıyı bu sistem vermiyordu. Sadece “Hata 54” diyordu ve operatör “Tamam” deyip geçiyordu. Çünkü tam olarak neye sebep olduğunu bilmiyordu. Böylece yaptığı son ayarlamalar, son dozaj düzeltmeleri, mod düzeltmeleri güncellenmiyordu. Operatör son olarak yapmış olduğu ayarlamaların doğru olduğunu, makine üzerinde doğru olduğunu zannederken, aslında önceki ayarlar geçerli kalıyordu.

Sonrasında artık bunu fark ediyorlar ve AECL yazılımında bir güncelleme yaparak tüm makinelere bunu dağıtıyor. Ve artık tüm makinaların doğru şekilde çalıştığından emin oluyorlar kendilerince.

Ancak 6 hafta sonra biri daha hayatını kaybediyor. Bu sefer farklı bir hata oluyor. Makinenin kendi kendine tüm ayarları ve tüm yapılarını kontrol eden bir çalışma şekli var. Bu çalışma şeklinde her bir kontrolde bir değişkenin değeri bir artırılarak devam ediyor ve bir nevi checklist kontrol edilmiş oluyor. Burada kullanılan değişkenin tipi integer ve 256 farklı değer alabilen bir değişken kullanılıyor.

Başlarda her ne kadar 256 durum kontrol edilmesi mümkün gibi gözükse de, her gün onlarca kez kullanıldığında cihaz bu kontrollerin sayısı çok fazla artıyor ve 256’yı geçiyor. Böylece cihaz kontrollerini yaparken 256’dan sonra 255’e, sonra 0’a döndüğünde aslında kontroller bitmemiş oluyor. Çünkü değişkenin limitlerine ulaştıkları için sıfıra dönüyorlar, ama makine bunu “tüm kontroller tamamlandı” olarak kabul ediyor. Çünkü değişken değeri 0 olduğunda “tüm kontroller tamamlandı ve hiçbir problem yok” anlamına geliyor.

Böylece cihaz üzerindeki bir arızayı daha fark edemiyorlar. Cihaz tüm kontrollerini kendi kendine sağlayamamış oluyor. Yine bu kontrolleri sağlayamadığı için cihaz üzerinde bazı şeyler eskisi gibi kaldığı için yine çok yüksek bir dozajla tedavi uygulanıyor ve yine bir kayba sebep oluyor.

Şimdi bunları aslında kanser tedavisinden korkalım diye ya da programcılık çok riskli, bundan kaçalım diye anlatmıyorum. Elbette ki burada fark etmek gereken şey şu: Aslında programcılıkta çok basit gibi gözüken bir şey sonrasında başka şeylere sebep olabiliyor. Burada sağlıkla ilgili bir yazılım yapıldığı için, sağlıkla ilgili bir cihazın yazılımı yapıldığı için risk daha fazla elbette. Ama inşaatla ilgili ya da büyük makinelerin yazılımları yapılırken de benzer risklerle karşılaşılabilir.

Farkında mısınız, hatanın… Yani makine bir problem olduğunun farkında. “Hata 54” diyor, bir şey var diyor, bir problem var diyor. Ama problemin ne olduğunu kullanıcıya söylemiyor ya da kendisi düzeltmiyor. Makine bunu “Burada bir problem oluştu” deyip durdurmyor, dondurmyor, ayarları düzeltmiyor ve sadece “Hata 54” deyip geçiyor.

Öbür tarafta sadece bir değişkenin kapasitesi daha az kaldı diye (belki double bir kapasite kullanılsa yeterli olacaktı, bilmiyoruz), ama sadece bir değişken kapasitesi uygun değerde kullanılmadı diye bir başka problem çıkıyor.

Tabii burada yazılımın kullandığı cihaz insan hayatına etki eden bir cihaz olduğu için, otomatik olarak yazılım öldürücü bir yazılım haline gelmiş oluyor. Dolayısıyla programlamada bu tarz şeylerin çok iyi planlanması gerekiyor. Yani bir değişkenin ne kadar kapasiteye sahip olacağı, hata ayıklama sisteminin ne olacağı gibi şeyler aslında üzerinden hızlıca geçip gidilecek şeyler değil.

Şimdi diyeceksiniz ki bugünün programlama şartları çok daha farklı. Evet, çok daha becerikli araçlar kullanıyoruz. Ama hala bir değişkenin ne kadar boyut aldığını biz belirliyoruz, değil mi? Ya da hata kodlarını biz belirliyoruz. Ya da daha önemlisi, kullanıcı arayüzleri ve kullanıcı deneyimi bizim elimizde. Yani biz ne kadar iyi kullanıcı deneyimi sağlarsak, o zaman o makine ya da o arayüz o kadar iyi kullanılıyor.

Eğer operatörler “Hata 54″ün yanında aynı zamanda “Ayarlarınız kaydedilmedi” mesajını görseydi, belki de bunlar yaşanmayacaktı ve çok daha erken bu hatanın çözümü bulunuyor olacaktı.

Tüm bunlar aslında hem yazılımcılıkta dikkat edilmesi gereken durumları, hem de aslında yazılımın sadece kodlamadan ibaret olmadığını, kullanıcı arayüzü ve kullanıcı deneyimi tarafında da yapılması gereken şeyler olduğunu bize gösteriyor.

Bundan sonra kodlama yaparken çok daha dikkatli olmak dileğiyle diyelim. Görüşmek üzere!

paylaş

Leave a comment

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir

Related Articles
Öne ÇıkanPodcast

AWS mi Paylaşımlı (Shared) Hosting mi?

Yeni Girişimlerde Sunucu Seçimi ve MVP Yaklaşımı Yeni bir web veya mobil...

BlogÖne Çıkan

Üniversitede Ders Alma Nasıl Yapılır?

Hey! Üniversiteye yeni başlayan arkadaşım. İlk gün heyecanını yaşamadan ders alma heyecanı...

SeriÖne Çıkan

SEO Yolculuğu

Eğer işletmeniz ya da girişiminiz dijital ise görünür olmak her şeydir. Fiziksel...

PodcastÖne Çıkan

Yazılımcılık Bir Ömür Yapılır mı?

Yazılım dünyası sürekli gelişen ve değişen dinamik bir sektör. Bu alanda kariyer...