Güncellemeyi ertelemek para biriktirmek değil, faiz ödemektir. Altı ay atlanan sürümler bir gün tek seferde uygulanmak zorunda kalır ve o gün mutlaka bir şey kırılır. Çözüm, güncellemeyi "vakit bulunca yapılan iş" olmaktan çıkarıp takvimi, sorumlusu ve geri dönüş planı belli bir politikaya bağlamaktır.
Erteleme neden bu kadar pahalıya patlar?
Üç mekanizma çalışır. Birincisi, bir güvenlik açığı yayınlandığı anda otomatik tarama botlarının hedef listesine girer; saldırgan sizi tanımıyor, kullandığınız sürümü tanıyor. İkincisi, aradaki her sürüm veritabanı şemasına kolon eklemiş, dosya yapısını değiştirmiş ya da PHP uyumluluğunu güncellemiş olabilir; on iki sürüm birikince bunların hepsi aynı anda üstünüze gelir. Üçüncüsü, hosting firmanız sunucuyu yenilediğinde PHP sürümü de yükselir ve hazırlıksız kod beyaz ekran verir.
Bir sürüm geride kalmak bakımdır; on sürüm geride kalmak artık bir projedir ve teklif ister.
Güncelleme türlerini ayırın, hepsine aynı davranmayın
Her güncelleme aynı aciliyette değildir. Politikanın ilk adımı bu ayrımı yapmaktır, çünkü "hepsi kritik" demek pratikte "hiçbiri planlanmıyor" demeye çıkar. Aşağıdaki tablo bir başlangıç şablonudur; süreleri kendi ekibinizin kapasitesine göre yazın.
| Tür | Ne zaman uygulanır | Test derinliği | Onay |
|---|---|---|---|
| Güvenlik yaması | 24-72 saat içinde | Kritik akışlar (giriş, ödeme, form) | Teknik sorumlu tek başına |
| Hata düzeltmesi | 2 hafta içinde | İlgili modül + hızlı duman testi | Teknik sorumlu |
| Özellik sürümü | Aylık pencerede | Test kurulumunda tam senaryo | İşletme sahibi/müdür |
| Altyapı (PHP, MySQL, sunucu) | Planlı, 3-6 ayda bir | Test kurulumunda kopya veriyle | İşletme + hosting sağlayıcı |
Politikayı yazıya dökün: altı satırlık bir belge yeter
Karmaşık bir doküman gerekmiyor. Şu altı başlığı tek sayfada netleştirin ve panoya asın:
- Sorumlu: güncellemeyi kim yapar, o kişi izindeyken kim yapar? İsim yazın, unvan değil.
- Takvim: sabit bir pencere seçin. Tipik olarak salı veya çarşamba sabahı iyidir; cuma akşamı en kötü seçimdir, çünkü sorun çıkarsa iki gün kimse müdahale edemez.
- Yedek kuralı: güncellemeden önce dosya + veritabanı yedeği alınır ve yedeğin açıldığı test edilir. Açılmayan yedek yedek değildir.
- Geri dönüş süresi: "15 dakika içinde eski sürüme dönemezsek bakım moduna alırız" gibi net bir eşik koyun.
- Duyuru: müşteri etkilenecekse kısa bilgilendirme, ekip için tek satır bildirim.
- Kayıt: hangi sürümden hangi sürüme, ne zaman, kim tarafından geçildiği tek bir tabloya işlenir.
Güvenli güncelleme prosedürü
Aşağıdaki sıra, paylaşımlı hosting/cPanel gerçekliğinde çalışacak biçimde hazırlandı. Küçük bir kurumsal sitede yarım saat, ödeme ve entegrasyon barındıran bir e-ticarette birkaç saat sürebilir; süreyi kendi kurulumunuzda bir kez ölçüp politikaya yazın.
- Sürüm notlarını okuyun. Özellikle "kırıcı değişiklik", "veritabanı güncellemesi" ve minimum PHP sürümü satırlarını arayın.
- PHP sürümünüzü kontrol edin. cPanel'de MultiPHP üzerinden görebilirsiniz; yeni sürüm daha yüksek bir sürüm istiyorsa önce onu planlayın.
- Tam yedek alın: public_html dosyaları ve veritabanı dökümü. Yedeği kendi bilgisayarınıza da indirin; sunucudaki yedek sunucu çökerse işe yaramaz.
- Yedeği bir test alt alan adında ayağa kaldırın ve güncellemeyi önce orada uygulayın.
- Test kurulumunda kritik akışları elle deneyin: giriş, sipariş/rezervasyon oluşturma, ödeme adımı, e-posta gönderimi, fatura veya PDF çıktısı.
- Canlıda düşük trafikli bir saat seçin ve bakım modunu açın.
- Güncellemeyi uygulayın, veritabanı güncelleme adımını atlamayın.
- Bakım modunu kapattıktan sonra aynı kritik akışları canlıda tekrarlayın, gerçek bir küçük sipariş verip iptal edin.
- 24 saat boyunca hata kayıtlarını ve e-posta gönderim kayıtlarını izleyin. Sorunlar çoğu zaman ilk gün değil, ilk gece çalışan cron görevinde ortaya çıkar.
Değiştirilmiş kod varsa
Hazır bir script üzerinde özel değişiklik yaptıysanız, güncelleme bu değişiklikleri ezer. Yapılacak iş bellidir: değişiklikleri ayrı dosyalarda toplayın, listesini yazılı tutun ve her güncellemeden sonra bu listeyi tek tek doğrulayın. "Nerede ne değiştirdiğimizi hatırlarız" cümlesi altı ay sonra geçerliliğini yitirir.
Geri dönüş adımları
Geri dönüş, panik anında hatırlanacak bir şey değil, önceden yazılmış dört satırdır: bakım modunu aç, güncellenmiş dosyaları sil ve yedekteki dosyaları geri kopyala, veritabanı dökümünü geri yükle, önbelleği temizleyip kritik akışları dene. Bu dört adımı bir kez prova edin ve kaç dakika sürdüğünü not edin; politikadaki geri dönüş eşiğini o ölçüme göre belirleyin.
Hızlı kontrol listesi
- Güncelleme öncesi yedek alındı mı ve açılabildiği test edildi mi?
- Test kurulumunda denendi mi?
- Ödeme, e-posta ve fatura akışları güncelleme sonrası doğrulandı mı?
- Geri dönüş adımları yazılı mı ve kaç dakika sürdüğü biliniyor mu?
- Sürüm kaydı tabloya işlendi mi?
- SSL sertifikası, cron görevleri ve API anahtarları güncelleme sonrası hâlâ çalışıyor mu?
- Eklentiler, temalar ve varsa entegrasyon tarafı da aynı turda gözden geçirildi mi?
Sık yapılan hatalar
- Cuma akşamı güncelleme yapmak. Hafta sonu destek yoksa risk ikiye katlanır.
- Yedeği yalnızca aynı sunucuda tutmak.
- Eklenti ve temaları unutmak. Ana yazılım güncel, eklenti iki yıllık ise açık kapı yine eklentidir.
- Güncelleme sonrası önbelleği temizlememek; kullanıcı eski varlık dosyalarını görüp "site bozuldu" der.
- Test kurulumunu canlı veritabanına bağlamak. Test siparişi gerçek müşteriye e-posta gönderirse iş büyür.
- Test kurulumunu arama motorlarına açık bırakmak; kopya içeriğin ve yanlış adresin indekslenmemesi için robots kuralı ve şifre koruması şart.
- Panel kullanıcı şifrelerini yıllardır değiştirmemek. Güncelleme penceresi bunun için iyi bir hatırlatıcıdır.
Uygulanabilir özet
- Takvimde sabit bir güncelleme penceresi açın ve sorumlunun adını yazın.
- Güvenlik yamaları için 72 saatlik bir taahhüt belirleyin; diğer türleri aylık pencereye yığın.
- Bir test alt alan adı kurun; maliyeti düşüktür ve önleyeceği tek bir kesintiden ucuza gelir.
- Her güncellemeyi tek satırla kayda geçirin: tarih, eski sürüm, yeni sürüm, yapan kişi, sonuç.
- Yılda en az iki kez yedekten gerçek geri yükleme provası yapın; prova edilmemiş plan plan sayılmaz.
