June 23, 2026
Bir “Bug” Kaç Can Alır?
Bir yazılım hatasının en kötü sonucu nedir?

By HSD Gebze Technical University
6 min read
Mühendislik dünyasında bazı hatalar sistemlerin çökmesine, bazıları ise veri kaybına yol açar. Ancak çok az yazılım hatası, doğrudan insan hayatına mal olacak kadar trajik sonuçlar doğurmuştur. 1980'lerin ortalarında, tıp teknolojisinin zirvesi olarak tanıtılan Therac-25 radyoterapi makinesi, tam olarak bu karanlık senaryonun başrol oyuncusu oldu.
Peki sistem seviyesindeki birkaç satır kod, nasıl oldu da şifa dağıtması beklenen bir cihazı ölümcül bir silaha dönüştürdü?
Therac-25 Nedir Ve Ne Amaçla Kullanılıyordu?
Therac-25, Kanada merkezli AECL (Atomic Energy of Canada Limited) ve Fransız CGR firmalarının ortaklığıyla kanser hastalarının tedavisinde kullanılmak üzere geliştirilmiş, tıbbi bir lineer hızlandırıcıydı. Cihazın amacı, yüksek enerjili radyasyon kullanarak tümör hücrelerini yok etmek ve hastaların tedavi süreçlerine katkı sağlamaktı.
Makine iki farklı modda çalışabiliyordu: Yüzeye yakın tümörler için düşük enerjili "Elektron" modu ve daha derin dokulara ulaşmak için kullanılan, önüne fiziksel bir hedef plaka yerleştirilerek uygulanan yüksek enerjili "X-Işını" modu. Döneminin en ileri teknolojisi olarak kabul edilen Therac-25, önceki modellerin aksine çok daha kompakt bir tasarıma sahipti ve operatörlere bilgisayar terminali üzerinden inanılmaz bir kullanım kolaylığı vadediyordu.
Sistemin Teknik Yapısı
Therac-25, AECL'nin daha önce ürettiği Therac-6 ve Therac-20 modellerinin doğal bir evrimiydi. Ancak bu evrim aşamasında alınan bazı mühendislik kararları, felaketin yapıtaşlarını oluşturdu.
Önceki modeller olan Therac-6 ve Therac-20, aslında bağımsız çalışan bir lineer hızlandırıcı ile bir bilgisayarın sonradan birbirine bağlanmasıyla oluşturulmuştu. Bu nedenle, o makinelerde donanımsal güvenlik kilitleri (hardware interlocks) adı verilen bağımsız elektromekanik devreler bulunuyordu. Örneğin, makine X-Işını moduna geçtiğinde hedef plakanın fiziksel olarak ışının önüne geldiğini doğrulayan mekanik şalterler vardı. Yazılım hata yapsa ve "Ateşle" komutu verse bile, plaka yerinde değilse bu elektromekanik kilitler devreye girer, sigortaları attırır ve radyasyonu fiziksel olarak engellerdi.
Fakat Therac-25 baştan aşağı "bilgisayar kontrollü" olacak şekilde, çok daha entegre ve kompakt tasarlandı. Mühendisler, cihazı küçültmek ve üretim maliyetlerini düşürmek için ölümcül bir karar aldılar: Bağımsız donanım kilitlerini sistemden tamamen çıkardılar. Böylece güvenliğin önemli bir kısmı yazılıma devredilmiş oldu.
Bu kararın arkasında ise yazılıma duyulan büyük güven yatıyordu. Therac-25'in kontrol yazılımının önemli bölümleri, yıllardır kullanılan Therac-20 yazılımından devralınmıştı. Oysa Therac-20'nin yazılımında da aynı hatalar vardı; sadece donanımsal kilitler her seferinde makineyi durdurduğu için bu yazılım hatalarını kimse fark etmiyordu.
Donanım kilitleri kaldırıldığında, hastanın hayatı tamamen PDP-11 bilgisayarı üzerinde çalışan ve tek bir yazılımcı tarafından yazılmış, gerçek zamanlı işletim sistemi (RTOS) standartlarından uzak bir koda emanet edilmiş oldu. Artık yazılımın sözü kanundu ve onu denetleyecek hiçbir fiziksel mekanizma kalmamıştı.
Sistemin güvenliği büyük ölçüde yazılıma emanet edilmişti ve yazılımda bulunan bazı kritik hatalar yıllar boyunca fark edilmeden kaldı.
Kazalar Nasıl Yaşandı?
Makinenin piyasaya sürülmesinden kısa bir süre sonra, 1985 ile 1987 yılları arasında, Amerika Birleşik Devletleri ve Kanada'daki farklı hastanelerde akıl almaz olaylar yaşanmaya başladı.
Hastalar tedavi sırasında aniden şiddetli bir yanma hissi duyduklarını söylüyor, bazıları ise sanki elektrik çarpmasına maruz kalmış gibi hissettiklerini ifade ediyordu.
Bu durum son derece sıra dışıydı. Normal bir radyoterapi seansında hastanın herhangi bir şey hissetmemesi beklenir. Tedavi kontrollü bir şekilde uygulanır ve verilen radyasyon dozu dikkatle sınırlandırılır. Ancak Therac-25 kazalarında bazı hastalar bir saniyeden kısa sürede 10.000 ila 25.000 rad arasında radyasyona maruz kalıyordu. Bu miktar, normal tedavi dozunun yüzlerce katına karşılık geliyordu.
Sonuçlar yıkıcıydı. Birkaç yıl içerisinde birden fazla hasta aşırı radyasyona maruz kaldı, ağır yaralanmalar meydana geldi ve bazı vakalar ölümle sonuçlandı. Therac-25 artık sadece bir tıbbi cihaz değil, yazılım tarihinin en önemli güvenlik vakalarından biri hâline gelmişti.
Gizemli Hata Kodları
Peki operatörler hastaları yakıp kavuran bu devasa gücü neden fark edemiyordu? Cevap, yazılımın tehlikeli hata yönetiminde ve korkunç dokümantasyon eksikliğinde gizliydi.
Cihaz bir anormallik algıladığında, operatörün ekranında yalnızca "MALFUNCTION" (Arıza) kelimesi ve ardından 1 ile 64 arasında değişen bir sayı beliriyordu (Örneğin: MALFUNCTION 54). Operatörler ne olduğunu anlamak için kullanım kılavuzunu açtıklarında, bu hata kodlarının hiçbir şekilde açıklanmadığını görüyorlardı. Daha da kötüsü, kılavuzda bu hataların hasta güvenliği için bir tehdit oluşturabileceğine dair en ufak bir uyarı dahi yoktu.
Zamanla operatörler bu mesajları sıradan bir aksaklık olarak görmeye başladı. Çünkü sistem sık sık çeşitli nedenlerle duraklıyor ve çoğu durumda tedaviye devam etmek için yalnızca tek bir tuşa basmak yeterli oluyordu.
Therac-25 operatörleri de tam olarak bunu yapıyordu. Ekranda bir hata mesajı belirdiğinde çoğu zaman durumu sorgulamadan tedaviye devam ediyorlardı. Ne yazık ki bazı durumlarda karşılarına çıkan hata mesajı sıradan bir yazılım aksaklığını değil, hastaya ölümcül miktarda radyasyon gönderildiğini işaret ediyordu.
Kazalar arttıkça araştırmacılar sorunun cihazın mekanik parçalarında değil, perde arkasında çalışan kontrol yazılımında olduğunu fark etmeye başladı. Ancak yazılımın nasıl olup da böylesine tehlikeli bir duruma yol açabildiğini anlamak yıllar sürecekti.
Ölümcül 8 Saniye
Therac-25'in neden olduğu kazaların arkasında aslında oldukça sıradan görünen bir durum vardı: Bir operatörün hatasını çok hızlı düzeltmesi.
Makine iki farklı tedavi modunda çalışıyordu: Elektron ve X-Işını. X-Işını seçildiğinde, ölümcül ışını süzmek için devasa mıknatısların ve koruyucu plakaların fiziksel olarak yer değiştirmesi gerekiyordu. Bu ağır mekanik süreç anlık gerçekleşmiyor, yaklaşık 8 saniye sürüyordu.
Sorun tam da bu 8 saniyelik zaman penceresinde, yazılımın içindeki bir "iletişim kopukluğunda" gizliydi.
Senaryoyu düşünelim: Operatör yanlışlıkla X-Işını modunu seçiyor. Cihazın arka planındaki donanım yönetim sistemi bu emri alıp, o 8 saniyelik ağır fiziksel hareketi anında başlatıyor. Ancak operatör saniyeler içinde hatasını fark edip ayarı Elektron moduna çeviriyor.
Operatörün ekranında artık güvenli olan "Elektron" modu yazıyordu. Onun bakış açısından her şey normaldi. Ancak cihazın beyninde, yazılım mühendisliğinde race condition (yarış durumu) olarak bilinen ölümcül bir kaos yaşanıyordu.
İşletim sisteminin arka planında iki ana işlem (process) çalışıyordu: Biri ekrandaki veriyi güncelliyor, diğeri mekanik parçaları hareket ettiriyordu. Normalde bu iki işlemin aynı veriyi kullanırken aralarında bir kilit mekanizması olması gerekirdi. Ancak Therac-25'te böyle bir güvenlik önlemi yoktu. Arayüz "Elektron moduna geçtik" derken, donanımı yöneten sistem 8 saniyelik X-Işını kurulumu için çoktan yola çıkmıştı ve arayüzdeki bu son dakika değişikliğini dönüp bir daha kontrol etmiyordu.
Yani sistemin beyni ikiye bölünmüştü: Ekran operatöre makinenin Elektron modunda olduğunu söylüyor, fiziksel donanım ise hâlâ X-Işını modunda kalıyordu.
İşte yarış durumu tam olarak buydu; iki farklı sürecin aynı verilere kontrolsüzce erişmesi ve sistemin kaderinin, bu işlemlerin saniyelik zamanlamalarına kalması. Normalde bir bilgisayar oyununda veya masaüstü uygulamasında bu senkronizasyon hatası yalnızca programın çökmesine yol açar. Ancak Therac-25'te, bu yazılım hatasının bedeli hastaya korumasız bir şekilde devasa dozda radyasyon fırlatılmasıydı. Ve bu kez bedel, birkaç saniyelik bir hatadan çok daha ağırdı.
İkinci Hata: Bir Sayacın Taşması
İlk yarış durumu hatası tespit edilip düzeltildiğinde, Therac-25 probleminin çözüldüğü düşünüldü. Ancak kazalar devam etti.
Bu durum araştırmacılar için oldukça şaşırtıcıydı. Çünkü artık aynı hatanın tekrar yaşanmaması gerekiyordu. Fakat sistemde çok daha temel bir problem daha vardı.
Yazılımın bazı bölümlerinde cihazın durumunu takip etmek için küçük sayaçlar ve bayraklar kullanılıyordu. Bu bayraklardan biri, belirli güvenlik kontrollerinin tamamlanıp tamamlanmadığını takip etmekle görevliydi.
Sorun, bu bayrağın doğrudan belirli bir değere ayarlanmak yerine her seferinde artırılmasıydı.
Normal şartlarda bu bir problem gibi görünmeyebilir. Ancak bilgisayarlarda sayılar sonsuza kadar büyüyemez. Bir değişken tutabileceği maksimum değere ulaştığında ve bir kez daha artırıldığında, değer sıfıra döner. Bu duruma integer overflow (tam sayı taşması) adı verilir.
Therac-25'te tam olarak böyle bir durum yaşandı.
Belirli koşullar altında sayaç taşmaya uğruyor ve sistem güvenlik kontrollerinin durumunu yanlış yorumluyordu. Sonuç olarak yazılım, aslında yerinde olmayan bir X-ışını hedef plakasını varmış gibi kabul edebiliyordu.
Sistem, önünde radyasyonu süzecek o ağır hedef plakası (X-Işını kalkanı) yerinde olmamasına rağmen makineyi ateşledi. X-Işını moduna ayarlanmış yüksek akımlı elektron ışını, herhangi bir filtreleme olmadan doğrudan hastaya fırlatıldı.
Hastalar, çok daha dar ve odaklanmış bir alanda, hedeflenen radyasyon dozunun yaklaşık 100 katına denk gelen, potansiyel olarak ölümcül bir beta radyasyonu dozuna maruz kaldı. Bir yazılımcının, güvenlik değişkenini "sabit tutmak" yerine "sürekli artırmasını" tercih etmesi, masum insanları bir kez daha ağır yanıklarla ve geri dönüşü olmayan fiziksel tahribatlarla baş başa bırakmıştı.
Therac-25'in Mirası
Therac-25 vakasından çıkarılan en önemli derslerden biri, güvenlik kritik sistemlerde yazılıma körü körüne güvenilemeyeceğidir. Bu olaydaki en büyük problemlerden biri, daha önceki modellerde bulunan bağımsız donanım güvenlik mekanizmalarının kaldırılmasıydı. Yazılım hata yaptığında onu durdurabilecek ikinci bir savunma hattı kalmamıştı. Günümüzde havacılık, otomotiv, sağlık ve uzay sistemlerinde hâlâ birden fazla güvenlik katmanı kullanılmasının temel sebeplerinden biri de budur.
Therac-25 aynı zamanda yazılım mühendisliğinin yalnızca kod yazmaktan ibaret olmadığını da göstermiştir. Bir mühendisin sorumluluğu çalışan bir sistem geliştirmekten çok daha fazlasıdır. Hataları öngörmek, riskleri değerlendirmek, kullanıcıları doğru bilgilendirmek ve insan hayatını etkileyebilecek kararların sonuçlarını düşünmek de mühendisliğin ayrılmaz bir parçasıdır.
Bu olayın ardından güvenlik kritik yazılımların geliştirilmesi ve test edilmesi konusunda çok daha katı standartlar ortaya çıkmıştır. Hata toleransı, güvenlik analizleri, bağımsız doğrulama süreçleri ve güvenlik sertifikasyonları günümüzde birçok sektörde zorunlu hâle gelmiştir. Çünkü Therac-25, bir sistemin "çalışıyor gibi görünmesinin" güvenli olduğu anlamına gelmediğini acı bir şekilde göstermiştir.
Yazılım tarihi, mühendislik vizyonunun sınırlarını zorlayan başarılar ve sistem tasarımlarını kökünden değiştiren krizlerle doludur. Apollo görevlerinde astronotları kurtaran o efsanevi uçuş yazılımı veya yıllar sonra Mars Pathfinder aracında iletişimi kilitleyen öncelik tersine dönmesi (priority inversion) gibi vakalar, donanım ile yazılım arasındaki o hassas dengeyi bize hep hatırlatır. Ancak Therac-25, bu denge bozulduğunda ve güvenlik testleri ihmal edildiğinde ödenecek bedelin doğrudan insan hayatı olduğunu gösteren en karanlık örnektir.
Teknolojimiz ne kadar gelişirse gelişsin, Therac-25'in bize öğrettiği o değişmez kural masada durmaya devam ediyor:
Bilgisayarlar hata yapar, yazılımlar çöker; masadaki bahis insan hayatıysa, koda asla körü körüne güvenilemez.
Kaynakça:
- https://hackaday.com/2015/10/26/killed-by-a-machine-the-therac-25/
- https://en.wikipedia.org/wiki/Therac-25
- https://www.cs.columbia.edu/~junfeng/08fa-e6998/sched/readings/therac25.pdf
- https://ethicsunwrapped.utexas.edu/case-study/therac-25
- https://www.youtube.com/watch?v=B31KJFLXnq8&t=2s
- https://www.youtube.com/watch?v=PuTqsYz_Gtg
- https://www.youtube.com/watch?v=M76TQpY8eWw
- https://www.youtube.com/watch?v=UXt5SG0qlR0&t=176s