Satu pangkalan data yang tidak boleh diakses pada pagi Isnin boleh menghentikan pesanan, invois, khidmat pelanggan dan keputusan pengurusan dalam masa beberapa minit. Jika serangan ransomware, kegagalan pelayan atau gangguan elektrik berlaku, persoalannya bukan sekadar sama ada data boleh dipulihkan. Soalan yang lebih penting ialah sama ada organisasi mempunyai pelan pemulihan bencana IT syarikat yang membolehkan operasi penting kembali berjalan dalam tempoh yang boleh diterima.

Bagi banyak organisasi, sandaran data sering dianggap sebagai jawapan. Sandaran memang asas yang penting, tetapi ia bukan keseluruhan pelan. Fail mungkin masih wujud, namun sistem aplikasi, konfigurasi rangkaian, akses pengguna, peralatan gantian dan pihak yang bertanggungjawab belum tentu tersedia apabila diperlukan. Pemulihan bencana yang baik menyusun semua elemen ini supaya pasukan tidak perlu membuat keputusan kritikal ketika tekanan berada pada tahap tertinggi.

Mengapa pelan pemulihan bencana IT syarikat perlu jelas

Gangguan IT membawa kesan yang berbeza mengikut jenis perniagaan. Syarikat perkhidmatan mungkin kehilangan rekod pelanggan dan saluran komunikasi. Operasi pengedaran pula boleh terhenti kerana sistem inventori atau pengimbasan tidak berfungsi. Dalam persekitaran kejuruteraan dan makmal, kehilangan akses kepada data ujian, sistem kawalan atau perisian khusus boleh melambatkan projek, menjejaskan pematuhan dan menambah kos kerja semula.

Pelan yang jelas mengurangkan masa tidak produktif, tetapi nilainya lebih luas daripada itu. Ia membantu pemimpin operasi menetapkan keutamaan, melindungi komitmen kepada pelanggan dan memberi panduan yang boleh diikuti oleh pasukan teknikal serta bukan teknikal. Ia juga menjadi bukti kepada pihak pengurusan, pelanggan dan auditor bahawa risiko operasi ditangani secara terancang.

Tidak semua sistem perlu dipulihkan pada kelajuan yang sama. Portal pemasaran boleh menunggu lebih lama berbanding sistem pesanan, sistem kewangan atau pangkalan data pelanggan. Justeru, pelan yang berkesan perlu berasaskan kesan perniagaan, bukan semata-mata senarai aset IT.

Mulakan dengan analisis kesan perniagaan

Langkah pertama ialah mengenal pasti proses yang mesti diteruskan untuk mengekalkan operasi. Libatkan pemilik proses daripada bahagian operasi, kewangan, jualan, sumber manusia dan pasukan teknikal. Perbincangan ini perlu menjawab perkara yang praktikal: apakah tugas yang gagal apabila sistem tertentu tidak tersedia, berapa lama proses itu boleh tergendala, dan apakah pilihan kerja manual yang realistik.

Daripada analisis ini, tetapkan dua ukuran utama. Recovery Time Objective (RTO) ialah tempoh maksimum sesuatu sistem boleh tidak tersedia. Recovery Point Objective (RPO) pula menentukan jumlah data yang boleh diterima untuk hilang, diukur dari titik sandaran terakhir. Sebagai contoh, sistem invois mungkin memerlukan RTO empat jam dan RPO satu jam, manakala arkib dokumen lama mungkin boleh menerima tempoh pemulihan yang lebih panjang.

Sasaran yang terlalu agresif meningkatkan kos kerana ia mungkin memerlukan replikasi masa nyata, infrastruktur kedua dan pemantauan berterusan. Sasaran yang terlalu longgar pula boleh menjejaskan kontrak, hasil dan kepercayaan pelanggan. Keputusan yang tepat bergantung pada nilai proses, kewajipan pematuhan, bajet dan toleransi risiko organisasi.

Petakan kebergantungan yang sering terlepas pandang

Aplikasi jarang berfungsi secara bersendirian. Sistem pengurusan pelanggan mungkin memerlukan pangkalan data, pelayan identiti, sambungan internet, sijil keselamatan, storan fail dan integrasi dengan penyedia pihak ketiga. Jika satu komponen ini tidak dipulihkan, aplikasi utama masih tidak boleh digunakan walaupun pelayannya telah hidup semula.

Dokumentasikan kebergantungan tersebut bersama pemilik sistem, versi perisian, konfigurasi penting, lesen, akaun pentadbir dan lokasi sandaran. Rekod ini perlu disimpan di lokasi yang masih boleh dicapai jika rangkaian utama terganggu. Dokumentasi yang hanya tersimpan dalam pelayan yang gagal bukanlah dokumentasi pemulihan yang berguna.

Reka strategi pemulihan yang sepadan dengan risiko

Strategi pemulihan tidak perlu sama untuk setiap sistem. Sesetengah beban kerja sesuai dipulihkan daripada sandaran awan, manakala sistem yang sangat kritikal mungkin memerlukan persekitaran pemulihan berasingan atau replikasi ke tapak kedua. Bagi organisasi dengan aplikasi legasi atau peralatan khusus, pelan mungkin turut memerlukan stok perkakasan gantian, kontrak sokongan pengeluar dan prosedur konfigurasi semula yang disahkan.

Kaedah sandaran juga perlu dinilai secara menyeluruh. Pastikan data disalin secara berkala, disimpan di lokasi berlainan dan dilindungi daripada pengubahsuaian atau pemadaman tidak sah. Dalam kes ransomware, sandaran yang sentiasa bersambung kepada rangkaian boleh menjadi sasaran yang sama. Salinan tidak boleh ubah atau salinan luar talian memberikan lapisan perlindungan tambahan, walaupun ia memerlukan pengurusan dan kos yang berbeza.

Pemulihan teknikal harus mengambil kira keselamatan. Memulihkan pelayan yang masih mengandungi punca pencerobohan hanya mengulangi masalah yang sama. Sebelum sistem dikembalikan kepada pengguna, pasukan perlu mengenal pasti skop insiden, menetapkan semula kelayakan akses jika perlu, memasang tampalan keselamatan dan memeriksa log atau indikator kompromi.

Tetapkan peranan, kuasa dan komunikasi

Ketika gangguan berlaku, kelewatan sering berpunca daripada kekeliruan, bukannya kekurangan teknologi. Pelan perlu menyatakan siapa yang boleh mengisytiharkan insiden, siapa yang meluluskan perbelanjaan kecemasan, siapa yang berhubung dengan vendor, dan siapa yang memberi kemas kini kepada pelanggan serta pihak pengurusan.

Pasukan tindak balas biasanya merangkumi ketua insiden, pemilik aplikasi, pentadbir infrastruktur, pegawai keselamatan, wakil operasi dan pihak komunikasi. Satu orang boleh memegang lebih daripada satu peranan dalam syarikat kecil, tetapi tanggungjawabnya masih perlu dinyatakan dengan jelas. Sertakan juga nombor hubungan alternatif, saluran komunikasi luar sistem utama dan prosedur eskalasi 24/7.

Komunikasi yang baik tidak memerlukan janji yang terlalu awal. Makluman awal patut menerangkan jenis gangguan, proses yang terjejas, tindakan semasa dan masa kemas kini seterusnya. Selepas fakta disahkan, organisasi boleh memberi anggaran pemulihan yang lebih tepat. Pendekatan ini membantu pelanggan dan kakitangan merancang kerja mereka tanpa menerima maklumat yang mengelirukan.

Uji pelan sebelum keadaan sebenar menguji anda

Pelan di atas kertas hanya menunjukkan niat. Ujian menunjukkan sama ada ia boleh dilaksanakan. Mulakan dengan semakan meja, iaitu pasukan melalui senario seperti kegagalan storan, kebakaran di pejabat atau serangan ransomware dan membincangkan tindakan setiap peranan. Ujian ini sesuai untuk mengesan nombor hubungan yang usang, keputusan yang tidak jelas dan jurang komunikasi.

Seterusnya, jalankan ujian pemulihan sebenar secara terkawal. Pulihkan sampel sistem atau aplikasi ke persekitaran berasingan, sahkan ketepatan data, uji akses pengguna dan ukur masa yang diambil. Jangan hanya menganggap sandaran berjaya kerana proses salinan selesai. Data perlu boleh dibuka, aplikasi perlu berfungsi dan proses perniagaan kritikal perlu dapat dilakukan.

Ujian tidak semestinya menuntut penutupan operasi penuh. Organisasi boleh memilih skop mengikut kematangan dan tahap risiko. Namun, sistem yang paling kritikal wajar diuji sekurang-kurangnya setiap tahun, dan selepas perubahan besar seperti migrasi awan, kemas kini aplikasi utama, pertukaran penyedia atau penyusunan semula rangkaian.

Jadikan penambahbaikan sebagai sebahagian daripada proses

Setiap ujian dan insiden sebenar perlu menghasilkan rekod penemuan. Mungkin masa pemulihan melebihi RTO, mungkin prosedur memerlukan kelulusan terlalu banyak, atau mungkin lesen perisian tidak tersedia di persekitaran pemulihan. Tetapkan pemilik tindakan dan tarikh sasaran untuk menutup jurang tersebut. Jika tidak, laporan pasca-insiden hanya menjadi dokumen tanpa perubahan operasi.

Bila bantuan pakar memberi kelebihan

Pasukan dalaman mungkin sangat memahami sistem harian, tetapi pemulihan bencana memerlukan gabungan kepakaran infrastruktur, keselamatan, sandaran, rangkaian, aplikasi dan operasi. Bagi organisasi tanpa sumber khusus, rakan teknologi boleh membantu menjalankan analisis kesan, membina seni bina pemulihan, mendokumentasikan prosedur dan melatih pengguna utama.

Nilai rakan penyelesaian bukan hanya pada teknologi yang dicadangkan. Perhatikan keupayaan mereka memahami aliran kerja anda, kesediaan memberi sokongan selepas pelaksanaan dan kebolehan menyelaras keperluan IT dengan peralatan teknikal atau persekitaran khusus. TT Synergy Resources membantu organisasi membentuk penyelesaian yang disesuaikan dengan keperluan operasi, daripada perancangan dan pelaksanaan hingga latihan serta sokongan berterusan.

Pelan pemulihan yang boleh dipercayai tidak dibina ketika pelayan sudah gagal. Mulakan dengan satu proses paling kritikal, tetapkan sasaran pemulihan yang realistik, dan uji andaian pasukan anda. Apabila gangguan berlaku, persediaan yang jelas memberi organisasi ruang untuk bertindak dengan tenang dan terus menjaga kepercayaan pelanggan.