Blog

13 Poin untuk Dimasukkan dalam Rencana Pemulihan Bencana Anda

SEBUAH rencana pemulihan bencana (DRP) is a document you need to keep handy to handle unexpected incidents that could shut down your company’s IT systems and hinder its overall operation.
A DRP aims to get your business up and running as quickly as possible during a disaster or data breach. With an pemulihan bencana yang efektif rencanakan, kecil kemungkinan Anda kehilangan keuntungan terlalu lama. Selain itu, harus memiliki cadangan yang ditetapkan untuk mencegah data sensitif (nomor jaminan sosial atau informasi kartu kredit) disusupi.

Apakah Bisnis Anda Memiliki Rencana Pemulihan Bencana?

Data hilang, downtime, dan gangguan teknologi adalah beberapa cerita horor baru yang bahkan ditemukan oleh perusahaan top saat ini. Setiap kali terjadi bencana di suatu perusahaan, tim engineering akan segera memperbaiki kerusakan tersebut, sebaliknya tim PR bekerja lembur untuk mengembalikan kepercayaan pelanggan. Tidakkah menurut Anda ini adalah upaya yang memakan waktu dan mahal? Tentu saja! Tetapi beberapa organisasi mengelola bencana ini dengan paling efektif dan itu juga dengan kerusakan tambahan yang lebih sedikit. Ingin tahu bagaimana caranya? Sederhana, mereka memiliki rencana pemulihan bencana yang komprehensif, mudah diikuti, dan teruji secara teratur.

Disasters come uninvited with loads of complex challenges, which organizations might take months or years to overcome. Cyber attacks, tornadoes, terrorist attacks, hurricanes, and floods are some of the disasters that can cause data breaches. A disaster plan is a long-term assurance of business operability as it is designed in such a way that it enables businesses to reduce damages of unpredicted outages.

Apakah Anda memiliki rencana pemulihan bencana, atau Anda baru memulai proses pembuatannya untuk organisasi Anda? Dalam salah satu kasus ini, daftar periksa rencana pemulihan bencana di bawah ini akan membantu Anda menambahkan semua komponen penting dalam rencana Anda.

1. Analisis Potensi Ancaman dan Kemungkinan Reaksi

Hal pertama adalah meluangkan waktu dan menganalisis semua kemungkinan faktor yang dapat mengganggu arus bisnis Anda. Setelah Anda selesai melakukan penelitian, inilah saatnya membuat rencana pemulihan yang berbeda untuk setiap skenario tersebut. Misalnya, serangan dunia maya menjadi lebih umum dan cenderung terjadi, dan sayangnya, rata-rata firewall tidak cukup kuat untuk melindungi sebagian besar dari serangan tersebut.

Jadi lihatlah kemungkinan serangan dunia maya lebih intens daripada yang Anda lakukan, katakanlah, tsunami. Anda dapat memilih untuk mengenkripsi data dan mengamankan perangkat keras. Cobalah untuk memahami kerentanan yang ada di dalam sistem Anda, karena ini adalah titik masuk yang akan digunakan peretas untuk mendapatkan akses.

Cara terbaik adalah terus memperbarui diri Anda tentang banyak skema yang digunakan peretas. Anda dapat menghindari sebagian besar infeksi phishing dan malware.

2. Perbaiki Tujuan Pemulihan Bencana

Pemulihan bencana membantu Anda menjaga bisnis Anda tetap beroperasi seperti biasa, terus-menerus, jadi Anda perlu memperbaiki layanan TI yang paling penting untuk menjalankan organisasi Anda. Juga, Sasaran Waktu Pemulihan (RTO) dan Sasaran Titik Pemulihan (RPO) yang diperlukan untuk layanan / mesin ini. Tetapi apakah Anda mengetahui RTO dan RPO?

RPO: Jumlah waktu yang dibutuhkan untuk pulih dari bencana setelah pemberitahuan gangguan bisnis. Jika terjadi bencana, jika bisnis Anda tidak mampu menahan setidaknya satu jam waktu henti tanpa kehilangan pelanggan karena pesaing Anda, maka itu penting. Anda memerlukan rencana pemulihan bencana yang andal yang terdiri dari RTO yang diperbolehkan dan dinyatakan dengan jelas.

RPO: Jendela waktu di mana data dapat diterima. Setelah bencana terjadi, jika bisnis Anda hanya dapat bertahan dari kehilangan data selama empat jam setelah satu hari penuh bisnis, ini dapat menyebabkan hilangnya data penting yang sangat besar, sehingga RPO Anda akan menjadi empat jam.

RTO dan RPO organisasi pasti akan memengaruhi strategi pemulihan dan biaya terkaitnya. Untuk mengurangi total biaya strategi pemulihan bencana, lebih baik membagi aplikasi menjadi beberapa tingkatan. Tingkat tertinggi yang dicadangkan untuk aplikasi yang sangat penting akan membutuhkan teknologi pemulihan bencana berdasarkan replikasi data kontinu secara real-time. Tingkat tingkat menengah mungkin memerlukan aplikasi berbasis snapshot, dan terakhir, tingkat terendah dapat bertahan dengan sistem cadangan tingkat file sederhana.

3. Akui Pemangku Kepentingan dalam Rencana Pemulihan Bencana Anda

Langkah selanjutnya dan penting adalah mengidentifikasi mereka yang perlu diperbarui setelah bencana melanda. Insinyur, dukungan, eksekutif, dll. Akan dilibatkan dalam melakukan pemulihan bencana yang sebenarnya. Namun, Anda juga perlu mengidentifikasi orang lain seperti vendor, anggota tim humas dan pemasaran, pemasok pihak ketiga, dan pelanggan utama. Sebagian besar perusahaan menyimpan daftar pemangku kepentingan dalam dokumentasi kantor proyek mereka untuk memberi tahu jika terjadi bencana.

4. Buat situs pemulihan bencana

Ada kemungkinan besar bahwa bencana akan sangat merusak pusat produksi Anda, sehingga tidak memungkinkan Anda untuk melanjutkan operasi di lokasi utama dan dengan demikian memindahkan beban kerja penting ke lokasi lain. Menurut rencana pemulihan bencana, daftar periksa yang Anda perlukan untuk membangun situs DR untuk digunakan dalam kasus relokasi darurat data penting, staf, sumber daya fisik, aplikasi iklan. Selain itu, Anda harus melengkapi situs dengan perangkat keras dan perangkat lunak yang cukup untuk menangani beban kerja penting.

5. Kumpulkan Seluruh Dokumentasi Infrastruktur

Ketika sebuah bencana terjadi, semuanya berjalan kacau, semua orang berada di bawah tekanan. Memang, Anda memiliki tim teknisi dengan keterampilan dan pengetahuan yang diperlukan untuk mengaktifkan prosedur pemulihan bencana, tetapi dokumentasi infrastruktur adalah wajib. Bahkan insinyur yang sangat mahir saat melakukan pemulihan bencana akan lebih suka menjalankan perintah demi perintah dari dokumentasi infrastruktur.

Jadi terdiri dari apa dokumentasi ini? Seluruh pengaturan sistem dan penggunaannya (instalasi, prosedur pemulihan, aplikasi yang berjalan, OS dan konfigurasi), templat awan, penyimpanan dan basis data (bagaimana dan di mana data disimpan, bagaimana cadangan dipulihkan, bagaimana data diverifikasi keakuratannya) dan semua koneksi jaringan Anda yang dipetakan (dengan perangkat yang berfungsi dan konfigurasinya).

6. Cherry-pick the Precise Technology

Disaster Recovery as a Service (DRaaS) and on-premise disaster recovery is not just the feasible solutions available for business continuity. The next option is to make use of cloud-based disaster recovery in order to spin up your disaster recovery site on a public cloud-like Microsoft AzureAWS dan Google Cloud in minutes using an automated disaster recovery solution.

Sebelum Anda membuat pilihan solusi, pastikan untuk mempertimbangkan total biaya kepemilikan, persyaratan pemeliharaan, skalabilitas, pemulihan ke titik waktu sebelumnya, dan kemudahan pengujian. Ada banyak pilihan dalam hal solusi pemulihan bencana, jadi lakukan penelitian menyeluruh dan pilih dengan bijak.

7. Luncurkan Saluran Komunikasi

Tidak ada yang tahu kapan bencana dapat mengetuk pintu Anda, jadi sebagai sebuah organisasi, Anda harus menyimpan daftar tim (beserta peran dan informasi kontak mereka) untuk pemulihan bencana. Cobalah untuk membangun rantai komando yang komprehensif yang mencakup individu yang bertanggung jawab dari masing-masing tim teknik (misalnya, database, sistem, jaringan, penyimpanan) dan kepemimpinan eksekutif yang relevan. Juga, atur saluran dan hub komunikasi khusus, atau alat berbagi informasi online untuk digunakan dalam pengiriman pesan instan.

8. Buat Garis Besar Prosedur Penanggulangan Insiden

Jika Anda memiliki rencana pemulihan bencana, maka “prosedur tanggap insiden” adalah suatu keharusan. Di sini perusahaan akan merinci kejadian mana yang harus dinyatakan sebagai bencana. Misalnya, jika sistem Anda mati, apakah Anda akan menganggapnya sebagai bencana? Selain itu, rencana tersebut juga harus menunjukkan cara memverifikasi bencana dan bagaimana hal itu akan dilaporkan — oleh sistem pemantauan otomatis, yang diajukan oleh panggilan dari tim rekayasa keandalan lokasi (SRE), atau dilaporkan oleh pelanggan?

Untuk memverifikasi bahwa bencana benar-benar terjadi, Anda perlu memeriksa status perangkat jaringan kritis, log aplikasi, perangkat keras server, atau komponen penting lainnya dalam sistem produksi Anda, yang Anda pantau secara proaktif. Jika ada sesuatu yang aneh atau tidak berfungsi, maka pasti Anda memiliki bencana di tangan Anda.

9. Buat Garis Besar Prosedur Respon Tindakan

Setelah bencana melanda, lingkungan pemulihan bencana perlu diaktifkan secepat mungkin. Prosedur respons tindakan akan menjelaskan cara melakukan failover ke situs pemulihan bencana dengan semua langkah yang diperlukan. Tidak peduli apakah proses pemulihan Anda menggunakan DRaaS atau alat pemulihan bencana untuk meluncurkan situs bencana Anda secara otomatis, Anda perlu menyiapkan prosedur respons tindakan secara tertulis untuk memastikan bagaimana layanan yang diperlukan akan dimulai, diverifikasi, dan dikendalikan.

Selain itu, menjalankan layanan produksi di lokasi lain tidaklah cukup, memastikan bahwa semua data yang diperlukan tersedia, dan semua aplikasi bisnis yang diperlukan berfungsi dengan baik, juga sama pentingnya.

10. Bersiap untuk Gagal Kembali ke Infrastruktur Utama

Failback memulihkan operasi di pusat produksi utama setelah dipindahkan ke situs DR selama failover. Situs DR tidak dirancang untuk menjalankan operasi harian; sebaliknya, mereka hanya dapat digunakan untuk keperluan darurat. Lokasi DR dibangun untuk waktu yang sangat singkat (sampai lokasi utama dipulihkan atau sampai pusat produksi baru dibangun).

Setelah bencana selesai, banyak upaya diperlukan untuk menerapkan pemindahan data dan layanan bisnis kembali ke lokasi utama — rencanakan kemungkinan gangguan sebagian pada bisnis Anda selama proses pengembalian. Untungnya, terdapat solusi pemulihan bencana yang menyediakan failback terpadu ke lokasi utama, diaktifkan secara otomatis atau manual setelah Anda menyelesaikan verifikasi lokasi TI utama.

11. Laporkan insiden tersebut kepada pemangku kepentingan

Setelah bencana terjadi, pertama-tama beri tahu tidak hanya mereka yang bertanggung jawab untuk melaksanakan kegiatan DR tetapi juga pemangku kepentingan utama seperti vendor, pelanggan, anggota tim PR dan pemasaran, dan pemasok pihak ketiga. Juga, pertimbangkan untuk memberi tahu masing-masing kelompok ini dan merumuskan jawaban untuk mengatasi masalah mereka. Lebih baik menulis siaran pers terlebih dahulu agar tidak membuang-buang waktu saat terjadi bencana dan menyiapkannya untuk dipublikasikan.

12. Lakukan Tes Ekstensif

Menguji rencana pemulihan bencana Anda adalah wajib tetapi biasanya diabaikan. Tes failover biasanya rumit dan menyebabkan hilangnya data dan gangguan layanan produk. Oleh karena itu, sebagian besar perusahaan tidak menguji rencana pemulihan bencana mereka secara teratur.

Untuk memahami seberapa baik rencana pemulihan bencana Anda akan bekerja, Anda harus menjadwalkan pengujian failover secara teratur. Mengabaikan pengujian rencana pemulihan bencana dapat membahayakan seluruh bisnis Anda selama terjadi bencana, yang berakhir tidak dapat pulih tepat waktu atau tidak ada pemulihan sama sekali. Uji kinerja juga membantu Anda menilai apakah lokasi sekunder Anda cukup untuk menahan beban bisnis atau tidak.

13. Selalu Perbarui Rencana Pemulihan Bencana Anda

Last but not least, karena pengujian rencana pemulihan bencana adalah wajib, begitu juga dengan memperbarui semua dokumen pemulihan bencana. Di akhir setiap tes, tinjau apa yang terjadi, bagaimana tim Anda menangani tes, dan dokumentasikan temuan Anda.

Tanda tangan:

Anda dapat memilih untuk melakukan pemulihan bencana do-it-yourself (pilihan yang murah tapi rawan kesalahan) atau memiliki rencana pemulihan bencana yang berguna untuk membantu perusahaan Anda memulihkan semua data yang hilang dan mempercepat organisasi Anda kembali ke operasi bisnis normal. Selain itu, juga akan dipastikan bahwa bencana tidak akan menimbulkan konsekuensi keuangan yang merugikan dan gangguan bisnis yang besar.

Pastikan Anda mempertimbangkan setiap aspek organisasi Anda (misalnya, jumlah karyawan, anggaran yang tersedia, faktor risiko, ukuran infrastruktur TI, dll.) Untuk menentukan apa yang terbaik bagi Anda dan tim Anda.

Tinggalkan Balasan

id_IDIndonesian