Kendi Sunucumda Yaşamak: Zaman ve Özgürlük Dengesi

Geçenlerde kendi VPS’imde arka arkaya üç farklı Docker container’ın birden OOM-killed olmasıyla uyandım. PagerDuty çaldığında sabahın 04:30’uydu ve ilk tepkim “Yine mi?” oldu. Bu, benim kendi sunucumda yaşamak dediğim, yani tüm kişisel projelerimi ve yan ürünlerimi yönettiğim dünyanın tipik bir sabah başlangıcıydı.

Bu durum, aslında yıllardır süregelen bir denge arayışının somut bir örneği: Sahip olduğum özgürlük ve kontrolün karşılığında harcadığım zaman ve emek. Kendi sunucumda yaşamak benim için bir tercih, bir felsefe haline geldi.

Özgürlüğün Bedeli: Zaman ve Emek

Yıllardır süregelen bir alışkanlığım var: Her şeyi kendi ellerimle kurmak ve yönetmek. Bu, 2006’dan beri sistem mimarisi ve operasyonları alanında kazandığım tecrübenin kişisel hayatıma yansıması aslında. Kendi sunucumda barındırdığım bu blog, hesapciyiz.com, spamkalkani.com ve islistesi.com gibi projelerim için de geçerli.

Bu özgürlüğün bir bedeli var elbette. Kimi zaman 28 Nisan’da olduğu gibi disk %100 dolduğunda veya kcompactd’nin %92 CPU kullandığını gördüğümde, elimde kahveyle terminal başında saatler geçirmem gerekiyor. Bir sshd’nin accept edememesi, bir Docker disk yangını veya algif_aead gibi kernel modüllerini blacklist’e alıp CVE’leri bertaraf etmek gibi durumlar, bu özgürlüğün getirdiği sorumluluklar.

Neden Kendi Sunucumda Yaşıyorum? Felsefem

Peki tüm bu sorunlara, uykusuz gecelere rağmen neden bu yolu seçiyorum? Temelde yatan birkaç felsefi sebep var:

Tam Kontrol ve Bağımsızlık

Kendi sunucumda, her şey benim tercihim. İşletim sisteminden web sunucusuna, veritabanından uygulama katmanına kadar her bileşeni ben seçiyorum. Astro, Node, SQLite, Nginx, systemd, GitHub Actions, Cloudflare benim günlük araç setimi oluşturuyor. Bu ekosistemi kendi ihtiyaçlarıma göre şekillendirebiliyorum, herhangi bir vendor’ın kısıtlamalarına takılmadan. Bu seviyedeki bir kontrol, özellikle karmaşık pipeline’lar veya özelleşmiş AI uygulamaları geliştirirken paha biçilmez oluyor.

Sürekli Öğrenme ve Deneyim

20 yıllık saha tecrübem olsa da teknoloji dünyası sürekli değişiyor. Kendi sunucum, yeni teknolojileri, araçları ve yaklaşımları denemek için bir kum havuzu görevi görüyor. Astro build’imin 2.5 GB RAM yiyip OOM olduğu anlar, Docker’ın 33 GB build cache ve 23 GB unused image ile diski tıkadığı durumlar, teorik bilgiyi pratik deneyime dönüştürüyor. Bu gerçek dünya senaryoları, beni sürekli olarak daha iyi çözümler bulmaya itiyor.

Ekonomik Verimlilik ve Ölçeklenebilirlik

Bazı durumlarda kendi sunucumda barındırmak, maliyet açısından da avantaj sağlıyor. Özellikle GitHub Actions kotalarını aşmamak için self-hosted runner kullanmak, bana hem esneklik hem de maliyet tasarrufu sağlıyor. Kendi VPS’imde yönettiğim 13+ Docker container (Postgres, Redis, Next.js uygulamaları dahil), tek bir sunucuda birden fazla projeyi düşük maliyetle barındırma imkanı sunuyor. Bu, özellikle yan ürünler için önemlidir.

Yenilikçilik ve Kendi Yolumu Çizme

AI destekli içerik pipeline’ı kurmak veya Knowledge Graph üzerine deneyimlerimi aktarmak gibi konularda, kendi altyapım bana tam özgürlük sağlıyor. Standart çözümlerin dışına çıkıp, kendi algoritmalarımı, entegrasyonlarımı ve hata giderme mekanizmalarımı geliştirebiliyorum. Bu, beni sadece bir tüketici olmaktan çıkarıp, aynı zamanda bir yaratıcı ve problem çözücü haline getiriyor.

Kendi VPS’imi Yönetmek: Pratik Zorluklar ve Çözümler

Kendi sunucumda yaşamak sadece felsefi bir duruş değil, aynı zamanda günlük operasyonel zorlukları da beraberinde getiriyor. Bu zorluklarla nasıl başa çıktığımı ve hangi pratik çözümleri geliştirdiğimi sıkça görüyorum.

Resource Management: Kaynak Yönetimi Çıkmazları

VPS’te 13 container yönetmek, bir tanesi sevimsiz davranırsa hepsinin swap’e inmesine neden olabiliyor. Özellikle yoğun yük altında veya kritik bir işlem sırasında sistemin kaynakları yetersiz kalabiliyor.

• VPS Overload Senaryoları: Swap’in sürekli fıştırması, kcompactd’nin %92 CPU ile kernel memory compaction yapması veya sshd’nin yeni bağlantıları accept edememesi gibi durumlar, sistemin aşırı yüklendiğini gösterir. Bu anlarda sisteme uzaktan erişmek bile imkansız hale gelebilir.
• Astro Build OOM: Kendi blogumun build süreci bile bazen 2.5 GB RAM tüketip sistemdeki 7.6 GB RAM’in yetersiz kalmasına neden olabiliyor. Bu, özellikle CI/CD pipeline’larında baş ağrısı yaratır.

Bu tür durumlarla başa çıkmak için aktif bir izleme (monitoring) sistemim var. Ayrıca, kaynak kullanımını optimize etmek için container’lara limitler koyuyor, gereksiz servisleri kapatıyor ve bazen de daha optimize edilmiş yazılımlara geçiş yapıyorum. Örneğin, bir Astro build’in OOM olması durumunda, build sürecini daha az RAM tüketen bir ortamda çalıştırmak veya build adımlarını optimize etmek gibi çözümler deniyorum.

Disk Yönetimi: Gizli Alan Tüketicileri

Docker’ın disk kullanım alışkanlıkları bazen kabus olabiliyor. Özellikle sık sık image build eden veya çok sayıda container çalıştıran bir sistemde disk doluluğu kaçınılmaz hale geliyor.

• Docker Disk Yangını: Kendi sunucumda 33 GB’lık build cache ve 23 GB’lık unused image birikimiyle %100 disk doluluğu yaşadığım anlar oldu. Bu, tüm servislerin durmasına ve sisteme erişimin engellenmesine yol açtı.
• Çözümler: Bu duruma karşı düzenli docker system prune -a komutuyla eski image’ları ve cache’i temizliyorum. Ayrıca, log rotasyonunu ayarlıyorum ve kritik verileri ayrı volume’larda tutarak disk doluluğunun etkisini minimize etmeye çalışıyorum. Bu rutin bakımlar, sistemin sağlığı için vazgeçilmez.

Otomasyon ve Güvenilirlik: Pipeline’ları Ayakta Tutmak

Kendi pipeline’larımı yönetmek, otomasyonun inceliklerini ve güvenilirliğin önemini bana sürekli hatırlatır. GitHub Actions runner’ları bile kendi başlarına sorun çıkarabilirler.

• GitHub Actions Runner State Corruption: Bazen _work/_temp içindeki dizinlerin bozulması runner’ın düzgün çalışmamasına neden olabiliyor. Bu durumda manuel olarak bu dizinleri silmek ve runner’ı yeniden başlatmak gerekebiliyor. Bu tip durumlar, otomasyonun bile manuel müdahaleye ihtiyaç duyabileceğini gösteriyor.
• Pipeline Reliability: Kendi AI generation pipeline’ımda preflight resource guard ve auto-fix mekanizmaları kullanıyorum. Ayrıca dedup-alert pattern’leri sayesinde aynı hatanın tekrar tekrar beni uyarmasını engelliyorum. Bu tür mekanizmalar, sistemin otomatik olarak kendini iyileştirmesini ve beni sadece gerçekten kritik durumlarda uyarmasını sağlıyor.
• Cloudflare Cache Stratejileri: Astro’nun varsayılan olarak max-age=0 döndürmesi, Cloudflare’ın cache’lemesini engelliyor. Bu durumu Nginx config’imle Cache-Control header’ını override ederek çözdüm. Böylece statik içeriklerim Cloudflare tarafından düzgün bir şekilde cache’lenebiliyor.
• CVE Mitigation: Kritik güvenlik açıkları bazen kernel seviyesinde müdahale gerektirebiliyor. Örneğin, algif_aead modülünü blacklist’e alarak CVE-2026-31431 gibi bir açığı kendi sunucumda manuel olarak bertaraf ettim. Bu tür durumlar, kendi sunucunu yönetmenin getirdiği sorumluluğu ve proaktif olmayı gerektirir.

AI Pipeline Yönetimi: Karakter Uyumsuzlukları ve Veri Bütünlüğü

AI destekli içerik üretimi, kendi başına birçok ilginç problemle geliyor. Özellikle metin işleme ve veri transferinde beklenmedik “quirk”ler ortaya çıkabiliyor.

• AI Quirk’leri: Tag’larda slash karakteri kullanmak, publishDate alanının tırnaklı string olarak gelmesi veya “dotted-i” gibi karakterlerin encoding sorunları yaratması, AI pipeline’ımda karşılaştığım spesifik sorunlardan sadece birkaçı. Bu sorunlar, genellikle veri doğrulama (validation) ve temizleme (sanitization) adımlarının ne kadar kritik olduğunu gösteriyor.
• Çözümler: Bu tür karakter problemlerini genellikle AI modelinden gelen çıktıyı işleyen ara katmanlarda regex veya özel karakter dönüştürme fonksiyonları kullanarak çözüyorum. Amacım, verinin tutarlı ve beklenen formatta olmasını sağlamak. Kendi sistemimde bu esnekliğe sahip olmak, bu tür sorunları hızlıca tespit edip düzeltmeme olanak tanıyor.

Ticaret ve Tutku Arasında: Yan Ürünlerim

Kendi sunucumda yaşamak, benim için sadece teknik bir meydan okuma değil, aynı zamanda yan ürünlerimi hayata geçirme aracı. hesapciyiz.com (TR finansal hesaplayıcılar), spamkalkani.com (Android spam blocker), islistesi.com (TR görev yönetimi) ve bu blog, kendi altyapımda barındırdığım projelerimden bazıları.

Bu projelerin her biri, benim için birer öğrenme ve uygulama alanı. Kendi sunucumda yönettiğim için, maliyetleri düşük tutabiliyor, performansı optimize edebiliyor ve dilediğim zaman yeni özellikler ekleyebiliyorum. Büyük bir TR e-ticaret sitesinde veya bir bankanın iç platformunda edindiğim tecrübeleri, bu küçük ama benim için anlamlı projelerde uygulama fırsatı buluyorum. Bu, bana hem teknik tatmin sağlıyor hem de potansiyel olarak yeni gelir kapıları açıyor.

Dengeyi Bulmak: Zaman Yönetimi ve Öncelikler

Kendi sunucumda yaşamak, sürekli bir denge arayışı. Her şeyi kendim yapma isteği ile zamanın kısıtlılığı arasındaki o ince çizgide yürüyorum. Bu dengeyi bulmak için bazı yaklaşımlarım var:

Neyi Kendin Yapmalı, Neyi Dışarıdan Almalı?

Her şeyi kendim yapmıyorum, yapamam da. Kritik altyapı bileşenleri için (örn: CDN için Cloudflare) dışarıdan hizmet almaktan çekinmiyorum. Ama uygulama katmanı, veritabanı ve CI/CD gibi çekirdek kısımlarda kontrolü elimde tutmayı tercih ediyorum. Bu, benim için stratejik bir karar. Hangi alanlarda derinlemesine bilgi sahibi olmak istediğimi ve hangilerini genel bir hizmet olarak kullanabileceğimi belirliyorum.

Zamanımı Neye Harcıyorum?

Bir Docker sorununu gidermek mi, yoksa yeni bir blog yazısı yazmak mı? Bu, sıkça karşılaştığım bir ikilem. Genellikle, doğrudan kullanıcıya değer katan veya benim için yeni bir şeyler öğrenmemi sağlayan görevlere öncelik veririm. Rutin bakımlar otomatize edilmiş olsa da, beklenmedik sorunlar çıktığında onlara ayırdığım zamanı bir yatırım olarak görüyorum. Çünkü her sorun, sistemimi daha iyi anlamamı ve gelecekteki olası problemleri önlememi sağlıyor.

Teknoloji Seçimlerimde Pragmatizm

Yeni ve parlak teknolojilere her zaman açığım, ancak seçimlerimi pragmatik bir yaklaşımla yapıyorum. SQLite’ı seçmemin nedeni, benim ölçeğimdeki projeler için sunduğu basitlik ve performans. Nginx kullanmamın sebebi, yıllardır edindiğim tecrübe ve kararlılığı. Her teknoloji seçimim, “Bu, benim için ne kadar zaman ve emek gerektirecek?” sorusunun cevabına dayanır.

Sonuç

Kendi sunucumda yaşamak benim için bir mücadele, bir öğrenme süreci ve en önemlisi bir özgürlük beyanı. Her ne kadar zaman zaman uykusuz gecelere mal olsa da, kendi sistemimin her köşesini bilmek, onu kendi ellerimle şekillendirmek paha biçilmez bir deneyim. Büyük kurumsal projelerde edindiğim tecrübeleri, kendi küçük dünyamda uygulayabilmek, benim için en büyük motivasyon kaynaklarından biri.

Bu yolculukta karşılaştığım her hata, her sorun, beni biraz daha geliştiriyor ve sistemimi daha sağlam hale getiriyor. Şu sıralar kendi AI generation pipeline’ımı daha da optimize etme sürecindeyim. Bakalım önümüzdeki ay hangi yeni sürprizlerle karşılaşacağım. Senin de benzer tecrübelerin oldu mu, merak ediyorum. Belki bir sonraki yazıda, bu AI pipeline’ının detaylarına daha fazla girerim.