Bir servisin sahibi değiştiğinde yalnızca nöbet listesi güncellenmez; karar geçmişi, risk iştahı, gizli operasyon alışkanlıkları ve kurumsal güven de el değiştirir. Birçok ekipte devir, wiki bağlantısı paylaşmak veya birkaç toplantı yapmak sanılır. Oysa kıdemli mühendislik pratiğinde servis sahipliği devri, operasyonel boşluk bırakmadan süreklilik üreten bilinçli bir protokoldür.
Neden servis sahipliği devri ayrı bir disiplin olmalı?
Servisler büyüdükçe yazılı doküman ile gerçek işletme davranışı arasındaki fark açılır. Runbook güncel görünür; fakat kritik alarmlarda hangi metriklerin gerçekten önemli olduğu, hangi müşterinin daha hassas etkilendiği veya hangi deploy penceresinin riskli olduğu çoğu zaman birkaç kişinin zihninde saklı kalır.
Bu görünmez bilgi aktarılmadan yapılan her devir, kısa vadede sakin görünür ama ilk incident anında çatlar. Yeni sahibi olan ekip teknik olarak yetkin olsa bile, bağlam eksikliği nedeniyle daha yavaş karar alır ve gereksiz escalation üretir.
Devir protokolünün dört katmanı
Ben servis sahipliği devrini dört katmanlı düşünmeyi faydalı buluyorum:
- Operasyonel gerçeklik
- Mimari sınırlar
- Paydaş haritası
- Karar yetkisi
İlk katman, alarm yüzeyi, bakım işleri, kapasite davranışı ve bilinen kırılganlıkları kapsar. İkinci katman, servisin hangi bağımlılıklarla yaşadığını ve hangi değişikliklerin başka ekipleri etkilediğini görünür kılar. Üçüncü katman, ürün, destek, güvenlik ve iş birimleriyle olan ilişkiyi açığa çıkarır. Dördüncü katman ise en kritik sorudur: yeni sahip neyi kendisi değiştirebilir, ne zaman daha geniş onay gerekir?
Operasyonel gerçekliği belgelemek ne demektir?
Bir servis için yalnızca dashboard bağlantısı paylaşmak yeterli değildir. Aşağıdaki parçalar açıkça yazılmalıdır:
- Kritik alarmların gerçek öncelik sırası
- Gürültülü ama tolere edilen sinyaller
- Elle yürütülen bakım adımları
- En sık yapılan geri alma senaryoları
- Kapasite artışı öncesinde bakılan göstergeler
Bu liste, servisin yaşayan davranış modelidir. Özellikle ERP veya entegrasyon ağırlıklı sistemlerde gece batch yükü, ay sonu kapanışları ve dış bağımlılık pencereleri belgede açık değilse yeni sahip ekip sürekli sürprizle karşılaşır.
Mimari sınırları nasıl aktarmalı?
Servisin topolojisini göstermek yararlıdır; ama daha değerlisi hangi değişikliklerin tehlikeli olduğunu söylemektir. Örneğin:
- Bu servis ana veri tabanı bağlantı havuzunda ortak limit kullanır.
- Retry süresi artırılırsa ERP kuyruğunda gecikme büyür.
- Sertifika yenileme akışı başka platform ekibinin pipeline’ına bağlıdır.
- Audit log formatı uyum gereği değiştirilemez.
Bu cümleler yeni sahibin tasarım özgürlüğünü kısıtlamak için değil, yanlış güven üretmemek için gerekir. Kıdemli mühendislikte olgunluk, sadece sistemi anlamak değil, sistemin görünmeyen kontratlarını adlandırabilmektir.
Paydaş haritası neden devrin parçası?
Servis sahipliği teknik olduğu kadar kurumsal bir roldür. Yeni sahibin sadece repository’yi değil, ilişki ağını da devralması gerekir. Hangi ürün yöneticisi bu servise duyarlıdır, hangi güvenlik ekibi belirli değişikliklerde bilgilendirilmelidir, hangi destek lideri olay anında ilk durum özetini bekler?
Bu ağ görünür olmazsa yeni sahip, teknik olarak doğru karar verse bile kurumsal sürtünme yaratır. Özellikle kesinti veya bakım anlarında kimin neyi ne hızda duyması gerektiği önceden aktarılmışsa geçiş çok daha sakin olur.
Devir tamamlandı mı, nasıl anlaşılır?
Bence aşağıdaki üç test geçilmeden devir tamamlanmış sayılmamalı:
- Yeni sahip ekip tek başına kontrollü bir değişiklik yayınlayabiliyor mu?
- Önceki sahip devreye girmeden orta ölçekli bir alarmı kapatabiliyor mu?
- Paydaş güncellemesini doğru dilde ve doğru ritimde paylaşabiliyor mu?
Bu testler geçilmiyorsa problem çoğu zaman yetkinlik değil, eksik çerçevedir.
Pratik bir 30 günlük geçiş modeli
Benzer ortamlarda şu ritim iyi çalışır:
- İlk hafta: gölge sahiplik ve ortak gözden geçirme
- İkinci hafta: yeni ekibin yönettiği düşük riskli değişiklik
- Üçüncü hafta: alarm ve incident simülasyonu
- Dördüncü hafta: eski sahibin danışman rolüne çekilmesi
Bu model, bilgiyi toplantı notlarından operasyon pratiğine taşır. Özellikle platform dönüşümü yaşayan kurumlarda servis sahipliğinin kadro değişimlerinden etkilenmemesi için bu tür ritüeller kritik değer üretir.
Sonuç
Kıdemli mühendisler için servis sahipliği devir protokolü, yalnızca devir teslim kontrol listesi değildir. Bu protokol; bilgiyi kişiden sisteme, sezgiyi sözleşmeye ve bağımlılığı güvenli işletmeye dönüştürür. Sağlam kurulduğunda ekip değişse bile servis davranışı bozulmaz; asıl kurumsal olgunluk da burada görünür.