Web Sitesi Bakım, Güvenlik Güncelleme ve Teknik Destek

Web sitesi bakımı arıza beklemek değildir

Bir site yayınlandıktan sonra kodu sabit kalsa bile sunucu, PHP sürümü, kütüphaneler, SSL, tarayıcılar ve harici servisler değişmeye devam eder. İçerik eklenir, kullanıcı hesapları açılır, formlar kötüye kullanılabilir ve yedekler fark edilmeden bozulabilir. Bakım hizmeti yalnızca hata çıktığında müdahale etmek yerine bu değişimleri planlı kontrollerle yönetir.

Teknik destek ile yeni geliştirme birbirinden ayrılmalıdır. Mevcut işlevin bozulması, güvenlik güncellemesi ve küçük içerik desteği bakım kapsamında değerlendirilebilir; yeni modül, tasarım değişikliği veya entegrasyon ise ayrıca analiz edilir. Bu ayrım talep önceliğini ve hizmet süresini daha öngörülebilir kılar.

İlk adım teknik varlık ve erişim envanteridir

Alan adı kayıt firması, DNS, hosting veya sunucu, kaynak kod deposu, veritabanı, SSL, e-posta gönderim servisi, zamanlanmış görevler, üçüncü taraf API’ler ve yönetici hesapları kaydedilir. Her varlığın sahibi, yenileme tarihi ve erişim yöntemi belirlenir. İşletme adına açılması gereken hesapların kişisel geliştirici hesabında kalması önlenir.

Başka ekipten devralınan projede kod kalitesi görülmeden sabit müdahale süresi veya tam uyumluluk sözü verilmez. Çalışma ortamı, bağımlılıklar, lisanslar, mevcut hatalar ve kritik işlevler kısa bir devralma incelemesiyle belirlenir. Eski altyapının kapsamlı yenilenmesi gerekiyorsa PHP uygulama modernizasyonu bakım işlerinden ayrı planlanır.

Güncelleme öncesi etki ve geri dönüş planı

“Güncelle” düğmesine basmak güvenli bir bakım süreci değildir. Değişen bileşenin sürüm notları, çalışma ortamı ve diğer bağımlılıklarla uyumu incelenir. Önce yedek alınır, mümkünse test ortamında güncellenir ve kritik kullanıcı senaryoları çalıştırılır. Canlıya geçiş zamanı, sorumlu kişi ve geri alma ölçütü kaydedilir.

1. Mevcut sürüm ve bağımlılık envanteri çıkarılır.
2. Değişiklik notları ile bilinen uyumsuzluklar incelenir.
3. Dosya ve veritabanı yedeğinin bütünlüğü kontrol edilir.
4. Test ortamında güncelleme ve temel regresyon senaryoları uygulanır.
5. Canlı değişiklik düşük riskli zaman aralığında yapılır.
6. Sonuçlar izlenir; eşik aşılırsa belgelenmiş geri dönüş uygulanır.

Yedek ancak geri yüklenebiliyorsa değerlidir

Yedek planı dosya, veritabanı ve gerekli yapılandırmaları kapsamalıdır. Sıklık, işletmenin kabul edebileceği veri kaybına göre belirlenir; yoğun işlem yapan sistemle ayda bir güncellenen kurumsal site aynı plana ihtiyaç duymaz. Yedekler üretim sunucusuyla aynı tek diskte tutulursa sunucu kaybında birlikte kaybolabilir.

Düzenli geri yükleme denemesi; arşivin açıldığını, veritabanının içe aktarılabildiğini, gerekli anahtar ve dosyaların mevcut olduğunu doğrular. Saklama süresi, şifreleme, erişim ve silme politikası kişisel veri içeriğiyle uyumlu olmalıdır. Geri dönüş süresi vaat edilmeden önce gerçek bir prova yapılır.

İzleme uyarı üretmeli, uyarı da iş akışına bağlanmalıdır

Çalışma süresi, HTTP hataları, disk doluluğu, SSL bitişi, yedek görevi, form gönderimi ve kritik zamanlanmış işler proje türüne göre izlenebilir. Her metriği toplamak yerine kullanıcıyı veya veriyi etkileyen sinyaller seçilir. Uyarının kime, hangi kanaldan ve hangi önem düzeyiyle gideceği belirlenmezse bildirim kalabalığı oluşur.

Tek bir kısa kesinti ile sürekli tekrarlayan hata farklı müdahale gerektirir. Uyarı mesajı etkilenen bileşeni, zamanı ve ilk kontrol adımını içermelidir. Hassas veri veya erişim anahtarı bildirim metnine eklenmez. Olay sona erdiğinde yalnızca alarmı kapatmak yerine kök neden ve tekrar önleme işi kaydedilir.

Temel güvenlik bakımı hangi alanları kapsar?

• Desteklenen yazılım ve bağımlılık sürümlerine geçiş planı,
• Yönetici hesapları, gereksiz kullanıcılar ve en az ayrıcalık kontrolü,
• Güvenli oturum, parola ve gerektiğinde çok faktörlü doğrulama düzeni,
• Formlarda sunucu doğrulaması, spam ve kaba kuvvet azaltma önlemleri,
• Dosya yükleme, dizin izinleri ve herkese açık yapılandırma kontrolleri,
• Loglarda anormal hata, yetki reddi ve kritik işlem incelemesi.

Bu kontroller sitenin saldırıya uğramayacağını garanti etmez. Amaç bilinen riskleri azaltmak, güncelleme süresini kısaltmak ve olay olduğunda güvenilir kayıtlarla müdahale etmektir. Bağımsız sızma testi veya mevzuat uygunluğu gerekiyorsa yetkin uzmanlık ayrıca kapsamlandırılmalıdır.

Destek talepleri nasıl sınıflandırılır?

Talep kaydında ekran görüntüsü kadar URL, kullanıcı rolü, zaman, beklenen sonuç ve tekrar adımı bulunmalıdır. Parola veya hassas müşteri verisi e-posta ve mesajla paylaşılmaz.

Bakım periyodu site türüne göre belirlenir

Kurumsal tanıtım sitesi, yoğun e-ticaret ve iş süreçlerini yürüten özel uygulama aynı bakım aralığına ihtiyaç duymaz. Değişiklik sıklığı, veri kritikliği, kullanıcı sayısı, entegrasyonlar ve kabul edilebilir kesinti değerlendirilir. Günlük otomatik kontroller, haftalık gözden geçirme ve aylık rapor gibi katmanlar projenin riskine göre seçilir.

İçerik ekibinin yaptığı yayınlar da kalite sürecine dâhildir. Büyük görsel yükleme, yanlış bağlantı, başlık düzeni veya form hedefi gibi sorunlar kod güncellemesi olmadan ortaya çıkabilir. bakım ve güncelleme planı rehberi, teknik ve editoryal sorumlulukları aynı tabloda düzenlemeye yardımcı olur.

Bakım hizmetinin ölçülebilir teslimleri

Her dönem yapılan değişiklikler, açık riskler, yedek ve izleme durumu, çözülen talepler ve ertelenen geliştirmeler anlaşılır bir kayıtla paylaşılır. Müdahale süresi ile sorunun çözülme süresi aynı değildir; harici servis veya donanım bağımlılığı varsa bu ayrım belirtilir. Destek saatleri, öncelik tanımları ve iletişim kanalı sözleşmede görünür olmalıdır.

Başlangıç için mevcut teknoloji, hosting bilgisi, yönetici erişimleri, sık yaşanan sorunlar, kritik formlar ve kabul edilebilir kesinti paylaşılmalıdır. Kapsamlı bir sunucu değişikliği gerekiyorsa hosting ve alan adı taşıma ayrı geçiş planıyla yürütülür. İyi bakım, hataları görünmez kılmak değil; değişiklikleri geri alınabilir, ölçülebilir ve sahipli hâle getirmektir.