Bir incident kapandığında takvim sakinleşir ama sistem gerçekten sakinleşmiş olmaz. Alarm sesi kesildiği anda çoğu ekip iki uçtan birine savrulur: ya ertelenmiş tüm işleri bir anda geri yüklemeye çalışır ya da kesinti sırasında açığa çıkan borçları belirsiz bir “sonra bakarız” alanına iter. Teknik lider için asıl sınav tam burada başlar. Çünkü incident sonrasındaki ilk birkaç gün, yalnızca toparlanma dönemi değil; ekibin gelecek iki haftasını, bazen bir çeyreğini şekillendiren öncelik sıfırlama anıdır.
Neden sıfırlama gerekir?
Kesinti döneminde işler doğal olarak bozulur:
- Planlı teslimatlar durur
- Operasyon yükü birkaç kişide toplanır
- Geçici çözümler kalıcı gibi görünmeye başlar
- Yeni riskler görünür hâle gelir
Eğer ekip bu tabloyu bilinçli biçimde yeniden çerçevelemezse backlog şişer, karar kalitesi düşer ve “incident bitti ama hâlâ toparlayamadık” hissi kalıcılaşır. Öncelik sıfırlama disiplini tam olarak bunu engeller: duygusal reaksiyonu değil, sistematik yeniden dengelemeyi öne çıkarır.
İlk yapılacak iş: aynı listede her şeyi tutmamak
Birçok ekip incident sonrası tek bir görev listesi üretir. Oysa üretim güvenliği ile yol haritası maddelerini aynı torbada tutmak, karar bulanıklığı üretir. Ben ilk ayırımı şu üç başlıkla yapmayı daha doğru buluyorum:
- Hemen kapatılması gereken operasyonel açıklıklar
- Öğrenim ve kalıcı iyileştirme işleri
- Yeniden başlayabilecek normal teslimatlar
Bu sınıflandırma yapılmadan “önceliklendirme” konuşmak genelde kavga üretir. Çünkü herkes farklı risk seviyesindeki işi aynı listede savunur.
Hangi işleri gerçekten acil saymalı?
Incident sonrasında her bulgu kritik değildir. Teknik liderin burada panik değil eşik üretmesi gerekir. Şu tip maddeler genelde ilk dalgada ele alınmalıdır:
- Aynı semptomu tekrar ettirecek açık konfigürasyon hataları
- Yetersiz alarm veya görünürlük boşlukları
- Rollback ve değişiklik güvenini düşüren eksikler
- Tek kişiye bağımlı müdahale adımları
Buna karşılık daha büyük mimari dönüşümler, olayın bahanesiyle “hemen yapalım” kategorisine sokulmamalıdır. Çünkü incident sonrası dönemde ekiplerin odak kapasitesi zaten azalmıştır. Büyük iş, doğru olabilir; ama ilk iş olmayabilir.
Yol haritası nasıl yeniden dengelenir?
Burada teknik liderin rolü “her şeyi durdurmak” değildir. Asıl iş, hangi teslimatların güvenle devam edebileceğini gösterebilmektir. Ben şu üç sorunun oldukça işe yaradığını görüyorum:
- Bu iş incident kök nedenini veya tekrar riskini artırıyor mu?
- Bu iş için gereken ekip odağı son günlerde operasyon tarafından tüketildi mi?
- Bu teslimat ertelenirse iş etkisi, operasyon iyileştirmesinden daha mı büyük?
Bu sorularla bakıldığında bazı proje maddeleri olduğu gibi devam eder, bazıları küçültülür, bazıları ise bilinçli biçimde ötelenir. Kritik nokta, bu kararların “hissettiğimiz için” değil görünür çerçeveyle alınmasıdır.
Toparlanma borcu diye ayrı bir dil kurmak gerekir
Ben incident sonrası dönemde “toparlanma borcu” ifadesini faydalı buluyorum. Çünkü bu alan klasik teknik borçtan biraz farklıdır. Toparlanma borcu şunları içerir:
- Geçici bypass veya manuel iş adımları
- Olay sırasında açılmış ama kapatılmamış erişimler
- Kalıcılaştırılmamış gözlemler ve timeline notları
- Yorgunluk nedeniyle ertelenmiş bakım işleri
Bu borç görünmez bırakıldığında ekip takvimi normal görünür ama sistem hâlâ yaralı çalışır. O yüzden teknik lider bu işleri “sonra bakarız” bölümüne değil, görünür bir toparlanma şeridine koymalıdır.
Ekip psikolojisi neden bu konunun parçası?
Çünkü incident sonrası ekipler aynı hızla geri dönmez. Bazı mühendisler hemen normal ritme geçer; bazıları ise birkaç gün boyunca temkinli ve dağınık çalışır. Kıdemli liderlik burada üretkenlik baskısını artırmak değil, karar yüzeyini sadeleştirmek anlamına gelir.
Sağlıklı yaklaşım genelde şöyledir:
- İlk hafta çok sayıda yeni paralel iş açılmaz
- Kritik sahiplikler yeniden dağıtılır
- Müdahaleyi taşıyan birkaç kişiye nefes alanı bırakılır
- Postmortem aksiyonları sayıca değil etkiyle filtrelenir
Bu düzen kurulursa incident, tüm sprinti bozan bir travma olmaktan çıkıp ölçülü bir toparlanma programına dönüşür.
Hangi metrikler gerçekten işe yarar?
Incident sonrasında sadece “kök neden kapandı mı?” diye bakmak eksik kalır. Ben şu sinyalleri daha anlamlı buluyorum:
- Aynı semptom için yeniden alarm oluşup oluşmadığı
- Olay sonrası açılan geçici işlerin kapanma süresi
- Ertelenen teslimatların yeniden planlanma netliği
- Operasyon yükünün kaç gün içinde normale döndüğü
- Müdahaleyi taşıyan kişilerin görev dağılımındaki düzelme
Bu metrikler, ekibin gerçekten toparlanıp toparlanmadığını gösterir. Çünkü incident’ın bittiği an ile etkisinin bittiği an çoğu zaman aynı değildir.
Teknik liderin en sık yaptığı hata
En sık gördüğüm hata, postmortem aksiyonlarını yeni backlog gerçekliği sanmak. Oysa her incident onlarca fikir üretir; bunların tamamı aynı ağırlıkta değildir. Teknik liderin görevi çok fikir çıkarmak değil, hangisinin sistem davranışını gerçekten değiştireceğini ayıklamaktır.
İkinci hata ise tam tersidir: olayı yalnızca bir ticket ile kapatmak. Bu durumda da ekip kısa vadede hızlandığını sanır ama birkaç hafta sonra aynı kırılganlık başka biçimde geri gelir.
Sonuç
Teknik liderler için incident sonrası öncelik sıfırlama, toplantı takvimini yeniden düzenleme işi değildir. Bu disiplin; operasyonel açıklıkları, toparlanma borcunu ve normal teslimat ritmini aynı resimde okuyabilme yeteneğidir. İyi kurulduğunda ekip kesintiden sonra daha yavaş değil, daha berrak hareket eder. Asıl olgunluk da burada görünür: sorunu çözmekte değil, çözüm sonrasındaki yön duygusunu kaybetmemekte.