Bagaimana cara merancang strategi disaster recovery dengan RPO dan RTO yang eksplisit?

Pertanyaan dan ruang lingkup

Rancang pemulihan untuk SaaS single-region setelah terjadi pemadaman di seluruh wilayah (region-wide outage). Bisnis membutuhkan batas kehilangan data maksimum satu jam (RPO) dan pemulihan layanan dalam waktu empat jam (RTO). Asumsikan 1.000 permintaan per detik pada puncaknya adalah asumsi wawancara, bukan fakta produksi yang terukur; aplikasi bersifat stateless, database utama bersifat relasional, dan object storage berisi unggahan pengguna.

Desain harus memulihkan data, kode aplikasi, konfigurasi, rahasia (secrets), perutean (routing), dan akses operator. Desain ini juga harus mencegah database utama yang rusak (corrupted) disalin secara membabi buta ke region pemulihan. "Kami memiliki backup" bukanlah jawaban yang lengkap: frekuensi backup, waktu pemulihan, otoritas failover, dan bukti dari drill harus sesuai dengan tujuan yang ditetapkan.

Apa yang sedang diuji oleh pewawancara

Buku panduan wawancara system design membingkai disaster recovery sebagai masalah RPO/RTO gaya wawancara dan mengharapkan domain kegagalan yang eksplisit, pilihan pemulihan, dan bukti operasional. AWS mendefinisikan RPO dan RTO sebagai target pemulihan yang ditetapkan oleh kebutuhan bisnis, kemudian merekomendasikan strategi yang terdefinisi, pengujian, pengelolaan configuration drift, dan otomatisasi.

Jawaban yang kuat:

• menerjemahkan RPO ke dalam frekuensi replikasi atau backup dan mengukur lag;
• menerjemahkan RTO ke dalam anggaran pemulihan, promosi, deployment, perutean, dan verifikasi;
• memisahkan pemulihan data plane dari tindakan control-plane yang mungkin tidak tersedia;
• memilih pilot light, warm standby, atau active/active berdasarkan biaya dan target, daripada menyebutkan multi-region secara default;
• melatih pemulihan dan failover, termasuk untuk data yang rusak dan konfigurasi yang usang.

Pertanyaan klarifikasi sebelum menjawab

1. Apakah RPO berlaku sama untuk pembayaran, profil, dan unggahan? Penjenjangan (tiering) dapat memberikan catatan kritis target yang lebih ketat daripada analitik.
2. Apakah bencananya berupa kehilangan region, deployment yang buruk, atau kerusakan logis (logical corruption)? Replikasi membantu kasus pertama tetapi dapat menyalin kasus kedua; backup point-in-time diperlukan untuk rollback.
3. Haruskah operasi penulisan (writes) berlanjut selama failover? Jika ya, pilih otoritas penulisan dan kebijakan konflik; jika tidak, jeda pemulihan read-only akan menyederhanakan kebenaran data.
4. Apakah RTO empat jam diukur hingga keberhasilan health-check, lalu lintas pelanggan, atau paritas fitur penuh? Runbook harus menyebutkan pencapaian (milestone) tersebut.
5. Bisakah akun pemulihan dan control plane dioperasikan secara independen? Kuota yang dialokasikan sebelumnya, kredensial, image, dan akses DNS dapat menentukan apakah target dapat dicapai.

Kerangka jawaban 30 detik

"Saya akan menyusun beban kerja secara berjenjang, membuat RPO/RTO bisnis dapat diukur, dan menggunakan replikasi database dan objek lintas-region secara asinkron ditambah backup point-in-time. Region pilot-light dengan infrastructure-as-code cocok untuk RTO empat jam jika pemulihan dan promosi tetap berada dalam anggaran waktu. Runbook akan mempromosikan titik data yang diketahui baik, men-deploy aplikasi, mengalihkan perutean, menjalankan pemeriksaan integritas dan smoke test, serta mengomunikasikan status. Drill triwulanan mengukur setiap langkah, memverifikasi pemulihan backup, mendeteksi configuration drift, dan memperbarui target jika pemulihan terukur tidak lagi sesuai."

Jawaban mendalam langkah demi langkah

1. Mengubah tujuan menjadi anggaran pemulihan

Untuk RPO ≤ 1 jam, batas maksimal lag replikasi atau interval backup yang diterima adalah satu jam. Tetapkan peringatan (alert) di bawah batas tersebut, misalnya ketika lag mendekati 45 menit, dan simpan snapshot point-in-time untuk pulih dari kerusakan data. Jangan mengklaim frekuensi replikasi universal; ukur beban kerja sumber dan tentukan margin pengaman.

Untuk RTO ≤ 4 jam, alokasikan anggaran waktu yang konkret: deteksi dan deklarasi, promosi data, deployment aplikasi, perutean, smoke test, dan cadangan waktu. Jika runbook membutuhkan 20 menit untuk memulihkan database, 30 menit untuk men-deploy image, dan 10 menit untuk mengalihkan lalu lintas, itu adalah asumsi yang harus diverifikasi dalam drill, bukan jaminan.

2. Memilih topologi pemulihan

Backup and restore adalah opsi termurah tetapi memerlukan pembangunan ulang infrastruktur dan biasanya memiliki RTO terbesar. Pilot light menjaga data yang direplikasi dan sumber daya pemulihan inti tetap siap sementara kapasitas aplikasi dimatikan; ini adalah titik awal yang masuk akal untuk target empat jam. Warm standby mempertahankan fungsionalitas stack yang diperkecil tetap berjalan dan mempersingkat pemulihan dengan biaya lebih tinggi. Active/active meminimalkan waktu failover tetapi menambah konflik penulisan lintas-region, kompleksitas pengarahan lalu lintas, dan beban operasional terbesar.

Pilihan bergantung pada tujuan: jangan membayar biaya active/active untuk target empat jam kecuali jika dampak bisnis membenarkannya. Simpan infrastructure-as-code, container image, skema, dan konfigurasi yang diberi versi di akun pemulihan agar deployment dapat direproduksi.

3. Melindungi dan memulihkan data

Replikasikan perubahan relasional secara asinkron ke region terpisah dan pantau lag. Promosikan hanya replika yang posisi log dan pemeriksaan integritasnya memenuhi RPO. Simpan backup point-in-time yang tidak dapat diubah (immutable) di akun atau region terpisah untuk menangani penghapusan yang tidak disengaja, ransomware, dan penulisan yang rusak. Replikasikan data objek dengan versioning dan verifikasi jumlah objek serta checksum.

Runbook mencatat timestamp pemulihan yang dipilih, membekukan atau mengosongkan (drain) penulisan bila diperlukan, mempromosikan data store, dan merekonsiliasi kehilangan data penulisan yang diterima. Jika catatan pembayaran memerlukan zero data loss, data tersebut membutuhkan tier yang berbeda dan kemungkinan replikasi sinkron; jangan mengklaim target satu jam mencakup setiap domain.

4. Memulihkan jalur penyajian (serving path)

Deploy aplikasi dari image yang immutable dan kode infrastruktur. Buat terlebih dahulu health check DNS atau global routing, akses secrets, kuota layanan, dan observabilitas di region pemulihan. Rute lalu lintas hanya setelah konektivitas database, migrasi, autentikasi, dan smoke test baca/tulis representatif berhasil lolos.

Pertahankan jalur kontrol failover seminimal mungkin. AWS mencatat bahwa operasi data-plane biasanya lebih tersedia daripada operasi control-plane selama bencana; desain yang bergantung pada pembuatan setiap sumber daya melalui control plane setelah pemadaman dapat meleset dari RTO-nya.

5. Membuat runbook aman untuk dieksekusi

Tentukan siapa yang dapat mendeklarasikan bencana, siapa yang mempromosikan data, dan siapa yang menyetujui pengalihan lalu lintas. Gunakan log langkah yang monotonik dengan perintah idempoten untuk setiap tindakan, kondisi berhenti, dan rencana rollback atau failback. Publikasikan pembaruan status pelanggan sebelum dan sesudah perubahan perutean. Selama pemulihan, nonaktifkan fitur non-kritis jika kapasitas berkurang dan pertahankan jejak audit dari titik pemulihan yang dipilih.

6. Memvalidasi dengan drill dan metrik

Jalankan uji pemulihan terjadwal, regional game days, dan pemeriksaan configuration drift. Ukur durasi deteksi, keputusan, pemulihan, promosi, deployment, perutean, smoke test, dan stabilisasi secara terpisah. Verifikasi jumlah baris yang dipulihkan, checksum, izin, antrean, dan background job. Simulasikan kegagalan backup, secret yang kedaluwarsa, kuota yang tidak mencukupi, dan lag replika parsial; masing-masing harus menghasilkan peringatan yang dapat ditindaklanjuti atau penghentian terdokumentasi.

Uji penerimaan adalah bukti nyata: pengukuran RPO dan RTO dari drill terbaru, celah yang belum terselesaikan, dan penanggung jawabnya. Dokumen tanpa uji pemulihan hanyalah sebuah hipotesis.

Contoh jawaban berkualitas tinggi

"Untuk RPO satu jam dan RTO empat jam, saya akan menggunakan replikasi database dan objek lintas-region secara asinkron, backup point-in-time yang immutable, dan region pilot-light yang dikelola oleh infrastructure-as-code. Saya akan mencadangkan waktu untuk deteksi, promosi data, deployment aplikasi, DNS atau global routing, dan smoke test, lalu membuktikan waktu-waktu tersebut dalam drill triwulanan. Runbook failover memilih titik pemulihan yang diketahui baik, melakukan promosi hanya setelah pemeriksaan integritas, men-deploy image yang immutable, memvalidasi autentikasi dan penulisan representatif, lalu mengalihkan lalu lintas. Jika sistem utama mengalami kerusakan logis, replikasi saja tidak aman, sehingga runbook memulihkan titik waktu sebelumnya. Data pembayaran kritis akan menjadi tier terpisah dengan target yang lebih ketat. Saya akan melaporkan lag terukur, durasi pemulihan, temuan drift, dan penanggung jawab perbaikan berikutnya."

Kesalahan umum

• Mengatakan "multi-region" tanpa tujuan → biaya dan kompleksitas menjadi tidak terbatas → turunkan topologi dari RPO/RTO dan tier layanan.
• Memperlakukan replikasi sebagai backup → kerusakan atau penghapusan data dapat langsung tereplikasi → simpan salinan point-in-time yang immutable dan uji pemulihannya.
• Mengabaikan kode dan konfigurasi → data yang dipulihkan tidak memiliki stack untuk melayani lalu lintas → beri versi pada image, skema, akses secrets, kuota, dan IaC di akun pemulihan.
• Menganggap perubahan DNS sebagai akhir pemulihan → lalu lintas mencapai sistem yang tidak sehat atau belum diverifikasi → sertakan promosi, smoke test, dan stabilisasi dalam RTO.
• Bergantung pada control plane yang tidak tersedia → otomatisasi tidak dapat membuat target selama pemadaman → sediakan sumber daya pemulihan penting terlebih dahulu dan latih jalurnya.
• Tidak pernah menjalankan drill → backup, kuota, dan runbook dapat menjadi usang → ukur pemulihan dan failover secara teratur dengan menyuntikkan kegagalan simulasi.

Pertanyaan lanjutan dan tanggapan

Apa yang berubah untuk RPO nol?

Replikasi asinkron tidak lagi memenuhi target. Tentukan otoritas penulisan sinkron atau terima penghentian penulisan di tingkat produk; kemudian evaluasi ulang latensi, kuorum, dan perilaku partisi regional.

Bagaimana Anda memulihkan diri dari kerusakan logis?

Hentikan promosi replika yang rusak, identifikasi backup point-in-time yang bersih, pulihkan ke lingkungan yang terisolasi, validasi invarian, dan putar ulang (replay) hanya perubahan yang disetujui. Region yang sehat tidak membuktikan datanya sehat.

Mengapa memilih pilot light daripada warm standby?

Pilot light menurunkan biaya steady-state dan cocok untuk target empat jam ketika proses deployment dan scale-up telah terukur. Warm standby dibenarkan ketika anggaran RTO tidak dapat mengakomodasi waktu penyediaan (provisioning) atau ketika lalu lintas dengan kapasitas terbatas harus segera dimulai.

Bagaimana cara mencegah configuration drift?

Render region pemulihan dari IaC yang diberi versi, bandingkan sumber daya yang diinginkan dan yang diamati, buat peringatan untuk perbedaan image, skema, secret, kuota, dan perutean, serta sertakan pemeriksaan drift dalam setiap drill.