İletişim formu başvuruları artık satış ekibine ulaştırmıyorsa ilk arayacağınız kişi kim? Siteyi yapan ajans, barındırma firması veya şirket içindeki içerik sorumlusu aynı soruna farklı yerlerden bakabilir. Web sitesi bakımında işlerin sahipsiz kalması çoğu zaman “Biz onu diğer taraf yapıyor sanıyorduk” cümlesiyle ortaya çıkar. Görevleri sorun çıkmadan bölüşmek, arızanın nedenini bulmanın da önünü açar.
Web sitesi bakımı, yayındaki sitenin yazılımını, içeriğini ve kullanıcı işlemlerini çalışır ve güncel tutmak için planlanan kontrollerle düzeltmeleri kapsar. İlk yayında ziyaretçinin sitede ne yapacağını tasarlamak gerekir; bakımda ise o işin değişikliklerden sonra da tamamlanabildiği izlenir. İşletme ile teknik ekip arasındaki sınır, kullanılan altyapıya ve anlaşmanın kapsamına göre kurulur.
1. Hesapları ve Yenilemeleri Sahipsiz Bırakmayın
Alan adı, barındırma, içerik yönetim paneli ve kullanılan ücretli lisansları tek listede toplayın. Her satıra hizmetin nerede tutulduğunu, işletme adına yetkili kişiyi, teknik erişimi olanları ve yenileme tarihini ekleyin. Parolaları ortak çalışma tablosuna yazmak yerine, erişimin güvenli biçimde nasıl devredileceğini belirleyin.
Alan adını yenileme ödemesini muhasebe yapabilir; bildirimi izleme görevi başka kişide olabilir. Yine de yenilemenin tamamlandığını kontrol edecek biri gerekir. ICANN’in alan adı yenileme önerileri, bitiş tarihini takip etmeyi ve otomatik yenilemede ödeme bilgisini güncel tutmayı vurgular. Yenileme takvimini uzantınızın ve kayıt firmanızın koşullarına göre oluşturun.
Bir çalışanın veya ajansın görevi bittiğinde hesaplara erişim de yeniden ele alınmalı. İşletmenin yetkili hesabı, kurtarma yöntemi ve yeni sorumlusu belli olmadan eski erişimleri kaldırmak işleri kilitleyebilir. Devir kaydında kimlerin yetkisinin devam edeceğini ve kimin yetkisinin kapatıldığını gösterin. Özel bir uygulamayı da devralıyorsanız yayındaki kaynak kodunu ve kurulum yetkilerini aynı toplantıda sınayın.
2. Güncellemeyi Yapacak ve Sonucunu Kontrol Edecek Kişiyi Belirleyin
“Sunucu çalışıyor” ile “sitenin bütün bileşenleri güncel” aynı kontrol değildir. Barındırma sağlayıcısı altyapıyı yönetirken içerik yönetim sistemi, tema, eklenti veya özel kod başka ekibin sorumluluğunda kalabilir. AWS’nin paylaşılan sorumluluk modeli altyapı ve uygulama sorumluluklarının hizmet türüne göre değiştiğini gösterir; kendi sağlayıcınızın kapsamını sözleşmesinden doğrulayın.
Teknik sorumlu, hangi bileşenin neden güncelleneceğini, bağımlılıklarını ve sorun yaşanırsa geri dönüş yolunu değerlendirsin. İşletme tarafı ise planlı çalışmanın hangi saatlerde başvuruları veya içerik girişini etkileyebileceğini bilsin. Her güncellemeyi topluca ertelemek de, etkisini incelemeden uygulamak da iyi bir çalışma düzeni oluşturmaz.
WordPress kullanıyorsanız resmî güncelleme açıklamasındaki yedek hazırlığıyla başlayın. Ardından değişen işlevi sınayın: menü düzenlendiyse ilgili yolları, form eklentisi değiştiyse gönderimi ve sonucu kontrol edin. Performans sorunu görülüyorsa rastgele ayar değiştirmek yerine yavaşlayan sayfayı ve kullanıcı adımını birlikte inceleyin.
Bakım kaydına yalnız “güncellendi” yazmayın. Değişen bileşen, uygulama tarihi, testi yapan kişi, gözlenen sonuç ve açık kalan iş bulunsun. Teknik işlem tamamlanmış olsa bile işletmenin doğrulaması bekleniyorsa görev henüz kapanmamıştır.
3. Yedek Almaya ve Geri Yüklemeye Ayrı Sorumluluk Verin
Yedekleme işleminin başarılı görünmesi, sitenin gerektiğinde geri açılabildiğini tek başına kanıtlamaz. Hangi verilerin kopyalandığını, kopyanın nerede tutulduğunu, ne kadar süre saklandığını ve ona kimin erişebildiğini sorun. WordPress gibi veritabanlı bir sitede yalnız dosyaları kopyalamak eksik kalabilir; WordPress yedekleme belgesi dosyalarla veritabanını ayrı parçalar olarak açıklar.
Geri yükleme kontrolünün de sahibi olsun. Teknik ekip uygun, canlıdan ayrı bir ortamda geri dönüşü deneyebilir. İşletme sorumlusu, gerekli sayfanın, görselin ve örnek kaydın kullanılabilir olduğunu doğrular. AWS’nin kurtarma testi yaklaşımı, yalnız geri yükleme işlemini başlatmayı değil, geri gelen verinin kullanılabilirliğini de sınamayı önerir.
Yedek sıklığını sitenin değişim hızına göre kararlaştırın. Ayda birkaç metin değişen tanıtım sitesiyle sürekli başvuru veya sipariş kaydeden site aynı kayıp aralığını kabul etmeyebilir. “Ne kadar yeni veriyi yeniden oluşturabiliriz?” ve “Hangi işler ne kadar süre durabilir?” sorularını işletme yanıtlasın; teknik yöntem kabul edilen kayıp ve kesinti sınırına göre seçilsin.
Eski bir yedeğe dönmek, yedekten sonra oluşan başvuruları veya içerik değişikliklerini geriye alabilir. Canlıya geri yükleme kararı verilmeden önce etkilenecek kayıtları ve onları koruma yolunu teknik sorumluyla değerlendirin. Yedek dosyasının bulunması kayıpsız dönüş garantisi değildir.
4. İçerik Doğruluğunu ve Başvuru Akışını İşletmeyle Birlikte İzleyin
Yeni hizmet bölgesini, değişen telefonu veya sona eren kampanyayı çoğunlukla işletme bilir. Teknik ekip, kendisine iletilmemiş değişikliği tahmin edemez. Bilgiyi doğrulayan kişiyle panelde yayımlayan kişi farklı olabilir; görev listesinde ikisine de yer verin. Mevcut sayfa ve içerik envanterine sorumlu ile gözden geçirme tarihini eklemek, dağınık mesajlardan daha izlenebilir bir başlangıç sağlar.
GOV.UK’nin mevcut içerik yönetimi yaklaşımı, yayımlanan bilginin düzenli değerlendirilmesini ele alır. İşletmenizde kontrol tarihini gerçek değişime bağlayın: kampanya bitişi, hizmet kapsamının değişmesi veya ekip devri gibi. Yalnız takvim hatırlatmasına güvenmeyin.
İçerik düzenleyen herkese teknik yönetici yetkisi vermek gerekmez. Örneğin WordPress’in rol ve yetkileri, içerik yayımlamayla yazılım yönetimini ayırır. Kendi sisteminizde de kişiye yapacağı iş kadar erişim tanımlayın.
Bir formu kontrol ederken ziyaretçi tarafıyla işletme tarafını birlikte düşünün. W3C’nin form bildirimleri açıklaması başarı ve hata sonucunun anlaşılır olmasını ister. Ekranda teşekkür mesajı çıkmasının yanında, izinli deneme kaydının kararlaştırılan alıcıya veya sisteme ulaştığını da doğrulayın. Gerçek müşteri bilgisi yerine deneme olduğu açık, gereksiz kişisel veri içermeyen kayıt kullanın.
5. Sorun Bildirimini ve İşi Kapatma Yetkisini Netleştirin
Başvuru formunun çalışmamasıyla bir fotoğrafın değiştirilmesi aynı aciliyette değildir. Sorunu bildiren kişi sayfa adresini, saati, yaptığı işlemi ve gördüğü sonucu iletsin. Teknik ekip nedenini araştırırken işletme hangi işin aksadığını açıklasın. Henüz kanıt yokken “sunucu bozuk” gibi teşhisleri kesin bilgi diye kaydetmeyin.
Destek kanalını, çalışma saatlerini, ilk yanıt beklentisini ve ilgili kişi ulaşılamadığında kime gidileceğini önceden konuşun. İlk yanıt, çözümün tamamlanması değildir. Dış sağlayıcının incelemesi veya ek erişim gerekiyorsa bağımlılık görünür kalsın. Sitenin her arızasının aynı sürede giderileceği varsayımıyla plan kurmayın.
Düzeltme sonunda bildirilen işlemi yeniden deneyin ve kaydı kapatacak kişiyi belirleyin. Tekrarlayan sorunlar için neden ve önleyici iş ayrı kayda dönüşebilir. Mevcut yapı gereken işi taşımıyorsa, bakım isteğini büyütmek yerine hedefli düzeltmeyle site yenilemesi arasındaki kapsamı değerlendirin.
İş Paylaşımını Kısa Bir Kayıtla Görünür Kılın
Aşağıdaki dağılım kurumsal site için temsili bir başlangıçtır. Aynı kişi birden çok görevi üstlenebilir; isim, kontrol sıklığı ve kapsam kendi anlaşmanıza göre doldurulmalıdır. “Ajans” veya “biz” yazmak yerine işi takip edecek kişiyi ya da sorumlu ekibi belirtin.
| Görev | İşi Takip Eden | Tamamlanma Kanıtı |
|---|---|---|
| Alan Adı Yenileme | İşletmenin hesap sorumlusu; ödeme tarafıyla birlikte | Yeni bitiş tarihi ve yenilemenin tamamlandığı kayıt |
| Teknik Güncelleme | Bakım ekibindeki teknik sorumlu | Sürüm, etkilenen işlev testi ve açık sorunlar |
| Yedek ve Geri Dönüş | Teknik sorumlu; veri kontrolünde işletme | Yedek kaydı yanında tarihli geri yükleme ve veri kontrolü |
| İçerik ve Başvuru | Bilgi sahibi, yayın yetkilisi ve başvuru alıcısı | Onaylı içerik, gönderim sonucu ve teslim doğrulaması |
| Arıza Takibi | Teknik inceleyen ve sonucu kabul eden kişi | Sorunun yeniden denenmesi, sonuç ve kapanış kaydı |
Her satıra bir sonraki kontrolü veya işi tetikleyecek değişikliği ekleyin. Ücret ve teslim kapsamını konuşurken de aynı listeyi kullanabilirsiniz; web sitesi teklifindeki bakım ve destek kalemlerini karşılaştırmak, listede kimin üstlenmediği işleri görmenize yardımcı olur. Kapsam dışı iş, sessizce taraflardan birine devredilmiş sayılmaz.
Web Sitenizin Bakım İşlerini Birlikte Netleştirelim
Elinizde site adresi, kullanılan hizmetler ve aksayan birkaç işlem varsa iş paylaşımını konuşmaya başlayabiliriz. Metazen’de teknik değerlendirmeyi ziyaretçinin tamamlaması gereken işle birlikte ele alıyoruz. Web geliştirme ve sunucu yönetimi deneyimi olan ekibimizle hangi kontrollerin gerektiğini, işletmenizin neleri doğrulayacağını ve bakımın nerede ek geliştirmeye dönüştüğünü değerlendirmek için web tasarım ve geliştirme hizmetimizin kapsamını inceleyebilirsiniz.
