Kurumsal Web Sitesi Teknik Altyapısı Nasıl Planlanmalı?

Kurumsal web sitesi yalnız tasarım ve içerikten oluşmaz. Hosting, CMS, güvenlik, performans, entegrasyon, deployment ve monitoring kararları sitenin sürdürülebilirliğini doğrudan etkiler.

Teknik altyapı planlanırken yalnız bugünkü trafik değil; içerik ekibinin çalışma biçimi, kampanya dönemleri, üçüncü taraf entegrasyonları, bakım kapasitesi ve olası büyüme senaryoları birlikte değerlendirilmelidir.

İş ve İçerik Gereksinimini Belirleyin

Kurumsal tanıtım sitesi, çok dilli yapı, içerik merkezi, lead-generation sitesi veya müşteri portalı aynı teknik mimariyi gerektirmez.

Editör sayısı, içerik yayın sıklığı ve onay süreci CMS seçiminde temel girdilerdir.

CMS Seçimi

WordPress gibi geleneksel CMS, headless CMS veya özel içerik yönetim sistemi kullanım senaryosuna göre değerlendirilebilir.

Karar; editör deneyimi, entegrasyon, frontend kontrolü, güvenlik ve bakım maliyeti birlikte düşünülerek verilmelidir.

Hosting ve Runtime

PHP, Node veya başka runtime kullanan uygulamalarda desteklenen sürümler, kaynak limitleri ve deployment modeli önceden planlanmalıdır.

CDN ve Edge Katmanı

Statik varlıkların kullanıcıya yakın noktadan sunulması latency ve origin yükünü azaltabilir. Cache politikası HTML, asset ve kullanıcıya özel içerik türlerine göre ayrılmalıdır.

Güvenlik Katmanı

• TLS
• WAF
• Rate limiting
• Least privilege
• 2FA
• Secret management
• Security headers

Deployment Süreci

Canlı sunucuda manuel dosya değiştirmek yerine version control, staging ve kontrollü deployment kullanılmalıdır.

Geri alınabilir deployment modeli kritik hatalarda müdahale süresini azaltır.

Backup ve Restore

Dosya ve database yedeklerinin ayrı stratejiyle tutulması gerekir. Yedek alınması kadar restore testinin yapılması da önemlidir.

Monitoring

• Uptime
• HTTP hata oranı
• Application error
• CPU ve RAM
• Disk
• Database
• SSL süresi
• External API health

Production Readiness Nasıl Değerlendirilmeli?

Kurumsal Web Sitesi Teknik Altyapısı Nasıl Planlanmalı? kapsamında production hazırlığı yalnız sayfanın tarayıcıda açılmasıyla tamamlanmış sayılmaz. Özellikle İş ve İçerik Gereksinimini Belirleyin, CMS Seçimi ve Hosting ve Runtime için ölçülebilir kabul kriterleri oluşturulmalıdır. Uptime, response time, hata oranı, deployment süresi ve kritik kullanıcı akışları için baseline değerler bulunması sonraki değişikliklerin etkisini ölçmeyi kolaylaştırır. Staging ile production ortamlarının temel konfigürasyon farkları kayıt altına alınmalı ve canlı sistem üzerinde doğrudan manuel değişiklikler mümkün olduğunca sınırlandırılmalıdır.

Güvenlik ve performans birlikte değerlendirilmelidir. CDN veya cache kullanımı origin yükünü azaltırken yanlış cache kuralı kullanıcıya özel içeriğin paylaşılmasına neden olabilir. Benzer şekilde WAF veya rate limit saldırı yüzeyini azaltabilir fakat kritik API veya entegrasyonların çalışmasını engellememelidir. Bu nedenle güvenlik değişiklikleri gerçek trafik senaryolarıyla test edilmeli; uygulama logları, reverse proxy kayıtları ve dış servis health metrikleri merkezi olarak izlenmelidir.

Yayın ve Geri Dönüş Planı

Yeni sürüm, CMS güncellemesi veya altyapı değişikliğinde deployment öncesi database ve dosya backup durumu doğrulanmalı; gerekiyorsa maintenance veya trafik yönlendirme planı hazırlanmalıdır. Database migration içeren sürümlerde geri dönüş yöntemi ayrıca tasarlanmalıdır. Yayın sonrasında yalnız ana sayfayı kontrol etmek yerine login, form, arama, API, ödeme veya lead akışı gibi sitenin iş açısından kritik fonksiyonları smoke test ile doğrulanmalıdır. Bu yaklaşım web altyapısını tek seferlik proje değil sürekli işletilen üretim sistemi olarak ele alır.

Web Altyapısı Teknik Kontrol Listesi

• Staging ve production ayrılmış mı?
• Deployment geri alınabilir mi?
• Backup restore testi yapıldı mı?
• Application ve web server logları izleniyor mu?
• Security header ve TLS kontrolleri yapıldı mı?
• Cache bypass kuralları test edildi mi?
• Runtime ve dependency lifecycle takip ediliyor mu?
• Kritik kullanıcı akışları smoke test ile doğrulanıyor mu?

Değişiklik Yönetimi, SLO ve Incident Readiness

Kurumsal Web Sitesi Teknik Altyapısı Nasıl Planlanmalı? kapsamında teknik kalite yalnız ilk canlıya çıkış anında değerlendirilmemelidir. Sistem güncellendikçe dependency, CMS, runtime, cache, güvenlik kuralı ve entegrasyon davranışı değişebilir. Bu nedenle değişikliklerin ticket veya release kaydıyla izlenmesi, hangi sürümün ne zaman production ortamına çıktığının bilinmesi ve kritik değişikliklerde geri dönüş yönteminin önceden tanımlanması gerekir. Özellikle İş ve İçerik Gereksinimini Belirleyin, CMS Seçimi ve Hosting ve Runtime üzerinde yapılan değişiklikler yayın öncesi ve sonrası karşılaştırılabilir metriklerle doğrulanmalıdır.

Operasyonel hedefler için Service Level Objective benzeri ölçülebilir sınırlar tanımlanabilir. Uptime, P95 response time, 5xx oranı, kritik form veya işlem başarısı ve deployment sonrası hata oranı gibi metrikler uygulamanın gerçek sağlığını gösterir. Sadece sunucunun erişilebilir olması yeterli değildir; örneğin ana sayfa 200 dönerken iletişim formu, ödeme, arama veya API entegrasyonu çalışmıyor olabilir. Bu nedenle teknik monitoring yanında iş açısından kritik synthetic veya smoke kontrolleri de kullanılmalıdır.

Incident hazırlığında sorunun kim tarafından fark edileceği, ilk müdahaleyi hangi ekibin yapacağı ve hangi durumda rollback uygulanacağı önceden belirlenmelidir. Log, request ID, deployment zamanı ve infrastructure metriği aynı olay üzerinde ilişkilendirilebildiğinde kök neden analizi hızlanır. Olay sonrasında yalnız sistemi tekrar ayağa kaldırmak yerine tekrar oluşmayı engelleyecek teknik veya süreç aksiyonlarının kaydedilmesi, web altyapısının zaman içinde daha dayanıklı hale gelmesini sağlar.

Sıkça Sorulan Sorular

Kurumsal web sitesi için özel sunucu şart mı?

Hayır. Trafik, güvenlik ve operasyon ihtiyacına göre paylaşımlı, managed veya özel altyapı seçilebilir.

CDN her site için gerekli mi?

Zorunlu değildir ancak performans, dağıtım ve güvenlik açısından birçok projede değer sağlayabilir.

Staging ortamı neden önemlidir?

Güncelleme ve değişikliklerin production öncesinde test edilmesini sağlar.

Backup varsa monitoring gerekli mi?

Evet. Backup kurtarma içindir; monitoring problemi erken fark etmek için kullanılır.