Teknik Borç Nedir: Platform Engineering Perspektifi

Saat 02:47. PagerDuty alarmı çaldı. Servis tamamen kapalı değil; ama p99 gecikme süresi 4 saniyeye fırlamış, hata oranı yükseliyor. On-call mühendis izleme paneline bakıyor, hatayı bulabiliyor ama kodu anlayamıyor. Altı ay önce "geçici çözüm" olarak yazılan ve bir daha dokunulmayan bir retry döngüsü sistemi yavaşlatıyor. Teknik borç nedir diye sormak için post-mortem raporu beklemenize gerek yok: bu tür gecelerde tam anlamıyla hissediyorsunuz.

Platform engineers için teknik borç (technical debt), bir kod kalitesi puanı değildir. Birikerek büyüyen, blast radius'u şişiren ve prodüksiyon olaylarının post-mortemlerinde yüzeye çıkan bir dağıtım riskidir. Aradaki fark önemlidir: biri bir araç çıktısıdır, diğeri gecenizi çalar. Bu ikisini birbirine karıştıran ekipler, teknik borç sorununu hiçbir zaman doğru yerde çözemez.

Teknik Borç Nedir? Tanımın Ötesine Geçin

Ward Cunningham'ın 1992'deki metaforunu hatırlayın: yazılım tasarımındaki kısa yolları finansal borca benzetmişti. Bilinçli bir tercih, ama faizi ödenecek. Platform engineering perspektifinden bakıldığında bu metaforun eksik bir tarafı vardır: borcun faiziyle kimin uğraştığını göstermiyor.

Geliştirici değil, on-call mühendis öder bu faizi. Sabahın üçünde alarm veren, anlaşılması zor bir servis bağımlılığıdır. Kimsenin tam olarak bilmediği bir konfigürasyon parametresidir. Güncellenmesi gereken ama güncellenmesi durumunda başka bir şeyin bozulacağı bir kütüphanedir.

Teknik borç bilinçli kararlardan birikebilir, bilinçsiz kararlardan da. Önemli olan bu borcun nerede biriktiği ve ne zaman patlayacağı konusunda bir öngörüye sahip olup olmadığınızdır. Öngörüsüz bir teknik borç yönetimi, gelecekteki bir olayı ertelemekten ibarettir.

Bir başka açıdan bakıldığında, teknik borç aslında bir iletişim sorunudur. Mühendisler borcun varlığını bilir ama bunu yönetim kademesine aktaracak dili bulmakta zorlanır. "Eski kod" veya "dağınık mimari" gibi ifadeler operasyonel risk dilini konuşmaz. Bu yüzden teknik borç tartışmaları çoğunlukla teknik ekibin içinde kalır ve kaynak tahsisine dönüşmez. Çözüm, borcun nasıl anlatıldığını değiştirmektir.

Teknik Borç Dört Farklı Kanaldan Sisteminize Girer

Borcun kaynağını bilmek, onu yönetmenin ilk adımıdır. Dört ana kanal vardır ve her biri farklı bir triaj stratejisi gerektirir.

Bilinçli kısayollar: Bir MVP için yazılan kod, üretime alınır ve orada kalır. Ekip büyür, sistem büyür, kısayol büyür. Bu en yaygın borç türüdür ve aynı zamanda en savunulabilir olanıdır: o an için doğru karardı. Sorun, geri dönülmemesidir. Geri dönüş için gerekli bağlam zamanla kaybolur ve borç görünmez hale gelir.

Entropi: İyi tasarlanmış bir sistem bile değişen gereksinimler altında zamanla çürür. Üç yıl önce makul görünen bir mimari karar, bugün on farklı servisin bağımlı olduğu kırılgan bir bileşene dönüşmüş olabilir. Kod değişmedi; ama çevresi değişti. Bu tür borç en sinsi olanıdır çünkü hiç kimse bilinçli olarak kötü bir karar almamıştır.

Bağlam kaybı: Kodu yazan mühendis ekipten ayrılır. Belgeleme yoktur veya güncel değildir. Kimse "neden böyle yapıldığını" bilmez. Bu borç türü en tehlikelisidir, çünkü görünmezdir. Bir olay sırasında devreye girdiğinde, MTTR'yi kaçınılmaz olarak uzatır.

Dış baskı: Sprint baskısı, özellik talepleri, kaynak kısıtlamaları. Mühendisler doğru çözümü bildikleri halde daha hızlı bir çözüme yönlendirilir. Bu karar kayıt altına alınmaz; ekip değişir; kimse borcu hatırlamaz. Bu tür teknik borç özellikle hızlı büyüyen ekiplerde kronik hale gelir.

Teknik Borcu Operasyonel Riske Göre Üç Kategoride Yönetin

Kodunuzdaki her çirkinlik teknik borç değildir; her teknik borç da aynı öncelikte değildir. Platform engineering perspektifinden üç kategori kullanmak çok daha yararlıdır ve bu sınıflandırma ekibinizin bütçe tartışmalarını da dönüştürür.

Kritik Operasyonel Borç: Bir sonraki büyük dağıtımda olaya dönüşme olasılığı yüksek olan borç. Hata toleransı olmayan bir üçüncü taraf entegrasyonu, prod'da hizmet veren ancak artık desteklenmeyen bir kütüphane, manuel müdahale gerektiren bir rollback prosedürü. Bu borç, sprint backlog'unuza değil, P1 alarmı gibi triaj edilmelidir. İzleme araçlarınız bu bölgeleri zaten gösteriyor olabilir: en çok alarm üreten yerler çoğunlukla en yüksek kritik borcun bulunduğu yerlerdir.

Yapısal Borç: Servisleri veya modülleri değiştirmeyi yavaşlatan tasarım kararları. Deployment frequency'nizi düşürür, change failure rate'inizi artırır. Takımın hızını etkiler ama bugece bir olay üretme ihtimali görece düşüktür. Çeyreklik teknik revizyon toplantılarında ele alınmalı; her sprint'e belirli bir oranda dahil edilmelidir.

Kozmetik Borç: Yeniden adlandırma gerektiren değişkenler, eksik belgeleme, tutarsız test coverage. Bunların önemi vardır, ama aciliyeti yoktur. Bir developer experience sorunu olarak değerlendirin, operasyonel risk olarak değil. Bu kategoriyi aşırı önceliklendiren ekipler, gerçek operasyonel borcun büyümesine izin vermiş olur.

Bu sınıflandırmayı operasyon ekibinizle birlikte yaparsanız, teknik borç tartışması "kod kalitesi" konuşmasından "dağıtım riski" konuşmasına dönüşür. CTO'nuza teknik borç için bütçe ve zaman istiyorsanız bu fark kritiktir: blast radius'u göstermeniz gerekir, refactoring listesi değil.

DORA Metrikleri Teknik Borcu Bir Olay Patlak Vermeden Önce Gösterir

Teknik borcunuzun büyüklüğünü doğrudan ölçemezsiniz. Ama dört DORA metriği size dolaylı yoldan söyler ve genellikle bir olay patlak vermeden çok önce işaret eder. Bu metrikleri düzenli olarak izleyen ekipler, teknik borcun kritik eşiği aştığını bir post-mortem'den önce fark edebilir.

Deployment Frequency (Dağıtım Sıklığı): Elite DORA ekipleri günde birden fazla dağıtım yapar. Teknik borç içinde boğulan bir ekip ise dağıtım sıklığını azaltır; çünkü değişiklikler büyük ve riskli hale gelir, on-call ekip temkinlileşir. Dağıtım sıklığınız düşüyorsa bunun nedeni sadece takım kapasitesi değildir. Teknik borcun sistemi ne kadar kırılgan hale getirdiğini sormak gerekir.

Change Failure Rate (Değişiklik Hata Oranı): Elite ekiplerde bu oran yüzde 0-15 aralığındadır. Teknik borç yükseldikçe bir değişiklik kaçınılmaz olarak başka bir şeyi bozar. Belirli bir servis veya bileşen sürekli daha yüksek hata oranı üretiyorsa, teknik borcunuzun adresini biliyorsunuz demektir. Bu oran, teknik borç birikiminin en net sinyal noktasıdır.

MTTR (Ortalama Kurtarma Süresi): Bir olay sırasında on-call mühendis neyi araştırmak zorunda kalır? Anlaşılması güç kod, belgesiz bağımlılıklar, izlenemeyen servisler. Her biri teknik borcun bir ürünüdür. Teknik borç yükseldikçe MTTR uzar; MTTR uzadıkça kullanıcıların etkilendiği pencere genişler.

Lead Time for Changes: Bir pull request ne zaman üretime ulaşır? Uzun lead time çoğunlukla büyük, riskli ve monolitik değişikliklere işaret eder; bu da derin teknik borç birikiminin belirtisidir. Küçük ve izole değişiklikler yapabilen ekipler, teknik borcu kontrol altında tutan ekiplerdir.

Bu metrikleri ölçmüyorsanız, teknik borcunuzun büyüklüğünü bilemezsiniz. Bu metrikleri ölçüyorsanız, teknik borç tartışması soyut olmaktan çıkar, veri odaklı bir mühendislik kararına dönüşür.

Pratik bir kural olarak şunu söylemek mümkündür: change failure rate'iniz üç hafta üst üste yüzde 30'un üzerine çıkıyorsa, bu bir proje yönetim sorunu değil, teknik borç sorunudur. Benzer şekilde, MTTR'niz sürekli 45 dakikanın üzerindeyse, on-call mühendisiniz sistemi anlayabilmek için çok fazla zaman harcıyor demektir. Her iki metrik de borcun operasyonel eşiği geçtiğinin güçlü sinyalleridir.

Teknik Borcu Bir Prodüksiyon Alarmı Gibi Triaj Edin

Platform mühendislerinin teknik borçla başa çıkamamasının temel nedeni çoğunlukla araç eksikliği değildir. Konuşma biçimidir. "Yeniden yapılandırmamız lazım" belirsizdir ve sprint planlamasında yer bulmaz. "Bu servis bir sonraki büyük dağıtımda yüzde 40 olasılıkla olay üretir ve MTTR tahminimiz 45 dakikadır" ise somut, önceliklendirilebilir ve savunulabilirdir.

Teknik borç triajı şu soruları yanıtlamalıdır: Bu borç hangi senaryo altında olaya dönüşür? Olası etki nedir, kaç kullanıcıyı ve kaç servisi etkiler? Düzeltmek kaç mühendis günü alır? Düzeltilmezse önümüzdeki 30 günde maruz kaldığımız risk nedir?

Bu soruları yanıtladığınızda teknik borç çalışması sprint backlog'unda yer bulabilir. Çünkü artık soyut bir "temizlik" talebi değil, ölçülebilir bir risk azaltma işlemidir. Teknik borcu bu şekilde çerçeveleyen ekipler, mühendislik kapasitesinin önemli bir bölümünü borç ödemeye ayırabilir ve bunu CTO düzeyinde savunabilir.

Teknik Borç Yönetimi: Ne İşe Yarar, Ne Yaramaz

Teknik borç yönetimi için zaman zaman önerilen bazı yaklaşımlar gerçekte işe yaramaz. "Teknik borç sprinti" bunların başında gelir: ekip bir hafta boyunca sadece teknik borç çalışır, ardından özellik geliştirmeye geri döner. Sorun şudur: bu yaklaşım, borç birikmeye devam ederken dönemsel bir temizlik yapmaktan ibarettir. Sprint bittikten birkaç hafta sonra ekip aynı yerdedir.

İşe yarayan yaklaşım, teknik borcu sürekli ve orantılı bir akış olarak yönetmektir. Her sprint'in belirli bir yüzdesi teknik borç çalışmasına ayrılır. Bu oran sabit değil, ölçülen operasyonel riske göre değişir. Change failure rate yüksekse oran artar; DORA metrikleri sağlıklıysa azalır.

Bu yaklaşımın ikinci ayağı görünürlüktür. Teknik borç görünmezse yönetilmez. Hangi modüllerin en yüksek karmaşıklığa sahip olduğunu, hangi servislerin en çok alarm ürettiğini ve hangi bağımlılıkların en eski versiyonda kaldığını izleyen bir dashboard olmalıdır. Bu bilgi olmadan teknik borç yönetimi kör bir iştir.

Bir üçüncü yaklaşım ise pull request kapısıdır: her değişiklik, etkilenen modülün karmaşıklık skorunu artırıyorsa otomatik bir uyarı tetikler. Bu, borcun sessizce birikmesini önleyen bir mekanizmadır.

Ekiplerin sıklıkla atladığı bir nokta, teknik borç yönetiminin sadece mühendislik değil, aynı zamanda bir ekip kültürü meselesi olduğudur. On-call rotasyonu yapan her mühendis, karşılaştığı anlaşılması güç kodu işaretlemenin bir yoluna sahip olmalıdır. Bu işaretleme sistemi olmadan, teknik borç yöneticilerin göremediği bir yerde birikmeye devam eder. Teknik borcu görünür kılmak, onu yönetmekten önce gelir.

Teknik Borç Asla Sıfırlanmaz; Ama Kontrol Altına Alınabilir

Teknik borçsuz bir sistem yoktur. Var olan fark, ekiplerin borçlarıyla ne yaptığıdır. Elite ekipler teknik borcu ayrı bir parantez olarak değil, deployment riskinin yönetilebilir bir bileşeni olarak görür.

Bu ekipler deployment frequency'yi artırdığında change failure rate düşer; çünkü değişiklikler küçük ve izole olur. MTTR kısalır; çünkü sistem daha iyi belgelenmiştir ve daha izlenebilirdir. Lead time azalır; çünkü yapısal borç azaldıkça değişiklikler daha az yan etki yaratır. Bu iyileşmeler birbirini besler: daha sık dağıtım yapan ekipler daha az borç biriktirir.

Sabahın üçünde alarm çaldığında istediğiniz şey, anlaşılması güç bir codebase değildir. Bir revert düğmesi ve hızlı kurtarma sürecidir. Teknik borç yönetimi, tam da o düğmeye güvenebilmek için yapılan mühendislik yatırımıdır. Ve bu yatırımın getirisi, bir sonraki post-mortem'de değil, yaşanmayan olayların sayısında ölçülür. Teknik borç konuşmalarını operasyonel risk diline çeviren ekipler, hem daha sağlıklı bir codebase elde eder hem de mühendislik kararlarına yönelik kurumsal desteği kazanır. Bu ikisi birbirini besler; uzun vadede sürdürülebilir bir delivery hızı için gereklidir.