RTO, RPO, dan MTTR: Menentukan Sasaran Pemulihan

Tanpa sasaran pemulihan yang spesifik dan dapat diukur, mustahil merancang strategi pencadangan yang sesuai, memilih tingkatan situs DR yang tepat, atau mengevaluasi apakah investasi teknologi pemulihan dapat dibenarkan. RTO, RPO, dan MTTR menerjemahkan persyaratan Availability bisnis menjadi sasaran rekayasa yang presisi. Metrik ini memungkinkan tim keamanan dan IT berdiskusi dengan eksekutif berdasarkan bukti mengenai cost downtime dibandingkan cost investasi DR — sehingga justifikasi bisnis menjadi konkret, bukan abstrak.

Sasaran Waktu Pemulihan (RTO) adalah waktu maksimum yang dapat diterima sejak dimulainya gangguan hingga Service normal dipulihkan. Jika System pembayaran kritis gagal pada pukul 10:00 AM dan bisnis hanya dapat menoleransi downtime paling lama 2 hours sebelum kehilangan pendapatan yang tidak dapat diterima atau melanggar SLA, RTO-nya adalah 2 hours — System harus dipulihkan paling lambat pada pukul 12:00 PM. RTO menentukan pilihan tingkatan situs DR (hot site untuk RTO 15 Minutes dibandingkan cold site untuk RTO 48 hours), frekuensi Replication, dan otomatisasi failover.

Sasaran Titik Pemulihan (RPO) adalah kehilangan data maksimum yang dapat diterima, diukur berdasarkan waktu — seberapa banyak kehilangan data yang masih dapat ditoleransi jika bencana terjadi. RPO 1 hour berarti ketika System dipulihkan, System tersebut harus berisi data yang usianya tidak lebih dari 1 hour sebelum bencana terjadi. RPO menentukan frekuensi pencadangan: RPO 1 hour memerlukan pencadangan setidaknya setiap hour (atau Replication berkelanjutan). RPO 4 hours dapat menoleransi interval pencadangan 4 hours. RPO berkaitan dengan pemulihan data, sedangkan RTO berkaitan dengan pemulihan Availability Service.

RTO dan RPO membahas aspek pemulihan yang berbeda dan harus ditentukan secara terpisah. Suatu System dapat memiliki RPO ketat (1 hour, yang berarti data sering direplikasi), tetapi RTO longgar (4 hours, yang berarti diperlukan waktu untuk menjalankan lingkungan DR meskipun datanya mutakhir). Sebaliknya, suatu System mungkin memiliki RPO longgar (24 hours, pencadangan Nightly sudah memadai), tetapi RTO ketat (failover harus selesai dalam 1 hour, sehingga lingkungan DR yang telah disiapkan sebelumnya harus tersedia dan siap diaktifkan). Kedua metrik tersebut berasal dari Analisis Dampak Bisnis.

Rata-Rata Waktu Pemulihan (MTTR) adalah average waktu aktual yang diperlukan untuk memulihkan Service setelah incident — pengukuran operasional atas kinerja pemulihan. RTO adalah downtime maksimum yang dapat ditoleransi (sasaran/persyaratan), sedangkan MTTR adalah average yang diamati (kinerja aktual). Organisasi mengukur MTTR dari berbagai incident sepanjang waktu dan membandingkannya dengan RTO untuk mengevaluasi kemampuan pemulihan. MTTR yang terus-menerus melebihi RTO menunjukkan bahwa kemampuan DR tidak memadai dan diperlukan investasi dalam otomatisasi, staffing, atau infrastruktur.

Rata-Rata Waktu Antar-Kegagalan (MTBF) mengukur keandalan System — average waktu System beroperasi di antara kegagalan. MTBF yang Higher menunjukkan keandalan yang lebih baik. MTBF dan MTTR secara bersama-sama menentukan persentase Availability: Availability = MTBF / (MTBF + MTTR). System dengan MTBF 2000 hours dan MTTR 2 hours memiliki Availability 2000/2002 = 99,9%. Memahami MTBF membantu memprediksi kapan kegagalan mungkin terjadi dan merencanakan jendela pemeliharaan secara tepat — Hardware dengan MTBF yang menurun mendekati akhir masa pakainya dan harus diganti secara proaktif.

Downtime Maksimum yang Dapat Ditoleransi (MTD) adalah waktu absolut maksimum suatu System dapat tidak tersedia sebelum bisnis mengalami kerugian yang tidak dapat dipulihkan — kehilangan pelanggan, denda dari regulator, atau ketidakmampuan memenuhi kewajiban kontraktual. MTD selalu lebih besar dari atau sama dengan RTO. Hubungannya: MTD adalah batas bisnis; RTO adalah sasaran IT. Jika kontrak mengizinkan pelanggaran SLA selama 4 hours sebelum denda berlaku, MTD mungkin 4 hours. Tim IT merancang RTO 1–2 hours untuk menyediakan margin keamanan sebelum mencapai MTD.

Perjanjian Tingkat Service (SLA) menetapkan komitmen kontraktual kepada pelanggan yang secara langsung menjadi dasar persyaratan RTO dan RPO. SLA penyedia komputasi awan yang menjanjikan uptime 99,95% memungkinkan downtime sekitar 4,4 hours per tahun. Pelanggaran SLA memicu kredit Service atau hak untuk mengakhiri kontrak. SLA internal antara IT dan unit bisnis berfungsi dengan cara yang serupa. RTO dan RPO harus dirancang agar downtime aktual tetap berada dalam komitmen SLA, dan MTTR harus diukur serta dilaporkan untuk menunjukkan kepatuhan.

Pilihan teknologi ditentukan secara langsung oleh persyaratan RTO dan RPO. RTO 15 Minutes dengan RPO nol memerlukan pengelompokan active-active dengan Replication Synchronous — tanpa kehilangan data dan dengan failover otomatis. RTO 4 Hours dengan RPO 1 Hour dapat menggunakan pengiriman log atau Replication asynchronous ke Warm standby. RTO 24 Hours dengan RPO 24 Hours dapat menggunakan pencadangan Daily ke penyimpanan Cold. Merancang ketahanan yang melebihi kebutuhan akan memboroskan anggaran; merancang ketahanan yang kurang akan menciptakan risiko bisnis yang tidak dapat diterima selama incident.

Objektif pemulihan hanya valid jika divalidasi secara berkala melalui pengujian. Organisasi harus melakukan pengujian pemulihan yang mengukur MTTR aktual dan memverifikasi titik pemulihan Data aktual (seberapa lama usia Data saat dipulihkan?). Jika pengujian menunjukkan bahwa MTTR secara konsisten mencapai 3 jam, sedangkan RTO adalah 1 jam, kesenjangan tersebut harus diatasi — baik dengan meningkatkan infrastruktur DR (otomatisasi, penyediaan awal) maupun dengan menyesuaikan kembali ekspektasi bisnis melalui BIA yang diperbarui. Frekuensi pengujian harus disesuaikan dengan tingkat kekritisan: sistem kritis setiap kuartal, sedangkan sistem lainnya setiap tahun.

Laporan RTO, RPO, dan MTTR harus dikomunikasikan kepada pemangku kepentingan bisnis dengan istilah yang mereka pahami. Daripada mengatakan, "MTTR kami untuk sistem Tingkat 1 adalah 47 menit," katakan, "ketika sistem kami yang paling kritis gagal, kami memulihkan layanan dalam waktu rata-rata kurang dari satu jam — masih dalam jangka waktu 2 jam yang diizinkan kontrak kami." Pelaporan rutin membangun kepercayaan pemangku kepentingan dan menciptakan pemahaman bersama tentang ketahanan organisasi. Pelaporan dasbor mengenai tren MTTR dari waktu ke waktu menunjukkan peningkatan program dan mendukung justifikasi anggaran untuk investasi DR.

Uji pemahaman Anda tentang konsep CompTIA Security+ (SY0-701) dari pelajaran ini.

Dalam pelajaran ini Anda mempelajari: RTO adalah waktu maksimum layanan dapat tidak beroperasi dan menentukan persyaratan kecepatan failover, RPO adalah kehilangan Data maksimum yang dapat diterima dan menentukan frekuensi backup serta replikasi, dan MTTR adalah waktu pemulihan rata-rata aktual yang diukur dan dibandingkan dengan RTO untuk mengevaluasi efektivitas program DR. Selanjutnya kita akan membahas strategi backup — aturan 3-2-1 dan backup yang tak dapat diubah yang tidak dapat dihancurkan oleh Ransomware.