Birçok kurumda mimari kararlar teknik dokümanlarda değil, birkaç kıdemli mühendisin zihninde yaşar. Neden o veritabanı seçildi, neden o servis ayrı VPC’ye taşındı, neden belirli bir alarm eşiği kabul edildi gibi soruların cevabı çoğu zaman toplantılarda dağılır ve zamanla buharlaşır. Sonra ekip değişir, sistem büyür ve aynı kararlar tekrar tekrar tartışılır. Karar günlüğü disiplini, teknik hafızayı kişisel otoriteden çıkarıp ekip tarafından taşınabilir bir işletim pratiğine dönüştürür.
Karar günlüğü tam olarak neyi çözer?
Bir ADR veya wiki sayfası yazmak tek başına yeni bir disiplin kurmaz. Buradaki asıl mesele, kritik kararların yaşam döngüsünü görünür hâle getirmektir:
- Kararın bağlamı neydi?
- Hangi alternatifler elendi?
- Hangi risk kabul edildi?
- Kararın yeniden gözden geçirilme koşulu ne?
Bu sorular cevapsız kaldığında ekipler geçmiş kararları ya kutsal metin gibi korur ya da nedenini bilmeden bozmaya çalışır. İki uç da pahalıdır.
Neden özellikle kıdemli mühendislik konusudur?
Çünkü kıdem arttıkça senden sadece iyi çözüm değil, tekrar üretilebilir muhakeme beklenir. Genç mühendis bir problemi çözer; kıdemli mühendis ise o çözümün hangi bağlamda doğru olduğunu ekip için okunabilir kılar. Bu yüzden karar günlüğü, belgeleme alışkanlığından daha derin bir liderlik pratiğidir.
İyi işlediğinde şu etkileri üretir:
- Yeni katılan mühendislerin bağlam kazanma süresi kısalır
- Aynı tartışmalar daha az tekrar eder
- Devir ve nöbet sırasında karar sınırları netleşir
- Postmortem ve mimari review daha verimli ilerler
Hangi kararlar günlüğe girmeli?
Her küçük tercih günlüğe yazılmaz. Günlük şişerse kimse okumaz. Ben şu tip kararları özellikle değerli buluyorum:
- Geri dönmesi pahalı mimari seçimler
- Güvenlik, ağ ve erişim modelini etkileyen kabuller
- Operasyon davranışını değiştiren alarm, rollback veya yayın kuralları
- Veri saklama, replikasyon ve yedekleme stratejileri
- İstisna olarak kabul edilen geçici ama kritik çözümler
Yani karar günlüğü, her toplantı notunun mezarlığı değildir. Kurumsal hafıza açısından pahalı düğüm noktalarının kaydıdır.
İyi bir kayıt nasıl görünür?
Ben çok uzun formatları sürdürülebilir bulmuyorum. Pratikte aşağıdaki alanlar çoğu durumda yeterlidir:
- Başlık: Kararın kısa adı
- Tarih ve sahiplik
- Bağlam
- Alternatifler
- Kabul edilen risk
- Beklenen operasyon etkisi
- Yeniden gözden geçirme tetikleyicisi
Buradaki son madde özellikle önemlidir. Çünkü birçok karar, sanki sonsuza kadar geçerliymiş gibi dokümante edilir. Oysa kurumsal altyapıda kararların çoğu çevresel koşullara bağlıdır. Trafik hacmi, ekip yapısı veya regülasyon değiştiğinde, doğru karar artık farklı olabilir.
Operasyon tarafında en büyük kazanç nerede?
Karar günlüğünün değeri yalnızca mimari toplantılarda değil, kesinti ve değişim anlarında görünür. Örneğin bir incident sırasında ekip şu soruya hızlı yanıt verebilmelidir: “Bu serviste neden agresif autoscaling yerine kapasite rezervi tercih ettik?” Cevap kişisel hafızadaysa risk büyür. Kayıtta ise müdahale hızı artar.
Aynı şey değişim yönetiminde de geçerlidir:
- Neden belirli ağ segmenti kapalı tutuluyor?
- Neden rollout penceresi farklı?
- Neden bazı loglar uzun süre saklanıyor?
Bu soruların cevabı görünür olduğunda ekip kararları daha sakin tartışır. Çünkü tartışma kişiler üzerinden değil varsayımlar üzerinden yürür.
Mentorluk etkisi neden güçlü?
Kıdemli mühendislik çoğu zaman görünmez düşünme biçimini öğretmektir. Karar günlüğü, bu görünmezliği kısmen görünür yapar. Yeni bir mühendis sadece son mimariyi değil, o mimariye giden muhakemeyi de okuyabilir. Bu, teknik öğrenmeyi ciddi biçimde hızlandırır.
Ben özellikle şu kullanım biçimini faydalı buluyorum:
- Büyük karar öncesi taslak kayıt açılır
- Review sırasında alternatifler birlikte netleşir
- Karar çıktıktan sonra operasyon etkisi eklenir
- Birkaç ay sonra kısa değerlendirme notu düşülür
Bu yöntem, dokümanı statik rapor olmaktan çıkarıp yaşayan karar geçmişine dönüştürür.
En sık yapılan hata
İlk hata, günlüğü yalnızca mimari ekiplerin işi sanmak. Oysa operasyon ve platform kararları da aynı ölçüde kritiktir. İkinci hata ise günlüğü çok ağır süreçle boğmaktır. Her karar için uzun onay mekanizması koyulduğunda ekipler kaydı bırakır, karar yine sohbet kanallarına döner.
Doğru denge şudur: kayıt açmak kolay, okumak hızlı, güncellemek net olmalı. Disiplinin amacı bürokrasi üretmek değil, hafıza maliyetini düşürmektir.
Sonuç
Kıdemli mühendisler için karar günlüğü disiplini, teknik yazı düzeni değil kurumsal düşünme altyapısıdır. İyi kurulduğunda mimari tercihleri kişisel otoriteye bağımlı olmaktan çıkarır; servis devrini, incident yönetimini ve mentorluk akışını güçlendirir. Sistemler karmaşıklaştıkça en değerli şey yalnızca doğru karar vermek değil, o kararın neden verildiğini ekipçe taşıyabilmektir.