Di banyak perusahaan, hybrid cloud membuat proses recovery terlihat lebih sederhana di atas kertas, tetapi lebih kompleks saat benar-benar diuji. Aplikasi bisa berjalan di VM cloud, database masih berada di data center, akses user bergantung pada identity provider, backup tersimpan di repository berbeda, dan koneksi antar-lokasi melewati firewall, VPN, atau DNS yang punya owner masing-masing.
Karena itu, status “backup ada” belum cukup untuk menjawab pertanyaan utama saat ransomware, outage, atau kesalahan konfigurasi terjadi: aplikasi mana yang harus pulih lebih dulu, komponen apa saja yang dibutuhkan, dan siapa yang mengambil keputusan saat failover dimulai?
Kenapa hybrid cloud membuat recovery lebih sulit
Pada lingkungan on-prem tradisional, dependency aplikasi biasanya lebih mudah dilacak karena banyak komponen berada di satu lokasi operasional. Di hybrid cloud, dependency itu tersebar. Satu layanan bisnis bisa bergantung pada compute di cloud, database internal, DNS publik, koneksi VPN, storage backup, akun admin, dan integrasi SaaS.
Masalahnya bukan hanya “di mana backup disimpan”, tetapi apakah semua dependency yang dibutuhkan untuk menjalankan aplikasi sudah ikut dipetakan. Recovery bisa gagal walaupun data berhasil direstore jika identity tidak bisa login, DNS belum diarahkan, firewall rule belum siap, atau database belum berada pada titik waktu yang konsisten.
Kesalahan umum: backup ada, dependensi tidak terpetakan
Kesalahan yang sering muncul di perusahaan menengah adalah menganggap backup sebagai satu-satunya ukuran kesiapan. Padahal recovery aplikasi membutuhkan urutan kerja yang jelas. Contohnya:
- VM berhasil direstore, tetapi database belum tersedia.
- Database tersedia, tetapi aplikasi tidak bisa autentikasi ke identity provider.
- Aplikasi aktif, tetapi DNS belum diarahkan ke environment recovery.
- Traffic sudah diarahkan, tetapi firewall rule atau VPN path belum dibuka.
- Backup repository aman, tetapi akun admin backup ikut terdampak insiden.
Inilah alasan dependency map menjadi penting. Map tersebut membantu IT Manager melihat hubungan antar-komponen sebelum insiden terjadi, bukan ketika tim sedang berada dalam tekanan.
Dependency map yang wajib dibuat IT Manager
Untuk memulai, petakan aplikasi kritikal berdasarkan fungsi bisnisnya. Setelah itu, turunkan setiap aplikasi menjadi dependency teknis dan operasional. Minimal, dependency map hybrid cloud perlu mencakup:
- Aplikasi kritikal: sistem ERP, finance, customer portal, file server, email, atau aplikasi operasional utama.
- Database: lokasi database, metode backup, replikasi, owner, dan titik restore yang dapat diterima.
- VM atau compute: server mana yang berjalan di cloud, on-prem, atau data center pihak ketiga.
- Storage: primary storage, backup copy, archive, object storage, dan retensi.
- DNS: domain, subdomain, TTL, owner perubahan, dan skenario switch saat failover.
- Identity dan MFA: akun admin, user login, service account, dan akses darurat.
- Firewall, VPN, dan network path: rule antar-segment, akses remote, dan jalur komunikasi antar-lokasi.
- Backup source dan backup copy: apa yang dibackup, ke mana disalin, siapa yang bisa menghapus, dan kapan terakhir diuji.
- Owner tiap komponen: siapa yang approve, siapa yang eksekusi, dan siapa yang memvalidasi hasil recovery.
- Urutan failover dan failback: langkah pemulihan dari sistem paling kritikal sampai sistem pendukung.
Hubungkan dependency map ke RPO dan RTO
Dependency map baru berguna jika dikaitkan dengan target bisnis. Dua istilah yang perlu dipakai secara konsisten adalah RPO dan RTO. RPO menggambarkan batas kehilangan data yang masih dapat diterima. RTO menggambarkan batas downtime yang masih dapat diterima.
Untuk aplikasi yang berbeda, targetnya tidak harus sama. Sistem transaksi, database finance, email, file sharing, dan aplikasi internal bisa memiliki prioritas pemulihan berbeda. Yang penting, keputusan itu jelas dan disetujui sebelum insiden.
Jika semua aplikasi diperlakukan “harus pulih secepatnya”, tim biasanya tidak punya prioritas yang bisa dieksekusi. Saat insiden terjadi, recovery menjadi debat, bukan runbook.
Recovery runbook jangan baru dibuat saat insiden
Setelah dependency map dibuat, langkah berikutnya adalah recovery runbook. Runbook bukan dokumen formalitas. Isinya harus cukup praktis untuk dipakai saat tekanan tinggi.
- Aplikasi mana yang dipulihkan lebih dulu?
- Backup atau replica mana yang digunakan?
- Siapa yang memutuskan failover?
- Siapa yang mengubah DNS, firewall, dan akses user?
- Bagaimana tim memastikan aplikasi benar-benar bisa digunakan?
- Evidence apa yang dikumpulkan untuk audit dan post-incident review?
Apa yang harus diuji minimal sekali
Tes recovery tidak harus langsung besar. Untuk perusahaan yang baru memulai, uji kecil yang terdokumentasi lebih baik daripada dokumen DR yang tidak pernah dibuka. Minimal, lakukan pengujian berikut:
- Restore satu VM atau satu aplikasi non-produksi dari backup yang benar.
- Validasi database bisa dibaca dan sesuai titik restore yang diharapkan.
- Tes akses user dengan akun biasa dan akun admin yang relevan.
- Tes DNS atau network path yang diperlukan saat failover.
- Verifikasi integritas backup dan siapa yang punya hak mengubah atau menghapus backup.
- Dokumentasikan durasi, hambatan, keputusan, dan gap yang ditemukan.
Tujuan tes ini bukan mencari hasil sempurna. Tujuannya menemukan dependency yang belum terlihat sebelum insiden nyata terjadi.
Bagaimana myBATICloud membantu
Untuk lingkungan hybrid, myBATICloud dapat membantu memetakan jalur recovery dari sisi compute, backup, storage, network, dan operasional. IaaS dapat menjadi layer VM/compute fleksibel, DRaaS membantu menyiapkan opsi failover, BaaS dan StaaS mendukung backup serta salinan data, sementara Managed Service membantu menjaga runbook, monitoring, dan review berkala.
Jika perusahaan sudah memakai solusi seperti Veeam, Acronis, atau Fortinet, pendekatannya tidak harus mengganti tool. Yang lebih penting adalah memastikan setiap tool masuk ke dependency map dan recovery sequence yang bisa diuji.
Checklist 30 menit untuk mulai
Jika tim belum punya dependency map, mulai dari satu aplikasi kritikal. Dalam 30 menit, jawab pertanyaan berikut:
- Aplikasi ini mendukung proses bisnis apa?
- Database dan storage mana yang dibutuhkan?
- Login user bergantung pada identity service apa?
- Jalur network, VPN, DNS, dan firewall apa yang harus aktif?
- Backup terakhir yang valid ada di mana?
- Siapa owner teknis dan owner bisnisnya?
- Berapa target RPO dan RTO yang realistis?
Kalau jawaban atas pertanyaan ini tersebar di banyak orang atau belum terdokumentasi, itu sinyal bahwa recovery readiness perlu diperbaiki sebelum insiden.
Minta review 30 menit: apakah dependency map hybrid cloud Anda sudah siap untuk recovery? Tim myBATICloud dapat membantu membaca gap awal tanpa hard-sell, lalu merekomendasikan langkah yang paling realistis untuk lingkungan Indonesia dan Jakarta. Mulai dari layanan cloud dan security myBATICloud, lalu lihat juga artikel checklist operasional lain untuk memperkuat jalur recovery.
Rujukan defensif yang digunakan untuk framing artikel ini mencakup prinsip umum dari CISA StopRansomware, Microsoft BCDR/RPO/RTO concepts, Veeam disaster recovery guidance, Acronis disaster recovery runbook concepts, dan Fortinet hybrid cloud security guidance. Artikel ini bersifat checklist operasional, bukan klaim insiden spesifik.