Bir barındırma planıyla değil, iş yükünüzle başlayın
Değer veya risk oluşturan yolculukları listeleyin: ilk ziyaret, arama, oturum açma, ürün detayı, form gönderimi, ödeme, editör güncellemesi veya API çağrısı. Her biri için zirve istek sayısını veya eşzamanlı kullanıcıyı, yüklemeyi, kişiselleştirmeyi, bağımlılıkları ve ziyaretçi bölgelerini kaydedin. Zamanlanmış ve yönetici işleri de aynı kaynakları tükettiği için dahil edin.
Listeyi kabul ölçütlerine dönüştürün. Largest Contentful Paint (LCP) ana içeriğin yüklenmesini; Interaction to Next Paint (INP) etkileşim duyarlılığını; Cumulative Layout Shift (CLS) beklenmeyen yer değiştirmeyi ölçer. Google iyi hedefleri LCP için 2.5 saniye içinde, INP için 200 milisaniyenin altında ve CLS için 0.1’in altında olarak tanımlar. Rota tamamlanması, sunucu yanıt süresi ve hata oranı hedefleri ekleyin.
Hızlı önbelleklenmiş bir sayfanın kimlik doğrulamalı veya veritabanı destekli bir işlemin yerini almasına izin vermeyin.
Zirve dönemi, beklenen büyüme, kampanya sıçramaları ve örtüşen toplu işleri tanımlayın.
Olası darboğazların her birinin host, sizin ekibiniz veya üçüncü taraf tarafından mı kontrol edildiğini işaretleyin.
Kapasiteyi, limitleri ve ölçekleme davranışını karşılaştırın
Teklifin arkasındaki limitleri sorun: işlemci ve bellek, depolama performansı, veritabanı bağlantıları, işçi (worker) limitleri, ağ ücretleri, istek kontrolleri ve paylaşılan komşu (noisy neighbor) kısıtları. “Sınırsız bant genişliği” uygulamanın zirvede yeterince önbelleksiz işi yapıp yapamayacağını göstermez. Hangi metriklerin görülebildiğini ve ne kadar süreyle saklandığını sorun.
Ölçekleme, tetikleyicisi, gecikmesi, tavanı ve fiyatı bilindiğinde önem taşır. Bunun otomatik olup olmadığını, oturumların ve işlerlerin güvende kalıp kalmadığını ve tavan ulaşıldığında ne olacağını doğrulayın. Teorik kapasite iddialarına göre değil beklenen zirvede ve ötesinde bir testi tercih edin. Boşta kapasite (headroom) evrensel bir yüzde değil, iş kararıdır.
Sadece ortalamaya bakmayın; p95 veya p99 yanıt sürelerini karşılaştırın.
Test sırasında veritabanı, kuyruk ve üst akış API zamanlamalarını toplayın.
Taşınma, teslimat, yedekleme ve ikinci bölge maliyetlerini taahhüt etmeden önce tahmin edin.
Orijini kasıtlı seçin ve teslimatı doğrulayın
Hedef kitle konumu, uygulama bağımlılıkları, veri konumu gereksinimleri ve işletme erişimini kullanarak bir orijin bölgesi seçin. Temsili coğrafyalardan ve ağ koşullarından test edin. İçerik dağıtım ağı (CDN), uygun varlıkları ziyaretçilere daha yakın sunabilen ve orijin işini azaltabilen dağıtılmış bir önbellektir; sağlıklı bir orijin, veritabanı veya uygulamanın yerini tutmaz.
Sadece panodaki bir ayara bakmayın; başlıkları ve davranışı inceleyin. Sürüm numarasıyla versiyonlanmış statik varlıklar genellikle daha uzun yaşam sürelerine sahip olabilir çünkü güncelleme yeni bir URL verir. Dinamik ve kişiselleştirilmiş yanıtlar açık kurallar gerektirir. HTTP paylaşılan önbellekleri özel olandan ayırır; hesap detaylarının başka bir müşteri tarafından yeniden kullanılmaması gerekir. Bir önbellek temizleme ve geri alma (rollback) prosedürünü prova edin.
Önbellek durumları farklı olduğu için ilk ziyaret ve tekrar ziyaret durumlarını yakalayın.
Sayfalar, varlıklar, çerezler, parametreler ve yerel ayar için Cache-Control ve önbellek anahtarlarını doğrulayın.
Yetkili personelin hassas içeriği açığa çıkarmadan zararlı bir kuralı devre dışı bırakma yöntemini belgeleyin.
Kurtarma kanıtını performans gereksinimi olarak ele alın
Neyin yedeklendiğini, kopyaların nerede tutulduğunu, saklama süresini, geri yükleme yetkisini ve yedeklerin veritabanları, yüklemeler, kod, yapılandırma ve altyapıyı kapsayıp kapsamadığını sorun. Kurtarma nokta hedefini (RPO) kabul edilebilir veri kaybı süresi ve kurtarma süresi hedefini (RTO) kabul edilebilir geri yükleme süresi olarak tanımlayın. Her ikisini de paket varsayılanından değil iş sonuçlarından belirleyin.
Başarılı bir yedekleme, kurtarma kanıtı sağlamaz. CISA planlı kurtarma testlerini, AWS ise felaket kurtarmanın değerlendirilip test edilmesi gerektiğini önerir. İzole bir ortamda yakın tarihli bir kopyayı geri yükleyin, önemli kayıtları ve medyayı kontrol edin, belgelenmiş sıralamayı kullanın ve geçen süreyi kaydedin. Alternatif bir bölge bazı riskleri azaltabilir ama maliyet ve karmaşıklık ekler.
Mevcut veriyi üzerine yazmadan tek bir dosya veya kaydı geri yükleyin.
Geri yükleme erişimini sınırlayın ve kurtarma kimlik bilgileri ile çalışma kitaplarını yetkili müdahalecilerin erişebileceği halde tutun.
Bir veritabanı anlık görüntüsü ayarları, uygulama sürümlerini veya teslimat kurallarını yeniden yaratmayabilir.
Desteği ve paylaşılan sorumluluğu ihtiyaç olmadan önce değerlendirin
Destek kapsamını, saatlerini, kanallarını, yükseltmeyi ve platform olaylarıyla uygulama hata ayıklamanın farkını karşılaştırın. Yama, yönetilen veritabanları, TLS, güvenlik duvarı kuralları, yedeklemeler ve geri yükleme için yazılı sorumluluk alın. Bir destek taahhüdü, gerçekçi bir senaryoda sahibin ve sonraki aksiyonun adını verdiğinde işe yarar.
Erişim rollerini, çok faktörlü kimlik doğrulamayı, denetim günlüklerini, gizli anahtar yönetimini ve hesap izolasyonunu gözden geçirin. Ödeme kartları veya hassas düzenlemeye tabi veriler için yalnızca barındırma özellikleri uyumluluk sağlamaz. Bu karşılaştırmayı teknik girdi olarak kullanın ve ödeme mimarisi ile uygulanabilir yükümlülükler için nitelikli güvenlik, hukuk veya uyumluluk incelemesi alın.
Sağlayıcının başarısız bir geri yüklemeyi, doygun bir veritabanını veya zararlı bir önbellek kuralını nasıl ele aldığını sorun.
Kimin üretimi değiştirebildiğini, yedekleri okuyabildiğini, günlükleri görebildiğini ve kimlik bilgileri oluşturabildiğini kontrol edin.
Hizmet kredileri ve yönetilen kapsam maddi koşullara sahip olabilir.
Gerçekçi, güvenli karşılaştırma testleri yapın ve skor kartı tutun
Her aday için aynı sürümü, yapılandırma niyetini ve test senaryosunu kullanın. Bir temel (baseline), beklenen zirve, kısa sıçrama, sürdürülebilir dönem ve güvenli bir kurtarma veya dağıtım egzersizi çalıştırın. AWS, üretime benzer ortamlar, tanımlı senaryolar, mimari çapında izleme, temizlenmiş veya sentetik veri ve düzenli yeniden test önermektedir. Sağlayıcıdan onay alın ve test politikasına uyun.
Kontrollü laboratuvar testlerini lansman sonrası saha verileriyle birleştirin. Laboratuvar testleri hata ayıklama için tekrarlanabilirdir; saha verisi gerçek cihazları, ağları, coğrafyayı, önbellek durumunu ve davranışı yansıtır. Büyük sürümler veya bağımlılık değişikliklerinden sonra skor kartını yeniden gözden geçirin. SIU bulguları lansman öncesi sertleştirme, sahipliğe atanmış düzeltme ve geri almayı hazır iyileştirmelere dönüştürebilir.
Konumları, eşzamanlılığı, önbellek durumunu ve yükleri tutarlı tutun.
Rota zamanlamaları, hatalar, kaynak metrikleri, sürümler, maliyetler ve gözlemleri saklayın.
Belgelendirilmiş ihtiyaçları sürdürülebilir işletme maliyetiyle karşılayan seçeneği tercih edin.