Blog

13 Perkara yang perlu disertakan dalam Pelan Pemulihan Bencana Anda

A rancangan 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 berkesan rancang, tidak ada kemungkinan anda kehilangan keuntungan terlalu lama. Juga, ia harus menyediakan sandaran untuk mengelakkan data sensitif (nombor keselamatan sosial atau maklumat kad kredit) tidak terganggu.

Adakah Perniagaan Anda Mempunyai Pelan Pemulihan Bencana?

Kehilangan data, downtime, dan kemarahan teknologi adalah beberapa kisah seram baru yang bahkan terdapat di kalangan syarikat-syarikat ternama ketika ini. Setiap kali berlaku bencana di sebuah syarikat, pasukan kejuruteraan bergegas untuk memperbaiki kerosakan, dan di sisi lain, pasukan PR bekerja lebih masa untuk mengembalikan keyakinan pelanggan. Tidakkah anda fikir ini adalah usaha yang memakan masa dan mahal? Sudah tentu! Tetapi beberapa organisasi menguruskan bencana ini dengan paling berkesan dan itu juga dengan kerosakan yang kurang. Tertanya-tanya bagaimana? Sederhana, mereka mempunyai rancangan pemulihan bencana yang komprehensif, mudah diikuti, dan diuji secara berkala.

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.

Adakah anda mempunyai rancangan pemulihan bencana, atau adakah anda baru memulakan proses membuatnya untuk organisasi anda? Dalam mana-mana kes ini, senarai semak rancangan pemulihan bencana di bawah akan membantu anda menambahkan semua komponen penting dalam rancangan anda.

1. Menganalisis Potensi Ancaman dan Kemungkinan Reaksi

Perkara pertama adalah meluangkan masa dan menganalisis semua kemungkinan faktor yang boleh mengganggu aliran perniagaan anda. Setelah anda selesai menjalankan penyelidikan, sudah tiba masanya untuk membuat rancangan pemulihan yang berbeza untuk setiap senario tersebut. Sebagai contoh, serangan siber menjadi semakin lazim dan cenderung berlaku, dan malangnya, firewall rata-rata tidak cukup kuat untuk melindungi dari kebanyakan dari mereka.

Oleh itu, perhatikan kemungkinan serangan siber lebih intensif daripada yang anda katakan, katakanlah, tsunami. Anda mungkin memilih untuk menyulitkan data dan mengamankan perkakasan. Cuba fahami kelemahan yang ada di dalam sistem anda, kerana ini adalah titik masuk yang akan digunakan oleh penggodam untuk mendapatkan akses.

Cara terbaik adalah untuk terus mengemas kini mengenai banyak skema yang digunakan penggodam. Anda boleh mengelakkan sebilangan besar jangkitan pancingan data dan perisian hasad.

2. Betulkan Objektif Pemulihan Bencana

Pemulihan bencana membantu anda menjalankan perniagaan anda seperti biasa, sentiasa, jadi anda perlu memperbaiki perkhidmatan IT yang paling penting untuk menjalankan organisasi anda. Juga, Objektif Masa Pemulihan (RTO) dan Objektif Titik Pemulihan (RPO) diperlukan untuk perkhidmatan / mesin ini. Tetapi adakah anda menyedari RTO dan RPO?

RPO: Jumlah masa yang diperlukan untuk pulih dari bencana setelah pemberitahuan mengenai gangguan perniagaan. Sekiranya berlaku bencana, jika perniagaan anda tidak dapat bertahan sekurang-kurangnya satu jam waktu henti tanpa kehilangan pelanggan daripada pesaing anda, maka sangat penting. Anda memerlukan rancangan pemulihan bencana yang boleh dipercayai yang terdiri daripada RTO yang dibenarkan dengan jelas.

RPO: Tetingkap masa di mana data boleh diterima. Selepas mogok bencana, jika perniagaan anda hanya dapat bertahan dari kehilangan data selama empat jam setelah seharian penuh perniagaan, ini dapat mengakibatkan bencana kehilangan data penting, jadi RPO anda akan menjadi empat jam.

RTO dan RPO organisasi pasti mempengaruhi strategi pemulihan dan perbelanjaan yang berkaitan. Untuk mengurangkan jumlah kos strategi pemulihan bencana, lebih baik membagi aplikasi menjadi tingkatan. Tahap tertinggi yang diperuntukkan untuk aplikasi kritikal misi memerlukan teknologi pemulihan bencana berdasarkan replikasi data berterusan masa nyata. Tahap peringkat pertengahan mungkin memerlukan aplikasi berasaskan snapshot, dan akhirnya, tahap terendah mungkin diperoleh dengan sistem sandaran peringkat fail yang mudah.

3. Kenali Pemangku Kepentingan dalam Pelan Pemulihan Bencana Anda

Langkah seterusnya dan penting adalah mengenal pasti mereka yang perlu dikemas kini sebaik sahaja berlaku bencana. Jurutera, sokongan, eksekutif, dan lain-lain akan terlibat dalam melaksanakan pemulihan bencana yang sebenarnya. Namun, anda juga perlu mengenal pasti orang lain seperti vendor, anggota PR dan pasukan pemasaran, pembekal pihak ketiga, dan pelanggan utama. Sebilangan besar syarikat menyimpan daftar pihak berkepentingan dalam dokumentasi pejabat projek mereka untuk diberitahu sekiranya berlaku bencana.

4. Buat laman web pemulihan bencana

Terdapat kemungkinan besar bahawa bencana akan merosakkan pusat pengeluaran anda dengan teruk, sehingga tidak mungkin bagi anda untuk meneruskan operasi di laman utama dan dengan itu memindahkan beban kerja yang kritikal ke lokasi lain. Menurut rancangan pemulihan bencana, senarai semak yang anda perlukan untuk membina laman DR untuk digunakan sekiranya berlaku kecemasan penempatan semula data kritikal, kakitangan, sumber fizikal, aplikasi iklan. Anda juga harus melengkapkan laman web ini dengan perkakasan dan perisian yang mencukupi untuk menanggung beban kerja yang penting.

5. Kumpulkan Keseluruhan Dokumentasi Infrastruktur

Apabila bencana berlaku, semuanya berlaku untuk melemparkan, semua orang berada dalam tekanan. Memang, anda mempunyai pasukan kejuruteraan anda dengan kemahiran dan pengetahuan yang diperlukan untuk mengaktifkan prosedur pemulihan bencana, tetapi dokumentasi infrastruktur adalah wajib. Malah jurutera yang sangat mahir ketika melakukan pemulihan bencana lebih suka memilih arahan dari dokumentasi infrastruktur.

Oleh itu, apa yang terdiri daripada dokumentasi ini? Keseluruhan penyediaan sistem dan penggunaannya (pemasangan, prosedur pemulihan, aplikasi berjalan, OS dan konfigurasi), templat awan, penyimpanan dan pangkalan data (bagaimana dan di mana data disimpan, bagaimana sandaran dipulihkan, bagaimana data disahkan untuk ketepatan) dan semua sambungan rangkaian anda yang dipetakan (dengan peranti yang berfungsi dan konfigurasi mereka).

6. Pilih Teknologi tepat

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 Awan Google in minutes using an automated disaster recovery solution.

Sebelum anda membuat pilihan penyelesaian, pastikan untuk mempertimbangkan jumlah kos pemilikan, keperluan penyelenggaraan, skalabilitas, pemulihan ke titik waktu sebelumnya, dan kemudahan pengujian. Banyak pilihan yang berkaitan dengan penyelesaian pemulihan bencana, jadi anda membuat kajian menyeluruh dan memilih dengan bijak.

7. Lancarkan Saluran Komunikasi

Tidak ada yang tahu kapan bencana dapat mengetuk pintu Anda, jadi sebagai sebuah organisasi, anda mesti menyimpan senarai pasukan (bersama dengan peranan dan maklumat hubungan mereka) untuk pemulihan bencana. Cuba buat rantaian arahan yang komprehensif yang merangkumi individu yang bertanggungjawab dari setiap pasukan kejuruteraan (contohnya, pangkalan data, sistem, rangkaian, penyimpanan) dan kepemimpinan eksekutif yang berkaitan. Juga, sediakan saluran komunikasi dan hub khusus, atau alat perkongsian maklumat dalam talian untuk digunakan untuk pesanan segera.

8. Gariskan Prosedur Respons Kejadian

Sekiranya anda mempunyai rancangan pemulihan bencana, maka "prosedur tindak balas insiden" adalah suatu keharusan. Di sini syarikat akan menentukan secara terperinci peristiwa mana yang harus dinyatakan sebagai bencana. Sebagai contoh, jika sistem anda tidak berfungsi, adakah anda akan menganggapnya sebagai bencana? Juga, rancangan itu juga harus menunjukkan bagaimana untuk mengesahkan bencana dan bagaimana ia akan dilaporkan— oleh sistem pemantauan automatik, yang ditimbulkan oleh panggilan dari pasukan kejuruteraan kebolehpercayaan laman web (SRE), atau dilaporkan oleh pelanggan?

Untuk mengesahkan bahawa bencana benar-benar berlaku, anda perlu memeriksa status peranti rangkaian kritikal, log aplikasi, perkakasan pelayan, atau komponen kritikal lain dalam sistem pengeluaran anda, yang anda pantau secara proaktif. Sekiranya ada sesuatu yang ganjil atau tidak berfungsi, pasti anda akan mengalami musibah.

9. Gariskan Prosedur Tindakan Tindakan

Setelah bencana melanda, persekitaran pemulihan bencana perlu diaktifkan secepat mungkin. Prosedur tindak balas tindakan akan menggariskan bagaimana failover ke lokasi pemulihan bencana dengan semua langkah yang diperlukan. Tidak kira sama ada proses pemulihan anda menggunakan DRaaS atau alat pemulihan bencana untuk melancarkan laman bencana anda secara automatik, anda perlu menyiapkan prosedur tindak balas tindakan secara bertulis untuk memastikan bagaimana perkhidmatan yang diperlukan akan dimulakan, disahkan, dan dikendalikan.

Selain itu, meningkatkan perkhidmatan pengeluaran di lokasi lain tidak mencukupi, memastikan bahawa semua data yang diperlukan ada di tempatnya, dan semua aplikasi perniagaan yang diperlukan berfungsi dengan baik, juga sama pentingnya.

10. Bersedia untuk Gagal Kembali ke Prasarana Utama

Failback adalah memulihkan operasi di pusat pengeluaran utama setelah mereka dipindahkan ke laman DR semasa failover. Laman DR tidak dirancang untuk menjalankan operasi harian; sebaliknya, ia hanya boleh digunakan untuk tujuan kecemasan. Laman DR dibina dalam jangka masa yang sangat singkat (sehingga tapak utama dipulihkan atau sehingga pusat pengeluaran baru dibina).

Setelah bencana berakhir, banyak usaha diperlukan untuk melaksanakan pemindahan data dan perkhidmatan perniagaan kembali ke lokasi utama — rencanakan kemungkinan gangguan sebahagian perniagaan anda semasa proses pengembalian. Nasib baik, ada penyelesaian pemulihan bencana yang memberikan kegagalan balik bersatu ke lokasi utama, diaktifkan secara automatik atau manual setelah anda menyelesaikan pengesahan lokasi IT utama.

11. Laporkan kejadian tersebut kepada pihak berkepentingan

Sebaik sahaja berlaku bencana, beritahu terlebih dahulu bukan sahaja mereka yang bertanggungjawab untuk melaksanakan aktiviti DR tetapi juga pihak berkepentingan utama seperti vendor, pelanggan, anggota PR dan pasukan pemasaran, dan pembekal pihak ketiga. Juga, pertimbangkan untuk memberitahu setiap kumpulan ini dan rumuskan jawapan untuk mengatasi masalah mereka. Lebih baik menulis siaran pers terlebih dahulu untuk tidak membuang masa semasa bencana yang sebenarnya dan siapkan untuk diterbitkan.

12. Lakukan Ujian Luas

Menguji rancangan pemulihan bencana anda adalah wajib tetapi biasanya diabaikan. Ujian failover biasanya kompleks dan mengakibatkan kehilangan data dan gangguan perkhidmatan produk. Oleh itu, kebanyakan syarikat tidak menguji rancangan pemulihan bencana mereka secara berkala.

Untuk memahami seberapa baik rancangan pemulihan bencana anda berfungsi, anda mesti menjadualkan ujian failover berkala. Mengabaikan ujian rancangan pemulihan bencana boleh membahayakan seluruh perniagaan anda semasa mogok bencana, akhirnya tidak dapat pulih tepat pada waktunya atau tidak ada pemulihan sama sekali. Ujian prestasi juga membantu anda menilai sama ada lokasi sekunder anda mencukupi untuk menahan beban perniagaan atau tidak.

13. Pastikan Pelan Pemulihan Bencana anda Dikemas kini

Akhir sekali, kerana pengujian rancangan pemulihan bencana adalah wajib, begitu juga dengan memperbarui semua dokumen pemulihan bencana. Pada akhir setiap ujian, tinjau apa yang berlaku, bagaimana pasukan anda mengendalikan ujian, dan dokumentasikan penemuan anda.

Keluar:

Anda boleh memilih untuk melakukan pemulihan bencana do-it-yourself (pilihan yang murah tetapi rawan kesalahan) atau mempunyai rancangan pemulihan bencana yang baik untuk membantu syarikat anda memulihkan semua data yang hilang dan mempercepat organisasi anda kembali ke operasi perniagaan biasa. Selain itu, ia juga akan memastikan bahawa bencana tidak akan mencetuskan akibat kewangan dan gangguan perniagaan yang besar.

Pastikan anda mengambil kira setiap aspek organisasi anda (misalnya, jumlah pekerja, anggaran yang ada, faktor risiko, ukuran infrastruktur IT, dll.) Untuk menentukan apa yang paling sesuai untuk anda dan pasukan anda.

Tinggalkan pesanan

ms_MYMalay