Mulai dari beban kerja Anda, bukan paket hosting
Daftar perjalanan yang menciptakan nilai atau risiko: kunjungan pertama, pencarian, masuk, detail produk, pengiriman formulir, checkout, pembaruan editor, atau panggilan API. Untuk masing-masing, catat puncak permintaan atau pengguna simultan, payload, personalisasi, dependensi, dan wilayah pengunjung. Sertakan pekerjaan terjadwal dan admin karena mereka mengonsumsi sumber daya yang sama.
Ubah daftar menjadi ukuran penerimaan. Largest Contentful Paint (LCP) mengukur pemuatan konten utama; Interaction to Next Paint (INP) mengukur responsivitas; dan Cumulative Layout Shift (CLS) mengukur pergeseran tak terduga. Google menggambarkan target bagus sebagai LCP dalam 2,5 detik, INP di bawah 200 milidetik, dan CLS di bawah 0,1. Tambahkan target penyelesaian rute, waktu respons server, dan tingkat kesalahan.
Jangan biarkan halaman cache cepat menggantikan transaksi yang diautentikasi atau bergantung pada basis data.
Definisikan periode puncak, pertumbuhan yang diharapkan, lonjakan kampanye, dan pekerjaan batch yang tumpang tindih.
Tandai apakah bottleneck kemungkinan dikendalikan oleh host, tim Anda, atau pihak ketiga.
Bandingkan kapasitas, batas, dan perilaku penskalaan
Minta batasan di balik penawaran: compute dan memori, performa penyimpanan, koneksi basis data, batas pekerja, biaya jaringan, kontrol permintaan, dan kendala tetangga bersama. “Bandwidth tak terbatas” tidak menunjukkan apakah aplikasi dapat melakukan pekerjaan yang cukup tanpa cache pada puncak. Tanyakan metrik apa yang terlihat dan berapa lama tersedia.
Penskalaan penting hanya ketika pemicu, penundaan, batas atas, dan harga diketahui. Konfirmasi apakah penskalaan otomatis, apakah sesi dan job tetap aman, dan apa yang terjadi pada batas atas. Lebih baik menguji pada puncak yang diharapkan dan melampauinya daripada mengandalkan klaim kapasitas teoretis. Headroom adalah keputusan bisnis, bukan persentase universal.
Bandingkan waktu respons p95 atau p99, bukan hanya rata-rata.
Kumpulkan waktu basis data, antrean, dan API hulu selama pengujian.
Perkirakan biaya penskalaan, pengiriman, cadangan, dan wilayah kedua sebelum berkomitmen.
Tempatkan origin dengan sengaja dan validasi pengiriman
Pilih wilayah origin berdasarkan lokasi audiens, dependensi aplikasi, kebutuhan lokasi data, dan akses operasi. Uji dari geografi dan kondisi jaringan yang mewakili. Content Delivery Network (CDN) adalah cache terdistribusi yang dapat menyajikan aset yang memenuhi syarat lebih dekat ke pengunjung dan mengurangi beban origin; CDN tidak menggantikan origin, basis data, atau aplikasi yang sehat.
Periksa header dan perilaku, bukan hanya pengaturan di dashboard. Aset statis yang diberi versi biasanya dapat memiliki masa hidup yang lebih lama karena pembaruan memiliki URL baru. Respons dinamis dan personalisasi memerlukan aturan eksplisit. HTTP membedakan cache bersama dari cache privat; detail akun tidak boleh menjadi dapat digunakan kembali oleh pelanggan lain. Latih prosedur purge cache dan rollback.
Tangkap kunjungan pertama dan kunjungan kembali karena status cache berbeda.
Verifikasi Cache-Control dan kunci cache untuk halaman, aset, cookie, parameter, dan lokal.
Dokumentasikan bagaimana staf berwenang menonaktifkan aturan berbahaya tanpa mengekspos konten sensitif.
Anggap bukti pemulihan sebagai persyaratan kinerja
Tanyakan apa yang dicadangkan, di mana salinan disimpan, retensi, otoritas restore, dan apakah cadangan meliputi basis data, upload, kode, konfigurasi, dan infrastruktur. Definisikan recovery point objective (RPO) sebagai kehilangan data yang dapat diterima dalam waktu, dan recovery time objective (RTO) sebagai waktu restorasi yang dapat diterima. Tetapkan keduanya berdasarkan konsekuensi bisnis, bukan default paket.
Cadangan yang berhasil bukan bukti pemulihan. CISA merekomendasikan pengujian pemulihan terjadwal, dan AWS mengatakan pemulihan bencana harus dinilai dan diuji. Pulihkan salinan terkini secara terisolasi, periksa catatan penting dan media, gunakan urutan yang didokumentasikan, dan catat waktu yang berlalu. Wilayah alternatif dapat mengurangi beberapa risiko tetapi menambah biaya dan kompleksitas.
Pulihkan satu file atau rekaman tanpa menimpa data saat ini.
Batasi akses restore dan simpan kredensial pemulihan serta runbook yang tersedia bagi penanggap yang berwenang.
Snapshot basis data mungkin tidak merekonstruksi pengaturan, versi aplikasi, atau aturan pengiriman.
Nilai dukungan dan tanggung jawab bersama sebelum diperlukan
Bandingkan ruang lingkup dukungan, jam layanan, saluran, eskalasi, dan perbedaan antara insiden platform dan pemecahan masalah aplikasi. Dapatkan tanggung jawab tertulis untuk patch, basis data terkelola, TLS, aturan firewall, cadangan, dan restorasi. Janji dukungan berguna ketika menamai pemilik dan tindakan selanjutnya dalam skenario yang realistis.
Tinjau peran akses, autentikasi multi-faktor, log audit, penanganan rahasia, dan isolasi akun. Untuk kartu pembayaran atau data sensitif yang diatur, fitur hosting saja tidak membangun kepatuhan. Gunakan perbandingan ini sebagai masukan teknis dan dapatkan tinjauan keamanan, hukum, atau kepatuhan yang memenuhi syarat terhadap arsitektur pembayaran dan kewajiban yang berlaku.
Tanyakan bagaimana penyedia menangani restore yang gagal, basis data jenuh, atau aturan cache yang merusak.
Periksa siapa yang dapat mengubah produksi, membaca cadangan, melihat log, dan membuat kredensial.
Kredit layanan dan cakupan terkelola dapat memiliki kondisi material.
Lakukan pengujian perbandingan yang realistis dan aman serta simpan skor
Gunakan rilis, intent konfigurasi, dan skrip uji yang sama untuk setiap kandidat. Jalankan baseline, puncak yang diharapkan, lonjakan singkat, periode berkelanjutan, dan latihan pemulihan atau penyebaran yang aman. AWS merekomendasikan lingkungan yang menyerupai produksi, skenario yang terdefinisi, pemantauan seluruh arsitektur, data yang disanitasi atau sintetis, dan pengujian ulang berkala. Dapatkan persetujuan penyedia dan ikuti kebijakan pengujiannya.
Gabungkan pengujian laboratorium terkontrol dengan data lapangan setelah peluncuran. Pengujian lab dapat diulang untuk debugging; data lapangan mencerminkan perangkat nyata, jaringan, geografi, status cache, dan perilaku. Kunjungi kembali skor setelah rilis besar atau perubahan dependensi. SIU dapat mengubah temuan menjadi penguatan pra-peluncuran, remediasi yang ditugaskan pemilik, dan perbaikan siap-rollback.
Jaga lokasi, konkurensi, status cache, dan payload tetap konsisten.
Simpan waktu rute, kesalahan, metrik sumber daya, versi, biaya, dan pengamatan.
Pilih opsi yang memenuhi kebutuhan yang terdokumentasi dengan biaya operasi yang berkelanjutan.