20 Hal yang Harus Direncanakan untuk Pemulihan Bencana TI

Menerapkan solusi pemulihan bencana bergantung pada tiga faktor — 1) waktu 2) sumber daya 3) jumlah dolar.

Sebagian besar organisasi bahkan tidak memikirkan DR ketika infrastruktur dan aplikasi TI berjalan tanpa masalah. Kebanyakan dari mereka berpikir tentang DR hanya ketika ada sesuatu yang rusak yang menciptakan dampak negatif yang besar pada bisnis.

Jika Anda seorang sysadmin, atau seseorang yang bertanggung jawab untuk menjaga agar TI tetap berjalan, Anda harus terus bekerja pada pemulihan bencana. Apakah perusahaan Anda mengalokasikan waktu dan anggaran atau tidak, Anda masih dapat mengerjakan beberapa aspek DR.

Berikut ini adalah daftar berbagai item yang mungkin ingin Anda pertimbangkan saat merencanakan DR. Daftar ini tidak lengkap dengan cara apa pun, tetapi seharusnya memberi Anda cukup ide untuk memulai DR.

Pusat data primer yang tangguh. Sebelum Anda merencanakan pusat data jarak jauh sekunder, Anda harus memastikan semua komponen di pusat data primer Anda sangat berlebihan. Fokus Anda harus merancang pusat data utama Anda sekuat mungkin sehingga Anda dapat pulih dengan cepat dari sebagian besar bencana (kecuali bencana alam) tanpa harus menggunakan pusat data jarak jauh sekunder. Misalnya, untuk basis data produksi Anda, memiliki basis data siaga fisik yang berjalan di pusat data yang sama, mengonfigurasi kartu NIC ganda dan kartu HBA di semua server prod, mengonfigurasi beberapa server web dengan penyeimbang beban, menghubungkan server ke dua sirkuit daya menggunakan redundan catu daya di server, dll.
Pusat data sekunder jarak jauh. Jika Anda menerapkan pusat data primer yang tangguh, tujuan Anda untuk menggunakan pusat data jarak jauh yang berlebihan terutama untuk bencana alam seperti gempa bumi, kebakaran, banjir, dll. Meskipun ini mungkin sangat jelas, perlu disebutkan, karena saya telah melihat beberapa perusahaan melakukan ini, mereka memiliki pusat data primer dan sekunder di kota yang sama, yang mengalahkan tujuan DR. Jika pusat data utama Anda berada di california, siapkan pusat data sekunder di suatu tempat di pantai timur.
Replikasi komponen produksi di pusat data DR. Anda tidak perlu mereplikasi semua perangkat keras dan aplikasi dari pusat data primer hingga sekunder. Seorang sysadmin, atau orang teknis mana pun dapat dengan cepat mengidentifikasi semua perangkat keras dan perangkat lunak penting yang perlu direplikasi di situs DR, tetapi Anda mungkin memerlukan bantuan dari departemen lain untuk mengidentifikasi aplikasi yang penting bagi bisnis. Anda harus memetakan fungsi bisnis penting ke komponen infrastruktur TI, dan memastikan semua komponen infrastruktur tersebut bersama dengan aplikasi dan data direplikasi ke situs DR.
Paket penyimpanan. Jika Anda memiliki semacam penyimpanan SAN (atau penyimpanan NAS) yang mendukung aplikasi penting di DR utama, Anda juga harus memiliki penyimpanan SAN (atau penyimpanan NAS) serupa di situs DR Anda. Untuk alasan kinerja, server prod di situs DR harus memiliki spesifikasi yang sama dengan server prod di situs utama. Namun, untuk penyimpanan, jika Anda memiliki penyimpanan SAN kelas atas dari vendor besar di situs utama, pertimbangkan untuk menerapkan penyimpanan SAN kelas atas yang serupa dari vendor kecil, yang mungkin menghabiskan lebih sedikit uang untuk konfigurasi dan kinerja yang sama. .
Mereplikasi data ke situs DR secara berkelanjutan. Menyinkronkan data antara pusat data primer dan bencana merupakan aspek penting dari keberhasilan implementasi DR. Setelah Anda mencantumkan semua aplikasi yang perlu direplikasi ke situs DR, Anda perlu mencari cara untuk menyinkronkan data antara kedua situs ini untuk semua aplikasi ini. Misalnya, Anda dapat mereplikasi database Oracle pada tingkat blok menggunakan teknologi replikasi yang disediakan oleh vendor penyimpanan, atau Anda dapat menggunakan datagurad untuk mereplikasi data pada tingkat oracle. Keduanya memiliki pro dan kontra sendiri. Anda harus menganalisisnya dengan cermat dan memilih yang sesuai dengan anggaran dan cakupan DR Anda.
Menggandakan data awal menggunakan cara manual. Saat Anda menyiapkan situs DR untuk pertama kalinya, Anda harus memutuskan bagaimana Anda akan melakukan sinkronisasi data awal. Misalnya, jika Anda mereplikasi database gudang data yang berukuran sangat besar, Anda tidak dapat menyalin cadangan awal database melalui jaringan ke situs jarak jauh, karena mungkin memakan bandwidth. Sebagai gantinya, Anda dapat mengambil cadangan kaset di pusat data primer dan menggunakannya di pusat data sekunder untuk menyiapkan basis data awal. Setelah penyiapan awal selesai, Anda dapat menerapkan beberapa bentuk sinkronisasi inkremental otomatis antar situs.
RTO adalah singkatan dari Recovery Time Objective. Bekerja dengan tim manajemen, Anda mengidentifikasi RTO yang dapat diterima untuk bisnis. Misalnya, organisasi Anda mungkin memutuskan bahwa RTO yang dapat diterima adalah 8 jam. yaitu Setelah bencana, dalam waktu maksimal 8 jam semua aplikasi kritis harus beroperasi penuh di lokasi DR. RTO memiliki dampak langsung pada berapa banyak jumlah dolar yang dihabiskan dalam mengimplementasikan solusi DR. Misalnya, RTO 1 jam mungkin memerlukan solusi DR yang sangat canggih yang terlalu mahal daripada yang dibutuhkan oleh RTO 24 jam.
RPO adalah singkatan dari Recovery Point Objective. Sama seperti RTO, Anda harus bekerja dengan manajemen untuk memutuskan RPO yang dapat diterima untuk bisnis. Misalnya, organisasi Anda mungkin memutuskan bahwa RPO yang dapat diterima adalah 2 jam. yaitu Setelah bencana, ketika Anda melakukan failover layanan ke DR sekunder, 2 jam kehilangan data dapat diterima oleh bisnis. Misalnya, jika bencana terjadi pada jam 3 sore, setelah Anda memulihkan sistem di situs DR, itu akan berisi data dari produksi hanya pada jam 1 siang. Jadi, Anda kehilangan data dari jam 1 siang – 3 sore. Sederhananya, jika RPO Anda adalah 2 jam, bisnis Anda harus rela kehilangan data selama 2 jam selama bencana.
Pengalihan otomatis atau manual? Anda telah memutuskan apakah Anda ingin melakukan failover otomatis atau failover manual setelah bencana. Dalam kebanyakan kasus, intervensi manual dapat diterima, karena Anda tidak ingin melakukan failover secara otomatis ke situs DR berdasarkan beberapa sinyal palsu. Ingatlah bahwa setelah Anda melakukan failover, ada banyak pekerjaan yang harus dilakukan untuk kembali ke pusat data utama.
Kegagalan jaringan. Saya telah melihat rencana DR yang memberikan banyak fokus pada replikasi data, tetapi kurang fokus pada aspek jaringan DR. Bekerja dengan tim jaringan Anda, Anda perlu mengidentifikasi semua infrastruktur jaringan yang perlu direplikasi. Misalnya, failover DNA untuk memastikan bahwa URL produksi Anda mengarah ke situs DR setelah failover. Jika Anda telah membuat koneksi VPN untuk pelanggan Anda, identifikasi cara melakukan failover koneksi VPN. Saat Anda membuat/memodifikasi aturan firewall (atau apa pun yang terkait dengan keamanan) di pusat data utama, Anda perlu mengidentifikasi bagaimana kebijakan keamanan tersebut dapat direplikasi ke situs DR secara berkelanjutan.
Penyiapan tangan jarak jauh. Anda harus memiliki rencana yang sesuai untuk mengakses pusat data jarak jauh untuk men-debug masalah apa pun. Anda dapat mengatur KVM di situs DR, untuk mengakses konsol perangkat keras yang terletak di situs DR dari kantor Anda. Atau, Anda perlu merencanakan beberapa bentuk layanan tangan jarak jauh manual, di mana seseorang dapat mengunjungi situs DR secara fisik dan melaksanakan instruksi Anda.
Pengujian DR tahunan. Beberapa organisasi menghabiskan banyak waktu dan uang dalam menyiapkan situs DR, hanya untuk mengetahui bahwa itu tidak benar-benar berfungsi seperti yang diharapkan ketika mereka berada dalam situasi DR yang sebenarnya. Sekali setahun, Anda harus memvalidasi konfigurasi DR Anda saat ini untuk memastikan situs DR berfungsi dengan baik dan memenuhi tujuan awal. Jika semuanya dikonfigurasi dengan benar, Anda seharusnya dapat secara manual melakukan failover aplikasi penting Anda dari situs utama ke situs DR, dan membiarkannya berjalan di sana selama beberapa hari. Ini juga membantu Anda melihat bagaimana situs DR menangani pemuatan waktu nyata.
Situs DR sebagai platform QA. Alih-alih menggunakan situs DR hanya untuk situasi bencana, Anda dapat menggunakannya sebagai platform QA untuk melakukan pengujian kinerja dan beban aplikasi Anda. Ini mungkin berguna, karena Anda tidak perlu berinvestasi dalam infrastruktur pengujian tambahan di pusat data utama. Saat Anda mengambil pendekatan ini, Anda akan tetap menyinkronkan data dari situs utama ke situs DR secara terus-menerus. Namun, setiap kali Anda melakukan pengujian beban, Anda perlu menerapkan beberapa solusi tambahan di mana Anda mengambil pos pemeriksaan status situs DR saat ini, melakukan pengujian QA Anda, dan kemudian segera mengembalikan ke pos pemeriksaan sebelumnya dan melanjutkan sinkronisasi data situs utama dari sana.
Rencana tanggapan DR. Setelah Anda mengimplementasikan situs DR, Anda harus memiliki rencana DR yang jelas tentang bagaimana Anda dan tim Anda akan merespons ketika ada bencana nyata. Berkolaborasi dengan berbagai departemen di organisasi Anda, dan identifikasi sumber daya utama yang akan menjadi bagian dari tim respons DR, dan identifikasi peran spesifik mereka dalam rencana respons DR. Rencana respons DR adalah petunjuk langkah demi langkah sederhana tentang apa yang perlu dilakukan saat ada DR, siapa yang akan melakukan tugas tersebut, dan dalam urutan apa tugas tersebut akan dilakukan.
Tidak punya situs DR? Banyak organisasi tidak memiliki situs DR. Jika Anda bekerja untuk salah satu dari mereka, dan Anda bertanggung jawab untuk aplikasi penting dan infrastruktur TI, Anda bertanggung jawab untuk membuat rencana DR, dan mendidik manajemen puncak Anda tentang pentingnya menghabiskan waktu dan uang untuk DR, dan dapatkan persetujuan mereka. Munculkan tiga paket DR berbeda—satu seharga $$$, satu seharga $$, satu seharga $. Seperti yang kami jelaskan sebelumnya, rencana DR dapat bervariasi tergantung pada berbagai faktor, dan biaya adalah salah satunya. Setelah Anda mempresentasikan rencana DR terperinci Anda kepada manajemen Anda, jika mereka masih tidak menyetujuinya, setidaknya Anda akan merasa senang bahwa Anda telah memberikan upaya terbaik Anda untuk membuat rencana DR yang baik.
Kapan menyatakan bencana? Anda perlu mengidentifikasi ini dengan jelas sebelumnya. Anda harus memiliki kriteria tertulis yang sangat jelas tentang kapan Anda akan beralih ke situs DR. yaitu Kriteria apa yang memicu kriteria failover DR? Kapan Anda memulai DR? Pada titik mana Anda menyatakannya sebagai DR, tambahkan mulai bekerja untuk gagal ke situs DR? Jawaban atas pertanyaan ini harus didefinisikan dengan jelas, dan ditinjau oleh setiap departemen di organisasi Anda, dan akhirnya kriteria ini harus disetujui oleh manajemen puncak. Bagi sebagian orang, ketika produksi sedang turun, karena seseorang menghapus sesuatu di produksi secara tidak sengaja mungkin tidak memicu DR. Untuk beberapa organisasi, mereka mungkin lebih baik memulihkan data dari cadangan di situs utama itu sendiri. Untuk organisasi lain, bisnis tidak dapat menunggu sampai mereka memulihkan dari cadangan, dan mereka harus beralih ke situs DR.
Cadangan, pencadangan, dan pencadangan. Cadangan adalah faktor yang sangat penting dalam rencana DR. Seperti yang kami sebutkan sebelumnya, tujuan Anda adalah untuk tidak pernah menggunakan situs DR, kecuali jika terjadi bencana alam yang nyata. Jadi, strategi pencadangan yang kuat di situs utama Anda sangat penting. Anda harus mencadangkan semua aplikasi penting Anda. Saat Anda membuat cadangan database Anda, simpan cadangan di empat lokasi. Pencadangan hampir tidak berguna jika Anda tidak memulihkannya di server pengujian untuk memvalidasi bahwa cadangan berfungsi secara berkelanjutan.
Menerapkan patch. Saat Anda menerapkan patch OS, memutakhirkan firmware, atau melakukan segala jenis manajemen konfigurasi ke perangkat keras di situs utama, Anda harus memiliki strategi untuk melakukannya di situs DR secara berkelanjutan. Anda tidak ingin berada dalam situasi di mana konfigurasi OS di situs utama Anda berbeda dengan situs DR.
DR yang berhasil bergantung pada banyak faktor. Berkat manajemen puncak, alokasi anggaran yang memadai, keterlibatan dari semua divisi bisnis, rencana DR yang kuat, sumber daya teknis yang kuat, implementasi DR yang teruji sepenuhnya. Yang terpenting, cakupan DR yang terdefinisi dengan baik yang selaras dengan tujuan bisnis sangat penting untuk keberhasilan DR.
Dokumentasi DR. Perencanaan DR yang tepat membutuhkan banyak proses yang harus ditetapkan. Semua proses ini harus didokumentasikan dengan baik. Misalnya, dokumen yang menjelaskan proses eskalasi saat DR menyerang. Dokumentasi teknis yang menjelaskan apa yang perlu dilakukan untuk melakukan failover ke situs DR. Dokumen komunikasi yang mencantumkan semua anggota tim yang terlibat dalam DR, dan apa yang menjadi tanggung jawab mereka, dan bagaimana mereka dapat dihubungi selama DR. Dokumen untuk tim dukungan pelanggan, yang tahu apa yang perlu dikomunikasikan kepada pelanggan, dan bagaimana menjangkau pelanggan saat terjadi bencana. Dokumen pengujian DR yang mencantumkan semua yang perlu diuji oleh tim QA setelah situs DR ditayangkan, dll.

Kami hanya menggores permukaan Disaster Recovery. Ada lebih banyak untuk itu daripada item di atas. Jika Anda seorang sysadmin, atau seseorang yang bertanggung jawab atas aplikasi dan infrastruktur TI Anda, dan jika tidak memiliki rencana DR, pertimbangkan ini sebagai pengingat untuk memulai sesuatu untuk strategi DR Anda.