Definisikan kesiapan berdasarkan hasil pelanggan
Mulailah dengan hasil, bukan label infrastruktur. Halaman depan yang bisa dijangkau tidak cukup jika pengunjung tidak bisa menyelesaikan tugas yang penting. Untuk setiap perjalanan kritis, nyatakan siapa yang mencoba melakukan apa, apa arti keberhasilan, dan hasil mana yang tidak dapat diterima. Mulailah dengan beberapa perjalanan agar tim bisa membuat keputusan nyata.
Klasifikasikan setiap langkah sebagai esensial, penting, atau dapat ditunda. Esensial berarti perjalanan tidak bisa selesai tanpanya; penting mungkin mengizinkan solusi darurat terbatas waktu; dapat ditunda berarti bisa dihilangkan, ditunda, atau disederhanakan. Ini adalah keputusan produk yang diinformasikan oleh engineering, bukan peringkat teknis universal.
Catat hasil yang dapat digunakan, misalnya pesanan diterima dan konfirmasi tersimpan, bukan hanya target respons halaman.
Petakan dependensi dan putuskan apa yang bisa menurun
Untuk setiap jalur kritis, petakan hosting atau delivery, DNS, layanan aplikasi, basis data, otentikasi, email, pembayaran, pencarian, tag, alat persetujuan (consent), dan API eksternal. Catat pemilik, jalur dukungan, batas relevan, dan efek pada pengguna jika masing‑masing tidak tersedia. OWASP merekomendasikan wawasan ke dalam dependensi perangkat lunak; disiplin kepemilikan yang sama membantu dengan dependensi operasional.
Dependensi keras menghentikan tugas saat gagal. Dependensi lunak dapat absen atau basi sementara tugas inti masih bekerja. AWS menggambarkan graceful degradation sebagai menjaga fungsi inti tetap tersedia ketika dependensi tidak sehat. Definisikan pilihan spesifik produk: sembunyikan widget nonesensial, tunda laporan, atau tampilkan fallback jujur. Jangan menciptakan inventori, harga, status pesanan, atau hasil pembayaran secara fiktif.
Tangkap tujuan, pemilik, batas yang diketahui, fallback, kontak perubahan, dan tanggal uji terakhir untuk setiap item.
Ubah prakiraan lalu lintas menjadi eksperimen kapasitas
Gunakan skenario, bukan satu angka lalu lintas. Nyatakan peristiwa, pola kedatangan, campuran permintaan, proporsi pengguna yang signed-in, geografis, aktivitas checkout atau penulisan bersamaan, dan periode puncak. Sertakan kasus tinggi dan asumsi. Google mencatat bahwa permintaan dapat memiliki biaya sumber daya yang sangat berbeda, sehingga permintaan per detik saja bisa menjadi model kapasitas yang buruk.
Uji lalu lintas yang berkelanjutan, representatif, end-to-end terhadap konfigurasi yang dekat dengan produksi, dengan persetujuan dan pengaman. AWS memperingatkan untuk tidak hanya menguji komponen, menggunakan subset permintaan yang tidak representatif, atau berhenti pada margin kecil di atas beban yang diperkirakan. Dokumentasikan kendala atau perlambatan pertama yang teramati. Uji di produksi langsung dapat memengaruhi pelanggan; gunakan lingkungan terkontrol kecuali latihan terencana dan didukung staf sesuai.
Simpan skenario, konfigurasi, campuran permintaan, durasi, kendala yang diamati, perubahan kapasitas, dan pemilik tindak lanjut.
Siapkan pilihan perubahan, rollback, dan pemulihan
Sebelum perubahan bernilai tinggi, identifikasi artefak atau konfigurasi untuk dikembalikan, persetujuan yang dibutuhkan, orang yang berwenang, dan metode validasi. Simpan runbook singkat untuk menghentikan rilis, mengembalikan deployment, menonaktifkan feature flag, mengurangi integrasi nonkritis, atau mengembalikan data menggunakan prosedur yang disetujui. Uji mekaniknya sebelum peristiwa; cadangan atau rencana rollback yang belum dilatih adalah sebuah asumsi.
Tetapkan objektif pemulihan berdasarkan dampak bisnis. Recovery Time Objective, atau RTO, adalah jeda maksimum yang dapat diterima sebelum layanan dipulihkan. Recovery Point Objective, atau RPO, adalah kehilangan data maksimum yang dapat diterima diukur dari titik pemulihan terakhir. AWS memperingatkan terhadap target yang sewenang‑wenang atau tidak realistis dan mencatat bahwa objektif dependensi memengaruhi apa yang dapat dicapai. Perlakukan target sebagai tujuan perencanaan, bukan janji ke pelanggan.
Verifikasi rollback atau restorasi terbatas dan aman serta catat apa yang diperiksa, oleh siapa, dan setiap celah yang ditemukan.
Tugaskan kepemilikan sebelum keputusan menjadi mendesak
Daftar kontak saja bukan kepemilikan. Untuk setiap jalur kritis, tetapkan pemilik bisnis untuk hasil yang dapat diterima, pemilik teknis untuk implementasi, dan pemilik keputusan yang berwenang membuat perubahan pelindung. Nama cadangan dan jelaskan kapan penyedia, agensi, pemroses pembayaran, atau tim internal memegang tindakan selanjutnya.
Jalankan tinjauan kesiapan singkat sebelum lalu lintas datang. Ulas satu kegagalan dependensi: apa yang tetap tersedia, tuas mana yang aman, siapa yang menyetujuinya, dan bagaimana keberhasilan diperiksa. Ini adalah latihan proaktif, bukan laporan status langsung. Catat tindakan bertanggal, pemilik, dan tanggal jatuh tempo.
Pra-otorisasi tindakan aman sempit bila sesuai agar perlindungan tidak menunggu rantai persetujuan yang tidak jelas.
Perlakukan jalur sensitif pembayaran dan keamanan dengan perhatian ekstra
Kesiapan checkout harus menjaga kebenaran selain ketersediaan. Jangan melewati otorisasi, melemahkan kontrol akses, mengekspos kredensial, atau mengubah skrip halaman pembayaran secara sembarangan. Panduan PCI SSC membahas otorisasi, integritas, dan deteksi pengubahan (tamper detection) untuk skrip halaman pembayaran dan header HTTP yang berdampak keamanan. Jika situs menerima kartu atau menggunakan frame pembayaran tersemat, mintalah pedagang, pemroses, akseptor (acquirer), dan penasehat keamanan atau kepatuhan yang memenuhi syarat meninjau perubahan material.
Simpan inventaris skrip produksi, integrasi, versi, dan kepemilikan akun, dan batasi siapa yang dapat mengubahnya. OWASP mencatat bahwa inventaris dependensi dan pin versi dapat mengurangi ketidakpastian tentang apa yang masuk ke build, sementara temuan otomatis tetap memerlukan verifikasi manual. Praktik ini mendukung kesiapan tetapi tidak menetapkan kepatuhan PCI atau menggantikan penilaian keamanan.
Gunakan hanya alur alternatif yang disetujui dan ditinjau oleh pemroses; jangan pernah mengumpulkan data kartu melalui saluran informal.