Bir değişiklik planı ne kadar iyi görünürse görünsün, üretimde her şey “planlandığı gibi” gitmez. Asıl sorun, değişiklikten sonra çıkan hatalar değil; hata çıktığında ekibin ne kadar hızlı ve doğru tepki verdiğidir. Bu yüzden ben kritik değişikliklerde “postmortem” kadar “pre‑mortem” disiplinini de önemserim.
Pre‑mortem’in amacı basit: “Değişiklik başarısız oldu” varsayımıyla, hatayı ve etkisini önceden zihinde yaşayıp riskleri görünür kılmak.
Pre‑mortem ne zaman yapılmalı?
Her deploy için toplantı yapmak sürdürülemez. Pre‑mortem’i şu tip değişikliklerde kullan:
Hata alanı geniş: platform, ağ, kimlik, loglama, DNS gibi ortak katmanlar
Geri dönüş zor: veri şeması, stateful servis, güvenlik politikası
İlk kez yapılıyor: yeni teknoloji/sağlayıcı/operasyon modeli
Üretim erişimi / yetki değişimi içeriyor
30 dakikalık pratik akış
Ben pre‑mortem’i 30 dakikaya sığdırmaya çalışırım:
Hedef (3 dk): Bu değişiklik hangi iş etkisini hedefliyor?
“Başarısız oldu” senaryosu (10 dk): Hangi 3 şekilde kötü biter?
Erken sinyaller (7 dk): Hangi metrik/log/alert bunu ilk yakalar?
Geri dönüş (7 dk): 1) otomatik 2) manuel 3) “dur ve izole et”
Karar noktaları (3 dk): Hangi eşikte rollback zorunlu?
Şablon: her değişiklik için aynı sorular
Ben şu soruları sabit kullanırım:
Blast radius: En kötü durumda etki alanı ne?
Bağımlılıklar: Hangi servis/katman sessizce etkilenir?
Gözlem: Başarıyı ve bozulmayı hangi sinyal gösterir?
Yetki: Kim rollback yapabilir? Break-glass var mı?
Veri: Geri dönüşte veri tutarlılığı riski var mı?
Zaman: Süreçte clock skew / TTL / cache etkisi var mı?
İletişim: Kimin hangi kanalda bilgilendirileceği net mi?
Bu sorular “doküman üretmek” için değil, kararları hızlandırmak için vardır.
Pre‑mortem çıktısı nasıl kullanılmalı?
En iyi çıktılar:
Değişiklik RFC’sine eklenen “risk ve geri dönüş” bölümü
Runbook’a eklenen karar noktaları (eşik + aksiyon)
En kötü çıktı: toplantı yapıp hiçbir yere yazmamak.
Liderlik tarafı: pre‑mortem bir güven inşasıdır
Pre‑mortem, “ekibe güvenmiyorum” mesajı değildir; aksine ekip üzerinde baskı kurmadan güvenli hız üretmenin yoludur. İyi bir lider; riskleri saklamaz, görünür kılar. Çünkü üretimde asıl hız, hatayı erken yakalayıp doğru geri dönebilme kabiliyetidir.
Kapanış
Üretimde mükemmel plan yoktur; ama iyi hazırlanmış geri dönüş vardır. Pre‑mortem; değişiklik öncesi küçük bir yatırım, değişiklik sonrası büyük bir zaman kazancıdır. Disiplinli uygulandığında ekip “cesur” değil, kontrollü olur.
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.
Her değişikliğe pre‑mortem yapmak çevikliği ve hızı düşürür mü, bu dengeyi nasıl kuruyorsunuz?
Kesinlikle her deploy için bu süreci işletmiyorum; eğer öyle yapsaydık ekip bir süre sonra bu ritüelden sıkılır ve verim alamazdık. Ben bu disiplini sadece 'blast radius' yani etki alanı geniş olan kritik değişikliklerde uyguluyorum. Örneğin; DNS güncellemeleri, veri tabanı şema değişiklikleri veya ortak kütüphane güncellemeleri benim için kırmızı çizgidir. 30 dakikalık bir pre-mortem seansı, bazen günlerce sürecek bir kriz yönetimini ve itibar kaybını önlüyor. Önemli olan hızı kesmek değil, yüksek hızda giderken virajı alamama ihtimalini sıfıra indirmek. Eğer bir değişiklik 'geri dönüşü zor' kategorisindeyse, harcayacağınız o yarım saat aslında size zaman kazandırıyor.
Ekipler genelde 'bir şey olmaz' diyerek riskleri küçümseme eğiliminde oluyor, bu psikolojik bariyeri nasıl aşıyorsunuz?
Bu çok sık karşılaştığım bir durum. Ekipler yetkinliklerine güvendikleri için hata payını görmezden gelebiliyorlar. Ben bu direnci kırmak için 'Hata çıkabilir mi?' diye sormak yerine, 'Değişiklik başarısız oldu ve şu an her yer patladı, neden olmuş olabilir?' varsayımıyla toplantıyı başlatıyorum. Bu yöntem, sorumluluğu birinin hatası olmaktan çıkarıp zihinsel bir simülasyona dönüştürüyor. Hatta en 'imkansız' görünen senaryoyu bile masaya yatırmaları için ekibi teşvik ediyorum. 'Rezil oluruz' korkusunu ortadan kaldırıp, riskleri konuşmayı bir profesyonellik göstergesi haline getirdiğimde, en sessiz mühendislerin bile hayati riskleri fark ettiğini gördüm.
Geri dönüş (rollback) planı hazırlamak yeterli değil mi, neden ayrıca bir pre-mortem sürecine ihtiyaç duyuyoruz?
Sadece bir rollback script'ine sahip olmak, maalesef güvenli bir liman değil. Ben geçmiş tecrübelerimde, teknik olarak rollback imkanı olmasına rağmen, 'belki düzelir' umuduyla bekleyen ve krizi derinleştiren ekipler gördüm. Pre-mortem'in asıl gücü, o kritik 'karar noktalarını' (decision points) önceden belirlemesidir. Hangi metrik ne kadar süre bozuk giderse geri döneceğiz? Kimin onayına ihtiyacımız var? Pre-mortem sırasında bu eşikleri netleştirdiğimde, operasyon anındaki o stresli ve duygusal karar verme sürecini devre dışı bırakmış oluyorum. Yani sadece 'nasıl' döneceğimizi değil, 'ne zaman' dönmemiz gerektiğini de bu sayede garantiye alıyoruz.
Pre-mortem sırasında odaklanılması gereken en kritik teknik gösterge sizce nedir?
Bana göre en kritik nokta 'sessiz bağımlılıklar' ve 'erken sinyaller'dir. Bir servis çöktüğünde bunu anlamak kolaydır, ancak bir değişiklik sonrası sistemin yavaş yavaş zehirlenmesini fark etmek zordur. Ben pre-mortem seanslarında ekibe hep şu soruyu sorarım: 'Hata oluştuğunda dashboard'da ilk hangi grafik kıpırdar?'. Eğer bu sorunun cevabını veremiyorsak, gözlemlenebilirlik (observability) tarafında eksiğimiz var demektir. Sadece CPU veya bellek kullanımına bakmak yetmez; iş mantığına dair metriklerin ve logların nasıl tepki vereceğini önceden kurgulamazsanız, pre-mortem sadece bir beyin fırtınası olarak kalır, operasyonel bir silaha dönüşmez.
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
Yeni yazılardan haberdar olun
Yeni içerikler ve teknik notlar e-postanıza gelsin.
📌
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.