Birçok ekibin en kritik problemi eksik dokümantasyon değil, sistemin gerçek davranışını açıklayan bilginin birkaç kişinin zihninde saklı kalmasıdır. Alarm eşikleri neden öyle seçildi, hangi entegrasyon neden hep cuma gecesi hassas davranıyor, hangi bakım adımı gerçekten riskli, hangi müşterinin trafiği hangi yan etkiyi tetikliyor; bunların önemli kısmı ticket sistemine değil hafızaya yazılır. Kıdemli mühendis için sessiz bilgi envanteri ritmi, tam bu görünmeyen alanı ekipçe okunabilir hale getirme disiplinidir.
Sessiz bilgi neden kurumsal riske dönüşür?
Sessiz bilgi ilk bakışta verimlilik gibi görünür. Çünkü deneyimli mühendis bir problemi hızlı çözer ve toplantı uzamaz. Fakat bu hız çoğu zaman kurumsal olarak ödünç alınmış bir hızdır. Bilgi kişide kaldıkça ekip bağımsızlığı düşer, nöbet kalitesi dalgalanır ve servis sahipliği görünürde dağıtılmış olsa da fiilen daralır.
Bu risk özellikle şu koşullarda büyür:
- Uzun ömürlü sistemlerin davranışı tarihsel kararlarla şekillenmişse
- Incident çözümünde düzenli olarak aynı birkaç kişi çağrılıyorsa
- Runbook’lar adımı yazıyor ama karar mantığını açıklamıyorsa
- Takım değişimi veya platform dönüşümü hızlanmışsa
Sorun yalnızca bilgi kaybı değildir. Sessiz bilgi, karar gecikmesi ve yanlış güven hissi de üretir. Doküman var sanılır ama kritik eşikler hâlâ sözlü kültürde taşınır.
Envanter çıkarmak ne demektir?
Buradaki amaç her şeyi yazmak değildir. Asıl iş, ekip için yüksek etkili ama düşük görünürlüklü bilgi kümelerini tespit etmektir. Ben bunu dört sınıfta düşünmeyi faydalı buluyorum:
- Operasyonel kestirme bilgiler
- Tarihsel karar bağlamları
- Kırılgan bağımlılık gözlemleri
- İnsan ve süreç tabanlı geçiş kuralları
Bir örnekle bakarsak, “bu job bazen timeout oluyor” bilgi değildir; gözlemdir. Bilgi ise şudur: “Timeout yalnızca ERP tarafındaki raporlama penceresi açıldığında oluşuyor, çünkü aynı storage pool üzerinde IOPS baskısı artıyor.” Envanterin değeri bu farkta ortaya çıkar.
Hangi kaynaklardan toplanmalı?
Sessiz bilgi çoğu zaman tek belgede bulunmaz. Onu şu yüzeylerde yakalarsınız:
- Postmortem notları
- Slack veya Teams kriz başlıkları
- Değişiklik sonrası açılmış geçici checklist’ler
- Kıdemli mühendislerin kişisel notları
- Gölge nöbet veya onboarding oturumlarında söylenen cümleler
Bu kaynaklar dağınık olabilir. O yüzden envanter çalışması tek seferlik arşivleme değil, tekrar eden bir ritim olmalıdır. Ayda bir yapılan kısa ama odaklı tarama, yılda bir yapılan büyük bilgi temizliğinden daha değerlidir.
Sağlam ritim nasıl kurulur?
Ben pratikte kırk beş dakikalık aylık oturum modelini etkili buluyorum. Bu oturumun amacı retrospektif yapmak değil, son dönemde birkaç kişinin üzerinde toplanmış bilgiyi görünürleştirmektir. Basit bir akış yeterlidir:
- Son otuz günde yalnızca belirli kişilerin çözdüğü olayları çıkarın
- Bu olaylarda yazılmamış karar noktalarını belirleyin
- Hangi bilginin runbook, mimari kayıt veya onboarding notuna dönüşeceğine karar verin
- Sahip atayıp kapanış tarihini görünür yapın
Burada önemli olan, “güzel olur” listesi üretmek değil; ekip davranışını değiştirecek maddeleri seçmektir. İyi ritim, bilgi toplama işi ile yayınlama işini ayırmaz.
Hangi bilgiler önce ele alınmalı?
Her sessiz bilgi aynı değerde değildir. Öncelik için şu sorular iyi çalışır:
- Bu bilgi yoksa incident süresi uzar mı?
- Bu bilgi tek kişide kaldığı için değişiklik riski artıyor mu?
- Bu bilgi ekipler arası iletişimde sürtünme yaratıyor mu?
- Bu bilgi yeni bir mühendisin bağımsızlaşmasını doğrudan etkiliyor mu?
Bu çerçeveyle bakıldığında bazı parlak teknik ayrıntılar geri plana düşer, bazı sıradan görünen cümleler ise kritik hale gelir. Örneğin bir firewall kuralının hangi portu açtığı değil, hangi entegrasyonun gerçek test saatleri dışında yanlış negatif ürettiği daha değerli olabilir.
Sessiz bilgi envanteri mentorlukla nasıl birleşir?
Kıdemli mühendislik yalnızca problemi çözmek değil, çözme kapasitesini çoğaltmaktır. Sessiz bilgi envanteri bu yüzden mentorlukla doğrudan bağlıdır. Çünkü bilgi tek başına yazıya döküldüğünde değil, ekip içinde kullanıldığında değer üretir.
Bu nedenle her envanter maddesi için küçük bir taşıma yöntemi tanımlamak gerekir:
- Runbook güncellemesi
- Kısa demo veya brown bag oturumu
- On-call shadowing notu
- Mimari karar kaydı
- Yeni üyeler için onboarding adımı
Bilginin depolandığı yer ile öğrenildiği yüzey aynı olmak zorunda değildir. Ama aralarında bilinçli bir köprü kurulmalıdır.
En sık hata: Her şeyi wiki’ye yığmak
Kurumsal ekiplerin sık yaptığı hata, sessiz bilgi problemini “bir Confluence sayfası açalım” düzeyinde çözmeye çalışmaktır. Bu yaklaşım kısa sürede belge çöplüğü üretir. Çünkü bilgi önceliklendirilmez, sahiplenilmez ve kullanım anına bağlanmaz.
Daha doğru yaklaşım, envanteri küçük tutmak ve şu disiplinleri korumaktır:
- Her madde bir risk veya karar anına bağlanmalı
- Her madde güncel sahibi olan bir sisteme referans vermeli
- Her madde düzenli bakım gerektirmeli
- Her madde ya runbook’a ya onboarding’e ya da mimari kayda bağlanmalı
Bu filtreler olmazsa bilgi artar ama belirsizlik azalmaz.
Sonuç
Kıdemli mühendisler için sessiz bilgi envanteri ritmi, dokümantasyon kampanyası değil ekip bağımsızlığı yatırımıdır. Sistem bilgisini kişisel reflekslerden çıkarıp ortak çalışma yüzeyine taşıdığınızda incident kalitesi yükselir, servis sahipliği daha gerçek hale gelir ve mentorluk soyut bir iyi niyet olmaktan çıkar. Kurumsal olgunluk da tam burada görünür: yalnızca bilen kişilere değil, bilgiyi taşıyan işletim modeline sahip olmakta.