Sev2 olaylar çoğu kurumda yanıltıcı biçimde “orta şiddette” görülür. Gerçekte ise müşteri etkisi vardır, iş birimleri baskı üretir, ekipler hızla bir karar merkezi arar ve teknik liderin masasına aynı anda hem tanı, hem iletişim, hem de değişiklik onayı gelir. Bu noktada liderin her kararı kendisinin vermesi kısa süreli güven hissi yaratır; fakat birkaç saat içinde hem tempo düşer hem de ekip inisiyatifi donar. Doğru yaklaşım, kararları rastgele dağıtmak değil, incident daha büyümeden hangi kararın kimde olduğunu önceden tanımlamaktır.
Neden özellikle Sev2 olaylarda zorlanılır?
Çünkü Sev1 kadar net komuta modeli kurulmaz, Sev3 kadar da rahat geçiştirilmez. Ekipler şu ikileme girer:
- Etki büyümeden hızlanmak gerekir.
- Fakat her değişiklik daha büyük bir müşteri etkisine de dönüşebilir.
Bu yüzden teknik lider çoğu zaman her tartışmanın içine çekilir. Hangi rollback’in güvenli olduğu, hangi ekipten destek isteneceği, dış iletişime ne yazılacağı ve bir sonraki durum güncellemesinin ne zaman geçileceği tek kişide toplanır. Bu bir süre sonra liderliği güçlendirmez; sistemi kırılganlaştırır.
Karar delegasyonu hangi kararlarla başlar?
Ben Sev2 olaylarında kararları dört sınıfa ayırmayı faydalı buluyorum:
- Tanı kararları: Hangi hipotez önce test edilecek?
- Müdahale kararları: Rollback, feature kapatma, trafik yönlendirme gibi teknik hamleler.
- İletişim kararları: İç paydaş, destek ve yönetim güncellemeleri.
- Risk kararları: Ek değişiklik açma, bakım penceresi dışına çıkma, geçici istisna verme.
Bu sınıflar ayrılmadığında herkes teknik kararı konuştuğunu sanır; oysa masada çoğu zaman iletişim ve risk kararı da vardır.
Kim hangi kararı almalı?
Pratik bir modelde roller şu şekilde netleşebilir:
- Incident komutanı: Tempo, zaman kutuları ve iletişim ritminden sorumludur.
- Teknik sürücü: Tanı ve geri alma seçeneklerini değerlendirir.
- Servis sahibi: Uygulama davranışı, veri etkisi ve bağımlılık risklerini teyit eder.
- Teknik lider: Yüksek etkili risk kararlarında son eşiği koyar ve darboğazları temizler.
Buradaki kritik nokta, teknik liderin her kararı ilk elden vermemesi; hangi eşikte devreye gireceğini bilmesidir. Örneğin önceden tanımlanmış rollback, kapasite artırımı veya feature flag kapatma yetkisi teknik sürücüde olabilir. Fakat veri tutarlılığı riski taşıyan şema değişikliği geri alımı teknik lider onayına bağlı kalmalıdır.
Hangi eşikler lider onayı gerektirir?
Ben üç eşiğin açıkça yazılmasını öneriyorum:
- Geri dönüşü zor veri değişikliği
- Birden fazla kritik servisi etkileyen trafik kaydırma
- Regülasyon, güvenlik veya müşteri taahhüdü riski doğuran geçici istisna
Bunun dışındaki kararlar mümkün olduğunca olay masasına yakın alınmalıdır. Çünkü liderin sürekli onay noktası olması, ekipte şu zararlı refleksi doğurur: sorumluluk yukarı taşınır, düşünme kası aşağıda zayıflar.
İletişim delegasyonu neden ayrı düşünülmeli?
Birçok teknik lider teknik delegasyonu tasarlar ama iletişim kendisinde kalır. Oysa Sev2 olaylarda iletişim gecikmesi, yanlış teknik karardan daha pahalı olabilir. İş birimi ya da destek ekipleri bilgi alamadığında kendi anlatısını üretir. Bu yüzden şu görev ayrı sahiplenilmelidir:
- Her 20 ya da 30 dakikada durum özeti geçmek
- Bilinen etkiyi tek cümlede güncellemek
- Tahmin ile kanıtı ayırmak
- Bir sonraki kontrol zamanını yazmak
Bu akış incident komutanında veya operasyon iletişimi sorumlusunda olabilir. Teknik lider yalnızca mesajın riskli kısmını gözden geçirir.
Delegasyon kültürü nasıl öğretilir?
Kıdemli mühendislik pratiğinde delegasyon, iş bırakmak değil öğretilebilir karar modeli kurmaktır. Ben bunun için olay sonrası üç sorunun güçlü olduğunu düşünüyorum:
- Hangi kararı merkezde tuttuğumuz için yavaşladık?
- Hangi kararı sahaya bıraktığımız için hızlandık?
- Hangi eşik belirsiz kaldığı için gereksiz escalation oluştu?
Bu sorular düzenli kullanıldığında ekip, yalnızca teknik çözüm değil karar dağıtımı konusunda da olgunlaşır.
En sık yapılan hata nedir?
Delegasyonu yalnızca sakin zamanların lüksü sanmak. Oysa gerçek ihtiyaç tam baskı anında ortaya çıkar. Eğer ekipler normal günlerde rollback, feature kapatma, kapasite açma veya geçici yönlendirme kararlarını birlikte prova etmiyorsa Sev2 anında herkes otomatik olarak en kıdemli kişiye bakar. Sonuçta teknik lider yorulur, ekip pasifleşir ve olay süresi uzar.
Sonuç
Teknik liderler için Sev2 olaylarda karar delegasyonu, otoriteyi bölmek değil müdahale ritmini korumaktır. Doğru rol tanımı, net onay eşikleri ve ayrı iletişim sahipliği kurulduğunda teknik lider her ayrıntıya koşmak zorunda kalmaz. Bunun yerine gerçekten yüksek etkili kararların kalitesine odaklanır. Kurumsal ekiplerde sürdürülebilir incident yönetimi tam olarak bu ayrımdan güç alır.