Geçenlerde bu blog için ufak bir CSS değişikliği deploy ettim. Normalde basit bir şey, sadece birkaç piksel oynattım, ama git push komutunu verdikten sonra o anlamsız gerginlik yine çöktü üzerime. Sanki kritik bir banka sistemi deploy etmişim gibi, içimde bir yerlerde “acaba” sorusu dönüp durmaya başladı.
Bu hisse aşinayım, 20 yıldır her deploy sonrası yaşıyorum. Otomatikman elim tail -f /var/log/nginx/access.log komutuna gidiyor, tarayıcıda Cloudflare dashboard’unu açıp cache hit oranlarını ve hata loglarını kontrol ediyorum. Her şey yolunda gözükse bile, bir süre daha tetikte kalmaya devam ediyorum.
O “Acaba” Hissinin Semptomları
Bir deploy sonrası gelen bu gerginlik, çoğumuzun bildiği bir durum. Bazen ufak bir kramp, bazen de saatler süren hafif bir paranoya şeklinde kendini gösteriyor. Hatta bazen, gece uykudan uyanıp “acaba bir şey unuttum mu?” diye kontrol etme isteğiyle baş başa kalıyorum.
Bu süreci sadece büyük projelerde yaşamıyorum. Kendi VPS’imde, 13’ten fazla Docker container yönettiğim bir ortamda bile, basit bir konfigürasyon değişikliği sonrası bu hissi yaşıyorum. Her şey otomatize edilmiş olsa da, insan yine de bir yerde “ya bir ihtimal?” diye düşünüyor.
Geçmişin Acı Tecrübeleri ve Tetikleyiciler
Bu “acaba” hissinin kökeninde, sanırım geçmişte yaşadığımız can yakıcı tecrübeler var. O anlar, beynimize derinlemesine kazınmış ve her deploy anında tetikleniyor. Benim için bu tetikleyicilerden bazıları çok net.
Kendi VPS’imde, bu hissin en yoğununu 28 Nisan’da yaşadım. Yeni bir container deploy etmiştim ve ertesi sabah Pipeline-health monitor “DEGRADED” maili attı. Sistemin kcompactd %92 CPU ile şiştiğini gördüm; SSH bile accept edemiyordu. O anki çaresizlik ve sonrasında gelen saatler süren debug süreci, bu gerginliğin nedenini açıklıyor.
Astro build’imin 2.5 GB RAM tüketip sistemdeki 7.6 GB RAM’i zorlayarak OOM (Out Of Memory) olmasına neden olduğu anlar da var. Ya da GitHub Actions runner’da _work/_temp içindeki dizinleri silmenin acısı… Tüm bu senaryolar, sistemin beklenmedik bir şekilde tepki verebileceği gerçeğini bana defalarca gösterdi. Bu yüzden, ne kadar hazırlıklı olursam olayım, o anlamsız stres benden bir süre ayrılmıyor.
Risk ve Kontrol Dengesi
Bu durum, aslında risk yönetimi ve kontrol ihtiyacının bir yansıması. Geliştirdiğimiz ya da yönettiğimiz sistemlerin canlıya çıktığında ne gibi sonuçlar doğurabileceği belirsizliği, bizleri bu stresle yüzleştiriyor. Her ne kadar sağlam testler, otomasyonlar ve izleme araçları kullansak da, “production” ortamının kendine has sürprizleri her zaman mevcut.
Bu dengeyi kurmak, yani hızlı deploy yapma isteği ile risksiz deploy hedefi arasında bir yol bulmak, çoğu zaman zorlayıcı oluyor. Bazen hız kazanmak için bazı kontrollerden feragat ettiğimiz oluyor, bunun da bedelini sonradan ödeyebiliyoruz. Öte yandan, her şeyi mükemmel hale getirmeye çalışmak da süreci yavaşlatıyor.
Benim Baş Etme Yöntemlerim
Yıllar içinde bu stresle başa çıkmak için kendi yöntemlerimi geliştirdim. Tamamen ortadan kalkmasa da, etkisini azaltmayı başardım. Bu yöntemlerin başında otomasyon ve kapsamlı izleme geliyor.
GitHub Actions ile otomatik deploy süreçleri kurdum. Her değişiklik testlerden geçtikten sonra otomatik olarak canlıya alınıyor. Prometheus ve Grafana ile sistemin her köşesini izliyor, Alertmanager ile anormalliklerde anında bildirim alıyorum. Pipeline reliability için özel olarak preflight resource guard’lar koydum; bir deploy öncesi sistem kaynaklarının yeterli olup olmadığını kontrol ediyor.
Geri dönüş mekanizmaları benim için hayati önem taşıyor. Bir deploy’un sorunlu olduğu anlaşıldığında, tek bir komutla önceki stabil sürüme dönebilmeliyim. Bu güven hissi, o ilk stres anını biraz olsun hafifletiyor. Ayrıca, hata yapmaktan utanmıyorum. Geçen ay sleep 360 yazıp OOM-killed olduğumda, “bu da bir dersti” dedim ve polling-wait mekanizmasına geçtim. Kendi yarattığım sorunlardan ders çıkarmak, bir sonraki deploy’da daha dikkatli olmamı sağlıyor.
”Olur O Kadar” Felsefesi ve Kabul
Sonuçta, bu işin doğasında bir miktar risk ve belirsizlik var. Mükemmel sistem diye bir şey yok, her zaman bir açık, bir bug ya da beklenmedik bir etkileşim olabilir. Bu gerçeği kabul etmek, “olur o kadar” felsefesini benimsemek, üzerimdeki baskıyı azaltıyor.
Elbette, bu bir rehavet hali değil. Aksine, beni sürekli daha iyi, daha dayanıklı ve daha güvenli sistemler inşa etmeye itiyor. CVE mitigation kapsamında kernel module blacklist’i (algif_aead, CVE-2026-31431 gibi) yaptığım anlar da oluyor; bu da işin parçası. Her hatadan, her problemden bir ders çıkarıp bir sonraki deploy’a daha hazırlıklı girmeyi öğreniyorum.
Bu sürekli tetikte olma hali, sanırım mesleğin bir parçası haline geldi benim için. Belki de bu durum, bizi daha iyi sistemler kurmaya iten bir motivasyon kaynağıdır. Kusursuzluğa ulaşma çabası değil, sürekli iyileştirme ve öğrenme döngüsü.
Senin de deploy sonrası benzer deneyimlerin var mı? O “acaba” hissiyle nasıl başa çıkıyorsun? Deploy sonrası ilk yaptığın şey ne oluyor? Yorumlarda paylaşabilirsen sevinirim, belki birbirimizden öğreneceğimiz şeyler vardır.