Menentukan RTO, RPO, dan Tingkat Pemulihan

Perencanaan keberlangsungan bisnis (BCP) adalah proses untuk memastikan bahwa fungsi bisnis penting dapat terus berjalan selama dan setelah bencana. Dalam komputasi awan, hal ini berarti merancang sistem yang dapat pulih dari kegagalan dalam batas waktu dan kehilangan data yang dapat diterima. Dua metrik utama—RTO dan RPO—menentukan arti "dapat diterima" untuk setiap beban kerja.

Tujuan Waktu Pemulihan (RTO) adalah durasi maksimum yang masih dapat diterima ketika sistem luring setelah bencana. RTO menjawab pertanyaan: "Berapa lama bisnis dapat menoleransi aplikasi ini tidak beroperasi?". RTO dinyatakan dalam satuan waktu—jam, menit, atau detik. Sistem pemrosesan Payment mungkin memiliki RTO 15 menit, sedangkan portal HR Internal mungkin memiliki RTO 24 jam.

Tujuan Titik Pemulihan (RPO) adalah jumlah maksimum kehilangan data yang masih dapat diterima, diukur berdasarkan waktu. RPO menjawab pertanyaan: "Berapa banyak data yang sanggup ditanggung untuk hilang oleh bisnis?". Jika RPO adalah 1 jam, bisnis menerima kehilangan transaksi hingga 1 jam. RPO menentukan seberapa sering Anda harus mencadangkan atau mereplikasi data. RPO 0 memerlukan replikasi sinkron, yang mahal dan dapat memengaruhi kinerja penulisan.

Penting untuk tidak menyamakan RTO dan RPO:

• RTO berkaitan dengan waktu—berapa lama sistem tidak beroperasi
• RPO berkaitan dengan data—berapa banyak data yang hilang

Sistem dapat memiliki RTO singkat (pemulihan cepat) tetapi RPO panjang (menerima kehilangan data yang signifikan), atau sebaliknya. Kondisi idealnya adalah keduanya singkat, tetapi pencapaiannya memerlukan investasi besar dalam replikasi dan kapasitas siaga hangat.

Tidak semua beban kerja memiliki tingkat kekritisan yang sama. Pendekatan umum adalah mengelompokkan beban kerja ke dalam tingkat pemulihan berdasarkan dampaknya terhadap bisnis:

• Tingkat 1 (Sangat Penting)—RTO/RPO ketat, biaya tertinggi (misalnya Payment dan platform perdagangan)
• Tingkat 2 (Penting bagi Bisnis)—RTO/RPO sedang (misalnya CRM dan ERP)
• Tingkat 3 (Tidak Kritis)—RTO/RPO longgar, biaya terendah (misalnya lingkungan pengembangan dan arsip)

Tingkat pemulihan yang berbeda dipetakan ke kemampuan Azure yang berbeda:

• Tingkat 1—penulisan multiwilayah Cosmos DB, grup failover otomatis SQL, arsitektur aktif-aktif, Traffic Manager
• Tingkat 2—Azure Site Recovery ke wilayah sekunder, replikasi geografis SQL (replika baca), pencadangan harian dengan retensi 30 hari
• Tingkat 3—Azure Backup dengan jadwal mingguan, tanpa replikasi, pemulihan dari snapshot

Untuk membenarkan investasi pada arsitektur dengan RTO rendah, hitung biaya waktu henti untuk beban kerja tersebut. Biaya ini mencakup kehilangan Revenue, denda SLA kepada pelanggan, penurunan produktivitas Staff, dan kerusakan reputasi. Jika biaya waktu henti selama 1 jam adalah $500.000, pengeluaran $50.000 per bulan untuk penyiapan aktif-aktif mudah dibenarkan. Gunakan angka-angka ini untuk menyusun kasus bisnis bagi tingkat pemulihan yang sesuai.

Azure Site Recovery (ASR) adalah layanan Primary untuk mencapai target RTO/RPO Tingkat 2 di Azure. ASR terus-menerus mereplikasi VM ke wilayah sekunder dan dapat memulai failover dalam hitungan menit. Frekuensi replikasi untuk VM Azure adalah setiap 30 detik (konsisten terhadap kerusakan) atau setiap 1–4 jam (konsisten terhadap aplikasi), sehingga RPO biasanya berada dalam rentang tersebut, bergantung pada Configuration.

Untuk beban kerja dengan RPO yang diukur dalam hitungan jam, Azure Backup dengan jadwal yang sesuai sudah memadai. Misalnya, RPO 4 jam memerlukan interval pencadangan paling lama 4 jam. Azure Backup mendukung kebijakan yang disempurnakan yang memungkinkan jadwal pencadangan per jam untuk VM Azure. Untuk basis data, pemulihan titik waktu (PITR) dengan pencadangan log transaksi dapat mencapai RPO kurang dari 1 jam dengan biaya lebih rendah daripada ASR.

Target RTO dan RPO harus didokumentasikan secara formal dalam Analisis Dampak Bisnis (BIA) dan ditinjau oleh pemangku kepentingan teknis maupun bisnis. BIA memetakan setiap aplikasi ke tingkat pemulihannya, mendokumentasikan target RTO/RPO, mengidentifikasi layanan Azure yang akan memenuhi target tersebut, dan menetapkan jadwal pengujian (seberapa sering rencana DR divalidasi melalui latihan).

Target RTO dan RPO masih berupa aspirasi sampai divalidasi melalui pengujian DR. Selama pengujian DR, ukur waktu aktual untuk pulih (apakah memenuhi RTO yang ditetapkan?) dan kehilangan data aktual pada titik pemulihan (apakah memenuhi RPO yang ditetapkan?). Jika pengujian menemukan kesenjangan, perbarui arsitektur atau prosedur hingga target tercapai secara konsisten. Dokumentasikan hasil pengujian untuk audit kepatuhan.

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

Dalam pelajaran ini, Anda telah mempelajari bahwa RTO adalah waktu henti maksimum yang dapat diterima, sedangkan RPO adalah kehilangan data maksimum yang dapat diterima dan diukur berdasarkan waktu; beban kerja dikelompokkan ke dalam tingkat pemulihan yang dipetakan ke layanan Azure tertentu; dan pengujian sangat penting untuk memvalidasi bahwa target RTO/RPO dapat dicapai. Selanjutnya, kita akan membahas rencana pemulihan dan failover otomatis dengan Azure Site Recovery.