En Uygun Fiyat Seçenekleri İle Yüksek Performanslı Cloud Server

Cloud Sunucu Nedir? (Bulut Sunucu Nedir, Cloud Server Ne İşe Yarar)

Cloud sunucu, uygulamalarınızı tek bir fiziksel makineye bağımlı olmadan çalıştıran, altyapısı dağıtık biçimde kurgulanmış sanal sunucudur. Klasik paylaşımlı hostingten farklı olarak, CPU/RAM/disk gibi kaynaklar sanallaştırma katmanı (hypervisor) üzerinden size özel atanır; fiziksel donanım arızalansa bile, altyapı otomatik olarak başka bir düğümden hizmeti sürdürür. Bu sayede bulut sunucu, ölçeklenebilirlik ve süreklilik vadeden modern projelerin temel taşıdır. Kullanım senaryoları; WordPress & WooCommerce, kurumsal web uygulamaları, SaaS, mikroservisler, API arka uçları, staging/QA ortamları ve analitik iş yüklerine kadar uzanır.

Bir cloud serverın çalışma mantığı üç katmanda anlaşılır: (1) Donanım ve sanallaştırma (hypervisor) kaynakları havuzlar, (2) ağ tarafında VPC/özel ağ ile izolasyon sağlanır, (3) yönetim katmanında imajlar, otomasyon (cloud-init/API) ve izleme ile devreye alma kolaylaşır. Bu yapı, tek bir fiziksel sunucuya bağlı tek hata noktası riskini azaltır ve planlı/plansız bakımlarda uygulamanızın kesintisiz kalmasına yardım eder.

Performans söz konusu olduğunda depolama teknolojisi öne çıkar. Modern cloud sunucular NVMe tabanlı blok depolama ile yüksek IOPS ve düşük gecikme sunar; bu, veritabanı ağır e-ticaret, raporlama ve yoğun okuma/yazma yapan uygulamalarda belirgin bir hız artışı olarak geri döner. CPU tarafında yeni nesil işlemci aileleri (ör. yüksek frekans çekirdekler) tek iş parçacığı performansını geliştirir; RAM yeterliliği ise in-memory cache (Redis/Memcached) kullanan projelerde sayfa açılışını gözle görülür şekilde hızlandırır.

Kurumlar açısından kritik başlık, esneklik ve sürekliliktir. Auto scaling ile trafik yükseldiğinde yeni örnekler (instance) otomatik devreye girer; azaldığında kaynaklar küçülür. Trafiği eşit dağıtmak ve tek sunucuya yük bindirmemek için load balancer kullanılır. Yüksek erişilebilirlik (HA) mimarilerinde veritabanı replikasyonu ve çok bölgeli (multi-AZ) yerleşim tercih edilir; tedarikçi tarafından ilan edilen SLA (uptime garantisi) burada kritik ölçüdür. İzleme ve alarm (CPU, disk, ağ, ping/HTTP) katmanı; performans düşüşlerini kullanıcı hissetmeden önce görmenizi sağlar.

Güvenlikte katmanlı yaklaşım esastır. Özel ağ (VPC) içinde sunucularınızı izole ederek yalnızca ihtiyaç duyulan portları açarsınız; kenarda firewall ve uygulama katmanında WAF ile filtreleme yapılır. Trafik hacimli saldırılar için DDoS koruması, yayınınızın ayakta kalmasına yardım eder. İşletim sistemi seviyesinde düzenli güncelleme, en az yetki prensibi ve anahtar tabanlı SSH erişimi uygulanmalıdır. Veri dayanıklılığı tarafında snapshot ve düzenli yedekleme politikaları (RPO/RTO hedefleriyle) devreye alınır; “yanlış dağıtım” veya “dosya silme” gibi insan hatalarında dakikalar içinde geri dönüş sağlanır.

Sıklıkla sorulan soru, “cloud sunucu fiyatları nasıl belirleniyor?” olur. Fiyat, temelde CPU sayısı ve saat hızı, RAM kapasitesi, depolama türü ve boyutu (SSD/NVMe), ağ çıkış trafiği (GB/TB), port hızı ve veri merkezi lokasyonuna göre değişir. Yönetilen hizmetler (yönetilen veritabanı, load balancer, WAF) ve lisanslar (ör. Windows, Plesk/cPanel) toplam maliyete eklenir. Birçok sağlayıcı “kullandığın kadar öde” (saatlik) ve sabit aylık paketleri birlikte sunar; öngörülebilir bütçe isteyenler aylık, dalgalı iş yükleri olanlar saatlik/saniyelik ücretlendirme modelini tercih eder. Maliyeti optimize etmek için kaynakları gerçek ihtiyaca göre boyutlamak, disk IOPS sınırlarını iş yüküne göre seçmek ve gereksiz idle örnekleri kapatmak pratik çözümlerdir.

Karşılaştırma yaparken “VPS mi, cloud sunucu mu?” sorusu gündeme gelir. VPS çoğu kez tek bir fiziksel sunucu üzerindeki sanal dilim anlamına gelir; büyüme ve hata toleransı genellikle sınırlıdır. Cloud sunucu ise altyapıdan itibaren dağıtık kurgulandığından ölçekleme ve iş sürekliliği açısından daha esnektir; cloud sunucu fiyatları ilk bakışta VPS’ten yüksek görünse de, kesinti riskinin ve operasyon maliyetlerinin düşmesi toplam sahip olma maliyetinde avantaj sağlayabilir. Çok öngörülebilir, tek uygulamalı ve kaynakları sabit iş yüklerinde dedicated sunucu hâlâ anlamlıdır; ancak yeni ürünler, kampanyalı projeler veya trafik pikleri yaşayan siteler için bulutun elastikiyeti büyük fark yaratır.

Yönetilebilirlik bu deneyimin görünmez kahramanıdır. Hazır imajlarla birkaç dakika içinde Linux cloud sunucu (Ubuntu, AlmaLinux) ya da Windows cloud sunucu (Windows Server) ayağa kaldırabilirsiniz. Birden çok sunucuyu aynı konfigürasyonla kurmak için cloud-init/Ansible/Terraform gibi otomasyon araçları idealdir; “kod olarak altyapı (IaC)” standardı, sürüm kontrolü ve tekrarlanabilir kurulum imkânı sağlar. Kontrol panelleri (cPanel/Plesk) ve yönetilen veritabanı hizmetleri, küçük ekiplerde uzmanlık ihtiyacını azaltır; ancak panel lisanslarının cloud sunucu fiyatları kalemi olduğunu unutmamak gerekir.

Kullanıcı deneyimi tarafında coğrafya önemli rol oynar. Hedef kitleniz Türkiye ise Türkiye lokasyon düşük ping ve hızlı sayfa açılışları sağlar; bu hız, dönüşüm oranlarına ve SEO metriklerine olumlu yansır. Global kitleye oynuyorsanız, içeriği uç noktalara yakınlaştırmak için CDN/edge önbellekleme ekleyebilirsiniz. Statik dosyaları CDN’den, dinamik trafiği load balancer üzerinden uygulama düğümlerine yönlendirmek, hem maliyet hem performans tarafında dengeli bir sonuç üretir.

Uygulama örnekleri üzerinden düşünelim: WooCommerce çalıştıran bir mağazada, NVMe tabanlı depolama ve yeterli RAM ile ürün listeleme/sorgu süreleri iyileşir; akşam piki için auto scaling kuralı devreye girer ve sepet akışında gecikme oluşmadan sipariş tamamlanır. Bir SaaS arka ucunda ise API düğümleri ölçeklenir, arka planda kuyruk/işleyici (worker) sayısı artırılır; izleme paneli CPU/süre patlamalarını gösterdiğinde kapasite planı gerçek veriye göre güncellenir. Tüm bu değişiklikler, altyapıyı kapatıp açmadan, dakikalar içinde yapılabilir.

Doğru cloud server seçimi için pratik kontrol listesi iş görür:

(1) İş yükünüzün CPU mu yoksa I/O ağırlıklı mı olduğunu belirleyin (ör. veritabanı için IOPS kritik). (2) Üç katmanlı güvenliği devreye alın (firewall, WAF, DDoS). (3) En baştan snapshot + yedekleme stratejisi tanımlayın (günlük/haftalık, saklama süresi). (4) Trafik dalgalanmaları için auto scaling + load balancer kurgulayın. (5) Hedef kitleye göre lokasyon ve SLA’yı kıyaslayın. (6) cloud sunucu fiyatlarında CPU/RAM/disk/transfer kalemlerini ayrı ayrı izleyin; gereksiz kaynakları kapatarak faturayı optimize edin. Bu yaklaşım, buluttan beklediğiniz esneklik ve sürekliliği gerçek dünyada tutarlı bir kazanca dönüştürür.

Linux Cloud Sunucu vs Windows Cloud Sunucu (Performans, Lisans, Panel ve Kullanım Senaryoları)

Bir projeyi buluta taşırken temel karar noktalarından biri, altyapının Linux cloud sunucu mu yoksa Windows cloud sunucu mu olacağıdır. Her iki seçenek de modern cloud sunucu mimarisinin esneklik, yüksek erişilebilirlik ve hızlı devreye alma avantajlarını paylaşır; fark, uygulama yığını, lisanslama, yönetim araçları ve maliyet kalemlerinde belirginleşir. Tercih; dil/çatı (stack), veri tabanı, panel, cloud sunucu fiyatları, ekip yetkinliği ve uzun vadeli ölçekleme planları birlikte ele alınarak yapılmalıdır.

Linux cloud sunucu tarafında yaygın dağıtımlar (Ubuntu, Debian, AlmaLinux/Rocky) web uygulamaları için varsayılan tercih halindedir. Nginx veya Apache + PHP-FPM, Node.js, Python (Gunicorn/Uvicorn) ve Ruby gibi ekosistemler sorunsuz kurulur. Paket yöneticileriyle (apt, dnf) güncelleme akışı sade ilerler, otomasyon araçları (cloud-init, Ansible, Terraform) ile tek tuşta çoklu örnek kurulumları yapılır. Açık kaynak ekosistemi sayesinde lisans maliyeti yoktur; bu durum özellikle birden çok test/QA ortamı gerektiren ekiplerde, cloud sunucu fiyatları üzerinde doğrudan olumlu etki yaratır. MySQL/MariaDB, PostgreSQL, Redis, Elasticsearch gibi bileşenler Linux’ta yaygın üretim standartlarıdır; konteyner tarafında Docker ve Kubernetes’le uyum doğrudandır.

Windows cloud sunucu, .NET/.NET Core tabanlı uygulamalar, kurumsal intranetler, Active Directory entegrasyonu, MS SQL Server ve IIS gerektiren senaryolarda yerini alır. RDP üzerinden yönetim konforu, GUI odaklı ekipler için öğrenme eğrisini yumuşatır. Plesk gibi paneller hem Windows hem Linux’ta çalışabildiği için, karışık yığınlarda tek panel standardı oluşturmak mümkün olur. Buna karşın Windows lisans bedeli ve kimi durumlarda CAL/SQL lisansları cloud sunucu fiyatları toplamını artırır; bu kalemlerin saatlik/aylık modele nasıl yansıtıldığı net görülmelidir. .NET Core’un Linux üzerinde koşabildiği unutulmamalı; yalnızca Windows’a bağımlı kütüphaneler, raporlama servisleri veya COM+ bağımlılıkları varsa Windows gerekliliği doğar.

Performans boyutunda web sunucusu ve I/O davranışı belirleyicidir. Linux’ta Nginx’in olay güdümlü (event-driven) mimarisi, yüksek eşzamanlı bağlantıda düşük bellek ayak izi ve tahmin edilebilir gecikme üretir. PHP-FPM havuz ayarları (pm, max_children), opcache, HTTP/2/3, TLS offload ile birlikte verimlilik artar. Windows + IIS tarafında Application Pool yönetimi, CPU affinity, ASP.NET Core Kestrel arkasında reverse proxy kurgusu doğru yapıldığında yüksek throughput yakalanır. Her iki dünyada da depolama teknolojisi kritik olup NVMe tabanlı blok depolama ve doğru IOPS sınıfı seçimi veritabanı ve oturum yönetimi gibi I/O yoğun işlemlerde fark yaratır.

Güvenlik ve güncelleme yönetimi katmanlı düşünülmelidir. Linux’ta SSH anahtar tabanlı giriş, fail2ban, SELinux/AppArmor, kernel güncellemeleri ve otomatik güvenlik yamaları standarda bağlanabilir. Windows’ta WSUS/Windows Update politikaları, RDP sertleştirme, güçlü parola/2FA ve güvenlik temelli GPO’lar devreye alınır. Her iki tarafta da VPC izolasyonu, güvenlik grupları/firewall, WAF ve ağ kenarında DDoS koruması olmazsa olmazdır. Loglama/SIEM tarafında Linux syslog + Promtail/Fluent Bit ile merkezi toplama yaygındır; Windows’ta Event Forwarding ve Defender for Cloud benzeri hizmetler aynı ihtiyaca cevap verir.

Panel seçimi günlük operasyonu doğrudan etkiler. cPanel, WHM ve LiteSpeed/OpenLiteSpeed ile Linux’ta yüksek performanslı bir LAMP/LEMP yığını kurulabilir; Plesk ise paylaşımlı hosting ve çok platform desteğiyle karışık ortamlarda tek panel standardı sağlar. E-posta (Postfix/Exim vs. Exchange/SMTP relay), DNS ve yedekleme iş akışları panel içinde otomatize edilebilir. Unutmamak gerekir ki panel lisansları da cloud sunucu fiyatları kalemidir; panel konforunu devre dışı bırakıp yapılandırmayı IaC ile yönetmek, ekip deneyimine bağlı olarak toplam maliyeti düşürebilir.

Veritabanı ve dosya servislerinde işletim sistemi tercihi genellikle uygulama ekosistemince belirlenir. Linux’ta PostgreSQL ve MySQL türevleri yüksek performans ve geniş topluluk desteğiyle öne çıkar; Windows tarafında MS SQL Server’ın gelişmiş özellikleri (Always On, SSRS, SSIS) kurum içi raporlama ve entegrasyon gereksinimlerini karşılar. Paylaşımlı dosya sistemlerinde Linux’ta NFS/Gluster, Windows’ta SMB DFS gibi seçenekler mevcuttur; kesintisiz dosya paylaşımları için bulutun yönetilen dosya servislerini tercih etmek, bakım yükünü azaltır.

Maliyet kırılımı yaparken yalnız sunucu etiketine bakmak yanıltıcıdır. Linux dağıtımlarında lisans bedeli yoktur; bu nedenle aynı donanım profili karşılaştırıldığında Linux cloud sunucu genellikle daha düşük aylık toplam üretir. Windows cloud sunucu lisansı, RDP/RemoteApp gereksinimleri ve SQL Server lisansı devreye girdiğinde bütçe artar; buna karşın .NET/AD/MS ekosistemiyle tam uyum, geliştirme ve entegrasyon maliyetlerini azaltabilir. Operasyon tarafında otomasyon (CI/CD, konfigürasyon yönetimi, snapshot/yedekleme) iki tarafta da mümkün olduğundan, “insan-saat” etkisini bütçe hesaplarına dahil etmek gerekir. Aynı proje için iki örnek ölçüp gerçek kullanım verilerine göre cloud sunucu fiyatlarını karşılaştırmak, varsayım hatalarını ortadan kaldırır.

Ekip yetkinliği, sürdürülebilirlikte en az lisans kadar önemlidir. Linux deneyimi güçlü takımlar terminal ve IaC ile her şeyi kodlayarak hızlı ilerler; Windows ağırlıklı BT ekipleri ise AD, GPO ve IIS alanında huzurlu çalışır. Karma yetkinlikli ekiplerde Plesk gibi panel üzerinde ortak bir operasyon yüzeyi oluşturmak, farklı dünyaları aynı süreçle yönetmeyi kolaylaştırır. İzleme/alarmlar için Prometheus + Grafana, ELK/Opensearch, Zabbix; Windows tarafında Azure Monitor/Log Analytics veya üçüncü parti APM araçları, üretim sorunlarını kullanıcı hissetmeden görünür kılar.

Uygulama türüne göre örnek karar çerçeveleri oluşturulabilir. WordPress/WooCommerce, Laravel, Node.js/Next.js, Python/Django/Flask ağırlıklı sitelerde Linux cloud sunucu tipik olarak daha verimlidir; TLS sonlandırma, HTTP/2/3 ve reverse proxy optimizasyonlarıyla yüksek istek hacmine dengeli yanıt verir. Kurumsal portallar, .NET tabanlı web API’leri, AD ile kimlik doğrulama, MS SQL gereksinimi olan CRM/ERP sistemlerinde Windows cloud sunucu ile uyum ve yönetilebilirlik öne çıkar. Karma yapılarda uygulama katmanı Linux, kimlik/veritabanı katmanı Windows olacak şekilde çok katmanlı mimari tercih edilebilir; load balancer ve VPC izolasyonu katmanlar arası güvenlik sınırı oluşturur.

Yeni dağıtıma geçiş veya platform değişimi yapılacaksa, kontroller listesi somut ilerleme sağlar: (1) Hedef OS üzerinde uygulama bağımlılıkları (runtime, kütüphaneler) hazır mı? (2) Veritabanı taşınırken sürüm ve kodlama (collation/charset) eşleşiyor mu? (3) Servis kullanıcıları ve gizli anahtarlar güvenli kasada (KMS/Secrets Manager) mı? (4) İzleme/uyarı platformu metrikleri toplayabiliyor mu? (5) snapshot ve geri dönüş testleri yapıldı mı? (6) CDN/edge katmanında yeni kök sertifikalar ve HTTP başlıkları (HSTS, CSP) tanımlandı mı? Bu adımlar, seçilen platformdan bağımsız şekilde üretim kalitesini korur ve beklenmedik gecikmeleri en aza indirir.

Özet bir kural yerine, iş hedefi ve ekosistem uyumunu merkeze almak daha sağlıklıdır. Açık kaynak yığınları ve yatay ölçek bekleyen web projeleri için Linux cloud sunucu doğal tercih olurken; Microsoft ekosistemine derin entegrasyon, AD ve MS SQL bağımlılıkları olan kurumsal uygulamalarda Windows cloud sunucu daha rasyonel tablo çıkarır. Her iki seçenekte de cloud sunucu fiyatları, lisans + donanım profili + trafik + yönetilen servisler toplamıyla değerlendirilmelidir; doğru eşleşme yakalandığında performans, güvenlik ve bütçe aynı doğrultuda ilerler.

NVMe SSD Cloud Sunucu Performansı ve IOPS (Veritabanı, E-ticaret ve Yoğun I/O İş Yükleri)

Modern uygulamalarda hızın belirleyici unsuru çoğu zaman CPU değil, depolamadır. NVMe tabanlı blok depolama; klasik SATA SSD’lere göre çok daha düşük gecikme (latency) ve yüksek IOPS üretir. Bu fark, veritabanı yoğun e-ticaret sitelerinde, raporlama/analitik görevlerinde, indeksleme yapan arama motorlarında ve WordPress/WooCommerce gibi dinamik CMS’lerde doğrudan tepki süresine yansır. cloud sunucu dünyasında depolama katmanının mimarisi, tek sunuculu bir kurulumdan farklıdır: sanallaştırma, ağ üzerinden blok depolama (distributed/block storage), çok kopyalı dayanıklılık ve kuyruk derinliği (queue depth) gibi değişkenler gerçek hayat hızını belirler.

Teknik çerçeveyi netleştirmek işinizi kolaylaştırır. NVMe sürücüler PCIe veri yolunda çalışır; SATA’ya kıyasla komut seti ve paralelliği sayesinde aynı anda çok daha fazla istek işleyebilir. Bahsi geçen IOPS metriği, saniyede kaç rastgele okuma/yazma işlemi tamamlandığını gösterir; ancak tek başına yeterli değildir. Uygulama davranışını anlamak için gecikme (ms/µs), throughput (MB/s) ve queue depth (Qd) değerlerini birlikte değerlendirmek gerekir. E-ticaret ve OLTP iş yüklerinde küçük blok (4–16 KB) rastgele I/O ve Qd=1–4 aralığı daha gerçekçi bir test zemini sağlar; raporlama ve yedeklemede ise sıralı ve büyük blok transferleri (64–1024 KB) throughput ön plana çıkar.

Bulut depolama sağlayıcıları performansı iki biçimde fiyatlar: kapasite (GB) ve performans (provisioned IOPS/MBps). Bazı platformlarda yalnızca disk boyutunu büyütmek, I/O tavanını da yükseltir; bazılarında IOPS ayrı bir satırdır. Bu ayrımı bilmeden yapılan büyütmeler, faturayı artırıp performansı aynı bırakabilir. En sağlıklı yaklaşım, iş yüküne göre “taban IOPS + burst” modeli seçmektir. Örneğin veritabanı ve cloud server dosya sistemi için taban IOPS’i güvenli bir seviyede tutup trafik piklerinde kısa süreli burst bütçesinden yararlanmak, hem tepki süresini dengeler hem de cloud sunucu fiyatlarını kontrol altında tutar.

Linux katmanında doğru ayarlar fark yaratır. Çoğu modern dağıtımda NVMe’nin I/O zamanlayıcısı olarak none veya mq-deadline önerilir; sanallaştırma katmanında ek kuyruklama yapılacağından, çift planlama (double scheduling) gecikmeyi artırabilir. Dosya sisteminde XFS veya ext4 yaygın tercihlerdir; küçük dosya ağırlıklı web projelerinde ext4, yüksek paralellikte XFS istikrarlı sonuç verir. noatime gibi bağlama seçenekleri gereksiz disk yazmalarını azaltır. TRIM/DISCARD desteği, uzun süre çalışan sistemlerde yazma performansının düşmesini engeller; forkliftten kaçınmak için çevrimiçi fstrim zamanlanabilir.

Veritabanı ayarları depolamadan verim almanın anahtarıdır. MySQL/MariaDB tarafında InnoDB buffer pool yeterince büyük tutulmalı; log file size, flush method ve flush neighbors I/O modeline göre ayarlanmalıdır. Sorgu önbelleği ve read replica kullanımı, yazma baskısını üretim diski üzerinden çekerek IOPS tüketimini dengeleyebilir. PostgreSQL’de shared_buffers, effective_cache_size ve checkpoint_segments/wal parametreleri, NVMe’nin düşük gecikme avantajını sahaya yansıtır. Büyük raporlarda work_mem ve maintenance_work_mem ayarlarının arttırılması, temp dosyası yazımını azaltarak depolama baskısını düşürür.

Uygulama katmanında önbellekleme, disk erişimini en ucuz yerden amorti eder. PHP-FPM + OPcache, WordPress’de page cache ve nesne önbelleği (Redis/Memcached), Laravel’de cache driver ve kuyruk/oturumların RAM tabanlı tutulması; milisaniye seviyesinde I/O isteklerini binlerce kez azaltır. Görsel/video gibi statik içerikler için CDN ve object storage kullanımı, bulut sunucu diskindeki gereksiz dosya operasyonlarını ortadan kaldırır. Bu optimizasyonlar, daha düşük IOPS sınıfı seçmenize imkân tanıyabilir; dolayısıyla cloud sunucu fiyatları üzerinde doğrudan düşürücü etki yapar.

Test ve doğrulama olmadan hiçbir ayar anlam taşımaz. Sentetik ölçüm için fio ile gerçekçi profiller oluşturabilirsiniz: 4k random read/write (70/30 oran), Qd=1–4; 64k sequential read/write, Qd=8–32 gibi. Testleri üretim saatleri dışında, izleme panellerini açık tutarak ve mümkünse izole bir diskte çalıştırın. Ölçümlerinizi yalnızca ortalama değerlerle değil, yüzde 95/99 gecikme (p95/p99) ile değerlendirmek, kullanıcıların deneyimlediği kuyruk gecikmelerini görmenizi sağlar. p99’un yüksek olduğu sistemlerde, sınırlı bir azınlık uzun bekleme yaşar; sepet aşaması gibi kritik akışlarda dönüşüm düşebilir.

Dayanıklılık ve veri bütünlüğü, performans kadar kritiktir. Birçok yönetilen blok depolama, arka planda veriyi birden fazla kopyalar; tek cihaz arızasında veri kaybı yaşanmaz. Ancak bu dayanıklılık, ağ üstünden replika yazımı nedeniyle ek gecikme getirebilir. Düşük gecikme talep eden yerel önbellekler için örnek (instance) içi ek SSD veya ephemeral disk kullanılabilir; bu diskler yeniden başlatmada silinebileceği için yalnızca tekrar üretilebilir veriler depo edilir. Kalıcı veriler mutlaka yönetilen blok depolamada veya replikalı veritabanında tutulmalıdır.

Büyüme planına uygun disk stratejisi belirlemek uzun vadede kazandırır. E-ticaret örneğinde ürün görselleri ve medya dosyalarını obje depolama + CDN’e, dinamik sorguları ise NVMe blok diske yönlendirmek dengeli bir mimari oluşturur. Günlük raporların üretildiği bir SaaS’ta, rapor arşivlerini soğuk depoya taşıyıp yalnız son 30 gününü cloud server üzerinde tutmak, hem kapasite hem IOPS ihtiyacını azaltır. Büyüme sırasında diski anında genişletebilmek, planlı bakım penceresini kısaltır; fakat dosya sistemi boyutunu da büyütmek gerekir (XFS/Ext4 çevrimiçi büyütmeyi destekler).

Uygulama dağıtımlarında, depolama katmanının CI/CD ile uyumu gözden kaçmamalıdır. Büyük sürüm geçişlerinde snapshot alıp, dağıtımdan hemen sonra smoke test ile p95/p99 gecikme metriklerini kıyaslamak, hatalı indeks/şema değişikliklerini hızlıca yakalamanızı sağlar. Veri göçleri için geçici yüksek IOPS sınıfına çıkıp, işlem bitince geri dönmek pratik bir maliyet taktiğidir; çoğu sağlayıcı disk sınıfını kesinti olmadan yükseltmeye izin verir.

Güvenlik tarafında şifreleme ve izolasyon da performansa etki eder. Sunucu içi disk şifreleme (LUKS/BitLocker) CPU yükünü artırabilir; donanım hızlandırmalı AES-NI destekli işlemciler bu etkiyi azaltır. Yönetilen blok depolamada şifreleme çoğunlukla altyapı düzeyinde yapılır; anahtar yönetimi (KMS) ile uyum, regülasyon gerektiren sektörlerde zorunludur. VPC içinde depolama trafiğini özel ağdan geçirerek, halka açık uçlardan kaçınmak gecikmeyi ve saldırı yüzeyini düşürür.

Toparlayıcı bir kontrol listesi pratik karar verir: (1) İş yükünüz rastgele mi, sıralı mı; tipik blok boyutu nedir? (2) p95/p99 hedefleriniz ve kabul edilebilir gecikme aralığı nedir? (3) Taban IOPS ve burst ihtiyacı nasıl; bütçe sınırı ne? (4) Dosya sistemi, zamanlayıcı ve TRIM politikası uygun mu? (5) Önbellek ve CDN stratejiniz diske binen yükü azaltıyor mu? (6) snapshot + geri dönüş testi düzenli mi? (7) Ölçek esnasında disk sınıfını büyütme planı ve izleme panelleri hazır mı? Bu sorulara net yanıtlar verdiğinizde, NVMe’nin sunduğu ham performansı gerçek kullanıcı deneyimine dönüştürmek ve bunu sürdürülebilir maliyetle yapmak mümkün olur; özellikle de cloud sunucu fiyatları kalemlerini kapasite ve performans ayrımıyla yönettiğinizde.

Türkiye Lokasyonlu Cloud Sunucu: Ping, Hız ve SEO Etkisi

Hedef kitleniz Türkiye’deyse, uygulamanızın sunucuya olan fiziksel yakınlığı doğrudan gecikme değerine (ping) yansır. İstanbul’dan Frankfurt’a giden bir istek, en iyi koşullarda bile onlarca milisaniye ek gecikme taşır; SSL el sıkışmaları, DNS çözümü ve yönlendirmeler derken toplam zaman büyür. Türkiye lokasyonlu bir cloud sunucu tercih edildiğinde, ağ sıçramaları azalır ve ilk bayt süresi (TTFB) düşer. Bu fark; sepette adım sayısı fazla olan e-ticaret sitelerinde, canlı yayın ve gerçek zamanlı bildirim kullanan web uygulamalarında ölçülebilir bir hız avantajı üretir.

Gecikme yalnız “tek sayı” değildir. Tarayıcının bir sayfayı açırken yaptığı işlemlere bakarsanız; DNS çözümü, TCP/TLS el sıkışmaları, istek/yanıt döngüsü ve paralel kaynak yüklemeleri toplamında onlarca ağ turu görürsünüz. Her tur, bulunduğunuz veri merkezinin coğrafi konumundan etkilenir. Türkiye lokasyonlu bir cloud server ile DNS Anycast pop’ları, CDN uçları ve uygulama düğümlerinizi aynı bölge etrafında konumlandırdığınızda turlar kısalır; Lighthouse/Pagespeed skorlarında TTFB ve FCP tarafında iyileşme sağlanır. Bu iyileşme, kullanıcıların sayfada kalma süresini artırdığı için arama davranışına dolaylı pozitif sinyal gönderir.

SEO tarafında sunucu lokasyonu tek başına bir sıralama faktörü olarak değerlendirilmez; fakat hız metrikleri, istikrar ve kullanıcı etkileşimi etkileyicidir. Core Web Vitals (LCP, CLS, INP) değerlerinin iyi olması için ham gecikmenin düşük seyretmesi avantaj sağlar. Türkiye lokasyonlu düğümler, yerel bağlantı omurgaları üzerinden daha stabil yönlendirme verdiğinde, özellikle mobil şebekelerde değişken gecikmenin neden olduğu “takılma” hissini azaltır. Arama motorlarının tarama bütçesi (crawl budget) açısından bakınca, TTFB’nin kısa olması tarama verimliliğini yükseltir; daha çok sayfa daha kısa sürede taranır.

İçerik dağıtımı için CDN kullanıyorsanız, asıl uygulama düğümünün lokasyonu yine önem taşır. Statik varlıkları (JS/CSS/görseller) kenara (edge) yakınlaştırırken, HTML yanıtı çoğu zaman orijinden gelir. HTML orijininin Türkiye’de olması, kritik yolun başını hızlandırır; geri kalan varlıklar CDN’den beslenir. load balancer arkasında birden fazla uygulama düğümü çalıştırmak ve bunları Türkiye içindeki birden çok availability zone’a yaymak, hem gecikmeyi hem de bölgesel arızalara karşı dayanıklılığı iyileştirir. DNS katmanında Anycast kullandığınızda, kullanıcıya en yakın pop’tan isim çözümü almak ilk adımı daha da kısaltır.

Veri yerleşimi ve mevzuat boyutu da gözden kaçmamalıdır. Bazı sektörlerde verinin ülke içinde tutulması beklenir; Türkiye lokasyonlu bir bulut sunucu mimarisi, veritabanı ve logların yetkisiz sınır ötesi dolaşımını engellemek açısından doğru altyapıyı sunar. Bu tercih, yasal gerekliliklerin yanı sıra gecikme tarafında da kazançtır; veritabanı replikasyonunun bölge dışına gitmesi gecikmeyi ve hata yüzeyini büyütür. Operasyonel olarak, yerel NTP/DNS ve yönlendirme tabelalarını (route) kullanan veri merkezleri, zamansal tutarlılık ve bağlantı istikrarı sağlar.

Uygulama profillerine göre lokasyonun etkisini ölçmek için gerçek kullanıcı ölçümü (RUM) ve sentetik testleri birlikte kullanmak gerekir. RUM ile İstanbul, Ankara, İzmir gibi yoğun bölgelerde p50/p75/p95 TTFB ve INP değerlerini izleyebilir; sentetik tarafta ise sabit hat üzerinden anlık gecikme ve paket kaybı oranlarını görebilirsiniz. Türkiye lokasyonlu bir kurulumda p95 değerleri genellikle daha stabil seyreder; bu, kullanıcıların bir kısmının çok kötü deneyim yaşamasını önler. Özellikle ödeme sayfaları ve canlı destek modüllerinde p99 kuyruk gecikmesini düşürmek dönüşümde hissedilir artış getirir.

Maliyet perspektifinde lokasyonun etkisi iki yönlüdür. Bazı sağlayıcılarda bölgesel enerji ve operasyon maliyetleri nedeniyle fiyat bantları farklı olabilir; cloud sunucu fiyatları bölgeden bölgeye değişir. Ancak aynı istek hacminde daha kısa oturumların ve daha iyi dönüşüm oranlarının, reklam ve operasyon bütçesine olumlu yansıması vardır. Sık erişilen statik içerikleri CDN’e taşıyıp dinamik içeriği Türkiye’de sonlandırmak, hem egress maliyetini hem de sunucu üzerinde CPU baskısını azaltır. Özetle etiket fiyatına değil, toplam sahip olma maliyetine bakmak gerekir; lokasyon seçimi bu toplamı aşağı çekebilir.

Ağ katmanında birkaç pratik öneri doğrudan sonuca etki eder. İlk olarak, firewall ve güvenlik gruplarını en az yetki prensibiyle düzenleyin; bölge içi özel ağ (VPC) üzerinden uygulama ve veritabanı katmanlarını ayırın. İkinci olarak, TLS 1.3 ve HTTP/2/3 desteği ile el sıkışma ve istek çoğullamayı hızlandırın; Türkiye’deki ana operatörlerle peering yapan veri merkezleri bu avantajı daha iyi kullanır. Üçüncü olarak, DDoS ve WAF katmanlarını uygulamaya en yakın noktada devreye alın; saldırı trafiğinin bölge dışına taşınması gereksiz transit maliyet ve gecikme oluşturur.

Dağıtım (deployment) stratejisi lokasyon kazancını pekiştirir. Blue/green veya canary dağıtımlarda aynı bölge içinde paralel ortam kurmak, DNS veya load balancer kuralı ile trafiği kademeli kaydırmanıza izin verir; ağ turları sabit kaldığı için performans şaşmaz. snapshot tabanlı hızlı geri dönüş ve bölge içi yedekleme kasası, beklenmedik hatalarda dakikalar içinde eski sağlıklı sürüme dönmenizi sağlar. Bu yaklaşım, pik trafikli kampanya dönemlerinde hız kesmeden deneme yapabilme özgürlüğü verir.

İş yükü türüne göre lokasyon kurgusu farklılaşabilir. WooCommerce veya yoğun arama/sıralama yapan katalog sitelerinde HTML orijin + veritabanı Türkiye’de, statikler CDN’de tutulduğunda kategori ve ürün sayfalarının TTFB’si düşer. Canlı skor/gerçek zamanlı bildirimli uygulamalarda WebSocket oturumlarının bölge içinde sonlandırılması, kuyruğa (queue) yazma gecikmesini azaltır. B2B portal ve dahili uygulamalarda, Türkiye içindeki ofis ve saha ağlarının aynı omurgaya yakın olması, RDP/SSH ve SFTP oturumlarında akıcılık sağlar.

Adreslenebilir başka bir katman da izleme ve alarmdır. Türkiye’deki uçlardan aktif ping/HTTP kontrolü yaparak p95 gecikme eşiklerini dinamik alarmlara bağlayın; bölgesel bir sorun anında otomatik kapasite arttırma veya trafik yön değiştirme kuralları tetiklenebilir. Anycast DNS üzerinde sağlık kontrolleriyle, İstanbul pop’u sorun çıkarırsa Ankara/İzmir rotasına, ya da ikincil bölgeye geçiş yapmak mümkün olur. Böylece hız avantajını istikrarla birleştirirsiniz.

Operasyon tarafında sade bir kontrol listesi iyi çalışır: (1) Hedef kitleniz çoğunlukla Türkiye’de mi? (2) Türkiye lokasyonlu veri merkezinin peering ve omurga haritalarını gördünüz mü? (3) HTML orijini ülke içinde; statikler CDN’de mi? (4) Anycast DNS ve yakın pop’lar aktif mi? (5) TLS 1.3, HTTP/2/3, HSTS ve brotli sıkıştırma açık mı? (6) DDoS/WAF bölge içinde mi sonlandırılıyor? (7) RUM/sentetik testlerle p50/p95/p99 TTFB ve INP izleniyor mu? (8) cloud sunucu fiyatları bölgesel farklarını CDN ve egress stratejisiyle dengelediniz mi? Bu sorulara net yanıtlar verildiğinde, lokasyon kararının performans ve görünürlük tarafındaki getirisi günlük metriklere güçlü şekilde yansır.

Cloud Sunucu Güvenliği: DDoS Koruma, Firewall ve WAF

Bir uygulamanın hızlı ve ölçeklenebilir olması kadar güvenli olması da zorunludur. Ağdan uygulama katmanına, veriden kimliğe kadar tüm yüzey alanını düşünmeden kurulan bir cloud sunucu mimarisi; yüksek trafik altında erişilemez hale gelebilir, veri sızıntısı riski doğurabilir veya itibar kaybı yaşatabilir. Sağlam bir güvenlik çerçevesi üç katmanda başlar: ağ kenarında hacimsel saldırıları durduran DDoS koruması, sunucu ve segment bazlı trafiği filtreleyen firewall politikaları ve uygulama katmanındaki kötü niyetli istekleri ayıklayan WAF. Bunlara ek olarak kimlik/erişim (IAM), gizli anahtar yönetimi, şifreleme, günlükleme (SIEM) ve yedekleme zinciri güvenliğin parçasıdır.

DDoS koruma, hedefi bant genişliği ve paket sayısıyla boğmaya çalışan saldırılara karşı savunma katmanıdır. Ağ katmanı (L3/L4) saldırılarda UDP/TCP flood, SYN flood, amplification (NTP, DNS, Memcached) gibi yöntemler yaygındır; çözüm olarak sağlayıcının kenarındaki scrubbing merkezleri trafiği temizler, yalnız düzgün akış uygulamanıza ulaşır. Uygulama katmanı (L7) saldırılarında ise HTTP istekleri görünürde “geçerli”dir; sayfa veya arama uçları yoğunlukla hedeflenir. L7 saldırıları için WAF ve akıllı oran sınırlama (rate limit) politikaları gerekir; bot yönetimi ve tarayıcı doğrulama ile insan–bot ayrımı güçlendirilir. Büyük kampanya dönemlerinde DDoS eşiği ve otomatik ölçek kurallarının birlikte test edilmesi, kesintisiz deneyim için kritik bir provadır.

Ağ segmentasyonu ve firewall kuralları ikinci hattı oluşturur. Özel ağ (VPC) içinde web katmanı, uygulama katmanı ve veritabanını ayrı alt ağlara bölmek; yalnız ihtiyaç duyulan portları açmak en az yetki prensibini uygular. Güvenlik gruplarıyla “web → app yalnız 443/HTTP2, app → db yalnız 3306/5432” gibi kural setleri tanımlayın. Yönetim erişimi için SSH/RDP’yi herkese açık bırakmak yerine bastion/jump host üzerinden, belirli ofis IP bloklarına sınırlayın. IPS/IDS (ağ içi imza/normal dışı trafik tespiti) ve flow günlükleri anormallik durumunda hızlı soruşturma sağlar. Bu segmentasyon yaklaşımı, tek makinede başlayan bir ihlalin diğer katmanlara bulaşmasını zorlaştırır.

WAF (Web Application Firewall), uygulama kontrollerinin çekirdeğidir. OWASP Top 10 (SQLi, XSS, XXE, SSRF, RCE vb.) imzaları, anomali skorlaması, coğrafi kısıtlama, IP/ASN bloklama ve bot imzaları ile katmanlı koruma sağlar. WAF’ı “hemen engelle” moduna almak yerine, önce monitor modda sahte-pozitif (false positive) oranını gözleyin; iş kritik uç noktalar (ödemeler, sepet) için ince taneli kurallar yazın. API trafiğinde JSON şema doğrulama ve istek boyutu/alan sayısı limitleri şablon saldırıları hızla yakalar. TLS 1.3, HTTP/2/3, SNI tabanlı çoklu virtual host ve load balancer üzerindeki health check’ler, WAF ile birlikte stabil bir ön kapı oluşturur.

Kimlik ve erişim (IAM) katmanı ihlallerin büyük kısmını önler. Panel ve API erişimlerinde çok faktörlü doğrulama (2FA), rol tabanlı yetkilendirme (RBAC) ve en az ayrıcalık prensibini zorunlu tutun. Dağıtım (CI/CD) anahtarları, veritabanı parolaları ve üçüncü parti API anahtarları secrets manager/KMS içinde saklanmalı; dosya sistemine düz metin olarak yazılmamalıdır. Anahtar rotasyonunu takvime bağlayın, erişim günlüklerini SIEM’e akıtın ve olağan dışı erişimleri uyarıya bağlayın. Geliştirici cihazlarında uç nokta koruması (EDR) ve disk şifreleme; çalınan kimlik bilgilerinin üretim ortamına sızmasını zorlaştırır.

Veri koruma stratejisinin iki ayağı vardır: aktarımda ve beklemede şifreleme. Aktarımda TLS 1.3, güçlü şifre paketleri ve HSTS/CSP/SRI gibi başlıklar; aradaki adam saldırılarını ve içerik manipülasyonunu önler. Beklemede şifreleme için yönetilen blok depolamada sağlayıcının şifreleme seçeneklerini, örnek içi disklerde LUKS/BitLocker yapılarını kullanın. Donanım hızlandırmalı AES-NI desteği CPU maliyetini düşürür. snapshot ve yedekleme kopyalarında “değiştirilemez (immutable)” ve sürümlemeli (versioned) politika, fidye yazılımı senaryolarında geri dönüş garantiniz olur; yedekten geri yükleme tatbikatı yapılmadıkça yedek tanım gereği tamamlanmış sayılmaz.

Günlükleme ve görünürlük olmadan güvenlik kördür. cloud sunucu üzerinde sistem günlüğü, web access/error, uygulama logları, WAF/firewall olayları ve veritabanı denetim günlüklerini merkezi bir havuzda toplayın. SIEM, kurallar ve dışa aktarımlar (Slack/Teams) ile p95 tepki süresi sıçramaları, 5xx hata oranı artışı, başarısız giriş denemeleri, olağan dışı trafik kaynakları anında görünür olur. İzleme tarafında altyapı (CPU/RAM/disk/IOPS, ağ), uygulama (APM), sentetik ve gerçek kullanıcı ölçümü (RUM) birlikte çalışmalıdır; yalnız CPU’a bakmak yerine “yanıt süresi + hata oranı + eşzamanlı istek” üçlüsünü takip edin.

Güncelleme ve zafiyet yönetimi ihmal edildiğinde, en iyi kenar korumaları bile yeterli olmaz. Otomatik güvenlik yamaları, kernel güncellemeleri, paket yükseltmeleri ve kullanılmayan servislerin kapatılması (attack surface azaltma) haftalık rutinin bir parçası olmalıdır. Konteyner kullanıyorsanız imaj taraması (image scanning), imza doğrulaması (cosign), Kubernetes’te NetworkPolicy, PodSecurityStandard ve gizli anahtarların secrets üzerinden yönetimi gereklidir. Klasik VM’de fail2ban, sshd sertleştirme, sudo günlükleri ve oturum denetimi pratik sonuç üretir.

Mimari esneklik güvenlikte de avantaj sağlar. İki uygulama örneğini load balancer arkasında koşturup blue/green dağıtım yaparsanız; güvenlik kuralı veya WAF kuralı hatalı olduğunda anında geri dönebilirsiniz. Bölge içi çoğaltma (HA) ve otomatik yeniden yerleştirme, tek düğüm arızasında hizmetin ayakta kalmasını sağlar. DNS katmanında Anycast ve sağlık kontrolleri, sorunlu pop’u devre dışı bırakır; trafiği sağlam noktaya taşır. Bu dayanıklılık, güvenlik ekiplerinin kural ayarlarında daha cesur iterasyon yapmasına olanak tanır.

Maliyet boyutunu planlamak önemlidir; güvenlik bir “ekstra” değil temel gereksinimdir. Sağlayıcınız çoğu zaman temel DDoS korumasını pakete dahil eder; gelişmiş WAF kuralları, bot yönetimi, özel rate limit ve yönetilen load balancer özellikleri ek ücretlidir. Cloud sunucu fiyatlarını planlarken “güvenlik için %X” şeklinde bir pay ayırmak; olası kesinti/ihlal maliyetiyle kıyaslandığında rasyonel bir sigortadır. “WAF fiyatları” ve “DDoS plan ücretleri” sağlayıcıya göre değişir; log miktarı/GB ve kural sayısı gibi metrikler toplamı etkiler. Gereksiz logları örnek içinde tutmak yerine, süreli arşiv politikasına bağlamak hem maliyeti hem veri kalabalığını azaltır.

Operasyon için pratik bir kontrol listesi hazırlayın: (1) VPC segmentasyonu tamam mı, yalnız gerekli portlar açık mı? (2) Kenarda DDoS ve uygulamada WAF aktif mi; monitor → block geçişi test edildi mi? (3) Bastion üzerinden erişim, 2FA ve IP kısıtı var mı? (4) TLS 1.3, HSTS, CSP ve güvenli çerez bayrakları (HttpOnly, Secure, SameSite) doğru mu? (5) snapshot ve yedekleme immutable/sürümlemeli mi; geri yükleme tatbikatı yapıldı mı? (6) SIEM kuralları p95/p99 artışı, 5xx, 401/403 patlamaları ve login deneme dalgalarını yakalıyor mu? (7) Zafiyet taraması ve yama yönetimi takvimli mi? Bu disiplin sahada akışkan bir güvenlik kalkanı üretir; hız, ölçek ve güvenlik aynı anda mümkün olur.

Snapshot & Yedekleme Stratejileri: RPO/RTO Nasıl Planlanır?

Bir felaket anında işlerin kaç dakika/ saat geriye gitmesine razısınız ve hizmeti ne kadar sürede tekrar ayağa kaldırmak istiyorsunuz? Bu iki soru RPO (Recovery Point Objective) ve RTO (Recovery Time Objective) hedeflerini belirler. Cloud sunucu ortamında doğru snapshot ve yedekleme kurgusu, bu hedeflere ulaşmanın temel aracıdır. “Günde bir yedek yeter” varsayımı çoğu modern uygulama için yetersizdir; veritabanı yazma hızı, sipariş sıklığı, dosya akışı ve mevzuat gereklilikleri (KVKK, sözleşmesel saklama süreleri) birlikte ele alınmalıdır.

Yedekleme dünyasında iki kavramı ayırarak başlamak gerekir: snapshot ve tam yedek (backup). Snapshot, blok seviyesi anlık görüntüdür; geri dönüşü saniyeler–dakikalar içindedir, dağıtım/versiyon geri alma ve hızlı kurtarma için idealdir. Ancak “yedek” yerine geçmez; aynı bölgede tutulan snapshot, bölgesel arızada yok olabilir. Tam yedekleme ise farklı bir depoda (çoğu zaman object storage) saklanan, çoğu senaryoda bölge dışına çoğaltılan, saklama politikası olan kopyadır. Sağlam mimaride ikisi birlikte kullanılır: operasyonel hız için snapshot, felaket senaryosu ve uzun süreli saklama için backup.

RPO/RTO planı iş yükü profiline göre hesaplanır. E-ticarette sepet ve sipariş verisi dakikada onlarca kez yazılıyorsa, 24 saatlik RPO iş hedefiyle çelişir; burada veritabanı günlükleriyle (MySQL binlog, PostgreSQL WAL) point-in-time recovery (PITR) kurgusu gerekir. RPO’nuz 15 dakika ise, cloud server üzerindeki veritabanı günlükleri en fazla 15 dakikalık bloklar hâlinde güvenli depoda tutulmalıdır. RTO tarafında hedef 30 dakika ise, snapshot’tan geri dönüp uygulamayı ayağa kaldırma, DNS/LB yönü ve önbellek ısındırma adımlarının toplam süresi 30 dakikayı geçmemelidir.

Uygulama tutarlılığı olmadan yedekler güven vermez. Linux cloud sunucu’da LVM freeze + snapshot, Windows cloud sunucu’da VSS ile application-aware tutarlılık alın; veritabanı tarafında FLUSH TABLES WITH READ LOCK, PostgreSQL pg_start_backup/pg_stop_backup ya da motorun kendi aracı (mysqldump, pg_dump, mongodump) ile mantıksal yedekleme seçeneklerini devreye alın. Mantıksal yedekler küçük tablolarda esneklik sağlar; fiziksel yedekler (dosya/blok düzeyi) büyük veri setlerinde hız kazandırır. Kritik nokta, yedeğin alındığı anda yazma işlemlerinin tutarlı bir anlık görüntüde olmasıdır.

Saklama politikası maliyet ve risk dengesini belirler. Kurumsal ekiplerde GFS (Grandfather–Father–Son) düzeni yaygındır: saatlik/daily artımlı, haftalık tam, aylık arşiv. En az 3 kopya, 2 farklı medya/konum, 1 kopya offsite prensibi (3-2-1 kuralı) basit ama etkilidir. Cloud sunucu fiyatlarına yalnız disk değil, yedek saklama da yansır; sıcak veri için kısa saklama, arşiv için düşük maliyetli katman mantıklıdır. Versiyonlamalı (versioned) ve değiştirilemez (immutable) saklama politikaları fidye yazılımı riskini düşürür; nesne depolarında object lock ile belirli süre boyunca silinemez kopyalar tutulabilir.

Ağ ve egress etkisi hesaba katılmalıdır. Yedekler bölge dışına kopyalanacaksa bant genişliği, zamanlama ve kısıtlama (throttle) politikası belirleyin; iş saatlerinde trafiği boğmadan gece pencerelerine alın. İlk tam yedek yerine seed diski mantığı ya da synthetic full yöntemleri, büyük veri setlerinde transfer maliyetini ve zamanı düşürür. Artımlı (incremental) ve fark (differential) yedekleme stratejileri, yalnız değişen blokları taşıyarak faturayı ve süreyi azaltır; deduplikasyon destekli çözümler aynı verinin tekrar tekrar saklanmasını engeller.

Felaket kurtarma (DR) senaryosu yalnız veriyi değil, çalışır sistemi hedefler. Bölge dışı bir ikinci ortamda minimum kapasiteyi “soğuk/ılık” bekletmek, büyük olaylarda RTO’yu kurtarır. Uygulama imajları, yapı artefaktları (container image, paketler), çevresel değişkenler ve gizli anahtarlar (KMS/Secrets Manager) DR ortamına senkronize edilmezse, yalnız veriyi geri getirmenin faydası sınırlı kalır. Load balancer ve DNS katmanında sağlık kontrolleri ile otomatik failover tanımlamak, kararı insan dışına taşır. DR testi yapılmamış bir plan, varsayımdır; yılda en az bir tatbikatla geri dönüş adımlarını gerçek zamanlı sınayın.

Depolama tarafında katmanlı yaklaşım pratik sonuç verir. Sıcak veri için NVMe blok depolama, anlık geri dönüş için sık snapshot, uzun saklama için düşük maliyetli nesne depolama tercih edilir. Büyük medya arşivleri ve log’ları temel diskte tutmak yerine soğuk katmana taşıyın; uygulamalar bu dosyalara HTTP üzerinden erişebilir. Bu sayede üretim diskinde IOPS baskısı azalır, cloud sunucu fiyatları daha öngörülebilir olur. Yedeklerin bulunduğu hesaplar için ayrı IAM politikaları ve write-once erişim modeli uygulanmalıdır; üretim kullanıcılarının yedekleri silebilmesi ciddi bir risktir.

Güvenlik ve uyumluluk başlıkları yedeklemenin ayrılmaz parçasıdır. Beklemede şifreleme (server-side ya da client-side) ve aktarımda TLS zorunludur. Anahtar yönetimini (KMS) operasyonel takvime bağlayın; anahtar rotasyonları ve erişim günlükleri denetime hazır olmalıdır. KVKK/GDPR açısından “unutulma hakkı” ve saklama süreleri, yedekler için de geçerlidir; süre dolduğunda ilgili kayıtların yedeklerden çıkarılması için süreç tanımlanmalıdır. whois gizleme gibi alan adı gizliliği önlemleri, yedek erişim yollarını da dolaylı korur; yedek erişim URL’lerini hizmet dışı bırakmak ve süresi dolan imzalı bağlantılar kullanmak yüzeyi daraltır.

Operasyonel iş akışında yedekleri “canlı” izlemeden edemezsiniz. Merkezi izleme panellerinde son yedek zamanı, başarısız görev sayısı, transfer hızı, saklama doluluk oranı ve restore süreleri görünür olmalıdır. Otomatik uyarılar; yedek gecikmesi, beklenenden düşük veri hacmi (anormallik algısı) ve hedef depoda kota aşımı için tetiklenmelidir. snapshot alındığında uygulamanın kısa süreli donmasını (freeze) kullanıcı hissetmemelidir; planlamayı yoğunluk dışı saatlere almak ve uygulama içi kuyrukları boşaltmak işe yarar.

Geri yükleme (restore) pratiği planın kalitesini ortaya çıkarır. Temsili bir veri setiyle test ortamında düzenli restore yapın; uygulama, veritabanı, dosya referansları, CDN yolları ve kimlik doğrulama akışı çalışıyor mu kontrol edin. Runbook dokümanında adımlar adım adım yazılı ve ekran görüntüleriyle destekli olmalıdır; ekipteki herkes tek başına dönebilmelidir. DNS ve load balancer kuralı için de geri dönüş senaryosu yazın; yanlış bir dağıtımın ardından snapshot’tan dönüş ve trafiği eski havuza alma dakikalarla ölçülmelidir.

Sahada uygulanabilir bir kontrol listesi, gereksiz riskleri temizler: (1) RPO/RTO hedefleri sayıyla tanımlandı mı? (2) snapshot sıklığı ve yedekleme saklama politikası (GFS/3-2-1) net mi? (3) Uygulama-tutarlı (VSS/LVM) yedekler alınıyor mu? (4) PITR için binlog/WAL arşivi açık mı ve ayrı depoda mı? (5) Bölge dışı kopya ve DR tatbikatı planlandı mı? (6) Yedek depoları immutable/versioned mı ve KMS ile şifreli mi? (7) İzleme/alarmlar yedek gecikmesi ve başarısız görevleri yakalıyor mu? (8) Geri dönüş testi en son ne zaman yapıldı? Bu çerçeve yerindeyse, veri kaybı ve kesinti riskleri ölçülebilir seviyeye iner; ekip hızla çalışırken cloud sunucu altyapınız beklenmedik anlarda dahi güven vermeyi sürdürür.

Cloud Sunucuda WordPress & WooCommerce Optimizasyonu

WordPress ve özellikle WooCommerce, doğru kurgulandığında yüksek trafikte dahi akıcı çalışan esnek bir yığındır. Başarının anahtarı; uygulama, veritabanı, önbellek ve ağ katmanlarını cloud sunucu mimarisiyle uyumlu şekilde ayarlamaktır. Amaç yalnızca hız rekoru kırmak değil, trafik dalgalanmalarında stabil kalmak ve bütçeyi verimli kullanmaktır. Aşağıdaki pratikler; sayfa açılışlarını kısaltır, sepet–ödeme akışlarını güvenli tutar ve cloud sunucu fiyatları tarafında gereksiz kaynak tüketimini azaltır.

Altyapı temeli ile başlayın. HTTP katmanında Nginx (veya OpenLiteSpeed) + PHP-FPM ikilisi, olay güdümlü mimari ve düşük bellek ayak iziyle öne çıkar; HTTP/2/HTTP/3, TLS 1.3 ve HSTS ile modern protokol avantajlarını açın. PHP tarafında OPcache’i etkinleştirin; opcache.memory_consumption, interned_strings_buffer ve max_accelerated_files değerlerini site büyüklüğüne göre ayarlayın. PHP-FPM havuzunda pm=ondemand veya trafik profilinize göre pm=dynamic, yeterli pm.max_children ve düzgün process_idle_timeout kullanın; yetersiz PHP worker, sepet/checkout sırasında kuyruk biriktirir. Statik varlıklar için brotli/gzip sıkıştırma, uzun Cache-Control başlıkları ve ETag uyumu kurun.

Veritabanında doğruluk payı büyük. WooCommerce, sipariş ve stok güncellemeleriyle wp_posts, wp_postmeta ve wp_options üzerinde yoğunlaşır. MySQL/MariaDB için InnoDB tercih edin; innodb_buffer_pool_size belleğinizin %50–70’i aralığında başlayabilir. innodb_log_file_size, flush_log_at_trx_commit ve innodb_flush_method iş yükünüze göre ayarlanmalı; sorgu yavaş günlükleri (slow query log) aktif edilerek, indeks gerektiren alanlar tespit edilmelidir. Kalabalık kataloglarda arama/filtre performansı için yerleşik LIKE sorguları yerine arama motoru (Elasticsearch/OpenSearch) entegrasyonu değerlidir; bu, NVMe diskin sağladığı düşük IOPS gecikmesini daha verimli kullanır.

Önbellekleme üç katmanlı düşünülmeli: opcode, nesne ve sayfa önbelleği. OPcache zaten devrede olmalı. Nesne önbelleği için Redis idealdir; WordPress’te persistent object cache (Redis) ile transient ve seçenek (options) tablosu yükünü azaltın. Tam sayfa önbelleği (full-page cache) blog/kategori/sayfa gibi dinamik olmayan kısımları hızlandırır; WooCommerce’de ise cart, checkout ve kullanıcıya özel sayfalarda önbellek baypas edilmelidir. Kurallar: sepet/ödeme/hesabım yolunu hariç tut; woocommerce_items_in_cart çerezi set ise cache devre dışı; varyantlı ürünlerde AJAX son noktaları (wc-ajax) cache dışı. Bu ayrımlar yapılmadığında “sepete eklendi ama görünmüyor” gibi hatalar ortaya çıkar.

Medya ve statikler için CDN zorunluya yakın. Görselleri, CSS/JS ve hatta font dosyalarını CDN’den servis ederek cloud server üzerindeki CPU ve egress baskısını azaltın; cloud sunucu fiyatlarında en görünmez kalem çoğu zaman bant genişliğidir. Görselleri WebP/AVIF’e çevirin, boyutlandırmayı srcset/sizes ile tarayıcıya bırakın. Büyük kataloglarda medya yüklerini obje depoya taşıyan offload eklentileri (S3 uyumlu) disk tüketimini ve yedekleme süresini düşürür; üretim diskiniz sıcak veriye ayrılır.

Tema ve eklenti disiplini fark yaratır. Tek bir sayfayı ölçen araçlarla (Query Monitor, New Relic/Datadog APM) yavaş kancaları (hooks) ve ağır sorguları belirleyin. “Ne kadar az eklenti, o kadar iyi” genellemesi her zaman doğru değildir; ancak işlev çakışması ve kötü yazılmış eklentiler TTFB’yi katlar. Slayt, sayfa kurucu ve görsel efekt eklentilerinin Critical CSS ve defer/async davranışı iyi ayarlanmalıdır. wp-cron görevlerini gerçek system cron ile dakiklik/5 dakikalık aralıklara bağlayın; yoğun sitelerde ALTERNATE_WP_CRON bayraklarından kaçının.

Oturum ve sepet yönetimi ölçeklenebilirlik için kritiktir. Çoklu örnekli yapıda (auto scaling + load balancer) kullanıcı oturumlarını ve sepet verisini tek düğüme bağlamayın. PHP oturumlarını (session) ve transiyentleri Redis’e taşıyın; yük dengeleme algoritmasında “sticky session” yerine stateless yaklaşımı hedefleyin. Dosya yüklemeleri ve ön yüz crop işlemlerini lokal disk yerine nesne depoya aktarmak, yeni örnek eklendiğinde medya tutarlılığını garanti eder.

Güvenlik performansın kardeşidir. Giriş (login) ve xmlrpc uçlarını WAF/firewall kurallarıyla koruyun; rate limit ve fail2ban ile kaba kuvvet denemelerini bastırın. Yönetici yolunu yeniden adlandırmak ve reCAPTCHA/turnstile gibi doğrulamalar bot baskısını azaltır. DDoS kenar koruması, promosyon/indirim kampanyalarında trafiği temiz tutar. Eklenti ve çekirdek güncellemeleri otomatikleştirilirken snapshot alıp, hata halinde geri dönüşü dakikalara indirin; yönetimsel güvenlik ile yedekleme stratejisi birlikte düşünülmelidir.

Gözlemlenebilirlik (observability) günlük işin parçası olsun. APM ile yavaş PHP işlemleri, harici API çağrıları ve veritabanı beklemelerini görün; altyapı metriklerinde CPU, RAM, disk IOPS ve ağ tavanlarını izleyin. RUM ile p50/p95 INP/LCP değerlerini gerçek kullanıcıdan ölçün; vitrin sayfaları ve ödeme sayfaları ayrı panolarda dursun. Alarmları yalnız CPU’ya değil, “p95 > 400ms” ve “checkout 5xx oranı > %0,5” gibi iş metriklerine bağlamak, kapasite aç/kapa davranışını iş hedefleriyle hizalar.

Dağıtım ve test süreci, WooCommerce için özel davranmalıdır. Blue/green veya canary dağıtımda veritabanı şeması değişikliği varsa, önce backward compatible yapıyı yayınlayın; ardından özellik anahtarı (feature flag) ile yeni davranışı açın. Sepet ve ödeme akışlarında smoke test otomatik koşsun; başarısızlıkta load balancer trafiği eski sürüme geri alsın. Büyük güncellemelerden önce snapshot, sonra rollback planı ve CDN önbellek temizliği (purge) listesi hazır olmalıdır.

Maliyet/performans dengesinde doğru boyutlandırma kazandırır. NVMe tabanlı disk, WooCommerce’in en pahalı tıkanıklıklarını çözer; buna karşılık gereğinden fazla vCPU her zaman fayda üretmez. PHP worker sayınız, ortalama istek süresi ve eşzamanlı kullanıcı sayısı üzerinden hesaplanmalıdır. CDN ile egress’i düşürmek ve Redis ile veritabanı üzerindeki okuma yükünü azaltmak, cloud sunucu fiyatlarında hissedilir tasarruf sağlar. Gece saatlerinde minimum örnek sayısını azaltan zamanlanmış ölçek politikaları da faturayı düzeltir.

Sahada uygulanabilir bir kontrol listesi hazırlayın: (1) HTTP/2/3 + TLS 1.3 aktif mi? (2) OPcache ayarları ve PHP-FPM havuzu trafiğe uygun mu? (3) Redis persistent object cache etkin mi ve wp_options autoload şişkinliği temizlendi mi? (4) Full-page cache kuralları WooCommerce istisnalarını doğru kapsıyor mu? (5) Veritabanı InnoDB ve buffer pool boyutu yeterli mi; yavaş sorgu günlüğü izleniyor mu? (6) CDN ve medya offload devrede mi? (7) Oturum/sepet Redis’te mi; load balancer altında stateless mimariye yakın mısınız? (8) Giriş/WP-Admin ve xmlrpc için WAF/firewall/rate limit kuralları hazır mı? (9) APM + RUM panelleri p95/p99 izliyor mu? (10) Büyük güncellemeler öncesi snapshot + geri dönüş senaryosu çalışıyor mu? Bu çerçeve oturduğunda, vitrin sayfalarından ödeme onayına kadar tüm akış hızlı, güvenli ve sürdürülebilir kalır; cloud sunucu altyapınız büyümeyi desteklerken bütçe hattı öngörülebilir olur.

SLA, Uptime ve İzleme: Cloud Sunucuda Kesintisiz Hizmet

Bir dijital hizmetin değeri, yalnız hızından değil, her an erişilebilir olmasından anlaşılır. Bu erişilebilirliği konuşurken üç kavramı ayırt etmek gerekir: söz verilen SLA (Service Level Agreement), ölçülen uptime ve ürün hedefi olarak belirlenen SLO (Service Level Objective). cloud sunucu sağlayıcınızın ilan ettiği SLA altyapı katmanına, sizin belirlediğiniz SLO ise son kullanıcı deneyimine karşılık gelir. Aradaki köprü, iyi tasarlanmış izleme (observability), doğru alarm politikaları ve olay yönetimi (incident response) disiplinidir.

Uptime tek bir yüzde değildir; hata bütçesi kavramıyla anlam kazanır. Örneğin %99,9 aylık hedef, yaklaşık 43,2 dakikalık hata bütçesine denk gelir. Bu süre yalnız tam kesinti değildir; yüksek gecikme (latency), artan hata oranı (5xx) ve kısmi işlev kayıpları da kullanıcı açısından kesinti sayılabilir. Bu nedenle SLI’larınızı (Service Level Indicator) yalnız “ayakta mı?” yerine “p95 yanıt süresi, hata oranı, başarılı ödeme oranı” gibi iş metrikleriyle tanımlayın. Böylece uptime raporu, kullanıcı deneyimiyle örtüşür.

Altyapı dayanıklılığı hedefin temelidir. En az iki kullanılabilirlik alanında (AZ) çalışan uygulama örnekleri, önünde load balancer ve DNS katmanında Anycast modeli ile tek noktaya bağımlılığı kırın. Sağlık kontrolleri yalnız ping değil, HTTP durum kodu ve kritik uçların (/healthz, /checkout) gerçek yanıt süresi üzerinden yapılmalıdır. Depolamada replikalı blok katmanı ve veritabanı replikasyonu; ağda DDoS ve uçta WAF ile katmanlı savunma, SLA hedeflerine yaklaşmak için somut etki üretir.

İzleme mimarisini üç kanalla kurun: altyapı metrikleri, uygulama performans izleme (APM) ve gerçek kullanıcı ölçümü (RUM). Altyapıda CPU/RAM/disk IOPS, ağ, bağlantı sayısı ve disk bekleme (iowait) gibi metrikler; uygulamada istek sayısı (RPS), p95/p99 gecikme, 4xx/5xx oranı, harici API beklemeleri, kuyruk derinliği; RUM’da ise LCP/INP/TTFB gibi Web Vitals değerleri birlikte izlenmelidir. Bu üç kanalın korelasyonu, bir bölgede yavaşlama varken diğerinde normale dönen eğrileri hızlıca ayırt etmenizi sağlar.

Alarm tasarımı, “CPU %80 oldu” düzeyinde kalırsa gürültü üretir. Sinyalleri iş hedeflerine bağlayın: “p95 > 400 ms + RPS > X + hata oranı > %Y → kritik”, “checkout 5xx > %0,5 → P1”, “veritabanı replikasyon gecikmesi > 2 sn → uyarı” gibi birleşik kurallar oluşturun. cloud sunucu tarafında otomatik ölçek (auto scaling) olaylarını da panoya işleyin; ölçek artışıyla p95’in düştüğünü görüyorsanız eşikleriniz doğru çalışıyor demektir. Tersi durumda kapasite açıldığı halde p95 düşmüyorsa darboğaz disk veya veritabanı olabilir.

Sentetik izleme, gerçek trafiğin az olduğu saatlerde erken uyarı sağlar. İstanbul, Ankara ve İzmir gibi farklı çıkış noktalarından düzenli HTTP/HTTPS, DNS ve TCP testleri çalıştırın. TLS sertifika bitiş tarihi, DNS TTL ve kayıt tutarlılığı, load balancer havuz sağlığı bu testlerde yer almalı. Anycast DNS üzerinde sağlık kontrolleri ile hatalı POP devre dışı kaldığında otomatik yön değişimi gözlemlenebilmelidir. Bu düzenek, uptime eğrisindeki ani düşüşleri “yakın gerçek zamanlı” görmenize yardım eder.

Günlükleme ve iz sürme (tracing) olmadan kök neden analizi eksik kalır. Uygulama loglarını, WAF/firewall olaylarını, sistem günlüklerini ve veritabanı denetim kayıtlarını merkezi bir SIEM’e akıtın. Dağıtık izleme (distributed tracing) ile tek bir kullanıcının isteğinin API, veritabanı ve harici servislerdeki yolculuğunu görün; sorunlu segment (ör. ödeme sağlayıcısı) netleşir. Log saklama ve indeksleme politikaları, hem performans hem maliyette dengeyi korumalı; gereksiz ayrıntı yerine ölçüm hedeflerine dönük alanları toplayın.

Bakım pencereleri SLA hesabında gri alandır. “Planlı bakım” etiketi kullanıcı gözünde kesinti olarak algılanır. Blue/green ya da canary dağıtım ile aynı bölgede paralel ortam kurup trafiği kademeli kaydırın; snapshot alarak hızlı geri dönüşü garanti altına alın. Veritabanı şema değişikliklerini backward compatible kurgulayıp özellik bayrağı (feature flag) ile açmak, schema-önce dağıtım stratejisinin kritik parçasıdır. Bu yaklaşım, “bakım” sürelerini gerçek dünyada birkaç saniyelik yer değişimine indirir.

Olay yönetimi (incident response) yazılı ve ölçülebilir olmalıdır. P1/P2/P3 öncelik tanımı, ilk geri dönüş süresi (MTTA), onarma süresi (MTTR) ve iletişim planı netleşsin. Durum sayfası (status page) hem ekip hem kullanıcılar için tek doğruluk noktasıdır; “sorun var mı?” çağrılarının sayısını düşürür. Olay sonrası kök neden analizi (postmortem) suçlayıcı dilden uzak, eylem maddeleriyle biter: “DNS’de yanlış kayıt türü eklendi → değişiklik onayı (four-eyes) zorunlu”, “veritabanı disk sınıfı düşük seçilmiş → IOPS sınıfı ve p95 hedefi izlemeye eklendi” gibi.

Veri ve yedek zinciri uptime kadar kritiktir. snapshot ve yedekleme politikaları olmadan yüksek SLA tek başına anlam taşımaz. PITR (point-in-time recovery) için günlük (binlog/WAL) arşivini ayrı depoda tutun; bölge dışı kopya ve DR tatbikatı takvimli olsun. Yedek depoları için değiştirilemez (immutable) ve sürümlemeli politika, fidye yazılımı riskine karşı son savunmadır. Geri yükleme (restore) süresi RTO hedefi ile test edilmelidir; panolarda “son başarılı yedek” ve “son restore testi” görünür olsun.

Maliyet görünürlüğü, sürekliliğin sürdürülebilir olmasını sağlar. İzleme/LOG/APM lisansları, egress ve depolama tüketimi faturaya yansır. Panolara cloud sunucu fiyatları ile metrikleri birlikte koymak, “p95 düşerken fatura neden arttı?” sorusuna hızlı yanıt verir. Statik görselleri CDN’e taşımak, log saklama süresini iş ihtiyacına göre ayarlamak, yoğun saatlerde akıllı sampling uygulamak ve gereksiz ayrıntıyı maskelemek maliyet disiplinini korur.

Güvenlik ve süreklilik birbirini tamamlar. Kenarda DDoS, uygulamada WAF, içeride en az yetki (RBAC), anahtar kasası (KMS/Secrets) ve bastion erişimi; ihlalleri kesintiye dönüşmeden bastırır. Zafiyet yönetimi ve yama takvimi (Linux/Windows), TLS 1.3, HSTS ve güvenli çerez bayrakları; hem performans hem güven sinyallerini güçlendirir. Gözden kaçan bir ayrıntı, örneğin süresi dolan sertifika, “tam kesinti” ile aynı etkiyi yaratabilir; sertifika bitiş tarihleri için otomatik uyarılar ekleyin.

Sahaya doğrudan uygulanabilir bir kontrol listesi hazırlayın: (1) İki AZ’de en az ikişer örnek ve load balancer var mı? (2) DNS Anycast ve sağlık kontrolleri aktif mi? (3) SLI/SLO tanımları p95/p99 ve hata oranı cinsinden yazıldı mı? (4) APM + RUM + altyapı metrikleri aynı panoda mı? (5) Alarm kuralları birleşik koşul mu; gürültü azaltıldı mı? (6) Blue/green ya da canary dağıtım deneyip geri dönüş test ettiniz mi? (7) snapshot + yedekleme + DR tatbikatı son tarihi nedir? (8) Olay yönetimi, durum sayfası ve postmortem süreci işler mi? (9) İzleme/log maliyetleri ile cloud sunucu fiyatları aynı tabloda izleniyor mu? Bu düzen yerleştiğinde, performans ve erişilebilirlik hedefleri rakamsal olmaktan çıkıp günlük çalışma ritminizin doğal sonucu hâline gelir.

Downtime’sız Migrasyon: Mevcut Sunucudan Cloud’a Geçiş

Canlı trafikte kesinti oluşturmadan mevcut ortamdan cloud sunucu altyapısına geçmek; doğru planlandığında güvenli ve hızlı bir operasyon olabilir. Başarının üç zemini vardır: doğru keşif, paralel kurulum ve kontrollü yön değiştirme. Amaç, mevcut performans ve işlevi kaybetmeden daha esnek, güvenli ve ölçeklenebilir bir mimariye taşınmaktır. Bu süreçte migrasyon planı, RPO/RTO hedefleri, beklenen SLA ve bütçe kısıtları ile uyumlu ilerlemelidir; geçiş süresince iki ortamın bir süre paralel çalışacağını, bunun da cloud sunucu fiyatları üzerinde kısa vadeli bir artış yaratabileceğini baştan kabul etmek gerekir.

İlk adım ayrıntılı keşiftir. Uygulama yığını (dil/çatı), işletim sistemi, bağımlılıklar, cron/planlı işler, çalışan servisler, veritabanı türü/sürümü ve veri boyutu eksiksiz envanterlenir. Medya yükleme yolları, e-posta gönderim yöntemi, harici API’ler ve DNS kayıtları (A/AAAA, MX, TXT, CNAME) çıkarılır. Mevcut sunucuda ortalama ve pik değerler; CPU, RAM, disk IOPS, ağ çıkışı ve p95/p99 yanıt süreleri kayda alınır. Böylece hedef cloud server boyutlandırması veriyle yapılır; gelişigüzel büyük makine seçip gereksiz fatura artışı önlenir.

Hedef mimari, esneklik ve güvenliği aynı anda sağlamalıdır. Türkiye odaklı projeler için düşük gecikme adına yerel bölge seçilir; VPC ile ağ izolasyonu yapılır, katmanlar (web–uygulama–veritabanı) ayrı alt ağlara ayrılır. Ön kapıda load balancer, kenarda DDoS ve uygulama katmanında WAF devreye alınır; örneklere yalnız ihtiyaç duyulan portlar açık bırakılır (firewall). Depolamada NVMe blok disk ve iş yüküne uygun I/O sınıfı seçilir; veritabanı için replikasyon ve HA tasarımı düşünülür. Ekip yetkinliklerine göre Linux cloud sunucu veya Windows cloud sunucu tercih edilir; altyapı IaC (Terraform/Ansible) ile tanımlanır ki aynı kurulum staging ve prod’da bire bir tekrarlanabilsin.

Veri senkronizasyonu geçişin kalbidir. MySQL/MariaDB için row-based replikasyon veya PostgreSQL için mantıksal replikasyonla cloud tarafında bir “read replica” açılır; başlangıç yedeği aktarıldıktan sonra canlı yazma trafiği esnemez. Binlog/WAL akışı ile cloud veritabanı güncel tutulur; kesim anında yazma trafiği kısa bir “dondurma” veya çok küçük bir okuma–yazma bölmesiyle cloud’a çevrilir. Dosya tarafında rsync/robocopy ile ilk büyük kopya yapılır, ardından artımlı delta senkronizasyonları gece pencerelerine alınır. Medya için nesne depolama ve CDN kullanılıyorsa kaynak URL’leri bulut deposuna yönlendirilir; CDN önbellekleri önceden ısıtılır (prewarm) ki kesim sonrası ilk istekler soğuk yakalanmasın.

Uygulama dağıtımı kesintisizliğin görünen yüzüdür. Blue/green yaklaşımında bulutta “yeşil” ortam, canlı ile aynı sürüm/konfigürasyonla ayağa kaldırılır; load balancer üzerinde ayrı hedef grupta sağlık kontrolleri (HTTP kodu + p95 sınırı) geçer. Canary yönteminde ise trafiğin %1 → %5 → %25 gibi kademeleri yeni ortama akıtılır; hata oranı ve gecikme beklenen eşiği aşmazsa yüzde artırılır. Oturumlar ve sepet verisi, sticky session’a bağlı kalmayacak şekilde Redis gibi paylaşımlı bir depoya taşınır; böylece örnek değişse de kullanıcı akışı bozulmaz. Arka plan işleyiciler (queue/worker) yeni ortamda devreye alınır, kuyruk derinliğine göre auto scaling kuralları hazırlanır.

DNS ve trafik kesimi adımında küçük ayrıntılar büyük fark yaratır. Kesimden 48–72 saat önce kritik alan adlarında TTL değerlerini düşürün (300–60 sn). Anycast DNS ve sağlık kontrolleri, sorun halinde otomatik geri dönüşe izin verir. Kurumsal ağlarda IP beyaz liste zorunluluğu varsa, yeni çıkış IP’leri önceden tanımlanır; ödeme sağlayıcıları ve üçüncü taraf servisler bilgilendirilir. Sertifikalar (Let’s Encrypt veya kurumsal) yeni ortamda hazırlanır; WAF ve firewall kuralları şablon olarak uygulanır. Kesim anında load balancer trafiği yeni hedef grubuna taşır veya DNS yeni IP’ye bakar; eski ortam bir süre daha yalnızca arka plan işleri ve read-only raporlar için açık kalabilir.

Test ve doğrulama geçişi görünmez kılar. Sentetik testlerle (HTTP, TLS, DNS) ülke içi farklı noktalardan p50/p95 TTFB ölçülür; gerçek kullanıcı ölçümü (RUM) ile eski–yeni karşılaştırması yapılır. APM, yavaş istekler ve harici API beklemelerini gösterir; IOPS ve ağ tavanları izlenir. Sepet/ödeme akışlarında otomatik smoke test senaryosu çalışır. Beklenmedik bir sapma varsa, planlı bir tıklama ile snapshot’tan geri dönüp trafiği eski ortama almak için runbook hazırdır; DNS TTL düşük olduğu için geri dönüş de hızla etkisini gösterir.

Güvenlik ve gizli anahtar yönetimi geçişte ayrı bir akıştır. API anahtarları ve parolalar gizli kasada tutulur; üretim dosya sistemine düz metin yazılmaz. Panel ve API erişimi 2FA ile korunur; VPC içinde yalnız gerekli portlar açıktır. DDoS kenarda, WAF uygulamada aktiftir; giriş uçlarında rate limit kuralları uygulanır. Veritabanı bağlantıları şifreli kanaldan yapılır; diskler bulut tarafında beklemede şifreli çalışır. Kesimden önce ve sonra snapshot + yedekleme kopyaları alınır; geri yükleme tatbikatının tarihi günceldir.

SEO ve e-posta ayrıntıları kullanıcı deneyimini korur. Alan adı değişmiyorsa kanonikler, robots.txt ve site haritaları aynı kalır; yalnızca orijin/IP değişir. Alan adı değişiyorsa 301 haritası bire bir hazırlanır; Search Console adres değişikliği adımı atlanmaz. CDN geçişinde cache key ve varyant kuralları aynen taşınır; brotli/gzip ve HTTP/2/3 açık tutulur. E-posta gönderimleri için SPF/DKIM/DMARC TXT kayıtları yeni DNS’te eksiksizdir; cloud hosting tarafında ters DNS (PTR) ve TLS raporları kontrol edilir ki teslim edilebilirlik etkilenmesin.

Maliyet ve kapasite planı şeffaf olmalıdır. Paralel çalışma döneminde iki ortam birden kaynak tüketir; bu nedenle bulut tarafında “gerektiği kadar” boyutlandırma yapılır. cloud sunucu fiyatları için kısa süreli yüksek I/O işi varsa disk sınıfı geçici yükseltilir, işlem bitince eski sınıfa dönülür; geceleri minimum örnek sayısı düşürülür. Geçiş tamamlandığında eski ortam kapatılır, yalnızca arşivleyip saklanacak günlükler taşınır; gereksiz egress maliyetleri ve log depolama tüketimi temizlenir.

Konteyner geçişleri benzer prensiplerle yürür. Docker imajları küçük katmanlarla optimize edilir; Kubernetes üzerinde readiness/liveness prob’ları, HPA (özel metrikle tetiklenen yatay ölçek) ve PodDisruptionBudget tanımlanır. Ingress + load balancer kesim için merkezi kapı olur; gizli anahtarlar secrets ile yönetilir. Duruma göre VM’den konteynere “kaldır–taşı” yerine önce bileşenleri ayrıştırıp kademeli geçiş (strangler pattern) uygulanır; risk dağıtılır.

Geçiş günü için pratik bir akış kurgulanır: saatler öncesinden son artımlı dosya senkronizasyonu, veritabanı replikasyon gecikmesinin kontrolü, CDN ön ısıtması, TLS/sertifika ve WAF kurallarının gözden geçirilmesi, alarm panellerinin “kesim” etiketleriyle açılması; kesim düğmesi basıldığında load balancer hedef grubunun değiştirilmesi; 15–30 dakikalık yakın takipte p95/p99, 5xx ve iş metriklerinin (sipariş/adım tamamlama) izlenmesi; sorun halinde anında geri dönüş. Bu disiplin, bulut sunucu mimarisinin vaad ettiği esnekliği gerçek dünyada downtime yaşamadan elde etmenizi sağlar.