Tek VPS'te Production Çalıştırmanın Psikolojisi

Saat 23:47, lambayı kapattım, sonra tekrar açtım

Tipik bir gece. Yatmadan önce telefon ekranı son bir kez parlıyor. mustafaerbay.com.tr açılıyor mu kontrol ediyorum. Açıldı. RAM ne kadar? free -h çekiyorum SSH’ta. 5.6 GB available, iyi. Yatabilirim.

Sonra zihnim başka bir şeye takılıyor. “Pipeline-health monitor en son ne zaman koştu?” Telefonu yeniden açıyorum. Mail kontrolü, son 4 saatte bir state-change yok. İyi.

Sonra bir tane daha. “Acaba dün taşıdığım itoverdose container’ı bu gece build alır mı? Eğer 03:00’da disk-cleanup ile aynı pencereye düşerse ne olur?”

23:51 oldu. Hâlâ yatakta değilim, telefondayım.

Bu production paranoyası ve onunla yaşamayı öğrenmenin hikayesi.

”Tek sunucu, çoklu proje” işin içine duygusal yük katıyor

7.6 GB RAM’li bir VPS’im var. Üzerinde benim 5 yan ürünüm yaşıyor:

• mustafaerbay.com.tr (bu blog — Astro + Node + SQLite)
• gercekveri.com (Türkiye veri platformu)
• islistesi.com (görev yönetimi — web + iOS + Android)
• hesapciyiz.com (TR finansal hesaplayıcılar — farklı VPS’te ama aynı paneli takip ediyorum)
• spamkalkani.com (Android spam blocker — farklı altyapıda, ama yine aynı kontrol)

Plus müşteri projeleri için iki Next.js docker container, postgres’ler, redis’ler. Toplamda 13 container.

Hepsi paranoyak bir kararla aynı VPS’te. Çünkü:

• AWS multi-AZ “production grade” parlak laflar pahalı geldi
• Indie ölçek = bir gece kullanıcı 0, ertesi gün belki 100
• Önce çalışsın, sonra zenginleşince ayırırım

Ama iki şey öğrendim çok geçmeden:

1. “Aynı VPS” karar, kendi sınırlarımı yönetme zorunluluğu doğuruyor
2. Bu yönetim sadece teknik değil — psikolojik

Deploy korkusu nedir, neden gerçek

Geçen sabah 06:14, bir test commit’i push ettim. Anasayfada bir tipo düzeltmesi. Hızlı, ufak değişiklik, beş satır kod.

Push’tan sonraki 60 saniye tatlısız geçti. VPS’te deploy timer dakikada bir pull yapıyor. “Şu an pull ediyor mu? Build başladı mı? Build OOM eder mi?” — bunlar zihnimde fiziksel olarak dolaşıyor. Telefonda gh run list açtım, mustafaerbay-deploy.service log’una baktım.

Build başlamış. Astro build 4 dakika sürer. 4 dakika boyunca VPS RAM’i 2.5 GB civarında dans ediyor. O sırada başka bir proje deploy bandına girerse → swap fistirma. Yine sshd timeout. Yine telefon mesajı: “siteler kapandı dostum.”

Bu olay bana 3 kez yaşandı son iki haftada. Üçüncüsünde flock mutex çözümünü kurdum, ama ön deploy’lardaki sıkıntı henüz tamamen geçmedi. Hâlâ her push’tan sonra “iyi mi peki?” diyen bir küçük ses var. Bunun adı klasik anlamda anxiety değil — daha çok özen. Ama 30 push’tan sonra 31’incide aynı özen sürmüyor mu? Sürüyor.

RAM grafiği, kalp ritmi gibi izlenir

Kişisel sırrım: telefonda terminal app’im var. Klavyenin üstünde sabit bir komut: ssh vps 'free -h | head -2'. Yapıştır, enter. 1 saniye sonra cevap.

Otobüste, sahilde, akşam yemeği masasında. “available 5.6” görüp rahatlıyorum. “available 800 MB” görüp gergin oluyorum, hemen ps aux --sort=-%mem | head ile “hangi container şişiyor?” arıyorum.

Bu profesyonel paranoya başkaları için garip görünebilir. “Production’a o kadar takıntılı olma” diyenler oluyor. Ama bana göre tam tersi:

“Takıntılı olunmadığı zaman production patlar. Patladığında saatlerce uyanık kalırsın. Önceden 30 saniye bakmak, 4 saatlik incident’ten ucuza çıkar.”

Bu bilgi rasyonel. Ama hissi yanı yorucu. Sürekli ufak bir endişe ile yaşamak demek.

Gece alarmı: “şimdi reboot atsam döner mi?”

Pipeline-health monitor mailim 4 saatte bir state’i kontrol ediyor. State değişince mail atıyor. Geliştirmeyi yaptıktan sonra ilk hafta inbox’ta iki mail vardı: bir DEGRADED, bir RECOVERED. Sistem doğru çalıştı.

Ama o iki mail arasında ne yaptım?

Saat 02:47’de uyandım, telefonu açtım. DEGRADED mailini gördüm. “Patlamış mı? Hangisi? Build’lerden mi? VPS down mu?” Kalktım, dolaşmam pijamayla, dizüstüne SSH attım, log’a baktım. Sebep: dlvr.it geçici bir problem yaşamış, RSS poll edememiş, yeni post Bluesky’a düşmemiş. Önemli değildi.

Geri yatağa girince bir saat uyuyamadım. “Eğer reboot etmek gerekirse, şu container’lar yeniden start eder mi? postgres’ler WAL recovery yaparken ne kadar sürer? Müşteri 06:00’da gelir, bizim baseerp’leri açar, belki o sırada hâlâ recovering oluyorsa…”

Sonunda dakikada bir telefonu açıp curl -sI https://baseerp.../healthz çekiyorum. 200 dönüyor. Tamam. Kapatıyorum. 5 dakika sonra yine açıyorum.

Hiç gerek yoktu. Sistem çalışıyordu, reboot gereği yoktu. Ama beynim “kontrol ediyorum” döngüsünden çıkamıyordu.

Bu durumun adı vigilance fatigue sanırım. Sürekli izlemenin ruhsal yorgunluğu.

Yapmaya çalıştığım üç şey (henüz tamamen başaramadığım)

1) Otomasyon = duygusal yedek

Pipeline-health monitor, disk-cleanup.timer, kernel-update-check, flock mutex — bunların hepsi benim adıma izleyen sistemler. Doğru kurarsam ben uyurken sistem kendi kendini koruyor. “Otomasyon = endişeyi kasaya kilitleme” prensibi.

Ama bu otomasyon kurulumu kendi başına stres üretir. “Acaba pipeline-health’i her 4 saatte bir koşması doğru threshold mu? 2 saat mi yapayım?” — bu sorular hiç bitmez. Bir yere kadar git, dur, ona güven.

2) “Worst case scenario” planlaması, anxiety’yi azaltır

VPS bir gün tamamen ölse ne yaparım? Ben şu yedeklere güveniyorum:

• Postgres’ler nightly cron ile S3’e backup
• mustafaerbay SQLite’ı /var/lib/mustafaerbay/blog.db.bak olarak günlük arşiv
• Kod git’te, content collection git’te
• DNS Cloudflare’de
• VPS’i 30 dakikada başka bir provider’da yeniden ayağa kaldıracak Ansible playbook taslağım var

Bu planı kafamda yapmak worst case’i somutlaştırıyor. “Tüm sistem ölürse 30 dk recovery” bilmek, “tüm sistem yarın ölür mü?” panik’inden çok daha tahammül edilir.

3) Stoic kabul: bir gün patlayacak

Bu sistemi 5 yıl çalıştıracak olsam, istatistiksel olarak bir gün uzun bir outage olacak. Disk patlayacak, datacenter yanacak, exotic bir kernel bug çıkacak. Bunu kabul etmek özgürleştirici:

• Hedefim “hiç patlamasın” değil, “patlayınca hızlı kalkayım”
• Hedefim “asla incident gelmesin” değil, “incident sırasında doğru insanı uyarayım”

Production’da uptime istemek anlaşılır. %100 uptime istemek hastalıktır.

Pratik kişisel kurallar

Bu yazıyı kendime ders niyetiyle yazıyorum. Notlarım:

• Telefonda terminal kullanmayı iş saatleriyle sınırla. 22:00’dan sonra ssh vps 'free -h' yapma. Yapmazsan da kötü bir şey olmaz, monitor zaten haber verir.
• Pipeline-health alert haricinde inbox’a bakma mesai saatleri dışında. Mail varsa monitor doğru zamanda göstermiş olur.
• Hafta sonu push yapma. Bu en zor olan. Çünkü hafta sonu en üretken zamanım. Ama pazar günü yaptığım her ufak deploy = pazartesi sabah erken uyanma + endişe.
• VPS dışında bir hobi tut. Müzik, yürüyüş, kitap. Production’a ait olmayan saatler.

Sonuç: production = ilişki

Tek VPS’te çoklu proje çalıştırmak bana ilişki gibi geliyor artık. Hem güvensin istiyorsun hem ona güveniyorsun. Sürekli hep küçük şeylere dikkat etmen lazım, ama her detayda paranoyak olursan ne sen rahat edersin ne de o.

Bir noktada bırakma noktası öğreniyorsun. “Tamam, bu kontrol monitor’un işi. Ben uyuyacağım. Patlasa benim haberim olacak. O kadar.” Bu cümleyi söylemek 6 ay sürdü. Hâlâ söylemekle yapmak farklı.

Bu yazıyı saat 23:55’te yazdım. Az sonra telefonu açıp ssh vps 'free -h' yapacağım — bunu kabul ediyorum artık. Sadece son bir kez.

Sonra ışığı kapatacağım.

Söz.