Bir altyapının ne kadar sağlam olduğunu, her şey yolundayken anlayamazsınız. Bu yüzden test ortamındaki bir sunucu kümesini üç gün boyunca bilerek hırpaladık. Amaç kahramanlık değildi; izleme, uyarı ve kurtarma süreçlerimizin gerçekten çalıştığını görmekti.
Birinci gün: diski sonuna kadar doldurduk
Log rotasyonunu kapatıp diski yüzde yüze taşırdık. Beklediğimiz gibi web sunucusu 500 vermeye başladı, ama asıl sürpriz şuydu: veritabanı, disk dolmadan çok önce geçici tablo yazamadığı için sessizce yavaşlamıştı. Uyarı eşiğimiz yüzde 90'daydı ve bu, ilk belirtiler için geç kalıyordu.
Eşiği yüzde 80'e çektik ve disk büyüme hızına bakan ikinci bir uyarı ekledik. Doluluk oranı kadar, doluluğa ne kadar süre kaldığı da önemliymiş.
İkinci gün: ağı kopardık
Uygulama sunucusu ile veritabanı arasındaki bağlantıya önce gecikme, sonra tam kopma enjekte ettik. Uygulama kopmayı fark etti ama yeniden bağlanma denemelerini beklemeden ve arka arkaya yaptı. Sonuç, veritabanı ayağa kalktığı anda üzerine binen bağlantı fırtınası oldu.
Üstel geri çekilme (exponential backoff) eklemek, kurtarma süresini dakikalardan saniyelere indirdi. Kopmaya dayanmak yetmiyor; geri dönüşü de nazikçe yapmak gerekiyor.
Üçüncü gün: yedekten geri döndük
En öğretici kısım buydu. Veritabanını tamamen sildik ve gecelik yedekten geri yükledik. Yedek sağlamdı, süreç çalıştı, ama geri yükleme belgesindeki bir komut altı ay önceki sürüme aitti. Kriz anında değil, test sırasında fark ettiğimiz için şanslıydık.
Üç günün özeti
- Uyarılar mutlak değeri değil, değişim hızını da izlemeli.
- Yeniden bağlanma mantığı, kopmanın kendisi kadar kritik.
- Test edilmemiş yedek, yedek sayılmaz.
- Kurtarma belgeleri de kod gibi eskir; onları da tazelemek gerekir.
Bu testleri kendi projenizde denemek isterseniz izole bir ortamda başlamak en doğrusu. VDS sunucu planlarında snapshot alıp rahatça kırabileceğiniz bir kopya oluşturabilirsiniz.