BT’de Acil Kültürü: Yangın Söndürme Döngüsünü Kırmak

BT ekiplerinin en çok düştüğü tuzak, işlerini “aciliyet” üzerinden yönetmek zorunda kalmalarıdır. İlk bakışta bu, BT’nin doğası gibi görünür: sistem çöker, kullanıcı bağlanamaz, servis durur ve ekip hızla müdahale eder. Ancak sorun, acilin kendisi değil; acilin normalleşmesi ve bir çalışma modeline dönüşmesidir. Buna BT’de “yangın söndürme kültürü” diyoruz.

🔥 Acil Neden Bu Kadar Yaygın?

Çünkü çoğu şirkette BT:

Planlanan işlerle değil, kesintilerle şekilleniyor
Proaktif izleme yerine reaktif müdahaleye dayanıyor
Süreç, otomasyon ve izlenebilirlik eksik
Envanter, log, performans ve trend verisi karar süreçlerinde kullanılmıyor
Teknik borçlar birikiyor ve her gün yeni bir acile dönüşüyor

Bir ekip sürekli acille çalışıyorsa, artık sorun arıza değil; yönetim modelidir.

🧾 Acil Kültürü Hangi Belirtileri Gösterir?

Belirti	Ne Anlama Geliyor?
“Şunu hemen yapabilir misin?” cümlesinin standart olması	Süreç yok, kişi bazlı iş var
Ticket açılmadan iş yapılması	İzlenebilirlik ve rapor yok
Monitoring alarmlarının olmaması	Kör uçlarda risk birikimi
Aynı sorunların tekrar tekrar yaşanması	Root Cause analizi yapılmıyor
Dokümantasyonun olmaması	Bilgi tek kişide kilitli
Otomasyon eksikliği	İnsan gücüyle operasyon
Kullanıcı baskısıyla öncelik değişmesi	Data değil, gürültü karar veriyor

⚠️ Peki Neden Asıl Sorun Bu?

Çünkü:

Siber güvenlik zayıflar:
Sistemler envanterde değilse, acil müdahalelerde portlar açılır, kurallar yazılır ama kimse kuralın neyi etkilediğini bilemez. Zero Trust, SIEM, EDR gibi olgunluk gerektiren güvenlik adımları bu ortamda ilerleyemez.
Teknik borç artar:
Anlık çözüm odaklı işler, kalıcı çözümleri hep erteler. Bugün 10 dakikada “geçici fix” yapılan bir sorun, 2 ay sonra 6 saatlik büyük bir kesintiye dönüşebilir.
BT’nin itibarı düşer:
Ekip kendini parçalar, gece gündüz çalışır ama yönetim bunu performans değil, kaos olarak görür. Çünkü başarı değil, sadece kesinti yokluğu ölçülür.
Maliyet yükselir:
Kayıt dışı alımlar (Shadow IT), sahiplenilmeyen sistemler, yanlış lisans kullanımı, plansız yenilemeler… Bunların hepsi acil kültürünün finansal yansımalarıdır.

🎯 Olgun BT’de işler nasıl yürür?

İşler öncelik matrisi + SLA ile yönetilir
Arızalar ticket’a dönüşmeden önce anomali olarak izlenir
Monitoring, log ve envanter verisi karar motorudur
Tekrar eden sorunlarda Root Cause + Preventive Action çıkarılır
İşler kişiden bağımsız süreçlerle yürür
Otomasyon ile tekrar eden işler yok edilir
Yönetim raporları kesintilerden değil, trendlerden oluşur

🧯 Nasıl Çözüm Getirilir? (Kısa ama güçlü reçete)

Ticket dışı işi yasaklamak değil, anlamsızlaştırmak (her işin ticket üzerinden daha hızlı yapılır hale getirilmesi)
Monitoring kurup aciliyet yerine anomali konuşmak
Envanteri genişletip sahipsiz sistemleri sahipli hale getirmek
Otomasyonla aynı işleri tekrar etmemek
BT KPI’larını “kesinti yokluğu” yerine trend iyileşmesi ve önleyici aksiyonlar üzerinden ölçmek

✍️ Kapanış

Acil kültürü, BT’nin kahramanlık hikâyesi gibi görünür ama aslında ilerlemeyi kilitleyen sis perdesidir. Gerçek kahramanlık, “yangın söndürmek” değil, yangının çıkmasını engelleyen sistemi kurmaktır.