Pengembangan rencana pemulihan bencana atau praktik terbaik atau sumber daya? [Tutup]

Saya telah ditugaskan untuk memimpin sebuah proyek untuk memperbarui rencana pemulihan bencana yang lama dan agak berat sebelah. Untuk saat ini kami hanya ingin menyelesaikan sisi IT dari DR. Terakhir kali mereka melakukan ini, mereka menetapkan ruang lingkup mereka dengan membuat satu bencana (pusat data banjir) dan merencanakannya dengan mengesampingkan semua jenis bencana lainnya. Saya ingin mengambil pendekatan yang lebih menyeluruh. Saya tahu ini adalah masalah yang diselesaikan, organisasi lain telah menulis rencana DR.

Rencana kami adalah untuk mengambil rencana DR IT kami dan maju dengan itu dan berkata "Hei, ini yang kami inginkan dalam rencana DR untuk IT, apakah itu sesuai dengan apa yang dilakukan oleh universitas lainnya? Apakah ada layanan yang dipulihkan yang memprioritaskan Anda? Mau diubah? " Kami memiliki ide yang cukup bagus tentang sisa rencana dan kami berharap ini akan berjalan dengan baik.

Apa yang saya cari adalah panduan tentang bagaimana ruang lingkup rencana DR dan pertanyaan apa yang harus saya pikirkan. Apakah Anda memiliki sumber daya, buku, pelatihan yang terkait dengan pengembangan rencana DR?

Sumber informasi yang sangat baik adalah Disaster Recovery Journal ( sekitar ).

Sumber daya masyarakat yang tersedia mencakup rancangan dokumen Praktik yang Diterima Secara Umum (GAP) saat ini , yang memberikan garis besar proses dan hasil yang sangat baik yang merupakan rencana dan proses kesinambungan bisnis yang solid. Juga tersedia beberapa kertas putih yang membahas berbagai topik DR / BC.

Prosesnya tampaknya menakutkan, tetapi jika didekati secara sistematis dengan garis besar di mana Anda ingin berakhir (seperti dokumen DRJ GAP), Anda dapat memastikan bahwa Anda mengoptimalkan waktu yang diinvestasikan dan memaksimalkan nilai produk akhir.

Saya menemukan publikasi triwulanan mereka juga menarik dan informatif ( berlangganan ).

Pastikan Anda memiliki daftar kontak darurat. alias Roster Recall

Seharusnya terlihat seperti pohon, dan tunjukkan siapa yang menghubungi siapa. Di akhir cabang, orang terakhir harus menelepon yang pertama dan melaporkan siapa pun yang tidak bisa dihubungi.

(Ini dapat dikoordinasikan melalui SDM, dan digunakan untuk semua jenis bencana)

Jika kami menambahkan ide kami, kami dapat membuat wiki yang bagus dari posting ini setelah semua orang menambahkan ide mereka sendiri. Saya mengerti ada banyak yang harus diikuti, tetapi beberapa dari kita memiliki prioritas khusus dalam hal pemulihan. Untuk memulai, ini milik saya:

Pastikan Anda memiliki dokumentasi off-line / jauh dari jaringan Anda

Dengan DR, hal-hal dasar adalah RTO Anda (Tujuan Waktu Pemulihan) dan RPO (Tujuan Titik Pemulihan), yang secara kasar diterjemahkan sebagai "berapa banyak waktu yang dapat diterima untuk menghabiskan waktu untuk mendapatkannya kembali, dan berapa banyak data yang dapat kami keluarkan untuk kehilangan". Dalam dunia yang ideal jawabannya adalah "tidak ada dan tidak ada", tetapi skenario DR adalah keadaan luar biasa. Ini benar-benar harus didorong oleh pelanggan Anda, tetapi karena Anda mulai dari sudut TI Anda dapat membuat tebakan terbaik, tetapi bersiaplah untuk menyesuaikan naik atau turun sesuai kebutuhan. Bertujuan untuk sedekat mungkin dengan "tidak ada dan tidak ada" yang bisa Anda peroleh adalah baik, tetapi Anda harus dapat mengenali kapan titik pengembalian yang semakin rendah masuk.

Kedua faktor ini mungkin berbeda pada waktu yang berbeda dalam setahun, dan berbeda pada sistem yang berbeda.

Saya suka pendekatan yang lebih menyeluruh; tergoda untuk mendaftar peristiwa yang dapat menyebabkan skenario DR, tetapi ini benar-benar lebih merupakan bagian dari ananlysis risiko / latihan mitigasi. Dengan DR insiden telah terjadi, dan spesifik tentang apa itu kurang relevan (kecuali mungkin dalam hal mempengaruhi ketersediaan fasilitas DR). Jika Anda kehilangan server, Anda harus mendapatkannya kembali, terlepas dari apakah itu terkena petir, tidak sengaja diformat, atau apa pun. Suatu pendekatan yang difokuskan pada skala dan penyebaran bencana lebih cenderung memberikan hasil.

Salah satu pendekatan untuk digunakan pada pelanggan, jika Anda merasa mereka enggan terlibat, adalah dengan mengajukan pertanyaan DR dari sudut pandang non-IT. Bertanya apa rencana mereka jika semua file kertas mereka terbakar adalah contoh di sini. Ini dapat membantu mereka lebih terlibat dalam hal DR yang lebih luas, dan dapat memasukkan info bermanfaat ke dalam rencana Anda sendiri.

Akhirnya menguji rencana Anda secara teratur sangat penting untuk kesuksesan. Tidak ada gunanya memiliki rencana DR indah yang tampak hebat di atas kertas tetapi itu tidak memenuhi tujuan itu.

Sebenarnya, model pengembangan "satu insiden" adalah ide yang baik, sebagai langkah pertama. Salah satu alasannya adalah membuat latihan perencanaan lebih realistis dan fokus. Rencanakan banjir, semuanya. Kemudian anggaplah kejadian yang berbeda (katakanlah, pemadaman listrik jangka panjang), terapkan rencana itu, dan perbaiki yang rusak. Setelah beberapa iterasi, rencananya harus relatif kuat.

Beberapa pemikiran ... - pastikan untuk memperhitungkan orang yang tidak tersedia. Jika ada banjir, Anda tidak dapat mengasumsikan bahwa semua staf yang relevan tersedia. Seseorang mungkin sedang berlibur, atau terluka, atau berurusan dengan keluarga mereka.
- merencanakan masalah dan kelemahan komunikasi. Memiliki banyak angka dan beberapa mode.
- rencana DR membutuhkan rantai komando. Mengetahui siapa yang membuat keputusan sangat penting.
- rencana perlu didistribusikan secara luas, termasuk di luar dan di luar jaringan. Itu harus dapat diakses selama bencana!

Di tempat saya bekerja, saya telah terlibat dalam menjalankan tes DR skala besar di masing-masing dua tahun terakhir. Kami telah menemukan bahwa menguji layanan, orang, dan proses kami dalam situasi "realistis" telah berguna. Beberapa pelajaran yang dipetik (mungkin jelas), dengan harapan Anda menemukan mereka berguna:

• Layanan yang belum diuji, terlepas dari apa yang telah mereka tulis dalam dokumentasi DR mereka, biasanya memiliki dependensi implisit, yang memicu bencana. Mengocoknya dengan satu atau dua tes realistis adalah hasil yang berguna dan terukur dari proses persiapan DR.
• Orang yang belum diuji cenderung berpikir bahwa sistem mereka baik-baik saja dan mereka akan "tahu apa yang harus dilakukan" dalam situasi bencana. Gemetar mereka up dengan tes realistis atau dua besar.
• Proses yang tidak teruji berantakan dengan cepat dalam situasi darurat aktual. Secara khusus, proses eskalasi kompleks difokuskan terutama pada menginformasikan jeda manajemen puncak dengan cara yang spektakuler. Proses ringan yang berfokus pada kebutuhan staf operasi dan responden lainnya, sumber utama informasi tentang keadaan darurat yang sedang berlangsung, pengalihan tanggung jawab secara eksplisit, dan prosedur respons darurat 'sehari-hari' paling berhasil.

Saya kira apa yang saya maksudkan adalah bahwa Anda harus mencoba untuk tidak membuat segalanya tentang proses perencanaan DR Anda secara teoritis. Dorong izin untuk benar-benar memecahkan masalah dan dengan demikian mendapatkan data keras tentang kesiapan organisasi Anda. Tentu saja itu akan memerlukan dukungan serius dari manajemen, tetapi dapat memfokuskan usaha secara luar biasa untuk menghabiskan beberapa hari untuk berlatih untuk yang terburuk.

Cian

Ada beberapa standar dari British Standards Institute (BSi) yang berfokus pada manajemen kesinambungan dan pemulihan bencana.

• BS 25999-1: 2006 Manajemen kelangsungan bisnis, Bagian 1: Kode praktik
• BS 25999-2: 2007 Manajemen kelangsungan bisnis. Spesifikasi
• BS 25777: 2008 Manajemen kontinuitas teknologi informasi dan komunikasi. Kode praktik

Ini mungkin tampak jelas, tetapi untuk mengikuti dokumentasi luar kantor di atas, pastikan Anda memiliki cadangan di luar lokasi (sebaiknya di luar wilayah). Ini bisa berupa layanan penyimpanan online atau tempat untuk mengambil kaset.

Saya katakan lebih baik keluar dari daerah karena saya berasal dari daerah di mana kita tidak memiliki banyak bencana alam setiap tahun, tetapi, jika / ketika kita memiliki satu, itu pada skala regional dengan kehancuran massal (gempa bumi, gunung berapi). Semua baik untuk memiliki cadangan Anda di brankas di bank, sampai bank Anda berada di bawah magma panas cair (/ Dr. Evil Voice).

Sesuatu yang telah saya baca adalah agensi yang berbagi biaya mempertahankan situs panas ketika situs besar terkena. Mereka memberlakukan rencana untuk memulihkan misi kedua perusahaan yang kritis ke situs panas menggunakan virtualisasi dan semacamnya, dan kemudian berbagi kepegawaian pada tingkat pastikan-semua-lampu-berkedip-kedip. Hanya pemikiran saja.

Untuk buku ada Perencanaan Pemulihan Bencana oleh Jon William Toigo, sekarang dalam edisi ke-3, dengan blook edisi ke - 4 (blog + buku) di cakrawala.

Laura,

Berikut ini tautan dari SQLServerPedia yang memberikan dasar-dasar DR.

http://sqlserverpedia.com/blog/sql-server-backup-and-restore/disaster-recovery-basics-tutorial/

Baca juga tentang "Kelangsungan Bisnis"