Kıdemli mühendislik pratiğinde en pahalı borç türlerinden biri kod borcu değil, runbook borcudur. Sistem ayakta görünürken ekip yalnızca birkaç kişinin kafasında yaşayan operasyon bilgisine yaslanıyorsa, ilk büyük incident anında bunun bedeli ortaya çıkar. Runbook borcu yönetimi, operasyonel hafızayı kahramanlıktan çıkarıp tekrar edilebilir mühendislik pratiğine dönüştürür.
Runbook borcu neden görünmez kalır?
Birçok ekip runbook eksikliğini dokümantasyon problemi gibi görür. Oysa sorun yalnızca belge yazmamak değildir; karar akışlarının, geri dönüş adımlarının ve gözlem sinyallerinin sistematik biçimde dışsallaştırılmamasıdır. Bu nedenle görünürde süreç işler, fakat bilgi yükü sessizce belirli kıdemli kişilere yığılır.
Runbook borcu genelde şu belirtilerle kendini gösterir:
- Aynı tip incident için her seferinde farklı müdahale sırası izlenir.
- Nöbetçi mühendis bir işi çözmek için belirli bir kişiye mesaj atmak zorunda kalır.
- Değişiklik sonrası geri dönüş kararı ölçüme değil tecrübeli kişinin hissine dayanır.
- Yeni katılan mühendisler üretim sistemine yaklaşırken gereğinden fazla çekingen davranır.
Bu tablo, organizasyonun teknik olgunluğunu olduğundan yüksek gösterir. Çünkü bilgi vardır, ama taşınabilir değildir.
Runbook yazmak değil, runbook portföyü yönetmek gerekir
Kıdemli mühendisler çoğu zaman “bir runbook yazarız” yaklaşımına düşer. Problem burada ölçeklenmez. Doğru yaklaşım, runbook’ları yaşayan bir operasyon portföyü olarak ele almaktır. Her runbook bir belge değil; bir risk sınıfı, bir karar ağacı ve bir gözlem bağlamı taşır.
Benim pratikte verimli bulduğum ayrım şu şekildedir:
- Müdahale runbook’ları: Incident sırasında ilk 15 dakikayı standardize eder.
- Değişiklik runbook’ları: Yayın, rollback ve doğrulama adımlarını açıklar.
- Bakım runbook’ları: Düzenli operasyon işlerini kişiden bağımsızlaştırır.
- Tanı runbook’ları: Belirtiye göre hangi sinyale bakılacağını tanımlar.
Bu sınıflandırma olmadan bütün operasyon bilgisi tek tip belgeye dönüşür ve arama kolay görünse de kullanımı zorlaşır.
İyi bir runbook hangi soruları cevaplamalı?
Runbook metni uzun olmak zorunda değildir. Ama karar kalitesini artıracak kadar net olmalıdır. Özellikle şu sorular cevapsız kalmamalı:
- Bu runbook hangi alarm, belirti veya değişiklik türü için geçerli?
- İlk üç kontrol noktası nedir?
- Hangi metrik, log veya dashboard müdahale kararını etkiler?
- Ne zaman rollback yapılır, ne zaman escalation açılır?
- Etki alanı hangi servislerle sınırlıdır?
Runbook yalnızca adım listesi olursa hız kazandırır ama muhakeme üretmez. Adımların yanında karar eşiği de tarif edilirse ekip kalitesi tutarlı hâle gelir.
Borcu nasıl ölçeriz?
Runbook borcu görünmez kaldığında öncelik alamaz. Bu yüzden teknik liderin görevi, belge saymak değil operasyonel açıklığı ölçmektir. Aşağıdaki sinyaller pratikte işe yarar:
- Son üç incident’ta manuel bilgi aktarımı kaç kez gerekti?
- İlk müdahale süresi kişi bazında ciddi değişiyor mu?
- Aynı iş için farklı ekip üyeleri farklı dashboard’lara mı gidiyor?
- Rollback kararı açık eşiklere bağlı mı, yoksa yoruma mı kalıyor?
Bu veriler sayesinde runbook çalışması “dokümantasyon temizliği” gibi değil, doğrudan incident performansı yatırımı gibi görülür.
Runbook borcunu kapatırken sık yapılan hata
En yaygın hata, kıdemli mühendislerin incident sonrasında tek başına belge yazmasıdır. Bu yöntem kısa vadede hızlı görünür; fakat runbook gerçek kullanıcıların diline ve akışına temas etmez. Sonuçta belge vardır ama nöbetçi ekip yine kişiye döner.
Daha sağlam model şudur:
- Incident veya değişiklik sonrası taslak akışı çıkarın.
- İlk kullanımını belgeyi hiç yazmamış bir mühendis yapsın.
- Eksik kalan karar eşiklerini kullanım sırasında düzeltin.
- Runbook’u ilgili alarm, dashboard ve repo referanslarıyla bağlayın.
Böylece runbook statik wiki sayfası değil, operasyon yüzeyinin gerçek parçası olur.
Teknik liderin rolü nedir?
Runbook borcu yönetimi yalnızca SRE veya operasyon ekibine bırakılmamalıdır. Teknik lider, hangi bilgilerin kurumsal hafızaya dönüşmesi gerektiğini seçen kişidir. Her şeyi belgelemek doğru olmadığı gibi, kritik karar yollarını kişide bırakmak da kabul edilemez.
Kıdemli mühendislik burada üç sorumluluk taşır:
- En yüksek etkiye sahip runbook boşluklarını önceliklendirmek
- Runbook kalitesini gerçek kullanım üzerinden değerlendirmek
- Yeni mühendisleri belge tüketicisi değil belge geliştiricisi yapmak
Bu yaklaşım, mentorlukla operasyon disiplinini aynı hatta taşır.
Sonuç
Kıdemli mühendisler için runbook borcu yönetimi, belge üretiminden çok sistematik hafıza tasarımı işidir. Operasyon bilgisi kişiden sisteme taşındığında nöbet yükü daha adil dağılır, incident müdahalesi daha öngörülebilir olur ve ekip kıdemi kurumsal çarpana dönüşür. Sağlam mühendislik kültürü, yalnızca iyi çalışan sistemlerle değil; gerektiğinde herkesin aynı netlikle müdahale edebildiği sistemlerle kurulur.