Site çöktü. Panik hâlinde her şeyi aynı anda düzeltmeye çalışmak, en uzun kesintiyi üreten yaklaşımdır. Doğru sıra, toparlanma süresini yarıya indirir.
Bu yazı, kesinti sonrası kurtarma önceliklendirmesini ele alıyor.
İlk On Dakikada Yapılmayacaklar
Refleksle yapılan ve durumu kötüleştiren hamleler:
- Hemen yedekten geri dönmek. Sorun anlaşılmadan.
- Birden fazla değişikliği aynı anda yapmak.
- Günlükleri okumadan tahmin yürütmek.
- Servisleri rastgele yeniden başlatmak.
Birinci madde en pahalı hatadır: sorunun nedeni anlaşılmadan yedekten dönmek, o günkü tüm veriyi silerken sorunu da çözmeyebilir — çünkü sorun yedeğin içinde de olabilir.
İkinci madde ise nedeni bulunamaz hâle getirir. Aynı anda üç şey değiştirildiğinde, düzeldiyse hangisinin işe yaradığı bilinemez.
Dördüncü madde geçici bir rahatlama verir ve asıl nedeni gizler. Yeniden başlatma ile düzelen bir sorun, birkaç saat sonra geri gelir.
Önce Kapsamı Belirlemek
Müdahaleden önce sorulacak sorular:
| Soru | Neyi ayırır |
|---|---|
| Tüm site mi, bir bölüm mü? | Altyapı / uygulama |
| Herkes için mi, bazıları için mi? | Sunucu / ağ / önbellek |
| Ne zaman başladı? | Değişiklikle ilişki |
| O sırada ne değişti? | Muhtemel neden |
| Hata mesajı ne diyor? | Katman |
Dördüncü satır vakaların büyük kısmını tek başına çözer: kesintilerin çoğu kendiliğinden olmaz, bir değişikliğin ardından gelir — eklenti güncellemesi, kod yayını, ayar değişikliği veya sertifika yenilemesi.
"Son 24 saatte ne değişti?" sorusuna verilecek dürüst bir yanıt, saatlerce sürecek aramayı kısaltır.
İkinci satır ise önbellek sorunlarını ayırt eder. Sadece bazı kullanıcılar etkileniyorsa, sorun büyük ihtimalle önbellek katmanında veya bölgesel bir ağ sorunundadır.
Kurtarma Önceliği
Her şeyi aynı anda kaldıramazsınız. Sıralama şöyle olmalıdır:
- Veri bütünlüğü. Kayıp veya bozulma sürüyor mu?
- Para akışı. Ödeme ve sipariş süreçleri.
- Ana kullanıcı yolculuğu. Sitenin temel işlevi.
- İletişim kanalları. E-posta ve form.
- İkincil özellikler. Arama, öneriler, raporlar.
- Yönetim paneli.
Birinci madde her şeyin önündedir: veri bozulması devam ediyorsa siteyi ayağa kaldırmak zararı büyütür — önce yazma işlemleri durdurulmalıdır.
Bu durumda doğru hamle, siteyi salt okunur veya bakım moduna almaktır. Kullanıcı sayfayı göremez ama veri de bozulmaz.
İkinci madde mali kaybı sınırlar. Ödeme akışı yarım kalmış işlemler üretiyorsa, bu işlemler daha sonra elle düzeltilmek zorunda kalır.
Altıncı maddenin en sonda olması şaşırtıcı gelebilir ama doğrudur — yönetim paneli çalışmasa da site ziyaretçiye hizmet verebilir.
Bakım Modunu Doğru Kullanmak
Bakım modu, kurtarma sırasında en değerli araçtır:
- Kullanıcıya durumu anlatır. Boş hata sayfası yerine.
- Yarım işlem üretilmesini engeller.
- Yükü keser. Onarım için nefes alanı sağlar.
- Doğru durum kodu döndürür. Arama motoru için.
Dördüncü madde arama sıralamasını korur: bakım modunda 503 döndürmek, arama motoruna "geçici, sonra tekrar gel" der; 404 veya 200 döndürmek ise sayfanın kaybolduğu ya da içeriğinin bu olduğu anlamına gelir.
Uzun bir kesinti sırasında yanlış durum kodu, sıralama kaybına yol açabilir.
Birinci madde ise itibarı korur. "Kısa bir bakım yapıyoruz, birazdan döneceğiz" mesajı, tarayıcı hata sayfasından çok daha iyi karşılanır.
Kısmi Hizmet Vermek
Her şey çalışmıyorsa, bir kısmı çalışsın:
| Bozuk olan | Kısmi çözüm |
|---|---|
| Ödeme sağlayıcı | Sipariş al, ödemeyi sonra tamamla |
| Arama işlevi | Kategori listelerini göster |
| Öneri motoru | Sabit liste göster |
| Görsel sunucusu | Yer tutucu görsel kullan |
| Veritabanı yazma | Salt okunur mod |
Bu tablonun mantığı şudur: bir bileşenin bozulması tüm sitenin çökmesine yol açmamalıdır — ikincil bir servis yanıt vermediğinde uygulama onsuz devam edebilmelidir.
Bu davranış kesinti anında değil, tasarım aşamasında kurulur. Her dış çağrının bir zaman aşımı ve bir yedek davranışı olmalıdır.
Beşinci satır özellikle değerlidir. İçerik siteleri salt okunur modda neredeyse tam işlevle çalışır.
Kesinti Sırasında İletişim
Teknik onarım kadar önemli olan taraf:
- Erken haber verin. Kullanıcı sormadan.
- Ne bilmediğinizi de söyleyin.
- Düzenli güncelleme yapın. Gelişme olmasa bile.
- Site dışında bir kanal kullanın.
- Bitince kapanış mesajı verin.
Dördüncü madde çok sık atlanır: kesinti duyurusunu çöken sitenin üzerinde yayımlamak işe yaramaz — duyuru için sosyal medya veya ayrı bir durum sayfası gerekir.
Üçüncü madde ise güveni korur. "Hâlâ üzerinde çalışıyoruz" mesajı, sessizlikten çok daha iyidir; sessizlik terk edilmişlik hissi verir.
İkinci madde beklenti yönetir. Tahmini süre veremiyorsanız bunu söylemek, yanlış bir süre vermekten iyidir.
Düzeldiğini Doğrulamak
"Çalışıyor gibi görünüyor" yeterli değildir:
- Ana sayfa değil, gerçek bir işlem deneyin.
- Farklı bir ağdan test edin.
- Giriş yapmış ve yapmamış olarak deneyin.
- Hata günlüklerine bakın. Sessiz hata var mı?
- Arka plan işlerini kontrol edin.
Beşinci madde en çok gözden kaçandır: site düzelse bile kesinti sırasında çalışamayan zamanlanmış görevler birikmiş olabilir — e-posta kuyruğu, sipariş işleme veya veri eşitleme geride kalmıştır.
Bu birikmiş işlerin nasıl ele alınacağı ayrı bir karardır. Hepsini birden çalıştırmak yeni bir yük dalgası üretebilir.
Birinci madde ise yüzeysel doğrulamayı engeller. Ana sayfa açılıyor diye ödeme akışının çalıştığı varsayılamaz.
Kurtarma sırasında panele hızlı erişebilmek büyük fark yaratır; Linux hosting hizmetleri tarafında hata günlükleri ve dosya yöneticisi panelden doğrudan ulaşılabilir durumdadır.
Kesinti Sonrası
Site döndükten sonra yapılacaklar:
| İş | Zamanlama |
|---|---|
| Zaman çizelgesini yazın | Aynı gün |
| Etkilenen veriyi tespit edin | Aynı gün |
| Geçici çözümleri kalıcıya çevirin | Birkaç gün içinde |
| Kök nedeni araştırın | Bir hafta içinde |
| Önleyici değişikliği yapın | Planlanmış |
Üçüncü satır uzun vadeli borç üretir: kesinti sırasında konulan geçici yamalar unutulur ve bir sonraki sorunun kaynağı olur — bunları listelemek ve kalıcı çözüme çevirmek gerekir.
Birinci satır ise hafızayı korur. Olay tazeyken yazılan zaman çizelgesi, bir hafta sonra hatırlanamaz.
İkinci satır müşteri ilişkisi için kritiktir. Kesinti sırasında kaybolan sipariş veya form gönderimi varsa, bunları bulup ilgilenmek gerekir.
Önceden Hazırlanmak
Kesinti anında yazılamayacak, önceden hazırlanması gerekenler:
- Erişim bilgilerinin site dışında bir kopyası.
- Bakım modu sayfası. Hazır beklesin.
- Kimin neyi yapabileceği listesi.
- Sağlayıcı destek iletişim bilgileri.
- Basit bir kontrol listesi.
Birinci madde çok yaşanmış bir kilitlenmeyi önler: hosting paneli şifresi sadece çöken sitedeki bir dosyada saklanıyorsa, kesinti anında ona ulaşamazsınız.
Beşinci madde ise panik anında düşünmeyi gereksiz kılar. Baskı altında sıralı düşünmek zordur; önceden yazılmış beş maddelik bir liste bunu üstlenir.
Sonuç
Kesintide en pahalı refleks, sorunun nedeni anlaşılmadan yedekten dönmektir — o günkü veriyi silerken sorunu çözmeyebilir. Önce kapsamı belirleyin; "son 24 saatte ne değişti?" sorusu vakaların çoğunu tek başına çözer. Kurtarma sırası veri bütünlüğü, para akışı, ana kullanıcı yolculuğu şeklinde olmalı; yönetim paneli en sonda. Bakım modunda 503 döndürmeyi unutmayın ve duyuruyu çöken sitenin dışında bir kanalda yapın.
Sıkça Sorulan Sorular (SSS)
Hemen yedekten dönmeli miyim?
Hayır, önce nedeni anlayın. Sorun anlaşılmadan yedekten dönmek o günkü tüm veriyi silerken sorunu da çözmeyebilir — çünkü sorun yedeğin içinde de olabilir. Ayrıca aynı anda birden fazla değişiklik yapmayın; düzeldiğinde hangisinin işe yaradığını bilemezsiniz.
Bakım modunda hangi durum kodu dönmeli?
503. Bu kod arama motoruna "geçici, sonra tekrar gel" der. 404 döndürmek sayfanın kaybolduğu, 200 döndürmek ise sayfanın içeriğinin bakım mesajı olduğu anlamına gelir — uzun kesintilerde ikisi de sıralama kaybına yol açabilir.
Neyi önce ayağa kaldırmalıyım?
Sıra şudur: veri bütünlüğü, para akışı, ana kullanıcı yolculuğu, iletişim kanalları, ikincil özellikler, yönetim paneli. Veri bozulması sürüyorsa siteyi açmak zararı büyütür — önce yazma işlemlerini durdurun, salt okunur veya bakım moduna alın.
Site döndükten sonra ilk iş ne?
Zaman çizelgesini aynı gün yazın ve etkilenen veriyi tespit edin. Ayrıca kesinti sırasında çalışamayan zamanlanmış görevleri kontrol edin — e-posta kuyruğu veya sipariş işleme birikmiş olabilir ve hepsini birden çalıştırmak yeni bir yük dalgası üretir.
