Geçen salı sabah saat 06:00’da, Pipeline-health monitor’dan gelen “DEGRADED” mailiyle uyandım. Kendi blogumun AI içerik pipeline’ı yine bir sorun yaşamıştı. Bu, indie hacker olarak kendi projelerimi yürütürken karşılaştığım sayısız “anı”dan sadece biri. Dışarıdan bakıldığında “kendi işinin patronu olmak”, “özgürce kod yazmak” gibi romantik bir tablo çiziliyor ama gerçekler çoğu zaman çok farklı.
Yan ürünlerim olan hesapciyiz.com, spamkalkani.com ve islistesi.com’u yönetirken ve bu blogu beslerken, sürekli bir operasyonel yük altındayım. Aslında yaptığım iş, büyük şirketlerdeki sistem mimarisi ve operasyon deneyimimin bir nevi minyatür versiyonu. Sadece bu sefer tüm rolleri tek başıma üstleniyorum.
Romantik Perdenin Ardı: Kendi İşinin Operasyonu
İnternette gördüğünüz başarılı indie hacker hikayelerinin çoğu, ürün geliştirme, pazarlama ve satış kısımlarına odaklanır. Ancak kimse size gece 03:00’te bir systemd servisi yeniden başlatmak zorunda kaldığınızı, bir Docker container’ının beklenmedik şekilde disk doldurduğunu veya bir GitHub Actions pipeline’ının neden patladığını anlatmaz. Bu, sürekli bir tetikte olma hali gerektiriyor.
Benim için indie hacker olmak, sadece fikir üretip kod yazmak değil; aynı zamanda bir DevOps mühendisi, bir sistem yöneticisi, bir QA ve hatta bazen bir müşteri destek elemanı olmak anlamına geliyor. Kendi VPS’imde çalışan 13’ten fazla Docker container’ın her birinin sağlıklı çalıştığından emin olmak, düzenli güncellemeler yapmak ve olası sorunlara karşı önlem almak günlük rutinimin bir parçası.
Kendi Sunucunun Dramı: VPS Overload ve OOM Senaryoları
Kendi VPS’imde, genellikle bir dizi container çalıştırıyorum. Bellek ve CPU kaynakları sınırlı olduğunda, en ufak bir aksaklık domino etkisi yaratabiliyor. Örneğin, geçen ay yaşadığım bir olayda, bir uygulamanın beklenmedik bellek tüketimi yüzünden sistemde kcompactd sürecinin %92 CPU kullanmaya başladığını gördüm. SSH bağlantısı kurmak bile imkansız hale gelmişti çünkü sshd yeni bağlantıları accept edemiyordu.
Bu gibi durumlarda, swap alanının şiştiğini, sistemin yavaşladığını ve en sonunda kritik servislerin OOM-killed olduğunu izlemek zorunda kalıyorum. Sorunun kaynağını bulmak ve çözmek için günler harcadığım oldu. Bazen basit bir sleep 360 komutuyla bir servisi geçici olarak durdurmaya çalışırken, yanlışlıkla sistemin OOM-killed olmasına neden olduğumu hatırlıyorum. Bu tür hatalar, pragmatik bir bakış açısıyla “olur o kadar” diyebileceğiniz ama yine de can sıkan deneyimler.
Docker Disk Yangını ve Otomasyonun Getirdiği Yeni Baş Ağrıları
Docker kullanmanın getirdiği esneklik tartışılmaz ama beraberinde yeni sorunları da getiriyor. Özellikle build cache’lerinin ve kullanılmayan imajların zamanla diski doldurması büyük bir sorun. 28 Nisan’da kendi VPS’imde tam da bu durumu yaşadım: Disk %100 dolmuştu. Geriye dönüp baktığımda, 33 GB’lık build cache ve 23 GB’lık unused image olduğunu gördüm. Bu, beni acil bir docker system prune -a operasyonu yapmaya itti.
GitHub Actions gibi otomasyon araçları, sürekli entegrasyon ve dağıtım süreçlerimde hayati öneme sahip. Ancak bu araçların da kendine has sorunları var. Kendi self-hosted runner’ımı kullanırken, bir keresinde _work/_temp dizinindeki bozulmuş bir state yüzünden pipeline’larım çalışmamıştı. Ne kadar manuel temizlik yaparsam yapayım, sorunu çözemeyip en sonunda runner’ı sıfırlamak zorunda kalmıştım. Bu tür durumlar, otomasyonun bize sunduğu konforun yanında getirdiği bakım yükünü açıkça gösteriyor.
AI Pipeline’ı Geliştirirken Karşılaştıklarım
Bu blog için kurduğum AI destekli içerik pipeline’ı, bana “indie hacker” olmanın başka bir yüzünü gösterdi. AI modellerinin output’ları her zaman mükemmel olmuyor. Örneğin, bazen tag’larda slash karakteri kullanması, publishDate alanını tırnaklı bir string olarak döndürmesi veya Türkçe karakterlerde (özellikle dotted-i) sorunlar yaşaması gibi “quirk”lerle karşılaştım. Bu durumlar, pipeline’a güçlü bir “auto-fix” ve “dedup-alert” mekanizması eklememi zorunlu kıldı.
Astro build süreçleri de ayrı bir hikaye. Benim gibi çok sayıda içerik üreten bir blog için, Astro’nun build process’i ciddi kaynaklar tüketebiliyor. Kendi sunucumda Astro build’inin 2.5 GB RAM yediği ve toplam sistem RAM’inin 7.6 GB’a çıktığı anlar oldu. Bu, küçük bir VPS için ciddi bir OOM riski demek. Bu gibi durumlarda preflight resource guard mekanizmaları kurmak, beklenmedik kesintilerin önüne geçmek için elzem hale geliyor.
Geliştirme mi, Bakım mı? Sürekli Bir Trade-off
Indie hacker’lar olarak sürekli yeni özellikler geliştirmek, ürünümüzü iyileştirmek ve pazarlamak isteriz. Ancak gerçeklik, zamanımızın önemli bir kısmının mevcut sistemleri ayakta tutmaya, hataları gidermeye ve operasyonel sorunları çözmeye gittiğini gösterir. Bu, sürekli bir trade-off döngüsüdüdür.
Örneğin, GitHub Actions kotalarını aşmamak için kendi self-hosted runner’ımı kullanma kararı, bana maliyet avantajı sağladı. Ama bu avantajın bedeli, runner’ın bakımını ve güncellemelerini benim üstlenmem gerektiği anlamına geliyordu. Bu, zaman zaman runner’ın state corruption yaşaması gibi sürprizlere yol açtı. X yapardık, ama Y yüzünden Z’yi seçtik ve bunun sonuçlarına katlandık.
CVE mitigation’ları bile kendi sunucumda benim sorumluluğumda. Örneğin, algif_aead kernel modülünü blacklist’e almak gibi basit görünen bir işlem, CVE-2026-31431 gibi potansiyel güvenlik açıklarını kapatmak için şart olabiliyor. Kurumsal bir ortamda güvenlik ekiplerinin yaptığı işleri, kendi projelerimde tek başıma takip etmek zorunda kalıyorum.
Sonuç: Yorgun Ama Devam Eden Bir Yolculuk
Indie hacker olmak, romantik hayallerin ötesinde, sürekli bir öğrenme, sorun çözme ve adaptasyon yolculuğu. Evet, kendi projelerini geliştirmek ve bir şeyler yaratmak inanılmaz bir haz veriyor. Ama bu hazzın bedeli, çoğu zaman gece geç saatlerde gelen alarmlar, beklenmedik operasyonel sorunlar ve sürekli bir bakım yükü oluyor.
Bu yolda, hatasız olmak diye bir şey yok. Geçen ay sleep 360 yazıp OOM-killed olduğumu veya bir AI çıktısının saçma sapan karakterler döndürdüğünü açıkça anlatabiliyorum. Çünkü bu hatalar, beni daha dayanıklı, daha akıllı sistemler kurmaya itti. Şu sıralar, AI pipeline’ımın reliability’sini artırmak için polling-wait mekanizmalarını daha da güçlendirmeye çalışıyorum. Sizin de başınıza buna benzer olaylar geldi mi? Ya da kendi projelerinizde hangi operasyonel yüklerle mücadele ediyorsunuz? Bir sonraki yazıda belki de bu polling-wait mekanizmalarının detaylarına ineriz.