Hai semuanya, apa kabar? Dalam pengelolaan infratruktur IT, terutama yang berkaitan dengan backup, ada beberapa hal yang bisa jadi concern dari tim admin saat terjadi insiden. Misalnya:

• Berapa banyak data yang hilang?
• Berapa lama lagi sistem dapat pulih kembali?

Dua hal di atas berhubungan dengan konsep Recovery Point Objective (RPO) dan Recovery Time Objective (RTO). Kita akan coba bahas secara singkat apa itu RPO dan RTO dan mengapa dua aspek tersebut penting dalam pengelolaan infrastruktur IT dan backup-nya.

Recovery Point Objective (RPO)

RPO adalah batas waktu maksimal kehilangan data yang ditoleransi oleh perusahaan saat sistem mengalami kegagalan. Singkatnya, “maksimal berapa lama (jam/menit) data yang bisa hilang tanpa merugikan bisnis?”. Nilai RPO dapat membantu kita untuk merencanakan seberapa sering kita perlu melakukan backup.

Rumus dasar RPO:
Interval backup ≤ RPO target

Skenario 1 – Toko Online: Target RPO = 1 jam.
Misalnya ada sistem toko online yang memiliki transaksi tiap menit. Kehilangan data transaksi lebih dari satu jam dapat mengacaukan catatan atau pembukuan keuangan. Untuk mengatasi kendala operasional yang diakibatkan oleh risiko sistem yang bisa mati di atas satu jam, maka tim IT dapat menjadwalkan backup job setiap satu jam sekali (misalnya jam 00:00, 01:00, 02:00, dst).

Misalnya sudah dibuat scheduled backup job tiap satu jam sekali dan sistem mati pada jam 14:45. Data backup terakhir adalah pukul 14:00. Maka, data yang hilang “hanya” data transaksi yang berjalan pada wakti 14:00-14:45 (45 menit) dan masih dalam toleransi RPO 1 jam.

Skenario 2 – Website/Blog: Target RPO = 24 jam
Misalnya ada suatu situs web yang tidak terlalu aktif trafiknya. Kehilangan data dalam waktu hitungan jam dirasa tidak berdampak besar. Maka tim IT dapat menjadwalkan backup job harian misalnya pada pukul 00:00. Misalnya ada crash pada pukul 18:00, data web dapat dipulihkan dengan hasil backup job pukul 00:00.

Data yang hilang adalah data dari pukul 00:00-18:00 (18 jam). Karena SLA/target yang ditetapkan adalah 24 jam, maka dalam skenario ini masih masuk SLA atau masih dalam toleransi RPO 24 jam.

Recovery Time Objective (RTO)

RTO merupakan durasi yang dapat ditoleransi/diizinkan bagi sistem untuk berada dalam kondisi down/mati hingga sistem dapat diakses atau digunakan kembali dengan normal. RTO lebih berfokus pada “berapa lama waktu yang kita punya untuk memulihkan sistem”.

Rumus dasar RTO:
Realisasi RTO ≤ RTO target (SLA)

Total RTO juga mencakup aspek berikut:

• Detection time: waktu sistem monitoring dalam mendeteksi crash dan mengirimkan notifikasi.
• Decision time: waktu yang dibutuhkan tim IT untuk analisa dan eksekusi disaster recovery.
• Execution time: proses pemulihan.
• Verification time: pengujian untuk memastikan sistem sudah dapat digunakan secara normal.

Skenario 1 – payment gateway: Target RTO = 15 menit*
Tiap menit dari sistem yang gagal artinya transaksi tidak dapat dilakukan dan perusahaan kehilangan pendapatan. Sistem yang perlu digunakan untuk meminimalisir risiko kegagalan adalah implementasi HA dan fitur automated failover. Misalnya, sistem crash pada pukul 10:00.

Sistem pemantauan mendeteksi ada node mati, proses HA triggered dan sistem dimulai kembali pada node yang masih aktif dalam jangka waktu 5 menit. Sistem payment dapat berjalan kembali pada pukul 10:05. Artinya, masih masuk ke dalam realisasi RTO dengan target 15 menit (waktu aktual failover= 5 menit).

Skenario 2 – sistem internal HRD: Target RTO = 5 jam
Misalnya ada sistem atau aplikasi internal yang digunakan tim HRD/manajemen yang penggunaannya tidak terlalu intens, yaitu hanya sebagai sistem presensi. Karena penggunaan yang tidak terlalu intens, manajemen menetapkan target RTO-nya selama 5 jam. Ada crash pada pukul 11:00 (proses atau jam clock in sudah lewat) yang diakibatkan hardware failure.

Tim IT sudah copy masalah ini dan ternyata masalah terdeteksi karena disk yang rusak. Proses pergantian hardware memakan waktu selama 1 jam dan aplikasi sudah up kembali pada pukul 12:00. Artinya, kegagalan sistem ini masih masuk atau dalam lingkup SLA/target RTO 5 jam (waktu aktual perbaikan = 1 jam).

Penutup

Berikut ini ringkasan mengenai RPO dan RTO:

| **Parameter**  | **RPO**                                    | **RTO**                                 |
|----------------|--------------------------------------------|-----------------------------------------|
| **Fokus**      | Toleransi kehilangan data                  | Toleransi *downtime*                    |
| **Arah Waktu** | Mundur ke belakang (cek *backup* terakhir) | Maju ke depan (durasi pemulihan sistem) |
| **Menentukan** | Frekuensi *backup*                         | Teknologi infra (HA/replikasi,dll)      |

Penerapan sistem yang optimal dan efisien dapat meminimalisir gangguan proses bisnis. Aspek RPO dan RTO dapat membantu tim IT dalam menjaga sistem tetap aman sesuai batas toleransi bisnis tanpa membuat anggaran perusahaan membengkak.

Tulisan kali ini sampai di sini dulu ya. Sampai jumpa. Bye.