Web sitesi yayına çıktıktan sonra bakım planında neler olmalı?

Bir sabah sitenin açılması, her şeyin çalıştığını göstermeyebilir. İletişim formu e-posta göndermiyor, ödeme bildirimi işlenmiyor veya son ürün değişiklikleri yedeğe alınmıyor olabilir. Bakım planı, yalnızca ana sayfaya ara sıra bakmaktan daha geniş bir sorumluluktur.

İyi planın başlangıcı, işletmenin siteye ne kadar bağımlı olduğunu anlamaktır. Aylardır değişmeyen bir tanıtım sitesiyle sürekli sipariş alan mağazanın aynı sıklıkta ve aynı kapsamda izlenmesi gerekmez. Öncelik, kaybın iş üzerinde yaratacağı etkiye göre belirlenmelidir.

Yedeğin içinde ne var?

Dosyalar, veri tabanı, yüklenen görseller ve gerekli yapılandırmalar farklı yerlerde tutulabilir. Sadece sitenin kodunu kopyalamak müşteri taleplerini korumayabilir; yalnızca veri tabanını almak da görselleri ve belgeleri eksik bırakabilir. Hangi bileşenlerin geri dönüş için gerektiği yazılı olmalıdır.

Yedek sıklığını değişen bilgiye göre belirleyin. Gün içinde çok sayıda sipariş oluşuyorsa yalnızca gecelik kopya yeterli olmayabilir. “Ne kadar veri kaybını karşılayabiliriz?” ve “İş ne kadar süre kapalı kalabilir?” soruları, teknik planın işletmedeki karşılığını anlatır.

Yedek alınmasıyla geri yüklenebilmesi aynı şey değildir

Başarılı yedek bildirimi yararlı bir işarettir; dosyanın kullanılabilir olduğunu tek başına kanıtlamaz. Belirli aralıklarla ayrı bir ortamda geri yükleme denenmelidir. Sayfa açılıyor mu, doğru kayıtlar geliyor mu ve gerekli dosyalara ulaşılabiliyor mu?

Yedeklerin tek sunucudaki tek hesaba bağlı kalması da birlikte etkilenme riski yaratır. Erişimi kontrollü ayrı kopyalar ve uygun koruma yöntemleri değerlendirilmelidir. Yedekleme hizmetinin saklama süresiyle işletmenin geçmişe dönme ihtiyacı birbirine uygun olmalıdır.

Güncellemeyi bir işlem sırası olarak düşünün

Kullanılan yazılım ve bileşenlerin güncel sürümleri takip edilir; değişikliğin etkisi değerlendirilir. Kritik işlevleri olan sistemlerde uygun test ortamında deneme yapılır. Güncellemeden önce kullanılabilir yedek ve geri dönüş yöntemi bulunur.

Ardından yalnızca sürüm numarasının değiştiğine bakılmaz. Form, giriş, ödeme ve veri aktarımı gibi temel işler yeniden kontrol edilir. Her güncellemeyi aylarca ertelemek de bütün değişiklikleri kontrolsüzce canlı sisteme uygulamak da iyi bir bakım yöntemi değildir.

İşin bozulduğunu kim fark edecek?

Sitenin kapalı kalması, form gönderiminin başarısız olması ve yedeğin alınamaması farklı uyarılar gerektirebilir. Uyarının hangi kişiye gideceği, hangi sürede değerlendirileceği ve destek kanalının nasıl kullanılacağı belirlenmelidir.

Alan adı, barındırma ve kullanılan hizmetlerin yenileme sorumluluğu da unutulmamalıdır. Hesap erişimleri tek bir çalışanın kişisel e-postasında kalırsa basit bir yenileme işi bile sorun olabilir. Bu bilgiler proje tesliminin parçasıdır.

Bakım raporu uzun olmak zorunda değildir. Hangi kontrollerin yapıldığı, hangi sorunların bulunduğu ve hangi işlemlerin tamamlandığı görülsün. İşletme için değerli olan “bakım yapıldı” cümlesi değil, günlük işin korunması ve sorun yaşandığında izlenecek yolun hazır olmasıdır.