Pengujian DR Tanpa Dampak

Rencana pemulihan bencana yang belum pernah diuji hanyalah hipotesis. Pengalaman di dunia nyata menunjukkan bahwa rencana DR sering kali mengungkap celah—pergeseran konfigurasi, otomatisasi yang hilang, buku pedoman yang kedaluwarsa, atau waktu mulai yang lebih lama dari perkiraan—yang hanya muncul dalam kondisi pengujian. Pengujian DR secara berkala adalah satu-satunya cara untuk memastikan bahwa rencana Anda akan berfungsi saat paling dibutuhkan.

Test Failover adalah fitur bawaan Azure Site Recovery yang memungkinkan Anda menyimulasikan pengalihan ke wilayah sekunder tanpa mengganggu produksi. Selama pengalihan uji, ASR membuat salinan VM yang direplikasi di jaringan virtual terisolasi pada wilayah sekunder. VM produksi tetap berjalan normal di wilayah primer, sehingga tidak ada risiko bagi pengguna aktif.

VNet uji yang terisolasi tidak boleh memiliki konektivitas ke sistem produksi. Hal ini mencegah VM uji menulis ke basis data produksi secara tidak sengaja, mengirim email kepada pelanggan sebenarnya, atau memicu transaksi pembayaran. Buat VNet pengalihan uji khusus tanpa peering ke VNet produksi dan tanpa akses internet, lalu gunakan VNet tersebut hanya untuk latihan DR.

Uji DR harus memvalidasi serangkaian kriteria tertentu:

• Waktu boot — apakah semua VM dimulai dalam jangka waktu yang diharapkan?
• Mulai aplikasi — apakah aplikasi diinisialisasi dengan benar saat terhubung ke basis data yang dipulihkan?
• Integritas data — apakah data pada titik pemulihan konsisten dan lengkap?
• RTO aktual — ukur total waktu yang berlalu sejak pemicu pengalihan hingga aplikasi melayani permintaan
• Eksekusi buku pedoman — apakah semua skrip otomatisasi selesai dengan sukses?

Selama pengujian, mulai penghitung waktu tepat saat Anda memicu pengalihan uji. Hentikan penghitung waktu ketika aplikasi dipastikan sehat (probe kesehatan penyeimbang beban mengembalikan 200 OK). Inilah RTO aktual Anda. Bandingkan dengan RTO target Anda. Jika nilai aktual melebihi target, identifikasi hambatannya—mulai VM yang lambat, inisialisasi basis data yang lama, atau keterlambatan propagasi DNS—lalu atasi hambatan tersebut.

Setelah pengalihan uji selesai, sambungkan ke basis data yang dipulihkan dan verifikasi datanya. Periksa apakah transaksi yang di-commit sebelum batas replikasi tersedia, serta apakah transaksi yang hanya sebagian di-commit ditangani dengan benar (dibatalkan atau diselesaikan). Untuk basis data yang mendukung pemulihan titik waktu (PITR), uji pemulihan ke timestamp tertentu dan verifikasi keadaan data yang diharapkan.

Setelah pengujian selesai, Anda harus membersihkan sumber daya pengalihan uji—VM uji, disk, dan antarmuka jaringan di wilayah sekunder. Azure Site Recovery menyediakan tindakan 'Cleanup test failover' di portal yang secara otomatis menghapus semua sumber daya uji. Lupa melakukan pembersihan akan membuang biaya dan memenuhi wilayah sekunder dengan sumber daya yang sudah tidak digunakan.

Setelah setiap uji DR, tulislah laporan pengujian yang mencakup: tanggal dan cakupan pengujian, RTO dan RPO aktual yang dicapai, daftar periksa item validasi beserta status lulus/gagal, celah atau kegagalan yang ditemukan, serta tindakan perbaikan yang direncanakan. Laporan ini berguna untuk audit kepatuhan (ISO 27001, SOC 2, HIPAA) dan untuk melacak peningkatan kematangan DR dari waktu ke waktu.

Praktik terbaik industri dan kerangka kerja kepatuhan biasanya mewajibkan uji DR minimal setahun sekali, tetapi banyak organisasi menguji setiap kuartal atau bahkan setiap bulan untuk beban kerja Tingkat 1. Pengujian yang lebih sering mendeteksi pergeseran konfigurasi lebih awal serta membangun kepercayaan diri dan pengalaman tim. Otomatiskan sebanyak mungkin penyiapan dan verifikasi pengujian untuk mengurangi upaya yang diperlukan dalam pengujian rutin.

Azure Chaos Studio adalah layanan rekayasa chaos terkelola yang memungkinkan Anda menyuntikkan kegagalan terkendali ke sumber daya Azure untuk menguji ketahanan aplikasi. Anda dapat mematikan VM, membuat zona gagal, membatasi CPU, atau menyuntikkan latensi jaringan untuk mengamati perilaku aplikasi. Berbeda dari latihan DR standar, rekayasa chaos menguji apakah aplikasi Anda menurun secara terkendali dalam kondisi kegagalan sebagian.

Pengujian DR paling bermanfaat jika menjadi bagian dari siklus peningkatan berkelanjutan: Rencanakan → Jalankan → Ukur → Perbaiki → Ulangi. Setelah setiap pengujian, atasi celah yang ditemukan, perbarui buku pedoman dan dokumentasi, lalu lakukan pengujian lagi. Seiring waktu, kesenjangan antara target RTO/RPO yang Anda tetapkan dan nilai aktual yang dicapai seharusnya menyempit hingga Anda secara konsisten lulus dalam setiap pengujian sesuai toleransi.

Uji pemahaman Anda tentang konsep Microsoft Azure Fundamentals (AZ-900) dari pelajaran ini.

Dalam pelajaran ini, Anda mempelajari bahwa pengalihan uji memungkinkan Anda menyimulasikan peristiwa DR tanpa mengganggu produksi dengan membuat salinan VM di VNet terisolasi; Anda harus mengukur RTO aktual dan memverifikasi integritas data selama pengujian; serta Anda harus membersihkan sumber daya uji dan mendokumentasikan hasil setelah setiap latihan. Selanjutnya, kita akan membahas pemulihan bencana khusus untuk layanan PaaS seperti Azure SQL Database.