Kendi Kendime Yaptığım Bir Hata
Kariyerimin en pahalı hatası bir kod satırı değildi; gece 3’te “Tamamdır, bu iş bitti.” diyerek bir tuşa basmaktı. Yıllarca sistem yönetimi, network altyapıları ve kurumsal yazılım geliştirmede edindiğim tecrübeye güvenerek yaptığım bu basit hata, bana sistem mimarisinin sadece karmaşık teknolojilerden ibaret olmadığını, aynı zamanda insan faktörünü ve anlık kararların önemini bir kez daha hatırlattı.
Bu yazıda, kendi sanal özel sunucumda (VPS) yaşadığım bir arıza hikayesini anlatacağım. Amacım, teknik detaylara boğulmadan, bir sistem mimarı olarak pragmatik yaklaşımımı ve bu tür durumlarla nasıl başa çıktığımı paylaşmak. Unutmayın, en büyük dersler bazen en basit hatalardan çıkar.
O Gece Neler Oldu?
Saatler gece yarısını geçmişti, ben de kendi projelerimden biri için kurduğum VPS üzerinde bazı optimizasyonlar yapıyordum. PostgreSQL veritabanımda WAL (Write-Ahead Log) dosya boyutlarının beklenenin üzerinde arttığını fark etmiştim. Bu durum, disk alanının hızla dolmasına ve potansiyel olarak performans sorunlarına yol açabilirdi.
İlk aklıma gelen, wal_level parametresini düşürmek ve archive_mode’u kapatmaktı. Hızlı bir pg_ctl restart ile değişiklikleri uygulamaya koydum. Normalde bu tür basit ayarlamalar sorunsuz çalışırdı, ama o gece farklı bir şey oldu. Sunucu yeniden başlatıldıktan kısa bir süre sonra, temel servislerim çalışmamaya başladı. Nginx erişilemez hale geldi, uygulamalarım hata vermeye başladı.
Hızlı Bir Değerlendirme: Ne Yanlış Gitti?
Panik yoktu, sadece bir anlık hayal kırıklığı. Yılların alışkanlığı bana sakin kalmayı öğretmişti. Hemen sunucunun log dosyalarına yöneldim. journald’in çıktıları, systemd servislerinin neden başlatılamadığını gösteriyordu. Temel sebep, PostgreSQL’in sağlıklı bir şekilde yeniden başlatılamamasıydı. Yaptığım değişiklikler, veritabanı tutarlılığına ters düşmüş ve servislerin ayağa kalkmasını engellemişti.
Özellikle archive_mode’u kapatmak, PostgreSQL’in WAL dosyalarını temizlemesini engellemiş ve disk alanını hızla tüketmeye devam etmesine neden olmuştu. Bu da diğer servislerin çalışması için gerekli disk alanının kalmamasına yol açtı. Kısacası, daha fazla disk alanı açmak isterken, tam tersi bir etki yaratmıştım.
Çözüm ve Çıkartılan Dersler
Durumu kontrol altına almak için sunucuya SSH ile bağlandım ve PostgreSQL işlemini manuel olarak sonlandırdım. Ardından, archive_mode ayarını geri on yaparak ve wal_level’ı varsayılana döndürerek veritabanını yeniden başlattım. Bu adımlar, veritabanının sağlıklı bir şekilde ayağa kalkmasını sağladı ve diğer servislerin de normale dönmesine olanak tanıdı.
Bu olaydan çıkardığım en önemli derslerden biri, “basit” görünen değişikliklerin bile sistemin genelinde beklenmedik etkilere yol açabileceğidir. Özellikle veritabanı gibi kritik sistemlerde yapılan ayarlamalarda, değişikliklerin tutarlılığını ve olası yan etkilerini daha dikkatli değerlendirmek gerekiyor. Ayrıca, sadece hata mesajlarına değil, sistemin genel durumuna ve kaynak kullanımlarına (disk, CPU, RAM) da odaklanmak gerekiyor.
Pragmatik Bir Yaklaşım
Bu tür durumlar için her zaman bir geri dönüş planım (rollback plan) olmuştur. Ancak bu sefer, değişikliklerin ne kadar hızlı ve öngörülemeyen sonuçlar doğurabileceğini bizzat deneyimlemiş oldum. Sistem mimarisinde “yapılamaz” diye bir şey yoktur, ancak her seçimin bir trade-off’u vardır. Bu olayda, hızlı bir çözüm arayışıyla daha uzun vadeli potansiyel sorunları göz ardı etmiştim.
Teknoloji sürekli gelişiyor ve biz de bu gelişim içinde sürekli öğreniyoruz. Kendi projelerimde bile, “bu kadar tecrübeyle hata yapmam” dememek gerekiyor. Her zaman, her koşulda öğrenmeye ve sistemi daha iyi anlamaya açık olmak, bir sistemci için en önemli özelliktir.
Senin de benzer bir “gece yarısı krizi” yaşadığın oldu mu? Ya da bir sistem değişikliği yaparken en çok nelere dikkat edersin? Yorumlarda paylaşarak bu sohbeti derinleştirebiliriz.