Rencana Pemulihan Bencana dan Kesinambungan Bisnis: Siap Sebelum Sistem Tiba-Tiba Mati

Pada suatu pagi, sistem kasir tidak bisa dibuka. Server di ruang belakang mati karena gangguan listrik, atau layanan penyimpanan yang dipakai bisnis mengalami gangguan besar, atau seorang karyawan tanpa sengaja mengenkripsi seluruh data karena membuka lampiran surel yang menipu. Pertanyaan yang muncul dalam hitungan detik adalah sama: berapa lama kita bisa beroperasi tanpa sistem ini, dan bagaimana mengembalikannya?

Sebagian besar bisnis tidak pernah memikirkan pertanyaan itu sampai kejadiannya benar-benar datang. Padahal bagi bisnis yang pekerjaannya bergantung pada sistem digital, entah itu toko online, klinik, distribusi, atau layanan jasa, gangguan beberapa jam saja dapat berarti pesanan hilang, pelanggan kecewa, dan kerugian yang sulit dipulihkan.

Artikel ini membahas rencana pemulihan bencana dan kesinambungan bisnis dengan bahasa yang praktis. Kita akan melihat perbedaan keduanya, bagaimana menentukan seberapa cepat sistem harus pulih, apa saja yang perlu disiapkan, bagaimana melatih rencana itu, dan bagaimana memulai dengan sumber daya yang terbatas tanpa harus membangun infrastruktur yang mahal.

Ringkasan

• Kesinambungan bisnis menjaga operasi tetap berjalan; pemulihan bencana mengembalikan sistem teknologi
• Tentukan dua angka: berapa lama gangguan dapat ditoleransi dan berapa banyak data yang boleh hilang
• Cadangan yang tidak pernah diuji bukanlah cadangan, hanya harapan
• Rencana tertulis, peran yang jelas, dan latihan berkala lebih penting daripada peralatan mahal
• Mulailah dari sistem paling kritis, lalu perluas secara bertahap

Dua istilah yang sering tertukar

Kesinambungan bisnis adalah kemampuan organisasi untuk terus menjalankan fungsi pentingnya selama dan sesudah gangguan. Ia mencakup orang, proses, lokasi, pemasok, dan teknologi. Pertanyaannya luas: bila kantor tidak bisa dipakai, bagaimana pelanggan tetap dilayani? Bila pemasok utama berhenti, siapa penggantinya?

Pemulihan bencana adalah bagian yang lebih sempit, yaitu rencana untuk memulihkan sistem teknologi informasi dan data setelah gangguan. Ia menjawab: bagaimana server, aplikasi, basis data, dan jaringan dikembalikan, dalam urutan apa, oleh siapa, dan dari cadangan mana.

Keduanya saling melengkapi. Rencana pemulihan teknologi yang sempurna tidak berguna bila karyawan tidak tahu cara melayani pelanggan selama sistem mati. Sebaliknya, rencana kesinambungan yang baik membutuhkan sistem yang bisa dipulihkan dalam waktu yang masuk akal.

Apa saja yang bisa menjadi bencana

Kata bencana sering membuat orang membayangkan banjir atau kebakaran. Kenyataannya, sebagian besar gangguan bisnis berasal dari kejadian yang lebih biasa. Mengenali jenis gangguan yang paling mungkin membantu Anda menyiapkan respons yang proporsional, bukan menyiapkan diri hanya untuk skenario yang dramatis.

• Kegagalan perangkat keras: server, penyimpanan, atau perangkat jaringan yang rusak
• Kesalahan manusia: data terhapus, konfigurasi salah, atau pembaruan yang merusak
• Serangan siber: perangkat pemeras, pencurian akun, atau gangguan layanan
• Gangguan penyedia: layanan awan, internet, listrik, atau pembayaran yang terhenti
• Bencana fisik: kebakaran, banjir, gempa, atau pencurian peralatan
• Hilangnya orang kunci: pengetahuan penting yang hanya dimiliki satu individu

Untuk setiap jenis, pikirkan kemungkinan terjadinya dan dampaknya pada bisnis Anda. Penilaian sederhana, bahkan dalam bentuk tabel dengan tingkat tinggi, sedang, dan rendah, sudah cukup untuk menentukan prioritas. Anda tidak perlu menyiapkan segalanya sekaligus; cukup mulai dari yang paling mungkin dan paling merugikan.

Dua angka yang menentukan segalanya: RTO dan RPO

Dua istilah teknis ini sangat berguna karena mengubah pembicaraan yang abstrak menjadi keputusan konkret. Recovery time objective, atau RTO, adalah berapa lama sebuah sistem boleh mati sebelum dampaknya tidak dapat diterima. Recovery point objective, atau RPO, adalah berapa banyak data yang boleh hilang, diukur dalam waktu mundur dari saat gangguan.

Bila RPO sebuah sistem kasir adalah satu jam, artinya Anda sanggup kehilangan transaksi satu jam terakhir sehingga cadangan perlu dibuat paling tidak setiap jam. Bila RTO-nya empat jam, sistem harus bisa berjalan kembali dalam empat jam setelah gangguan. Semakin ketat angkanya, semakin mahal solusinya.

Tidak semua sistem membutuhkan angka yang sama. Sistem kasir dan pemrosesan pesanan mungkin memerlukan pemulihan cepat, sedangkan sistem pelaporan bulanan dapat menunggu sehari. Mengelompokkan sistem ke dalam tingkat kritikalitas menghemat biaya karena sumber daya terbaik dipakai untuk yang paling penting.

Strategi cadangan yang bisa diandalkan

Cadangan adalah fondasi pemulihan. Aturan yang sering dipakai adalah memiliki setidaknya tiga salinan data, pada dua jenis media atau lokasi berbeda, dengan satu salinan berada di luar lokasi utama. Tujuannya sederhana: tidak ada satu kejadian pun, baik kebakaran, pencurian, maupun perangkat pemeras, yang dapat menghilangkan seluruh salinan sekaligus.

Perangkat pemeras telah mengubah cara berpikir tentang cadangan. Penyerang kini sering mencari dan merusak cadangan lebih dulu sebelum mengenkripsi data utama. Karena itu, sebagian salinan sebaiknya tidak dapat diubah atau terputus dari jaringan utama, sehingga tidak bisa dijangkau oleh akun yang sama yang dipakai sehari-hari.

• Cadangan otomatis terjadwal sesuai RPO, bukan bergantung pada ingatan seseorang
• Salinan di luar lokasi atau di penyedia terpisah dengan akses yang berbeda
• Salinan yang tidak dapat diubah selama jangka waktu tertentu untuk melawan perangkat pemeras
• Enkripsi cadangan, dan penyimpanan kunci di tempat yang aman dan terpisah
• Pemantauan keberhasilan cadangan dengan pemberitahuan bila gagal
• Cakupan menyeluruh: basis data, berkas, konfigurasi, dan rahasia aplikasi

Cadangan yang belum pernah diuji hanyalah harapan

Banyak bisnis memiliki cadangan yang berjalan setiap malam dan merasa aman. Baru saat benar-benar dibutuhkan mereka menemukan bahwa berkasnya rusak, tidak lengkap, atau tidak ada yang tahu cara memulihkannya. Satu-satunya cara mengetahui bahwa cadangan bekerja adalah mencoba memulihkannya.

Jadwalkan uji pemulihan secara berkala. Mulailah dari yang sederhana: pulihkan satu berkas acak dari cadangan dan pastikan bisa dibuka. Lalu tingkatkan: pulihkan sebuah basis data ke lingkungan uji dan periksa isinya. Pada tingkat tertinggi, simulasikan pemulihan seluruh sistem dan ukur berapa lama yang sebenarnya dibutuhkan, lalu bandingkan dengan RTO.

Catat hasil setiap uji: apa yang berhasil, apa yang gagal, dan berapa lama. Temuan dari uji adalah bahan paling berharga untuk memperbaiki rencana. Waktu yang diukur dalam latihan sering jauh lebih lama dari perkiraan, dan lebih baik mengetahuinya sekarang daripada saat krisis.

Menulis rencana yang benar-benar dipakai

Rencana pemulihan yang tersimpan di server yang sedang mati tidak banyak gunanya. Simpan salinan rencana di tempat yang dapat diakses saat sistem utama tidak tersedia: tercetak, di penyimpanan terpisah, dan di ponsel orang-orang kunci. Rencana juga harus cukup singkat dan jelas untuk dibaca di tengah tekanan.

1. 01Daftar sistem dan layanan, dikelompokkan menurut tingkat kritikalitas dengan RTO dan RPO masing-masing
2. 02Siapa yang berwenang menyatakan keadaan darurat dan memulai rencana
3. 03Daftar kontak: tim internal, penyedia layanan, vendor, dan pihak berwenang
4. 04Langkah pemulihan per sistem dalam urutan yang benar, termasuk ketergantungan antar sistem
5. 05Lokasi cadangan, cara mengaksesnya, dan siapa yang memegang kredensialnya
6. 06Cara kerja sementara bagi karyawan dan layanan pelanggan selama sistem belum pulih
7. 07Rencana komunikasi kepada karyawan, pelanggan, dan mitra

Urutan pemulihan penting. Basis data biasanya dipulihkan sebelum aplikasi yang bergantung padanya; layanan identitas dan jaringan sering harus lebih dulu dari semuanya. Menuliskan ketergantungan ini di muka mencegah kebingungan dan waktu terbuang saat tekanan tinggi.

Kesinambungan operasional: bekerja saat sistem mati

Sering kali pertanyaan paling penting bukan bagaimana memulihkan server, tetapi bagaimana pekerjaan berjalan sementara itu. Toko perlu cara mencatat penjualan, gudang perlu cara mengeluarkan barang, dan layanan pelanggan perlu cara menjawab tanpa akses ke data. Prosedur cadangan manual yang sederhana sering kali cukup untuk beberapa jam.

• Formulir cetak atau lembar kerja luring untuk mencatat transaksi sementara
• Cara menerima pembayaran bila sistem utama tidak tersedia
• Daftar kontak pelanggan dan pemasok penting yang tersimpan terpisah
• Prosedur memasukkan kembali data manual setelah sistem pulih tanpa duplikasi
• Pesan standar untuk pelanggan tentang gangguan dan perkiraan pemulihan
• Aturan siapa yang berhak mengambil keputusan khusus saat sistem mati

Latih prosedur manual ini minimal setahun sekali. Karyawan yang belum pernah mencobanya akan kebingungan saat benar-benar dibutuhkan. Latihan juga mengungkap hal-hal kecil yang terlewat, seperti formulir yang habis atau nomor telepon yang sudah tidak berlaku.

Pilihan infrastruktur dan biayanya

Ada spektrum pilihan untuk mencapai RTO yang ketat. Di ujung sederhana, cadangan di luar lokasi dan prosedur pemulihan manual cukup untuk sistem dengan toleransi sehari atau lebih. Di tengah, lingkungan siaga yang sudah disiapkan di awan dapat dinyalakan saat dibutuhkan, dengan RTO hitungan jam. Di ujung mahal, sistem aktif ganda berjalan paralel di dua lokasi dengan RTO hampir nol.

Layanan awan membuat pilihan tengah jauh lebih terjangkau daripada dulu, karena Anda membayar sumber daya siaga hanya saat dipakai. Namun awan tidak menghapus kebutuhan akan rencana. Ketersediaan layanan awan adalah tanggung jawab bersama: penyedia menjaga infrastrukturnya, sedangkan konfigurasi, data, dan cadangan Anda tetap menjadi tanggung jawab Anda.

Pilihlah tingkat yang sebanding dengan nilai sistemnya. Menghabiskan biaya besar untuk pemulihan sistem pelaporan yang bisa menunggu seminggu adalah pemborosan, sementara mengabaikan sistem yang menghentikan seluruh penjualan adalah risiko. Tinjau pilihan ini setiap tahun karena nilai dan kebutuhan bisnis berubah.

Pencegahan dan pemulihan berjalan berdampingan

Rencana pemulihan tidak menggantikan pencegahan; keduanya saling melengkapi. Setiap gangguan yang berhasil dicegah adalah satu latihan pemulihan yang tidak perlu dijalankan. Langkah pencegahan dasar yang konsisten sering kali lebih berpengaruh daripada solusi canggih yang diterapkan setengah-setengah.

• Pembaruan keamanan secara rutin untuk sistem operasi dan aplikasi
• Autentikasi berlapis untuk akun penting dan akses jarak jauh
• Pemisahan jaringan sehingga satu perangkat yang terinfeksi tidak menjangkau semuanya
• Pelatihan karyawan mengenali surel dan tautan yang menipu
• Pembatasan hak akses agar kesalahan atau penyusupan tidak merusak seluruh sistem
• Pemantauan dan peringatan dini atas aktivitas yang tidak biasa

Kombinasi pencegahan yang sederhana dan pemulihan yang teruji menciptakan ketahanan yang realistis. Anda tidak bisa menjamin tidak ada kejadian, tetapi Anda bisa memastikan kejadian tidak berubah menjadi bencana yang menghentikan bisnis.

Orang dan komunikasi saat krisis

Teknologi hanya sebagian dari pemulihan; sisanya adalah orang. Tetapkan siapa memimpin respons, siapa yang berkomunikasi, siapa yang melakukan pemulihan teknis, dan siapa penggantinya bila orang tersebut tidak tersedia. Satu orang yang menjadi satu-satunya pemegang pengetahuan adalah titik kegagalan tersendiri.

Komunikasi yang jujur dan tepat waktu menjaga kepercayaan. Pelanggan umumnya memaklumi gangguan bila diberi tahu apa yang terjadi dan kapan perkiraan pulih, tetapi kecewa bila dibiarkan tanpa kabar. Siapkan templat pesan untuk berbagai situasi sehingga tim tidak perlu menyusunnya dari nol saat tertekan.

Setelah kejadian, adakan tinjauan tanpa mencari kambing hitam. Apa yang terjadi, mengapa, apa yang berjalan baik, dan apa yang perlu diperbaiki. Tinjauan semacam ini mengubah setiap gangguan menjadi pembelajaran yang memperkuat rencana berikutnya.

Mengaitkan pemulihan dengan pemasok dan mitra

Bisnis Anda bergantung pada pihak lain: penyedia internet, layanan awan, pemroses pembayaran, kurir, dan pemasok barang. Gangguan pada salah satunya dapat melumpuhkan operasi Anda meskipun sistem internal baik-baik saja. Daftar ketergantungan eksternal ini perlu dimasukkan ke dalam rencana, lengkap dengan alternatif bila memungkinkan.

Tanyakan kepada penyedia kritis tentang jaminan ketersediaan, prosedur pemulihan, dan cara mereka memberi tahu pelanggan saat terjadi gangguan. Periksa pula apakah ada alternatif yang dapat dipakai dengan cepat, misalnya koneksi internet cadangan atau penyedia pembayaran kedua. Satu jalur tunggal untuk fungsi yang sangat penting adalah risiko yang layak dipertimbangkan ulang.

Memulai dengan sumber daya terbatas

1. 01Daftar sistem yang dipakai dan tentukan tiga yang paling kritis bagi bisnis
2. 02Tetapkan RTO dan RPO kasar untuk ketiganya bersama pemilik proses
3. 03Pastikan ada cadangan otomatis di lokasi terpisah, dan uji pemulihan satu kali
4. 04Tulis rencana satu hingga dua halaman dengan kontak, peran, dan langkah utama
5. 05Siapkan prosedur manual sederhana untuk fungsi bisnis yang paling penting
6. 06Adakan latihan meja sekali setahun: bahas skenario dan telusuri rencana bersama
7. 07Tinjau dan perbarui rencana setiap kali ada sistem atau orang kunci yang berubah

Latihan meja adalah cara murah dan efektif untuk memulai. Kumpulkan orang-orang kunci, ceritakan skenario seperti "server utama mati pada jam sibuk", lalu telusuri langkah demi langkah apa yang akan dilakukan. Biasanya terungkap celah-celah penting hanya dari satu jam diskusi.

Kesalahan yang sering terjadi

• Mengira cadangan sama dengan pemulihan tanpa pernah mengujinya
• Menyimpan cadangan di lokasi dan jaringan yang sama dengan sistem utama
• Rencana yang hanya ada di kepala satu orang atau di sistem yang mungkin mati
• Tidak memperbarui rencana setelah sistem dan orang berganti
• Hanya memikirkan teknologi dan melupakan cara kerja serta komunikasi
• Menganggap layanan awan otomatis menyelesaikan seluruh urusan pemulihan

Penutup

Tidak ada bisnis yang kebal dari gangguan, tetapi ada perbedaan besar antara bisnis yang pulih dalam hitungan jam dan yang lumpuh berhari-hari. Perbedaannya hampir selalu terletak pada persiapan yang dilakukan dengan tenang sebelum kejadian, bukan pada peralatan termahal.

Mulailah dari yang kecil: tentukan sistem paling kritis, tetapkan angka toleransi, pastikan cadangan benar-benar dapat dipulihkan, tulis rencana singkat, dan latih. Setiap langkah mengurangi ketidakpastian, dan saat gangguan benar-benar datang, tim Anda akan tahu apa yang harus dilakukan.