Barındırma ve sunucu
Projeleri ihtiyaca göre paylaşımlı, sanal sunucu (VPS) veya adanmış sunucu üzerinde barındırıyoruz. Hedef kitlesi Türkiye olan projelerde gecikmeyi azaltmak için Türkiye veya yakın Avrupa lokasyonlarını tercih ediyoruz.
- SSD/NVMe depolama
- Güncel PHP ve veritabanı sürümleri
- Sunucu düzeyinde önbellek yapılandırması
- Trafik artışında ölçeklenebilir kaynak planı
Yedekleme politikası
Yedek, sorun çıktığında değil çıkmadan önce planlanır. Yedekleri barındırma sunucusundan ayrı bir konumda tutuyoruz; aksi hâlde sunucu kaybında yedek de kaybolur.
- Günlük otomatik tam yedek
- Yedeklerin ayrı konumda saklanması
- Geri yükleme testlerinin düzenli yapılması
- Büyük güncellemelerden önce ek anlık yedek
Güvenlik
- Ücretsiz SSL sertifikası, otomatik yenileme
- Güvenlik duvarı ve zararlı yazılım taraması
- Yönetim paneli için güçlü parola ve rol bazlı yetkilendirme
- Çekirdek, eklenti ve kütüphane güncellemelerinin takibi
- Şüpheli giriş denemelerine karşı hız sınırlama
İzleme ve çalışma süresi
Barındırdığımız projeleri sürekli izliyoruz. Erişilemezlik tespit edildiğinde ekibimize otomatik uyarı gider ve müdahale başlar. Hedefimiz %99.9 çalışma süresidir; planlı bakımlar bu oranın dışındadır ve önceden bildirilir.
Kesinti anında ne oluyor? Olay müdahale süreci
Erişilemezlik tespit edildiğinde süreç kişilere değil, yazılı bir akışa bağlı ilerliyor. Böylece kimin nöbette olduğundan bağımsız olarak müdahale aynı sırayla yapılıyor ve olay sonrası ne yaşandığı kayıt altında kalıyor.
-
01
Otomatik uyarı
İzleme sistemi erişilemezliği dakikalar içinde yakalar ve ekibe bildirim gönderir; uyarı tek kişiye değil ekibe düşer.
-
02
İlk teşhis
Sorunun kaynağı ayrıştırılır: sunucu, uygulama, veritabanı, alan adı veya dış servis. Yanlış katmanda aranan hata en çok zaman kaybettiren şeydir.
-
03
Geçici önlem
Hızlı bir çözüm mümkünse önce site ayağa kaldırılır; kalıcı düzeltme sonraya bırakılır. Öncelik erişilebilirliktir.
-
04
Kalıcı düzeltme
Kök sebep giderilir. Kaynağı bulunmadan yapılan temizlik, aynı sorunun tekrar etmesini engellemez.
-
05
Bilgilendirme
Kesinti süresi, sebebi ve alınan önlem yazılı olarak paylaşılır. Neyin olduğunu tahmin etmek zorunda kalmazsınız.
Veri kaybında hedeflenen geri dönüş süresi ve veri aralığı
Yedekleme politikasının iki somut ölçüsü var ve ikisini de baştan yazılı olarak veriyoruz. Birincisi geri dönüş süresi: sorun anından sitenin yeniden çalışır hâle gelmesine kadar geçen hedef süre. İkincisi kabul edilebilir veri aralığı: en kötü senaryoda kaç saatlik verinin kaybedilebileceği.
- Günlük tam yedekte azami veri kaybı 24 saatlik dönemle sınırlıdır
- Standart projelerde geri yükleme hedefi mesai içinde birkaç saattir
- E-ticaret gibi sipariş verisi taşıyan projelerde yedek sıklığı artırılır
- Yedekler barındırma sunucusundan ayrı bir konumda tutulur
- Geri yükleme yılda en az bir kez test edilir; denenmemiş yedek yedek sayılmaz
- Büyük güncelleme öncesi ek anlık yedek alınır ve geri dönüş planı hazırlanır
Güvenlik katmanlarında hangi önlem neyi durduruyor?
Tek bir önlem her saldırıyı durdurmuyor; koruma katmanlı çalışıyor. Aşağıdaki tablo hangi katmanın hangi riski karşıladığını gösteriyor.
| Katman | Neyi engeller | Uygulama |
|---|---|---|
| Güncelleme disiplini | Bilinen açıkları tarayan otomatik botlar | Çekirdek, eklenti ve kütüphane takibi |
| Web uygulama güvenlik duvarı | Yaygın saldırı kalıpları ve zararlı istekler | Sunucu ya da servis düzeyinde filtre |
| Giriş sınırlama | Parola deneme saldırıları | Hız sınırlama ve başarısız deneme engeli |
| Rol bazlı yetki | Yetkisi olmayan kullanıcının erişim genişletmesi | Panelde en az yetki ilkesi |
| Güvenlik başlıkları | Tarayıcı tarafındaki içerik enjeksiyonu | CSP, HSTS, nosniff, frame-options |
| Ayrı konumda yedek | Sunucunun tamamen kaybı | Günlük dış yedek |
Sunucu konumu ve hızda neyi neden seçiyoruz?
Sunucunun ilk baytı gönderme süresi (TTFB), sayfa hızının başlangıç noktası. Sunucu 800 ms’de yanıt veriyorsa tarayıcı tarafında ne yaparsanız yapın o gecikme sabit kalıyor. Bu yüzden konum ve kaynak seçimini tahminle değil, hedef kitlenin bulunduğu yere göre yapıyoruz.
- Hedef kitlesi Türkiye olan projelerde Türkiye veya yakın Avrupa lokasyonu
- TTFB hedefi 200 ms altı; aşıldığında önce sunucu tarafı incelenir
- Sunucu düzeyinde önbellek ve metin sıkıştırma standart olarak açık
- Statik dosyalarda uzun süreli tarayıcı önbelleği tanımlı
- Trafik artışında kaynak geçici olarak yükseltilebilir; kampanya dönemleri önceden planlanır
Kurumsal e-posta neden ayrı tutuluyor?
Kurumsal e-postayı web sitesiyle aynı paylaşımlı sunucuda tutmak yaygın ama riskli. Aynı sunucudaki başka bir site spam gönderdiğinde sunucunun IP adresi kara listeye girebiliyor ve sizin e-postalarınız da karşı tarafa ulaşmıyor. Site yoğunlaştığında e-posta yavaşlıyor, taşıma sırasında ise yazışmalar risk altına giriyor. Bu yüzden e-postayı ayrı ve kurumsal bir serviste yapılandırmayı öneriyoruz.
Teslim ve erişim
Alan adı, barındırma ve yönetim paneli erişimleri müşteriye aittir. Talep ettiğinizde tüm erişim bilgileri size devredilir; hiçbir projeyi erişim kısıtıyla bağlı tutmuyoruz.