Tetapkan dan uji RTO serta RPO

Tetapkan dua sasaran terpisah

Recovery Time Objective (RTO) menetapkan durasi gangguan maksimum yang dapat diterima sebelum layanan yang berguna harus kembali tersedia. Recovery Point Objective (RPO) menetapkan kehilangan data maksimum yang dapat diterima, diukur sebagai waktu. Sepakati sasaran ini dengan penanggung jawab bisnis untuk layanan dan skenario kegagalan yang ditentukan.

Target ketersediaan menjelaskan kinerja layanan selama suatu periode. RTO dan RPO menjelaskan ekspektasi pemulihan. Keduanya menjawab pertanyaan yang berbeda.

Untuk layanan pemesanan fiktif, penanggung jawab menetapkan RTO 60 menit dan RPO 15 menit. Angka ini merupakan contoh, bukan rekomendasi umum. Layanan lain mungkin memerlukan batas berbeda karena pesanan yang hilang dan laporan yang terlambat memiliki dampak berbeda.

Ukur seluruh proses pemulihan

Layanan berhenti pada 10:00. Tim mencatat latihan berikut:

Total waktu pemulihan adalah 55 menit. Latihan memenuhi RTO 60 menit. Menghitung hanya operasi pemulihan 25 menit akan menyembunyikan sebagian besar durasi gangguan.

Titik pemulihan terbaru yang dapat digunakan adalah 09:40. Selisihnya terhadap gangguan pada 10:00 adalah 20 menit. Nilai ini melampaui RPO 15 menit sebesar 5 menit. Memulihkan data yang sama dengan lebih cepat tidak akan mengurangi selisih tersebut.

Periksa data yang benar-benar hilang atau tidak konsisten. Selisih waktu menunjukkan potensi kehilangan; selisih itu tidak menghitung pesanan yang terdampak. Rekonsiliasi catatan pembayaran dan pemenuhan pesanan dari pihak eksternal sebelum melanjutkan pemrosesan normal. Coba asumsi berbeda dalam latihan pemulihan.

Pilih strategi pemulihan

Strategi harus mencakup layanan, data, dan dependensi yang diperlukan. Bandingkan pola berikut berdasarkan sasaran yang diukur:

Tidak ada waktu pemulihan universal untuk pola tersebut. Implementasi, volume data, dependensi, dan kondisi pengujian menentukan hasilnya. Sertakan biaya operasi dan kemampuan tim dalam keputusan.

Lindungi dari lebih dari sekadar gangguan layanan

Replika dapat menyalin penghapusan yang tidak diinginkan atau data yang rusak. Simpan versi yang dapat dipulihkan atau gunakan point-in-time recovery sesuai kebutuhan. Verifikasi retensi, izin pemulihan, dan akses ke kunci enkripsi. Sesuaikan isolasi cadangan dengan skenario, termasuk hilangnya akses ke akun utama.

Untuk pemulihan regional, periksa lokasi data yang diizinkan dan seluruh rantai dependensi. Sertakan identitas, DNS, sertifikat, secret, artefak deployment, kuota, dan akses jaringan. Lingkungan pemulihan yang kekurangan satu kunci penting dapat menjadi tidak berguna.

Tentukan siapa yang dapat menyatakan terjadinya kejadian, siapa yang menjalankan pemulihan, dan siapa yang menerima layanan yang dipulihkan. Rencanakan failback atau operasi lanjutan di lingkungan pemulihan. Cegah penulisan yang saling bertentangan dari beberapa komponen dan rekonsiliasi data sebelum beralih kembali.

Ubah rencana menjadi bukti

Tulis runbook dan latih penggunaannya dalam kondisi terkendali. Catat skenario, ukuran dataset, waktu mulai dan selesai, titik data yang dipulihkan, langkah yang gagal, dan penanggung jawab. Verifikasi operasi bisnis nyata dengan data uji yang aman.

Ulangi latihan setelah perubahan yang relevan dan sesuai jadwal yang disepakati. Perubahan skema, dependensi eksternal baru, atau volume data yang berbeda dapat membuat hasil sebelumnya tidak lagi berlaku. Hubungkan bukti latihan dengan rilis dan tanggung jawab operasi.