Geçenlerde kendi VPS’imde çalışan AI generation pipeline’ında, ardı ardına gelen OOM-killed hataları beni yine eski günlere götürdü. Bir sleep 360 komutunun nasıl bir sistemin canına okuyabileceğini ve basit bir hatanın nelere mal olabileceğini bir kez daha gördüm. Bu durum, sistem mimarlığının aslında biraz da “paranoya” işi olduğunu düşündürdü bana.
Benim için bu “paranoya” hali, kötü senaryoları öngörme, her şeyin ters gidebileceğini kabul etme ve buna göre önlemler alma üzerine kurulu bir yaşam biçimi gibi. Kulağa biraz negatif gelse de, sahada edindiğim 20 yıllık tecrübe, bu yaklaşımın neden vazgeçilmez olduğunu defalarca kanıtladı.
Paranoyanın Kökenleri: Geçmişteki Yaralar
Bu “paranoyak” ruh hali, boş bir kuruntu değil, yaşadığım ve ders çıkardığım acı deneyimlerin bir sonucu. Yıllar içinde birçok sistemin nasıl beklenmedik şekillerde çöktüğünü, yavaşladığını veya tamamen erişilemez hale geldiğini gördüm. Bu olaylar, benim mimari yaklaşımımın temelini oluşturdu.
Hatırlıyorum, bir keresinde büyük bir TR e-ticaret sitesinde, kritik bir kampanyanın ortasında veritabanı sunucusu tamamen kilitlenmişti. O anki çaresizliği ve panik halini hiç unutmam. Kendi VPS’imde de benzer ama daha küçük çaplı krizler yaşadım; örneğin 28 Nisan’da diskimin %100 dolması gibi. Bu tür olaylar, “ya olursa?” sorusunu sormanın ne kadar önemli olduğunu öğretti bana.
Kendi VPS’imde Yaşadığım Olaylar
Kendi sunucumda 13’ten fazla Docker container yönetiyorum. Bazen bir tanesi bile beklenmedik bir şekilde davranmaya başladığında, domino etkisiyle diğerlerinin de swap’e indiğini görüyorum. Bu tür senaryolar, sistemin her bir parçasının birbiriyle nasıl etkileşimde olduğunu ve en zayıf halkanın tüm sistemi nasıl etkileyebileceğini gösteriyor.
Bir keresinde, Docker’ın build cache’inin 33 GB’a ulaştığını ve kullanılmayan imajların da 23 GB yer kapladığını fark ettim. Sunucu diskim %100 dolmuştu ve SSH bile atamıyordum. Bu durum, basit bir disk doluluğunun bile tüm operasyonu felç edebileceğini acı bir şekilde öğretti. O günden beri docker system prune -a komutunu düzenli olarak çalıştırıyorum.
Her Şeyin Bozulabileceğini Bilmek
Bir sistem mimarı olarak benim en temel prensibim, her şeyin, ama her şeyin bir gün bozulacağı gerçeğini kabul etmektir. Bu, bir donanım arızası olabilir, bir yazılım bug’ı olabilir veya basit bir insan hatası olabilir. Önemli olan, bu bozulmaların olacağını bilip, bunlara karşı nasıl bir direnç mekanizması kurduğumuzdur.
GitHub Actions runner’ımda bir kez _work/_temp dizinleri yüzünden state corruption yaşadım. O dizinleri silmenin acısı ve tüm pipeline’ı yeniden kurmak zorunda kalmak, otomasyon sistemlerinin bile ne kadar kırılgan olabileceğini gösterdi bana. Bu tür olaylar, yedeklilik ve hızlı geri dönüş mekanizmalarının neden bu kadar değerli olduğunu açıklıyor.
Resilience ve Hata Toleransı
Bu “paranoyak” bakış açısı, beni sistem tasarlarken resilience ve fault tolerance kavramlarına daha fazla odaklanmaya itiyor. Bir bileşenin çökmesi durumunda sistemin nasıl ayakta kalmaya devam edeceğini planlamak, mimarinin en kritik adımlarından biri.
Örneğin, bu blog’un Astro build süreci bazen 2.5 GB RAM yiyip, toplamda 7.6 GB sistem RAM’ini zorlayarak OOM oluyor. Böyle bir durumda, pipeline’a preflight resource guard ekleyerek önce kaynak kontrolü yapıyorum. Eğer yetersiz kaynak varsa, işlemi erteleyip polling-wait moduna geçiyorum. Geçen ay sleep 360 yazıp OOM-killed olduğumda, bu polling-wait mekanizmasını devreye sokmak zorunda kaldım.
Cloudflare Cache Stratejileri
Cloudflare kullanırken bile bu “paranoya” devreye giriyor. Astro’nun varsayılan olarak max-age=0 dönmesi, statik içerikler için istediğim performansı vermiyordu. Bu yüzden Nginx üzerinde bir override yaparak belirli yollar için daha uzun cache süreleri tanımladım. Bu, içerik tazeliği ve performans arasında bir trade-off yapma ve bu trade-off’u bilinçli olarak yönetme meselesidir.
location /_astro/ {
expires 1y;
add_header Cache-Control "public, max-age=31536000, immutable";
proxy_pass http://localhost:4321;
}Bu örnekte, _astro ile başlayan statik asset’ler için 1 yıllık bir cache süresi belirledim. Bu, CDN katmanında gereksiz origin hitlerini azaltarak hem performansı artırıyor hem de sunucumun yükünü hafifletiyor.
Güvenlik ve Sürekli Tetikte Olmak
Sistem mimarlığında “paranoya”nın en belirgin olduğu alanlardan biri de güvenlik. Ben her zaman, saldırganların sistemdeki en zayıf noktayı bulmaya çalışacağını varsayarım. Bu yüzden, sadece bilinen zafiyetlere karşı değil, potansiyel risklere karşı da önlem almaya çalışırım.
Geçtiğimiz yıllarda, CVE’lerin ne kadar kritik olabileceğini birçok kez gördüm. Kendi sistemimde bile, CVE-2026-31431 gibi potansiyel riskleri takip edip, algif_aead gibi kernel modüllerini blacklist’e alarak olası bir açığı kapatmaya çalıştım. Bu tür proaktif adımlar, sistemin genel güvenlik duruşunu güçlendiriyor.
Kendi VPS’imdeki Runner Ekonomisi
GitHub Actions kotasını delmemek için kendi VPS’imde self-hosted runner kullanıyorum. Bu, bir yandan maliyet avantajı sağlarken, diğer yandan da sürekli güncellemeleri ve güvenlik yamalarını takip etmemi gerektiriyor. Bu durum, “paranoyayı” bir tür maliyet optimizasyonu ve risk yönetimi aracı olarak görmemi sağlıyor.
AI destekli içerik pipeline’ımı kurarken bile, tag’lerde slash (/) kullanıldığında veya publishDate alanının tırnaklı bir string olmaması durumunda oluşan hataları fark ettim. Hatta dotted-i karakter problemi gibi Türkçe’ye özgü detaylar bile, sistemin her katmanında beklenmedik sorunlar çıkarabileceğini gösteriyor. Bu tür “quirk”ler, benim için sürekli tetikte olmanın ve her detayı düşünmenin bir parçası.
Paranoya mı, Profesyonellik mi?
Peki, sistem mimarlığındaki bu “paranoya” hali aslında nedir? Benim için bu, sürekli endişeli olmak veya her an bir felaket beklemek değil. Daha çok, sistemlerin doğasında var olan karmaşıklığı ve kırılganlığı anlayarak, bu riskleri minimize etmek için bilinçli adımlar atmaktır. Buna risk-aware design diyebiliriz.
Bu, bir nevi mühendislik bakış açısıdır. Bir köprü inşa eden mühendisin, deprem, fırtına veya aşırı yük gibi senaryoları düşünerek tasarım yapması gibi, biz de sistemlerimizi potansiyel arızalara karşı dayanıklı hale getirmeye çalışırız. Kendi yaptığım hatalardan utanmam; aksine, geçen ay sleep 360 yazıp OOM-killed olduğumda, bu hatadan ders çıkarıp polling-wait mekanizmasını geliştirdim. Bu, “olur o kadar” deyip geçmek yerine, “bir daha olmasın diye ne yapabilirim” sorusunu sormaktır.
Sistem mimarlığı benim için biraz da bu, sürekli tetikte olmak ve her şeyin ters gidebileceğini bilerek tasarlamak. Bu “paranoya” olmasaydı, ne hesapciyiz.com ne spamkalkani.com ne de islistesi.com gibi yan ürünlerim bu kadar stabil çalışırdı. Senin de böyle “paranoyak” anların oldu mu hiç? Yorumlarda paylaşmak istersen sevinirim.