Uzayan incident’larda en çok gözden kaçan risk, teknik arızanın kendisi değil; bağlam kaybıdır. Ekip değişir, yorgunluk artar, kim hangi hipotezi neden eledi unutulur. Yeni gelen ekip aynı denemeleri tekrarlar, riskli bir kararı neden aldığınızı anlayamaz ve olay gereksiz yere uzar.
Bu yüzden büyük olaylarda yalnızca status update değil, bir karar defteri tutmak gerekir. Handoff kalitesi, çoğu zaman MTTR kadar güvenlik ve iletişim kalitesini de belirler.
1) Karar defteri nedir?
Karar defteri, olay zaman çizelgesinin bir parçasıdır ama ondan daha seçicidir. Şunları taşır:
Hangi hipotez değerlendirildi?
Ne kanıt bulundu?
Hangi aksiyon alındı?
Neden alındı?
Hangi risk kabul edildi?
Bu kayıt sayesinde yeni gelen ekip “neler yapıldı” listesinden çok, neden o yoldan gidildiğini görür.
2) Ne zaman handoff gerekir?
Şu senaryolarda resmi handoff şarttır:
Incident vardiya değişimine giriyorsa
IC veya teknik lider yorulma eşiğine gelmişse
Farklı uzmanlık alanından ekip devralacaksa
Olay “stabil ama çözülmedi” durumuna geçtiyse
Burada yapılan hata, handoff’u Slack içinde serbest akışa bırakmaktır. Rastgele mesajlar geçmişi gösterir ama karar mantığını taşımaz.
3) İyi handoff şablonu
Ben şu beş başlığın çok işe yaradığını görüyorum:
Şu anki etki: hangi kullanıcılar, hangi servisler?
Çalışan hipotez: en güçlü açıklama nedir?
Kanıtlar: bu hipotezi destekleyen sinyaller
Yapılanlar: denenen değişiklikler ve sonucu
Sınırlar: yapılmaması gereken riskli aksiyonlar
Bu beşli, yeni gelen ekibi doğrudan karar yüzeyine taşır.
4) Karar defterinde neyi özellikle yazarım?
Rollback yapılmadıysa neden?
Müşteriye hangi mesaj verildi?
Hangi veri kaynağı güvenilmez bulundu?
Hangi aksiyon yalnızca IC onayıyla yapılabilir?
Çünkü incident uzadıkça ekipler teknik detayları değil, karar bağlamını unutmaya başlar.
5) Devir sırasında yapılan klasik hatalar
“Loglara bakıldı” gibi belirsiz ifade kullanmak
Deney sonucunu değil, sadece komutu yazmak
Riskli değişikliği sözlü bırakmak
Handoff sonrası kimin karar verici olduğunu netleştirmemek
Handoff sonunda mutlaka tek cümlelik sahiplik olmalı: “Bu andan itibaren koordinasyon X’te, teknik karar önerisi Y’de.”
6) Araç değil alışkanlık
Karar defterini wiki, incident tool veya ortak dokümanda tutabilirsiniz. Araç ikinci plandadır. Esas farkı yaratan alışkanlık:
Her önemli karar sonrası kısa kayıt
Her 10–15 dakikada durum özeti
Her handoff öncesi son risk listesi
Bu ritim, olay uzadığında sistemi sakin tutar. İnsan hafızasına güvenmek yerine, kararları görünür kılar.
Sonuç
Uzayan incident’larda kaliteyi belirleyen şey sadece iyi mühendislik değil, iyi devir disiplinidir. Karar defteri ve net handoff akışı sayesinde yeni ekip aynı duvara tekrar çarpmaz, riskli aksiyonlar daha görünür olur ve koordinasyon dağılmaz. Olay yönetiminde profesyonellik çoğu zaman “daha çok kişi” değil, “daha temiz bağlam devri” ile gelir.
Paylaş:
Bu yazı faydalı oldu mu?
Yükleniyor...
Geri bildiriminiz için teşekkürler!
Bu yazı nasıldı?
Sıkça Sorulanlar
Bu makale ile ilgili okurların sorduğu yaygın sorular.
Karar defterini ilk kez uygulamaya koyduğumda hangi adımları izledim ve hangi araçları kullandım?
Ben karar defterine geçiş yaparken önce mevcut olay yönetim sürecimi haritaladım ve hangi aşamalarda bağlam kaybı yaşandığını tespit ettim. Ardından, her vardiya değişiminde bir Google Docs şablonu oluşturdum; bu şablonda hipotez, kanıt, alınan aksiyon ve risk değerlendirmesi için ayrı bölümler vardı. Dokümanı otomatik olarak Slack kanalına bağlamak için Zapier entegrasyonu kurdum, böylece ekip üyesi vardiya sonu bir komutla güncellemeyi paylaşabiliyordu. İlk iki haftada sadece kritik iki incident'ta deneme yaptım, geri bildirimler sayesinde şablonun başlıklarını sadeleştirerek süreci 5 dakikadan az bir sürede tamamlamayı başardım.
Handoff sırasında karar mantığını net bir şekilde iletmek için en etkili format nedir ve bunun dezavantajları neler?
Ben handoff'ta en etkili formatın “karar defteri özet slaytı” olduğunu gördüm; 5 dakikalık bir PowerPoint/Google Slides dosyası, başlıkta olay kimliği, zaman çizelgesi, değerlendirilmiş hipotezler ve alınan risk kararlarını bir bakışta gösterir. Bu format, yeni ekip üyesinin kısa sürede karar zincirini kavramasını sağlar ve toplantı sonrası referans olarak kalır. Ancak dezavantajı, slaytların hazırlanması ekstra zaman alabilir ve görsel odaklı olduğundan bazı teknik detaylar gözden kaçabilir. Bu yüzden slaytı tamamladıktan sonra aynı içeriği karar defteri dokümanına da yansıtmak, eksik kalmaması açısından kritik bir adımdır.
Karar defteri tutarken bir hipotezi yanlış değerlendirdiğimde nasıl bir düzeltme süreci izlemeliyim?
Yanlış bir hipotez fark ettiğimde önce hatanın nereden kaynaklandığını not alırım; bu, eksik veri, yanlı varsayım ya da yorgunluk gibi faktörleri içerir. Ardından, karar defterine bir “Düzeltme Girişi” bölümü ekleyerek orijinal hipotezin tarih ve saatini, neden yanlış olduğunu ve yeni kanıtları yazarım. Bu girişin sonunda, yeni hipotez ve planlanan aksiyonları net bir şekilde listelerim. Takım üyelerini bu güncelleme hakkında bilgilendirmek için Slack'te bir “Düzeltme” bildirimi gönderirim ve bir sonraki handoff'ta bu değişikliği vurgularım. Bu şeffaf süreç, güveni korur ve aynı hatanın tekrarlanmasını önler.
Bazı ekipler Slack'te serbest handoff yapmayı tercih ediyor, bu yaklaşımın yaygın bir yanılgısı nedir ve gerçek etkisi ne?
Ben gözlemlediğim en yaygın yanılgı, serbest Slack mesajlarının bağlamı tam olarak yansıtamaması ve karar mantığını kaybetmesidir. Ekipler genellikle “Şu anki durum: X deneme yapıldı, Y başarısız” gibi kısa notlar bırakır; bu, yeni gelenin geçmiş denemeleri görmesini sağlar ama neden bu denemelerin seçildiği, risk kabulü ve alternatif senaryoları içermez. Sonuç olarak, yeni ekip aynı denemeleri tekrarlayabilir, karar sürecinde tekrar tekrar soru sormak zorunda kalır ve MTTR uzar. Bu yüzden, Slack'te bir mesajla sınırlı kalmayıp, o mesajı karar defteri girişine bağlamak ve handoff toplantısında özetlemek, bağlam kaybını önlemenin en etkili yolu olur.
ME
Mustafa Erbay
Sistem Mimarisi · Network Uzmanı · Altyapı, Güvenlik ve Yazılım
2006'dan bu yana sistem mimarisi, network, sunucu altyapıları, büyük yapıların kurulumu, yazılım ve sistem güvenliği
ekseninde çalışıyorum. Bu blogda sahada karşılığı olan teknik deneyimlerimi paylaşıyorum.
Kişisel Notlar
Bu notlar sadece sizde saklanır. Tarayıcınızda yerel olarak tutulur.
Hazır0 karakter
Yorumlar
Sunucu Taraflı AI Moderasyon
Yorumlar sunucuda yapay zeka ile denetlenir ve kalıcı olarak saklanır.
?
0/2000
Sunucu taraflı AI denetim
Henüz yorum yok. İlk siz yapın!
✉️Ücretsiz · Spam yok · İstediğin an çık
Haftalık özet — AI değil, bizzat ben seçiyorum
Haftada bir mail: o haftanın en önemli yazısı, perde arkası notları, ve "bu hafta gerçekten kullandığım araç" bölümü. Az gürültü, çok sinyal.
📌
Haftanın en iyisiSadece okumaya değer tek yazı
🔧
Alet çantasıBu hafta kullandığım araçlar
🧠
Perde arkasıBlog'a girmeyen notlar
Spam yapmıyoruz. İstediğiniz zaman ayrılabilirsiniz. · Sadece Umami (self-hosted, Google yok) ile takip.
