Acil tıpta "Altın Saat" (Golden Hour) kavramı, hayatın ve ölümün arasındaki en ince çizgiyi tanımlar. İlk kez 1975 yılında Dr. R Adams Cowley tarafından formüle edilen bu prensip şunu söyler: Ağır bir travma geçiren hastanın hayatta kalma şansı, ilk 60 dakika içinde yapılan müdahalenin kalitesiyle doğru orantılıdır. Bu süre geçtikten sonra, en yetenekli cerrah bile geri dönüşü olmayan hasarlarla yüzleşmek zorunda kalır.

Bu kavram acil tıp dünyasının her köşesine işlemiştir. Ambulans çağrısından hastanın ameliyathaneye alınmasına kadar geçen süreçteki her bir saniye optimize edilmiş, protokolleştirilmiş ve ölçümlenmiştir. Çünkü acil tıp, zamanın bir kaynak değil, bir silah olduğunu anlamıştır.

Peki yazılım dünyası?

Sunucu Odasındaki Altın Saat

Büyük bir e-ticaret platformunu düşünün. Black Friday gecesi saat 21:00'de ana veritabanı sunucusu yanıt vermeyi durduruyor. Bu an, dijital dünyanın travma anıdır.

İlk 5 dakika içinde yapılan müdahale, şirketin o geceyi gelir kaybıyla mı yoksa itibar kaybıyla mı kapayacağını belirler. İtibar kaybı, gelir kaybından çok daha ağır bir yaradır çünkü iyileşmesi aylar alır.

Ancak çoğu yazılım ekibinin bir "Altın Saat" protokolü yoktur. Alarm çaldığında ne olur? Nöbetçi mühendis telefonunu açar. Belki açmaz çünkü sessiz moddadır. Slack'e bir mesaj atılır. 15 dakika sonra biri yanıt verir. VPN bağlantısı kurmaya çalışır. Şifresini hatırlayamaz. IT'ye bilet açar.

Bu arada sunucu hâlâ yerde yatmaktadır. Ambulansın anahtarı kaybolmuş gibidir.

MIST ve SBAR: Acil Tıptan Ödünç Alınacak Protokoller

Acil tıpta bir paramedik hastaneye hasta teslim ederken, o kaotik ortamda bile yapılandırılmış bir iletişim protokolü kullanır. En yaygınlarından biri MIST formatıdır:

  • Mechanism (Mekanizma): Ne oldu?
  • Injuries (Yaralanmalar): Neler hasar gördü?
  • Signs (Belirtiler): Hayati bulgular neler?
  • Treatment (Tedavi): Şimdiye kadar ne yapıldı?

Bu format, kritik bilginin saniyeler içinde, eksiksiz ve anlaşılır bir şekilde aktarılmasını sağlar. Bir paramedik asla "Şey, hasta biraz kötü görünüyordu, bir şeyler yaptık, tam hatırlamıyorum" demez.

Yazılım dünyasında ise olay müdahalesi (incident response) genellikle şöyle başlar: "Bir şeyler bozuldu galiba. Birisi bakabilir mi?" Bu mesajda ne bozuldu, ne zaman bozuldu, kimleri etkiledi, hangi servisler çalışmıyor gibi kritik bilgilerin hiçbiri yoktur.

Eğer MIST formatını yazılıma uyarlasaydık şöyle görünürdü:

  • Mekanizma: Son deploy'dan 3 dakika sonra başladı.
  • Hasar: Ödeme servisi yanıt vermiyor, kullanıcılar checkout yapamıyor.
  • Belirtiler: CPU %100, veritabanı bağlantı havuzu tükenmiş, hata oranı %78.
  • Yapılanlar: Son deploy geri alındı, etki devam ediyor.

Bu kadar net, bu kadar yapılandırılmış bir ilk mesaj, ekibin müdahale süresini dakikalardan saniyelere indirebilir.

"Scoop and Run" vs "Stay and Play"

Acil tıpta iki temel müdahale felsefesi vardır. "Scoop and Run" (Kap ve Koş): Hastayı minimum müdahaleyle en hızlı şekilde hastaneye taşı. "Stay and Play" (Kal ve Müdahale Et): Sahada kapsamlı müdahale yap, hastayı stabilize et, sonra taşı.

Hangi yaklaşımın seçileceği hastanın durumuna ve mevcut kaynaklara bağlıdır. İç kanama geçiren birini sahada ameliyat edemezsiniz, onu en yakın travma merkezine yetiştirmeniz gerekir. Ama solunum yolu tıkanmış birini stabilize etmeden taşırsanız yolda kaybedersiniz.

Yazılım krizlerinde de aynı karar verilmelidir. Veritabanı tamamen çökmüşse ve elimizde yedek (backup) varsa, sorunu sahada (production) çözmeye çalışmak yerine hızlıca yedekten geri dönmek (Scoop and Run) daha mantıklı olabilir. Ancak sorun bir bellek sızıntısıysa (memory leak) ve sistemi yeniden başlatmak geçici bir çözümse, kök nedeni bulana kadar sahada kalmak (Stay and Play) gerekir.

Sorun şu ki, çoğu yazılım ekibi bu ayrımı yapacak deneyime ve soğukkanlılığa sahip değildir. Ya her şeyi sahada çözmeye çalışarak altın saati tüketirler, ya da her şeyi geri alarak asıl sorunu hiç çözmezler ve aynı kriz bir hafta sonra tekrar eder.

Tıpkı acil tıpta olduğu gibi yazılımda da altın saatin farkında olmak, o saati nasıl kullanacağınızı bilmek ve en önemlisi o saat dolmadan harekete geçmek; işte projenizin yaşaması ile ölmesi arasındaki fark budur.