Pekerjaan tidak selesai sampai dokumen selesai.
Tidak ada pepatah yang lebih benar daripada dalam perencanaan pemulihan bencana. Dokumen dalam perencanaan DR menguraikan cara memulai bisnis saat bisnis besar terjadi. Tergantung di mana bisnis Anda berada, yang besar mungkin gempa bumi, pemogokan buruh, badai, banjir, atau segerombolan belalang.
Dokumen untuk perencanaan DR hanya mencakup prosedur dan dokumen lain yang harus dirujuk oleh personel bisnis agar semuanya berjalan kembali setelah bencana. Prosedur perencanaan DR sangat penting karena orang yang bukan ahli terkemuka pada sistem yang mendukung proses bisnis penting mungkin harus membaca dan mengikuti prosedur tersebut. Orang-orang tersebut harus membangun kembali sistem kritis dalam waktu singkat sehingga sistem tersebut dapat mendukung proses kritis. Dan orang-orang yang melakukan proses tersebut mungkin bukan ahli materi pelajaran di tingkat proses bisnis.
Kelangsungan hidup bisnis tergantung pada dokumen yang benar. Anda tidak mendapatkan kesempatan kedua.
Dalam bab ini, saya menjelaskan bagaimana sebenarnya menuliskan rencana DR.
Anda hanya menyukai dokumentasi, bukan? Berpikir begitu.
Menentukan Isi Rencana
Sebelum memulai tugas menulis rencana DR, tim perlu menyepakati apa itu rencana DR. Anda dapat menggambarkannya seperti ini:
Rencana pemulihan bencana adalah kumpulan dokumen yang menjelaskan tanggap darurat pascabencana, penilaian kerusakan, dan restart sistem untuk proses bisnis penting yang ditentukan.
Iblis, seperti yang mereka katakan, ada dalam detailnya.
Rencana DR harus berisi beberapa elemen kunci yang dapat Anda gunakan untuk memulai sistem dan proses penting setelah bencana terjadi. Sebagian besar organisasi harus memasukkan elemen-elemen berikut dalam rencana DR mereka:
- Prosedur deklarasi bencana
- Daftar kontak darurat dan pohon
- Pemilihan kepemimpinan darurat (tim kepemimpinan yang telah ditentukan dan juga prosedur untuk membentuk tim dengan cepat)
- Prosedur penilaian kerusakan
- Prosedur pemulihan dan restart sistem Prosedur untuk transisi ke operasi normal
- Pemilihan tim pemulihan (tim pemulihan yang telah dipilih sebelumnya, serta proses untuk menemukan orang lain yang dapat membantu saat bencana benar-benar terjadi)
Saya membahas elemen-elemen ini secara lebih rinci di bagian berikut.
Prosedur deklarasi bencana
Prosedur pemulihan bencana dimulai ketika seseorang mengatakan demikian. Dan kapan seseorang berkata begitu? Ketika bencana telah terjadi.
Maaf jika ini terdengar konyol. Banyak perencana DR terlalu terpaku pada cara menyatakan bencana. Berikut adalah beberapa ide tentang cara mendeklarasikan bencana, salah satunya mungkin cocok untuk Anda:
Deklarasi berdasarkan konsensus: Anda menunjuk tim inti pembuat keputusan, mungkin manajer menengah atau senior, sebagai tim kepemimpinan DR. Ketika bencana terjadi, anggota tim inti saling menghubungi dan mungkin mengadakan panggilan konferensi, jika mereka bisa. Ketika dua atau lebih anggota tim inti setuju bahwa organisasi harus memulai rencana pemulihan bencana, mereka membuat keputusan itu. Keputusan ini memicu eksekusi rencana DR. Deklarasi tipikal mungkin seperti ini:
1. Peristiwa itu terjadi.
2. Dua atau lebih anggota tim inti rencana DR mendiskusikan acara tersebut melalui telepon, jika memungkinkan. Mereka bertukar informasi tentang apa yang mereka ketahui tentang acara tersebut dan potensi dampaknya terhadap bisnis.
3. Dua atau lebih anggota tim inti menyimpulkan bahwa peristiwa tersebut memiliki dampak yang cukup besar pada bisnis untuk mempengaruhi operasi bisnis.
4. Anggota tim inti memutuskan untuk menyatakan bencana, yang memicu tindakan tanggap bencana dan pemulihan, termasuk melakukan komunikasi darurat dan rencana tindakan yang menilai kerusakan dan memulai pemulihan layanan.
Anda tidak perlu membuat prosedur deklarasi bencana Anda jauh lebih rumit daripada langkah-langkah sebelumnya.
Anggota tim inti mungkin atau mungkin tidak berada di dekat fasilitas bisnis saat mereka perlu melakukan penilaian langsung terhadap dampak acara. Mereka dapat membuat panggilan penilaian dan memutuskan berdasarkan apa yang mereka ketahui pada saat itu, atau mereka dapat memilih untuk mengumpulkan lebih banyak informasi sebelum membuat pernyataan.
Deklarasi berdasarkan kriteria: Tunjuk anggota tim inti sebagai tim kepemimpinan DR. Ketika suatu peristiwa terjadi, satu atau lebih dari mereka membaca daftar periksa singkat, yang mungkin berupa serangkaian pertanyaan Ya atau Tidak. Jika jawaban tertentu, atau jumlah minimum jawaban adalah Ya, tim menyatakan bencana, yang memicu rencana DR. Inilah bagaimana proses ini mungkin terjadi dalam bencana:
1. Terjadi peristiwa terkait cuaca yang berdampak luas pada kota.
2. Anggota tim inti rencana DR mulai menghubungi satu sama lain untuk berbagi informasi tentang situasi tersebut.
3. Anggota tim inti yang tersedia menjawab pertanyaan dasar pada daftar periksa deklarasi bencana mereka. Anggota tim inti memutuskan bahwa hasil daftar periksa memerlukan deklarasi bencana. Jika mereka tidak dapat mencapai konsensus, mereka harus mengumpulkan lebih banyak informasi atau hanya memutuskan satu atau lain cara.
4. Tim inti menyatakan bencana dan mulai memberi tahu anggota tim inti lainnya, menginstruksikan mereka untuk mulai bekerja melalui prosedur rencana DR mereka untuk menilai, menahan, dan memulai pemulihan dari bencana.
Selama bertahun-tahun, saya mendengar banyak orang mengungkapkan kekhawatiran yang sama: Bagaimana jika sebuah organisasi menyatakan bencana secara tidak perlu? Jawaban singkatnya: Jangan khawatir tentang itu. Jika tim inti menyatakan bencana, dan mereka kemudian memutuskan bahwa situasinya tidak terlalu buruk, mereka dapat menghentikan respons bencana. Misalnya, jika peristiwa cuaca buruk mengakibatkan pemadaman utilitas dan masalah transportasi yang meluas, sebuah organisasi mungkin pada awalnya menyatakan bencana tetapi kemudian membatalkan upaya tanggap bencana ketika menemukan bahwa sistem TI kritis hanya terisolasi ringan dan dapat dipulihkan dengan cepat, meskipun bersalju. , inci air, abu vulkanik, atau apa pun yang mendorong deklarasi bencana. Anda dapat membuat deklarasi bencana sebagai ilmiah atau tidak ilmiah seperti yang Anda inginkan. Jangan terlalu rumit,
Daftar kontak darurat dan pohon
Setelah Anda menyatakan bencana, langkah logis berikutnya dalam rencana komprehensif adalah mulai memberi tahu personel yang bertanggung jawab untuk melakukan aktivitas terkait rencana DR, seperti komunikasi, penilaian, dan pemulihan. Anggota tim inti rencana DR yang berpartisipasi dalam deklarasi bencana jelas mengetahui terlebih dahulu kapan organisasi mengumumkan bencana, dan pemberitahuan berpindah dari sana ke personel tanggap bencana tambahan, manajemen, personel yang berkomunikasi dengan pemasok dan pelanggan, dan seterusnya.
Di mana anggota tim inti perencanaan DR akan berada saat bencana terjadi? Metode yang jelas tidak ilmiah di bagian ini didasarkan pada probabilitas sederhana.
Periode tujuh hari berisi lima hari kerja, yang totalnya 168 jam. Dengan asumsi bahwa anggota tim inti memiliki kehidupan, Tabel 9-1 menunjukkan rincian kemungkinan aktivitas karyawan, memberi Anda gambaran tentang di mana orang mungkin berada saat bencana terjadi.
Saat terjadi bencana, karyawan mungkin akan berada di rumah, baik untuk tidur, bekerja, atau bersantai. Tempat yang paling mungkin mereka kunjungi berikutnya adalah di tempat kerja itu sendiri, diikuti dengan perjalanan pulang pergi, berbelanja, beribadah, dan melakukan sesuatu yang lain sama sekali. Tabel 9-1 tidak memperhitungkan minggu liburan atau perjalanan bisnis. Jika seorang anggota tim inti menghabiskan banyak waktu rekreasi jauh dari rumah (berperahu, mendaki gunung, atau apa pun), anggota tim inti tersebut kemungkinan besar akan berada jauh dari rumah saat terjadi bencana.
Mengingat kemungkinan besar bencana akan terjadi ketika anggota tim inti tidak bekerja, Anda perlu membuat informasi yang dibutuhkan anggota tim inti portabel dan mudah digunakan. Anda memiliki banyak pilihan dalam hal menyimpan informasi kontak darurat, serta melakukan deklarasi bencana dan aktivitas komunikasi darurat lainnya. Tabel 9-2 menampilkan pilihan-pilihan ini.
Banyak organisasi menempatkan daftar kontak darurat pada kartu dompet berlapis. Kartu dompet sangat portabel karena dapat dimasukkan ke dalam dompet atau dompet. Dan staf lebih cenderung membawa dompet atau dompet mereka (dan karena itu kartu mereka) saat terjadi bencana, bahkan jika mereka sedang berlibur atau jauh dari rumah. Orang tidak memerlukan listrik atau teknologi lain untuk membaca kartu dompet.
Pertimbangkan untuk meletakkan barang-barang berikut di kartu dompet kontak darurat Anda:
- Nama anggota tim inti: Tapi, tentu saja!
- Nomor telepon seluler, rumah, dan kantor: Berbicara langsung melalui telepon adalah hal terbaik berikutnya untuk berada di sana.
- Nomor ponsel dan kantor pasangan: Bila Anda tidak dapat menemukan anggota tim inti, menelepon pasangannya dapat membantu menemukannya.
- Kontak email dan pesan instan: Dalam bencana, Anda tidak pernah tahu infrastruktur apa yang akan rusak dan apa yang masih akan berjalan.
- Nomor jembatan konferensi: Lebih dari satu, lebih disukai, dan dari layanan yang berbeda.
- Alamat bisnis utama: Untuk berjaga-jaga jika anggota tim inti perlu mengetahuinya.
- Petunjuk tentang prosedur deklarasi bencana: Lacak ingatan anggota tim inti.
- URL yang berisi lebih banyak prosedur bencana: Prosedur pemulihan bencana disimpan secara online. Semoga dihosting jauh, jauh dari bisnis Anda, seandainya kerusakan meluas.
Anda mungkin memerlukan lebih banyak informasi daripada yang muncul di daftar sebelumnya, atau Anda mungkin membutuhkan lebih sedikit, tergantung pada pemulihan bencana dan kebutuhan bisnis Anda.
Kepemimpinan darurat dan pemilihan peran
Ketika organisasi Anda mengumumkan bencana, siapa yang akan memimpin tim tanggap?
Sebenarnya, saya pikir pertanyaannya adalah, siapa yang tidak akan memimpin? Pada awal bencana, anggota tim inti masing-masing memiliki sejumlah tanggung jawab yang berbeda terkait dengan departemen masing-masing. Setiap anggota akan memiliki cukup untuk membuatnya sibuk ketika bencana terjadi. Tetapi selama bencana, beberapa keputusan harus dibuat, menit demi menit dan jam demi jam.
Kecenderungan alami pertama Anda mungkin untuk memilih, dari antara anggota tim inti, orang yang seharusnya menjadi pemimpin tim bahkan sebelum upaya pemulihan dimulai. Namun, tergantung pada sifat bencana dan kapan itu terjadi, Anda tidak tahu anggota tim inti mana yang akan aktif pada awal bencana. Anda dapat mengurutkan kemungkinan pemimpin dari antara anggota tim inti, atau Anda dapat membiarkan mereka mencari tahu di antara mereka sendiri. Dalam situasi bencana, salah satu anggota tim inti hanya akan melangkah keluar dan memimpin sisanya. Jika tim inti Anda berasal dari manajemen perusahaan, beberapa anggota tim inti Anda memiliki keterampilan dan bakat kepemimpinan. Salah satu dari mereka akan memimpin, dan yang lain akan mengikuti. Anda tidak perlu menjadi ilmiah tentang siapa yang akan memimpin. Bahkan, Anda mungkin bisa membiarkan anggota tim mencari tahu sendiri. Sifat bencana mungkin memerlukan respons 24 jam selama beberapa hari, atau bahkan berhari-hari atau berminggu-minggu. Setidaknya pada awal bencana, tim respon inti harus menugaskan salah satu anggotanya sebagai petugas tugas, yang melibatkan memimpin tim selama beberapa jam. Pemimpin dapat bertukar, memberi anggota kesempatan untuk beristirahat jika organisasi Anda membutuhkan liputan 24/7.
Ketika respons bencana berlangsung selama beberapa hari, tim respons harus membuat jadwal kepemimpinan dan manajemen yang lebih formal sehingga semua anggota tim tahu siapa yang bertanggung jawab pada jam berapa dan hari apa. Namun, seperti beberapa hal lain dalam tanggap bencana dan pemulihan (seperti pemilihan kepemimpinan), Anda mungkin tidak ingin terlalu kaku dalam rencana DR Anda. Biarkan kepemimpinan dan tim respons untuk membuat keputusan tersebut dengan cepat. Lagi pula, Anda perlu mempertimbangkan banyak kemungkinan skenario dengan berbagai kondisi kerusakan dan pemulihan, dan Anda akan memiliki pilihan personel yang tidak terduga yang tersedia untuk memimpin, mengelola, dan memulihkan bisnis.
Selain peran kepemimpinan dan manajemen, Anda juga membutuhkan juru tulis. Seseorang perlu menuliskan diskusi, tugas, temuan, dan keputusan. Jangan berharap untuk mengingat keputusan ini nanti karena mungkin semuanya akan kabur ketika tim tanggap bencana akhirnya bisa mundur setelah upaya pemulihan yang lama. Sebaliknya, catat keputusan ini dan hal-hal lain di tempat.
Pada awal bencana, juru tulis harus bekerja dengan cara kuno — pena dan kertas. Solusi berteknologi tinggi, seperti komputer notebook atau perekam suara, mungkin sangat tidak praktis, tergantung pada sifat bencana.
Prosedur penilaian kerusakan
Rencana pemulihan bencana perlu memasukkan prosedur untuk menilai kerusakan peralatan dan fasilitas. Tujuan dari penilaian kerusakan adalah untuk mengidentifikasi keadaan sistem TI dan fasilitas pendukung yang terlibat dalam bencana dan untuk memutuskan apakah sistem dan fasilitas pendukung rusak atau dinonaktifkan sejauh Anda memerlukan sistem TI di lokasi lain untuk terus mendukung fungsi bisnis yang kritis.
Penilaian kerusakan adalah seni dan ilmu. Di bagian ini, saya tidak memberi tahu Anda cara menentukan apakah sebuah bangunan aman untuk dihuni — itulah peran insinyur sipil dan struktural profesional. Demikian pula, saya tidak menyelidiki apakah bencana memerlukan evakuasi atau apakah personel dapat tetap tinggal untuk membantu penilaian dan kemungkinan pemulihan atau dimulai kembali. Hal-hal ini penting, tentu saja, tetapi mereka berada di luar cakupan buku ini.
Tidak ada proses bisnis yang layak mempertaruhkan nyawa seseorang. Keselamatan personel harus selalu menjadi prioritas utama dalam setiap rencana pemulihan bencana. Jika badai, tornado, atau air banjir yang naik datang — atau jika gempa bumi atau tanah longsor telah merusak bangunan — jangan tinggal di belakang atau memasuki bangunan dengan bahaya yang tidak diketahui demi bisnis.
Prosedur penilaian kerusakan berfokus pada penentuan apa yang terjadi pada sistem TI penting dan fasilitas terkait — seperti HVAC (Pemanasan, Ventilasi, dan Pendingin Udara), jaringan, utilitas, dan perimeter keamanan — dalam bencana. Anda juga perlu mencari tahu apakah Anda masih dapat mengakses atau memulai ulang sistem TI, atau apakah bisnis perlu menerapkan Rencana B — rencana pemulihan bencana.
Anda tidak perlu menggunakan prosedur penilaian kerusakan yang rumit, tetapi Anda mungkin menemukan prosedur yang Anda gunakan agak membosankan. Kebosanan mungkin terletak pada jumlah pemeriksaan sederhana yang perlu Anda lakukan untuk menilai kesehatan dan ketersediaan sistem secara keseluruhan. Berikut ini contoh untuk membantu menjelaskan apa yang saya maksud:
Acme Services (bukan perusahaan nyata) adalah organisasi yang menyediakan manajemen catatan online untuk pelanggan korporat di seluruh dunia. Bencana alam atau buatan manusia telah terjadi (bayangkan badai, kerusuhan sipil, tsunami, gempa bumi, banjir, atau bencana lainnya yang Anda kenal), dan sistem online Acme mengalami gangguan sementara.
Sebagaimana ditentukan dalam prosedur deklarasi bencana Acme, anggota tim inti yang dapat menghubungi satu sama lain menentukan bahwa besarnya bencana memerlukan deklarasi bencana resmi dan inisiasi rencana pemulihan bencana.
Setelah beberapa penundaan terkait dengan sifat bencana (bayangkan infrastruktur transportasi yang rusak), beberapa personel tanggap darurat tiba di gedung kantor Acme. Mereka ragu-ragu memasuki gedung (yang tampaknya tidak rusak) untuk menemukan bahwa gedung itu tidak memiliki listrik atau air yang mengalir. Sistem TI tampak tidak rusak. Baterai UPS telah habis (membutuhkan waktu lebih dari satu jam untuk mencapai fasilitas), dan generator cadangan tidak bekerja.
Karena Waktu Henti Maksimum yang Dapat Ditoleransi (MTD) untuk proses online kritis Acme diatur ke delapan jam, tim penilai kerusakan memutuskan bahwa mereka perlu menerapkan rencana DR dengan kekuatan penuh. Bahkan jika mereka segera menyalakan generator, kesehatan sistem TI masih dipertanyakan, dan pelanggan dari seluruh dunia ingin sekali mengakses sistem Acme sehingga mereka dapat menjalankan bisnis mereka.
Contoh sebelumnya sedikit sederhana, tetapi berisi panggilan penilaian penting: Tidak ada orang yang tersedia untuk memulai generator. Jika seseorang dapat menyalakan generator, tim masih membutuhkan waktu untuk menilai kesehatan dan kemampuan jangkauan sistem TI yang penting. Selanjutnya, generator biasanya hanya memiliki beberapa jam bahan bakar, tidak cukup untuk menjaga sistem kritis tetap berjalan sampai listrik dipulihkan, yang bisa memakan waktu beberapa hari dalam bencana yang meluas. Keputusan tim untuk menjalankan rencana pemulihan bencana itu masuk akal.
Prosedur penilaian pada dasarnya hanyalah daftar periksa. Anda perlu memeriksa daftar item yang berpotensi panjang ini dan mencentang kotak Running atau Not Running. Satu atau lebih tanda centang Tidak Berjalan mungkin berarti Anda perlu menggunakan sistem di lokasi alternatif, kecuali jika Anda dapat memperbaiki item Tidak Berjalan dengan cepat. Penilaian hanya itu: pemeriksaan tentang apa yang berjalan dan apa yang tidak. Setelah Anda menilai item, Anda harus memulai prosedur pemulihan dan memulai ulang, yang keduanya akan saya bahas di bagian berikut.
Personil yang melakukan prosedur penilaian kerusakan mungkin bukan ahli materi pelajaran. Dalam bencana, individu pilihan yang paling tahu tentang sistem sering tidak tersedia untuk penilaian atau pemulihan. Oleh karena itu, Anda perlu membuat prosedur penilaian kerusakan yang cukup rinci sehingga orang selain ahli materi utama dapat melakukan prosedur dengan benar.
Anda bisa mendapatkan template untuk hampir semua prosedur pemulihan bencana dari berbagai sumber. Bab 14 dan Bab 15 berisi sumber untuk ini dan alat serta kemampuan lainnya.
Pemulihan sistem dan prosedur restart
Setelah Anda mengembangkan deklarasi bencana dan prosedur penilaian, Anda perlu membuat instruksi untuk memulihkan dan memulai ulang sistem TI yang vital. Anda menggunakan prosedur ini untuk memulihkan dan memulai ulang sistem TI yang mendukung proses bisnis penting sesegera mungkin.
Anda mungkin perlu membuat prosedur pemulihan dan restart sistem Anda cukup rumit dan panjang. Mereka perlu memasukkan setiap detail kecil yang terlibat dalam menjalankan dan menjalankan sistem dari berbagai keadaan, termasuk bare metal (server tanpa sistem operasi atau perangkat lunak aplikasi yang diinstal pada mereka).
Daftar ini menggambarkan beberapa skenario bencana untuk situs dingin, situs hangat, dan situs panas:
Situs dingin: Dalam skenario mulai ulang situs dingin, Anda mungkin atau mungkin tidak memiliki komputer untuk memulai (situs dingin khas tidak memiliki komputer). Mereka bisa dikotak-kotakkan, atau mungkin Anda harus pergi dan membelinya. Prosedur cold-site yang khas mungkin menyerupai langkah-langkah berikut:
1. Memesan sistem dan perangkat jaringan dari pemasok atau produsen untuk mengganti sistem dan perangkat yang rusak akibat bencana.
2. Ambil media cadangan terbaru dari mana pun Anda menyimpannya.
3. Instal perangkat jaringan dan bangun jaringan server. Verifikasi konektivitas ke pelanggan, pemasok, dan mitra.
4. Instal sistem operasi dan aplikasi di server baru.
5. Pulihkan data dari media cadangan.
6. Jalankan aplikasi dan lakukan tes fungsionalitas.
7. Mengumumkan ketersediaan aplikasi yang dipulihkan kepada karyawan, pelanggan, dan mitra, sesuai kebutuhan.
Prosedur sebelumnya mungkin berlangsung selama beberapa hari hingga dua minggu.
Situs hangat : Dengan peralatan dan server yang sudah ada, pemulihan situs hangat membutuhkan waktu lebih sedikit dan umumnya sedikit lebih rumit daripada pemulihan situs dingin. Berikut adalah prosedur situs hangat yang khas:
1. Ambil media cadangan terbaru dari mana pun Anda menyimpannya
2. Konfigurasi perangkat jaringan. Verifikasi konektivitas ke pelanggan, pemasok, dan mitra.
3. Instal atau perbarui sistem operasi dan aplikasi di server baru.
4. Pulihkan data dari media cadangan.
5. Jalankan aplikasi dan lakukan tes fungsionalitas.
6. Mengumumkan ketersediaan aplikasi yang dipulihkan kepada karyawan, pelanggan, dan mitra, sesuai kebutuhan.
Prosedur situs hangat sebelumnya mirip dengan prosedur situs dingin, tetapi Anda memiliki permulaan dengan situs hangat di atas situs dingin karena Anda sudah memiliki komputer yang tersedia.
Situs populer : Siap untuk mengambil tugas produksi dengan server yang sudah disiapkan dalam hitungan jam atau bahkan menit. Berikut adalah prosedur situs panas yang khas:
1. Konfirmasi status aktivitas pencerminan atau replikasi terbaru.
2. Lakukan perubahan konfigurasi jaringan yang diperlukan.
3. Alihkan status node cluster server dan server database ke aktif.
4. Lakukan pengujian fungsionalitas aplikasi.
5. Mengumumkan ketersediaan aplikasi yang dipulihkan kepada karyawan, pelanggan, dan mitra, sesuai kebutuhan.
Sistem di lokasi yang panas hampir siap untuk mengambil alih tugas operasional dengan pemberitahuan singkat. Prosedur yang tepat untuk pindah ke server situs panas bergantung pada teknologi yang Anda gunakan untuk mewujudkan kesiapan — apakah replikasi transaksi, pencerminan, pengelompokan, atau kombinasi dari semuanya.
Saya sengaja menghilangkan banyak detail dari prosedur dalam daftar sebelumnya. Anda perlu mempertimbangkan banyak faktor tambahan saat mengembangkan prosedur pemulihan sistem:
Komunikasi : Selama operasi pemulihan, tim pemulihan harus terus berkomunikasi dengan tim inti DR, serta pelanggan, pemasok, mitra, dan entitas lainnya.
Area kerja : Menetapkan area di mana pekerja TI yang kritis dapat bekerja selama dan setelah operasi pemulihan. Sistem TI dalam keadaan pulih mungkin agak lebih tidak stabil daripada di lingkungan produksi aslinya, dan mereka mungkin memerlukan lebih banyak pengamatan, penyesuaian, dan penyetelan.
Keahlian : Buat prosedur pemulihan cukup umum sehingga orang yang terbiasa dengan tugas administrasi sistem, tetapi belum tentu sistem Anda, dapat memulihkan sistem Anda tanpa harus membuat tebakan atau asumsi. Langkah demi langkah berarti langkah demi langkah!
Orang-orang yang menulis prosedur pemulihan sistem harus berasumsi bahwa siapa pun yang membaca dan mengikuti prosedur tersebut dalam bencana yang sebenarnya tidak terbiasa dengan lingkungan sistem khusus Anda.
Template yang bisa Anda dapatkan dari beberapa sumber memiliki garis besar untuk prosedur pemulihan sistem. Saya membahas template ini di Bab 14 dan Bab 15.
Transisi ke operasi normal
Setelah bencana terjadi dan Anda memulihkan sistem TI penting di pusat pemrosesan alternatif, aktivitas pemulihan telah memulihkan fasilitas pemrosesan dan kerja asli. Saat memulihkan pusat pemrosesan asli, Anda perlu membangun kembali sistem TI di sana dan mematikan situs alternatif.
Waktu pemindahan kembali ke pusat pemrosesan awal (atau fasilitas pengganti permanen jika fasilitas awal benar-benar hancur) bergantung pada banyak faktor, termasuk.
Stabilitas aplikasi : Jika aplikasi yang berjalan di situs pemulihan sedikit tidak stabil, konsultasikan dengan personel yang memelihara aplikasi untuk menentukan waktu terbaik untuk beralih kembali ke situs pemrosesan utama.
Beban kerja bisnis : Transisi kembali ke situs pemrosesan utama pada saat beban kerja rendah sehingga setiap pengguna atau sistem terkait akan lebih mentolerir pengalihan yang sebenarnya.
Staf yang tersedia : Memiliki staf yang cukup baik di lokasi pemulihan dan lokasi pemrosesan utama untuk mengalihkan pemrosesan kembali ke lokasi utama.
Biaya : Biaya tambahan yang terkait dengan pengoperasian lokasi pemulihan dapat memberikan tekanan untuk transisi kembali ke lokasi pemrosesan utama sesegera mungkin.
Kesiapan fungsional : Mengoperasikan dan mendukung aplikasi TI penting di lokasi pemrosesan utama harus memenuhi beberapa kriteria minimum agar aplikasi dapat berfungsi dengan baik setelah Anda mentransisikannya kembali ke situs utama. Dengan kata lain, apakah Anda siap untuk kembali ke operasi normal?
Tuliskan prosedur untuk mentransisikan sistem kembali ke situs pemrosesan utama. Prosedur ini tidak sama dengan prosedur pemulihan. Keadaan dan konfigurasi sistem di situs pemrosesan alternatif mungkin tidak akan persis seperti yang Anda rencanakan. Untuk alasan apa pun, Anda mungkin harus membuat beberapa perubahan selama prosedur pemulihan yang mengakibatkan sistem pemulihan tidak dikonfigurasi atau dirancang persis seperti yang Anda inginkan. Dengan kata lain, titik awal untuk transisi kembali ke lokasi pemrosesan utama mungkin tidak persis seperti yang diantisipasi oleh para perencana DR. Jadi, prosedur untuk kembali ke situs utama juga tidak sesuai. Gambar 9-1 mengilustrasikan fakta bahwa transisi kembali ke situs utama tidak selalu berarti transisi kembali ke keadaan utama.
Anda perlu menulis prosedur yang menjelaskan cara transisi dari sistem DR sementara kembali ke sistem di lokasi pemrosesan utama. Bagaimana Anda bisa menulis prosedur untuk mencapai keadaan akhir yang diinginkan ketika Anda tidak tahu persis seperti apa keadaan awal (sistem pemulihan)?
Pengujian dapat membantu dengan teka-teki ini. Pengujian penuh, termasuk pengujian failover, memaksa anggota tim pemulihan untuk benar-benar membangun sistem dan infrastruktur pemulihan aplikasi, lalu mentransisikannya kembali. Selama pengujian tersebut, Anda harus mengungkap sebagian besar variabel yang mungkin terjadi dalam bencana yang sebenarnya, sehingga prosedur transisi ke normal harus sangat mirip dengan kenyataan. Saya menjelaskan berbagai jenis tes di Bab 10.
Terakhir, Anda dapat memasukkan masalah yang Anda temukan selama pengujian ke dalam catatan rilis (deskripsi terperinci tentang sistem dan prosedur) yang dapat dibaca oleh personel pemulihan untuk lebih memahami masalah apa pun yang mungkin mereka hadapi selama operasi pemulihan dan transisi ke normal.
Tim pemulihan
Ketika bencana melanda, siapa yang dapat diandalkan oleh tim inti untuk melakukan semua tugas yang terkait dengan komunikasi, penilaian, pemulihan sistem, dan operasi transisi ke normal? Siapa pun yang dapat mereka temukan. Ingat, Anda dapat memilih tim pemulihan terlebih dahulu, tetapi bencana dapat membuat beberapa anggota tim tersebut tidak tersedia karena berbagai alasan.
Serius, tergantung pada jenis bencana, banyak staf operasional normal banyak yang tidak tersedia karena berbagai alasan, termasuk
Keluarga dan rumah adalah yang utama : Ketika bencana regional terjadi, pekerja dengan keluarga dan rumah memenuhi kebutuhan tersebut sebelum memikirkan pekerjaan. Ketika pekerja memiliki hal-hal yang terkendali di depan rumah, maka mereka dapat mengalihkan perhatian mereka ke tempat kerja dan tanggung jawab pekerjaan mereka.
Masalah transportasi : Bencana daerah dapat mengganggu sistem transportasi, sehingga menyulitkan pekerja untuk melakukan perjalanan ke lokasi kerja.
Komunikasi terganggu : Pekerja sering dapat melakukan banyak tugas pemulihan melalui kabel, melalui koneksi VPN (Virtual Private Network, untuk akses jarak jauh) dari tempat tinggal mereka ke jaringan bisnis. Tetapi bencana yang meluas dapat mengganggu komunikasi, membuat pekerjaan seperti itu sulit atau tidak mungkin dilakukan.
Evakuasi : Seringkali, otoritas sipil memerintahkan evakuasi massal yang mencegah pekerja untuk dapat melakukan perjalanan ke lokasi kerja. Terkadang, evakuasi bekerja secara terbalik, mencegah pekerja meninggalkan pekerjaan untuk melakukan perjalanan pulang, yang menimbulkan serangkaian tantangan lain.
Cedera, sakit, dan kematian : Bencana regional sering kali, menurut sifatnya, kekerasan, yang dapat menyebabkan cedera, penyakit, dan kematian.
Anda tidak dapat memilih sendiri anggota tim pemulihan Anda. Bencana memilih mereka untuk Anda. Untuk alasan ini, Anda perlu membuat prosedur pemulihan yang cukup spesifik sehingga siapa pun dengan keterampilan dasar yang relevan dapat melakukannya dengan percaya diri dan benar.
Menyusun Rencana
Bagian sebelumnya dalam bab ini membahas isi rencana pemulihan bencana dalam arti yang sangat pragmatis — bagian dan kata-kata yang Anda masukkan ke dalam dokumen rencana DR. Di semua organisasi kecuali organisasi terkecil, beberapa orang menulis bagian dari rencana, dan lebih banyak lagi orang yang terlibat dalam tinjauan dokumen. Di bagian berikut, saya menjelaskan beberapa pendekatan dan metode yang dapat Anda gunakan untuk menyusun rencana pemulihan bencana.
Anda tidak perlu menulis rencana dari awal. Anda bisa mendapatkan template dari beberapa sumber yang tercantum di Bab 14 dan Bab 15.
Struktur tingkat perusahaan
Bagian ini membahas beberapa cara organisasi dapat memotong dan memotong rencana DR-nya. Anda dapat mengadopsi salah satu dari pendekatan ini atau menyesuaikannya agar sesuai dengan kebutuhan bisnis Anda.
Organisasi multi-unit yang melakukan rencana DR besar harus mencari cara untuk menulis rencana ini untuk proses dan aplikasi penting yang menjangkau departemen atau unit bisnis. Haruskah rencana DR selaras dengan aplikasi, atau haruskah selaras dengan unit bisnis? Sulit untuk mengatakannya; tim pengembangan DR Anda perlu mempertimbangkan pilihan dan memutuskan. Gambar 9-2 menunjukkan aplikasi versus sudut pandang unit bisnis.
Berikut adalah beberapa pertimbangan yang dapat membantu Anda memahami cara mendekati masalah gambaran besar ini:
Geografi : Bencana, sebagian besar, menyerang wilayah geografis, terlepas dari struktur organisasi atau politik organisasi yang berlokasi di wilayah tersebut. Menulis rencana DR yang menangani bisnis di daerah yang terkena bencana mungkin paling masuk akal bagi organisasi Anda. Di perusahaan besar, rencana DR perlu merujuk unit dan fungsi bisnis yang terletak di lokasi lain, terutama ketika unit dan fungsi tersebut berada di jalur kritis untuk proses bisnis yang terkena bencana.
Struktur organisasi : Segmen yang berbeda dari organisasi besar dapat mendorong perencanaan DR pada tingkat yang berbeda. Kurangnya kemajuan satu segmen seharusnya tidak menghalangi segmen lain. Pikirkan situasi seperti ini sebagai rencana DR untuk setiap roda penggerak dalam roda organisasi. Jika Anda melakukan hal-hal di unit bisnis organisasi Anda dengan unit bisnis, Anda mungkin ingin membuat rencana DR berkeping-keping, secara asinkron.
Fungsi bisnis : Inti dari perencanaan pemulihan bencana adalah untuk memulihkan dan memulihkan fungsi bisnis penting secepat mungkin, terlepas dari susunan geografis atau politik organisasi. Dengan mengingat tujuan ini, rencana DR harus menangani seluruh proses bisnis, terlepas dari di mana fungsi tertentu berada.
Daftar pertimbangan sebelumnya agak idealis. Meskipun idealisme tidak banyak mempengaruhi bisnis dunia nyata, pertimbangkan sudut pandang ini ketika Anda mencoba mencari tahu bagaimana organisasi Anda perlu menyusun perencanaan DR-nya.
Struktur tingkat dokumen
Seperti proyek formal lainnya di mana informasi bisnis penting muncul dalam dokumen, pertimbangkan untuk menyiapkan beberapa struktur dalam dokumen pemulihan bencana individu. Ya, saya sedang berbicara tentang templat dokumen. Template Anda mungkin termasuk yang berikut ini:
Penamaan dokumen dan file standar : Buat nama dokumen yang berbeda (apa yang muncul di halaman judul), serta nama file dokumen tersebut (nama dokumen di komputer), konsisten.
Header dan footer standar : Cantumkan nama dokumen di bagian atas setiap halaman (header) dan informasi seperti Rahasia Perusahaan, nomor halaman, tanggal, dan nomor versi di bagian bawah setiap halaman (footer).
Halaman judul : Buat halaman judul formal yang mencakup semua metadata dokumen, termasuk judul (tetapi, tentu saja!), versi, tanggal, dan sebagainya.
Daftar isi : Daftar isi membantu pembaca dengan cepat menemukan bagian dalam dokumen. Dokumen yang lebih besar mungkin juga memerlukan indeks, daftar gambar, dan daftar tabel.
Hak cipta dan legalese lainnya : Membantu melindungi kekayaan intelektual organisasi.
Riwayat modifikasi : Membantu Anda melacak perubahan yang dibuat dari satu versi ke versi berikutnya, serta siapa yang membuat perubahan itu dan kapan.
Versi dokumen: Panggil saya pilih-pilih, tetapi ini membantu.
Judul dan paragraf standar : Tampilan yang konsisten membuat dokumen DR lebih mudah dibaca dan digunakan. Anda bahkan mungkin mempertimbangkan untuk melakukan penomoran bagian bersarang (seperti Bagian 1, 1.1, 1.1.1, dan seterusnya) jika Anda memiliki rencana DR yang sangat besar.
Bergantung pada kematangan manajemen dokumen di organisasi Anda, struktur template dalam daftar sebelumnya mungkin terlalu berat, terlalu ringan, atau tepat — sama seperti dalam kisah abadi, “The Three Bears.”
Mengelola Pengembangan Rencana
Kecuali jika Anda hanya memiliki satu orang yang menulis rencana DR organisasi Anda, Anda perlu menetapkan beberapa proses dan prosedur untuk upaya ini sehingga bagian-bagian dari rencana tersebut dapat disatukan dengan lancar tanpa menjadi kusut. Anda memerlukan manajemen dokumen formal, termasuk jenis aktivitas dan kemampuan ini:
Templat dokumen formal : Saya membahas templat secara rinci di bagian sebelumnya.
Kontrol versi : Melacak versi dokumen secara manual, mungkin dengan memasukkan nomor versi setiap dokumen dalam nama dokumen itu. Anda juga dapat menggunakan produk manajemen dokumen formal yang menjalankan fungsi seperti check-out dokumen, check-in, dan manajemen versi. Anda dapat menemukan beberapa produk manajemen dokumen yang baik yang tersedia saat ini, dan mungkin organisasi Anda sudah memilikinya.
Tinjauan dokumen: Menetapkan prosedur tinjauan dokumen formal di mana penulis dokumen mengedarkan setiap dokumen ke peninjau tertentu yang dapat mengedit dan memberi komentar. Beberapa produk manajemen dokumen mengelola tinjauan dokumen.
Buku ini hanya mencakup dasar-dasar manajemen dokumen tingkat tinggi sehingga Anda dapat mengatur pengembangan dokumen rencana DR dengan lebih baik jika Anda memiliki beberapa orang yang menulis dokumen tersebut dan lebih banyak orang yang meninjaunya.
Mempertahankan Rencana
Ketika Anda telah sepenuhnya menulis, meninjau, mengoreksi, merevisi, dan memeriksa rencana tersebut, Anda perlu melindungi rencana itu dari bahaya dan kerugian. Dengan kata lain, Anda perlu membuat rencana DR itu sendiri tahan bencana! Apa gunanya rencana DR yang baik jika terjebak di dalam sistem yang tidak dapat dioperasikan yang rusak atau hancur dalam bencana?
Anda perlu menjaga rencana DR Anda, bersama dengan banyak informasi pendukung, terhadap kerugian, untuk berjaga-jaga jika terjadi bencana yang signifikan. Pikirkan skenario terburuk, apa pun yang mungkin terjadi di bagian dunia Anda. Berikut adalah beberapa metode yang dapat Anda gunakan untuk mempertahankan rencana DR Anda, untuk berjaga-jaga jika hal yang tidak terduga terjadi:
Pengikat tiga cincin : Seringkali, cara berteknologi rendah adalah yang terbaik. Binder tidak memerlukan kabel daya atau catu daya. Membuat binder untuk setiap anggota tim inti, serta personel kunci lainnya. Buat satu set untuk bekerja dan satu set lagi untuk rumah. Satu kelemahannya adalah kesulitan dalam menjaga semuanya tetap terkini. Saya tidak mengatakan perencanaan DR itu mudah!
Kunci CD-ROM atau USB : Perangkat ini ringkas dan ringan, dan memiliki banyak kapasitas. Pada sisi negatifnya, Anda memerlukan komputer yang berfungsi untuk mengaksesnya.
Server yang dapat diakses melalui Internet : Server ini adalah ide yang bagus, selama Anda menempatkan setidaknya beberapa dari mereka jauh dari pusat bisnis utama sehingga bencana regional tidak akan mempengaruhi mereka. Kelemahan yang mungkin adalah Anda memerlukan konektivitas Internet untuk mengakses server ini.
Penyimpanan di luar situs : Kemungkinan besar, sebagian besar organisasi menggunakan penyimpanan media di luar situs untuk penyimpanan media cadangan. Seringkali, perusahaan penyimpanan di luar lokasi ini juga menyimpan catatan kertas selain catatan elektronik, jadi mengapa tidak meminta mereka menyimpan paket DR Anda?
Mengambil Langkah Selanjutnya
Setelah Anda menulis rencana DR Anda, apakah Anda sudah selesai? Hampir tidak. Anda memiliki banyak tugas masih di depan.
Anda perlu menguji rencana DR Anda untuk memastikan bahwa mereka benar-benar akan bekerja dalam bencana nyata. Pengujian DR-plan tercakup dalam Bab 10.
Setelah Anda menyelesaikan dan memberkati rencana DR Anda, apakah perangkat lunak dan arsitektur data yang mendasari, proses bisnis, dan sistem TI pendukung akan berhenti berubah? Tidak mungkin! Rencana pemulihan bencana perlu terus diperbarui, yang saya bahas di Bab 11.
0 Komentar