🇬🇧 Read this article in English
Executive Summary: Peristiwa tahun 2020 telah mengungkap sebuah kenyataan pahit — sebagian besar rencana disaster recovery IT dibangun untuk dunia yang sudah tidak ada lagi. Rencana tersebut berasumsi pada gangguan lokal, infrastruktur on-premise, dan karyawan yang secara fisik dapat datang ke kantor. Artikel ini mengkaji asumsi-asumsi spesifik yang membuat rencana DR Anda usang bahkan sebelum pandemi dimulai, dan menguraikan kerangka kerja praktis untuk membangunnya kembali berdasarkan risiko-risiko yang benar-benar relevan saat ini.
Enam bulan lalu, jika Anda bertanya kepada sebagian besar CIO apakah organisasi mereka memiliki rencana disaster recovery IT, jawabannya pasti ya. Bahkan dengan penuh percaya diri. Rencana itu tersimpan dalam sebuah map di suatu tempat — atau lebih mungkin di situs SharePoint yang tidak pernah disentuh siapa pun sejak siklus audit terakhir. Rencana itu mencakup prosedur failover server, jadwal backup, dan recovery time objectives (RTO) untuk aplikasi-aplikasi kritis. Di atas kertas, semuanya terlihat menyeluruh. Praktiknya, rencana itu dibangun untuk menghadapi banjir, pemadaman listrik, dan kerusakan perangkat keras. Bukan untuk skenario di mana setiap karyawan di perusahaan pulang pada hari Jumat dan tidak kembali lagi ke kantor.
Itulah tepatnya yang terjadi. Dan kesenjangan antara apa yang direncanakan organisasi dengan apa yang sebenarnya mereka hadapi sangatlah mencolok.
Saya telah menghabiskan dua puluh tahun memberikan masukan kepada berbagai organisasi mengenai strategi IT, dan saya telah meninjau dokumen disaster recovery dalam jumlah yang tak terhitung. Apa yang mengejutkan saya tahun ini bukanlah kegagalan dari rencana-rencana tersebut — melainkan betapa mudahnya kegagalan itu diprediksi. Kelemahannya tidak tersembunyi. Kelemahan itu tertanam dalam asumsi-asumsi dasar yang jarang sekali dipertanyakan oleh sebagian besar organisasi.
Apa yang Sebenarnya Dicakup oleh Sebagian Besar Rencana Disaster Recovery IT
Untuk memahami mengapa begitu banyak rencana gagal memenuhi harapan, Anda perlu memahami untuk apa rencana tersebut dirancang. Rencana disaster recovery IT pada umumnya disusun berdasarkan serangkaian skenario spesifik: bencana alam, kegagalan perangkat keras, serangan siber, dan gangguan di tingkat fasilitas. Buku panduan ini biasanya mencakup prosedur backup dan pemulihan data, failover ke pusat data sekunder, alur komunikasi untuk staf IT, serta dokumentasi recovery time objectives (RTO) dan recovery point objectives (RPO) untuk sistem-sistem yang kritikal bagi bisnis.
Hal-hal ini bukannya tidak penting. Namun, semuanya memiliki satu kesamaan: mereka berasumsi bahwa gangguan tersebut dapat dilokalisasi. Banjir melanda satu pusat data. Serangan ransomware mengenkripsi satu segmen jaringan. Kebakaran menghancurkan satu kantor. Rencana tersebut memperhitungkan cara mengaktifkan kembali sistem sementara orang-orang terus bekerja — mungkin dari lokasi sekunder, tetapi tetap dalam lingkungan yang terkendali dan dapat diprediksi.
Apa yang hampir tidak diperhitungkan oleh rencana mana pun adalah gangguan global yang terjadi secara serentak, yang mengubah bukan hanya di mana sistem berjalan, tetapi bagaimana, di mana, dan apakah orang dapat mengaksesnya sama sekali.
Lima Asumsi yang Membuat Rencana Disaster Recovery IT Anda Kedaluwarsa
Setelah menangani tantangan pemulihan dan kelangsungan bisnis bersama beberapa organisasi tahun ini, saya telah mengidentifikasi lima asumsi yang secara konsisten merusak rencana yang sebenarnya sudah didokumentasikan dengan baik.
1. Kantor Akan Tetap Tersedia
Sebagian besar rencana DR berasumsi bahwa setidaknya beberapa infrastruktur fisik tetap dapat diakses. Bahkan rencana dengan ketentuan “bekerja dari lokasi alternatif” biasanya mengarah ke kantor sekunder, fasilitas co-working, atau fasilitas mitra. Ketika setiap kantor di setiap kota tutup secara bersamaan, asumsi itu runtuh dalam semalam.
Organisasi yang belum berinvestasi pada infrastruktur akses jarak jauh — kapasitas VPN, alat kolaborasi berbasis cloud, lingkungan virtual desktop — mendapati diri mereka kewalahan menyediakan akses untuk ratusan atau ribuan karyawan dalam hitungan hari, bukan bulan.
2. Gangguan Hanya Bersifat Sementara
Perencanaan DR tradisional menggunakan target waktu pemulihan (RTO) yang diukur dalam hitungan jam atau hari. Asumsi implisitnya adalah Anda hanya menjembatani sebuah celah — menjaga segala sesuatunya tetap berjalan hingga operasi normal dilanjutkan. Tidak ada yang merencanakan gangguan yang berlangsung selama enam bulan dan terus berlanjut, tanpa tanggal akhir yang jelas.
Perbedaan ini sangat penting karena mengubah seluruh perhitungannya. Solusi sementara — misalnya, mengalihkan traffic melalui koneksi cadangan — dapat diterima untuk 72 jam. Hal ini tidak dapat diterima untuk enam bulan. Solusi sementara berubah menjadi infrastruktur permanen, padahal tidak pernah dirancang atau diamankan untuk tujuan tersebut.
3. Tenaga Kerja Selalu Tersedia
Rencana DR memperhitungkan sistem yang down. Mereka jarang memperhitungkan orang yang tumbang — atau menjadi tidak tersedia dalam jumlah besar. Pandemi memunculkan ketidakhadiran massal, cuti paksa, kendala pengasuhan anak, dan tantangan kesehatan mental yang mengurangi kapasitas tenaga kerja efektif di setiap fungsi, termasuk IT.
Saya pernah bekerja dengan sebuah perusahaan manufaktur skala menengah di mana seluruh tim infrastruktur yang terdiri dari tiga orang terdampak dalam jendela waktu dua minggu yang sama. Bukan karena virus itu sendiri, melainkan karena penutupan sekolah yang membuat mereka harus membagi fokus antara migrasi server dan membantu PR matematika anak kelas dua SD. Rencana DR tidak memiliki ketentuan untuk hal ini.
4. Rantai Pasok Berfungsi Normal
Perlu mengganti server yang rusak? Memesan laptop baru untuk pekerja jarak jauh? Mengadakan lisensi VPN tambahan? Dalam gangguan normal, rantai pasok (supply chain) tetap utuh dan pengadaan hanyalah masalah waktu tunggu (lead time) dan persetujuan anggaran. Pada tahun 2020, rantai pasok global terhenti. Kelangkaan laptop menjadi risiko kelangsungan bisnis yang nyata — sebuah kalimat yang tidak pernah saya bayangkan akan saya tulis dalam konteks profesional.
Waktu tunggu perangkat keras yang biasanya dua hingga tiga minggu membengkak menjadi dua hingga tiga bulan. Organisasi yang mengandalkan pengadaan just-in-time tanpa inventaris cadangan mendapati diri mereka tidak mampu memfasilitasi karyawan mereka sendiri.
5. Postur Keamanan Siber Bertahan di Bawah Tekanan
Ketergesaan untuk memfasilitasi kerja jarak jauh menciptakan perluasan permukaan serangan (attack surface) yang sangat besar, yang sebagian besar tim keamanan tidak memiliki sumber daya untuk mengatasinya secara real-time. Perangkat pribadi di jaringan perusahaan. VPN yang dikonfigurasi secara terburu-buru. Shadow IT yang menjamur ketika karyawan mencari solusi mereka sendiri untuk menutupi celah kolaborasi. Menurut FBI, keluhan serangan siber yang dilaporkan meningkat sekitar 400% pada bulan-bulan awal pandemi [Sumber: FBI IC3, 2020].
Sebagian besar rencana disaster recovery memperlakukan keamanan siber sebagai domain terpisah dengan prosedur respons insidennya sendiri. Namun, ketika aktivasi DR itu sendiri memunculkan kerentanan keamanan baru, keduanya menjadi tidak terpisahkan — dan sangat sedikit organisasi yang telah merencanakan tumpang tindih tersebut.
Mengapa Ini Bukan Hanya Masalah Pandemi
Akan sangat menenangkan jika kita menganggap ini sebagai anomali sekali dalam satu abad dan melupakannya. Saya sangat menyarankan Anda untuk tidak melakukan itu.
Pergeseran mendasar yang membuat rencana DR tradisional menjadi tidak memadai sebenarnya sudah bergerak sebelum COVID-19 mempercepatnya. Adopsi cloud terus meningkat. Tren kerja jarak jauh terus berkembang. Ancaman siber semakin meningkat. Pandemi tidak menciptakan tren-tren ini — ia hanya menguji ketahanan organisasi terhadapnya tanpa peringatan dan tanpa masa tenggang.
Pertanyaan yang seharusnya diajukan oleh para eksekutif bukanlah “bagaimana kita merencanakan pandemi berikutnya” melainkan “skenario apa lagi yang akan mengekspos celah yang sama ini?” Serangan siber besar-besaran yang melumpuhkan jaringan perusahaan selama berminggu-minggu. Peristiwa geopolitik yang mengganggu ketersediaan penyedia cloud di wilayah tertentu. Peristiwa iklim yang membuat kantor fisik tidak dapat diakses untuk jangka waktu yang lama di berbagai geografi. Ini bukan sekadar hipotesis. Hal-hal ini semakin mungkin terjadi.
Membangun Kembali Rencana Disaster Recovery IT Anda untuk Realitas Saat Ini
Memperbarui rencana disaster recovery bukanlah sekadar menambahkan bagian “pandemi” ke dalam dokumen yang sudah ada. Ini membutuhkan evaluasi ulang terhadap arsitektur dasar dari rencana tersebut. Berikut adalah kerangka kerja yang telah saya gunakan bersama klien, yang disusun ke dalam empat pilar.
Pilar 1: Perluasan Skenario
Bergeraklah melampaui skenario single-point-of-failure. Rencana Anda harus mencakup:
- Gangguan lokal — ruang lingkup tradisional (kehilangan fasilitas, kerusakan hardware, peristiwa regional)
- Gangguan terdistribusi — peristiwa yang memengaruhi beberapa lokasi secara bersamaan tetapi membiarkan infrastruktur tetap utuh (pandemi, gangguan sipil yang meluas)
- Gangguan berkelanjutan — peristiwa yang berlangsung selama berminggu-minggu atau berbulan-bulan, bukan sekadar jam atau hari
- Gangguan beruntun (cascading) — peristiwa di mana insiden awal memicu kegagalan sekunder (misalnya, transisi kerja jarak jauh yang menciptakan pelanggaran keamanan siber)
Untuk setiap kategori, dokumentasikan asumsi spesifik, ketergantungan, dan strategi pemulihan. Tujuannya bukan untuk memprediksi setiap kemungkinan bencana, melainkan untuk memastikan rencana Anda berfungsi di berbagai pola gangguan, bukan hanya satu skenario saja.
Pilar 2: Ketahanan Infrastruktur
Evaluasi tumpukan teknologi (technology stack) Anda terhadap satu pertanyaan kritis: dapatkah setiap fungsi bisnis esensial beroperasi tanpa ketergantungan sedikit pun pada kantor fisik?
Ini bukanlah argumen untuk meninggalkan infrastruktur on-premise sepenuhnya. Ini adalah argumen untuk memastikan bahwa kemampuan pemulihan Anda tidak bergantung pada akses fisik. Area spesifik yang perlu dinilai:
- Kapasitas akses jarak jauh: Dapatkah VPN atau arsitektur zero-trust Anda menangani 100% pengguna jarak jauh secara bersamaan — bukan hanya 20-30% seperti pada operasi normal?
- Kesiapan cloud: Apakah aplikasi-aplikasi kritis dapat diakses dari lokasi mana pun, atau apakah ada yang memerlukan akses jaringan on-premise?
- Sistem komunikasi: Apakah rencana komunikasi krisis Anda tetap berjalan ketika server email mati dan karyawan tidak berada di dalam gedung?
- Manajemen endpoint: Dapatkah Anda menyediakan, mengamankan, dan mendukung perangkat yang tidak berada di jaringan perusahaan?
Pilar 3: Kelangsungan SDM dan Proses
Ini adalah area yang paling buruk ditangani oleh sebagian besar rencana DR. Prosedur pemulihan teknis tidak ada artinya jika orang yang harus mengeksekusinya tidak tersedia, tidak terlatih, atau kewalahan.
Buat ketentuan eksplisit untuk:
- Pelatihan silang (Cross-training): Tidak boleh ada prosedur pemulihan kritis yang bergantung pada satu individu. Dokumentasikan prosedur pada tingkat detail yang memungkinkan seseorang di luar tim utama untuk mengeksekusinya
- Kedalaman suksesi: Identifikasi setidaknya tiga lapis kepemilikan (ownership) untuk setiap sistem dan proses yang kritis
- Otoritas keputusan: Berikan pra-otorisasi untuk batas pengeluaran dan wewenang pengambilan keputusan agar tindakan pemulihan tidak terhambat oleh rantai persetujuan selama krisis
- Perencanaan kapasitas tenaga kerja: Buat model skenario di mana 25%, 50%, atau 75% tim tidak tersedia dan identifikasi tingkat staf minimum yang layak (minimum viable staffing)
Pilar 4: Pengujian yang Mencerminkan Kondisi Nyata
Uji coba DR tahunan yang melibatkan pengalihan ke pusat data cadangan pada hari Sabtu pagi dengan seluruh tim IT bersiaga memang lebih baik daripada tidak sama sekali — tetapi tidak jauh lebih baik. Mereka hanya menguji failover teknis. Mereka tidak menguji ketahanan organisasi.
Pengujian yang efektif harus mencakup:
- Latihan mendadak yang menyimulasikan kondisi dunia nyata, termasuk informasi yang tidak lengkap dan personel kunci yang “tidak tersedia”
- Latihan simulasi diskusi (Tabletop exercises) dengan pimpinan senior — bukan hanya IT — yang membedah pengambilan keputusan di bawah skenario gangguan spesifik
- Simulasi durasi panjang yang melampaui 24 jam pertama dan menguji operasi berkelanjutan di bawah kondisi yang terdegradasi
- Tinjauan pasca-pengujian dengan temuan yang didokumentasikan, penanggung jawab perbaikan yang ditunjuk, dan tenggat waktu yang jelas — bukan sekadar satu slide ringkasan dalam laporan kuartalan
Laporan Horizon Scan 2019 dari Business Continuity Institute mencatat bahwa hanya 27% organisasi yang menguji rencana kelangsungan bisnis mereka lebih dari dua kali setahun [Sumber: BCI Horizon Scan Report, 2019]. Mengingat apa yang kita ketahui sekarang, angka tersebut seharusnya mengkhawatirkan setiap eksekutif yang membaca artikel ini.
Pertanyaan yang Sering Diajukan (FAQ)
Seberapa Sering Rencana Disaster Recovery IT Harus Diperbarui?
Minimal satu tahun sekali — namun ini harus berupa tinjauan komprehensif, bukan sekadar formalitas. Pembaruan material juga harus dipicu oleh setiap perubahan signifikan pada infrastruktur, struktur organisasi, hubungan vendor, atau lanskap ancaman. Jika Anda memigrasikan aplikasi utama ke cloud, mengganti sistem ERP, atau menggunakan penyedia managed services baru, rencana DR Anda harus mencerminkan hal tersebut dalam waktu 30 hari, bukan menunggu siklus tinjauan tahunan berikutnya.
Apa Perbedaan Antara Disaster Recovery dan Business Continuity?
Disaster recovery berfokus secara spesifik pada pemulihan sistem IT dan data setelah terjadinya gangguan. Business continuity (kelangsungan bisnis) adalah disiplin yang lebih luas untuk mempertahankan seluruh fungsi bisnis yang kritis — termasuk SDM, proses, fasilitas, dan rantai pasok — selama dan setelah peristiwa yang mengganggu. Rencana disaster recovery IT yang kuat adalah komponen dari business continuity, bukan penggantinya. Salah satu pelajaran paling jelas dari tahun 2020 adalah bahwa organisasi membutuhkan keduanya, dan keduanya harus terintegrasi dengan erat.
Apakah Bisnis Skala Kecil dan Menengah Perlu Berinvestasi dalam Perencanaan DR?
Tentu saja — dan bisa dibilang lebih mendesak dibandingkan perusahaan besar. Organisasi yang lebih besar biasanya memiliki redundansi yang lebih banyak, kekuatan tim cadangan yang lebih dalam, dan cadangan finansial yang lebih besar untuk menyerap gangguan. Perusahaan skala menengah dengan tim IT yang hanya terdiri dari tiga orang dan ketergantungan pada vendor tunggal memiliki margin kesalahan yang jauh lebih kecil. Rencana tersebut tidak perlu berupa dokumen setebal 200 halaman. Rencana itu hanya perlu menjawab tiga pertanyaan dengan jelas: apa saja sistem kritis kita, bagaimana kita memulihkannya, dan siapa yang bertanggung jawab untuk memastikan hal itu terjadi?
Bagaimana Migrasi Cloud Memengaruhi Perencanaan Disaster Recovery?
Migrasi cloud mengubah perencanaan DR secara signifikan tetapi tidak menghilangkan kebutuhannya. Penyedia cloud menangani redundansi di tingkat infrastruktur, yang mengurangi eksposur Anda terhadap kegagalan perangkat keras dan peristiwa di tingkat fasilitas. Namun, Anda tetap bertanggung jawab atas pemulihan di tingkat aplikasi, strategi backup data, manajemen akses, dan — yang paling krusial — memahami komitmen DR dari penyedia layanan Anda sendiri. Bacalah SLA (Service Level Agreement) dengan saksama. “Uptime 99,9%” masih menyisakan hampir sembilan jam downtime per tahun, dan sebagian besar SLA cloud secara eksplisit mengecualikan kategori pemadaman tertentu dari jaminan mereka.
Rencana yang Anda Butuhkan Adalah Rencana yang Bersedia Anda Pelihara
Ada godaan, pasca krisis, untuk merancang respons yang terlalu rumit (over-engineer). Saya telah melihat organisasi menghasilkan dokumen DR setebal 300 halaman yang komprehensif, sangat mendetail, dan sama sekali tidak berguna karena tidak ada yang membacanya dan tidak ada yang memeliharanya.
Rencana disaster recovery IT terbaik bukanlah yang paling menyeluruh di atas kertas. Rencana terbaik adalah yang dipahami oleh orang-orang yang harus mengeksekusinya, diuji di bawah kondisi yang mendekati kenyataan, dan diperbarui secara berkala agar mencerminkan lingkungan yang seharusnya dilindunginya.
Tahun 2020 memberikan ujian tekanan (stress test) langsung terhadap kesiapsiagaan setiap organisasi. Beberapa berhasil melewatinya. Sebagian besar tidak. Pertanyaannya sekarang adalah apakah pelajaran yang didapat akan diterjemahkan menjadi perubahan struktural atau sekadar diarsipkan bersama rencana lama yang sejak awal memang tidak berfungsi.
Saran saya: jangan menunggu krisis berikutnya untuk mencari tahu. Ambil dokumen rencana disaster recovery Anda dari rak minggu ini. Bacalah dengan sudut pandang yang segar dan ajukan satu pertanyaan sederhana — apakah ini benar-benar akan berfungsi jika semuanya kembali kacau besok? Jika jawaban jujurnya membuat Anda ragu, Anda tahu apa yang harus dilakukan selanjutnya.
