Yazılıma yeni başlayan veya orta kıdemdeki geliştiricilerin kodlarında en sık rastlanan, ilk bakışta "sorumlu ve tedbirli" gibi görünen ama aslında bir felaketin tohumlarını eken klasik bir kalıp vardır:

try {
  processCriticalTransaction(userPayload);
} catch (error) {
  logger.error("Bir hata oldu ama çaktırmıyoruz:", error);
  return null; // veya return [];
}

Geliştirici bu kodu yazarken kendince gurur duyar: "Bakın, sistemim asla çökmüyor (crash olmuyor). Hata çıksa bile yakalıyorum, loga yazıyorum ve akışı kesintisiz devam ettiriyorum."

Oysa o geliştiricinin bilmediği şey, sistemin kalbine saatli bir bomba yerleştirdiğidir.

Hatayı yutarak (exception swallowing) yoluna devam eden o süreç; bellekte yarım kalmış bir nesne referansı, veritabanında açılmış ama kapanmamış bir transaction kilidi veya hesaplama mantığında zehirlenmiş bir state (durum) bırakmıştır.

Sistem çökmeyip suni solunumla nefes almaya devam ettikçe; o bozuk veri diğer servislere yayılır, bellek sinsi bir şekilde tükenir ve saatler sonra, gecenin üçünde tüm platform öngörülemez, kurtarılamaz ve izi sürülemez bir kaskat çöküşle (cascading failure) yerle bir olur.

İşte tam bu noktada, telekomünikasyon dünyasının ve dağıtık sistemlerin en devrimci dehası olan Joe Armstrong'un ve Erlang/OTP dünyasının o radikal manifestosu yankılanır: "Let it crash!" (Bırakın çöksün!)

Tıpta Apoptozis ve DNR: Ne Zaman Duracağını Bilmek

Bu felsefeyi kavrayabilmek için biyolojinin ve acil tıbbın en derin kurallarına bakmak gerekir.

İnsan vücudunda her gün milyarlarca hücre DNA hasarına uğrar veya işlevini yitirir. Vücut bu hasarlı hücreleri "ne pahasına olursa olsun yaşatmaya" çalışmaz. Aksine, biyolojinin en kusursuz savunma mekanizması olan apoptozis (programlanmış hücre ölümü) devreye girer. Hasarlı hücreye intihar sinyali gönderilir; hücre sessizce parçalanır, temizlenir ve yerine kemik iliğinden gelen taptaze, sağlıklı bir hücre yerleşir.

Eğer vücut o hasarlı hücreyi zorla yaşatmaya çalışsaydı ne olurdu? O hücre kontrolsüzce çoğalır, diğer dokuları istila eder ve biz buna tıp dilinde kanser derdik.

Benzer şekilde, acil serviste veya yoğun bakımda hekimliğin en ağır ama en hayati kararlarından biri "DNR" (Do Not Resuscitate - Canlandırma Uygulamayın) anıdır.

Beyin ölümü gerçekleşmiş, çoklu organ yetmezliğine girmiş ve biyolojik olarak geri dönüşü imkansız bir hastaya saatlerce kalp masajı yapmak, adrenalin pompalamak hastayı hayata döndürmez; sadece hastanın kaburgalarını kırar, dokuları parçalar ve ölümü gereksiz bir ıstırapla uzatır. İyi bir hekim, ne zaman müdahale edeceğini bildiği kadar, doğanın sınırlarına ne zaman saygı duyup geri çekileceğini de bilen hekimdir.

Erlang Felsefesi: Bozuk State'i Tamir Etmeye Çalışma

Yazılımda "Let it crash" ilkesi, "Hata yönetimini boş verin, sistem darmadağın olsun" anlamına gelmez. Tam aksine, kusursuz bir hata izolasyonu ve yeniden başlatma disiplini demektir.

Geleneksel savunmacı programlamada (defensive programming), geliştirici her olası hatayı önceden tahmin edip kodun içine yüzlerce if-else ve try-catch serpiştirir. Bu durum kodu okunmaz hale getirdiği gibi, tahmin edilemeyen sıra dışı bir durum (edge case) ortaya çıktığında sistemin öngörülemez bir duruma (undefined state) girmesine neden olur.

Erlang ve aktör modelinin yaklaşımı ise son derece berraktır:

İzolasyon (Shared Nothing): Her işlem (process) kendi izole bellek alanında çalışır. Bir işlemin çökmesi, yanındaki diğer işlemi fiziksel olarak etkileyemez.
Fail Fast (Hızlıca Çök): İşlem beklenmeyen bir durumla karşılaştığı an, durumu yamamaya çalışmadan anında ölmeli (crash olmalıdır). Çünkü belleğindeki verinin bozulup bozulmadığını garanti edemezsiniz.
Süpervizör Ağacı (Supervisor Trees): Ölen işlemi gözlemleyen bir üst mekanizma (supervisor) vardır. Bu mekanizma, ölen süreci milisaniyeler içinde öldürür ve onu bilinen, temiz, kararlı bir başlangıç state'i ile yeniden ayağa kaldırır.

Bu, bir cerrahın ameliyathanede enfekte olmuş ve dokusu çürümüş bir apandisiti dikip onarmaya çalışmak yerine, onu kökünden kesip dışarı atması ve hastanın sağlıklı dokusunun kendini yenilemesine izin vermesi gibidir. Temiz bir başlangıç, yamalı bir hayattan her zaman daha güvenilirdir.

Zombi Süreçler ve Sessiz Zehirlenme

Bir sistemde istisnaları yutmanın en korkunç sonucu "Zombi Süreçler"dir.

Örneğin bir mikroservis mimarisinde, ödeme kuyruğunu tüketen bir worker düşünün. Bir veritabanı bağlantı hatası veya deserialization bug'ı yüzünden worker'ın bir thread'i kilitlendi. Ancak geliştirici hatayı catch bloğunda yuttuğu için proses işletim sistemi seviyesinde ayakta duruyor; Kubernetes pod'unun liveness check'i 200 OK dönmeye devam ediyor.

Dışarıdan baktığınızda her şey yeşil, monitörler pırıl pırıl!

Fakat içeride, kuyruktaki mesajlar birikiyor; kilitlenen thread hafızayı tüketiyor, diğer thread'lerin kaynaklarını sömürüyor. Sistem can çekişiyor ama ölmesine izin verilmediği için yerine yeni bir pod ayağa kaldırılamıyor.

Eğer o worker ilk hatada "bırakılsaydı ve çökseydi"; işletim sistemi prosesi öldürecek, Kubernetes pod'un çöktüğünü anlayıp 2 saniye içinde taze bir pod başlatacak ve kuyruk akmaya devam edecekti.

Sistemin çökmesini engellemek adına yaptığınız her yapay pansuman, aslında sistemin kendini iyileştirme refleksini felç eden bir toksindir.

Çöküşten Korkmayan Mimariler İnşa Etmek

Mühendislik olgunluğu, "asla çökmeyen sistemler" hayal etmekten vazgeçip; "her an çökebileceğini kabul eden ve çöktüğünde hiçbir veri kaybetmeden, saniyeler içinde ayağa kalkan sistemler" tasarlamaya başladığınızda gelir.

Bu zihniyet dönüşümü mimarinizi kökten değiştirir:

Stateless Tasarım: Süreçlerinizin içinde kalıcı durum tutmazsınız. Bir sürecin ölmesi hiçbir veri kaybına yol açmaz; durum veritabanında veya dağıtık kuyrukta güvenle saklanır.
İdempotent İşlemler: Yeniden başlayan bir süreç, yarım kalmış bir işi tekrar denediğinde (retry) yan etki (side-effect) üretmez; aynı işlemi güvenle tekrarlayabilir.
Circuit Breaker ve İzolasyon: Çöken bir bağımlılık, tüm platformu peşinden sürüklemez; devre açılır ve sistem zarafetle geriler (graceful degradation).

Korku, mimarinin en kötü danışmanıdır. Bir sistemin çökmesinden korktuğunuz için her satırı yapay korumalarla boğarsanız, ortaya sadece kriz anında ne yapacağı kestirilemeyen kırılgan bir canavar çıkarırsınız.

Bırakın çöksün. Hızlı çöksün, gürültülü çöksün ve temiz çöksün. Çünkü ancak doğru çökmeyi bilen sistemler, gerçek krizlerin ortasında dimdik ayakta kalabilir.

erlang

"Bırakın Çöksün": Bazen Sistemlerin Çökmesine İzin Vermek Gerekir