Rekomendasi untuk merancang strategi pemulihan bencana

  • Artikel

Berlaku untuk rekomendasi daftar periksa Keandalan Azure Well-Architected Framework ini:

RE:09 Terapkan rencana kelangsungan bisnis dan pemulihan bencana (BCDR) terstruktur, teruji, dan terstruktur yang selaras dengan target pemulihan. Paket harus mencakup semua komponen dan sistem secara keseluruhan.

Panduan ini menjelaskan rekomendasi untuk merancang strategi pemulihan bencana yang andal untuk beban kerja. Untuk memenuhi tujuan tingkat layanan internal (SLA) atau bahkan perjanjian tingkat layanan (SLA) yang telah Anda jamin untuk pelanggan Anda, Anda harus memiliki strategi pemulihan bencana yang kuat dan andal. Kegagalan dan masalah utama lainnya diharapkan. Persiapan Anda untuk menangani insiden ini menentukan berapa banyak pelanggan Anda dapat mempercayai bisnis Anda untuk mengirimkannya dengan andal. Strategi pemulihan bencana adalah tulang punggung persiapan untuk insiden besar.

Definisi

Istilah Definisi
Failover Pergeseran lalu lintas beban kerja produksi secara otomatis dan/atau manual dari wilayah yang tidak tersedia ke wilayah geografis yang tidak terpengaruh.
Failback Pergeseran lalu lintas beban kerja produksi secara otomatis dan/atau manual dari wilayah failover kembali ke wilayah utama.

Strategi desain utama

Panduan ini mengasumsikan bahwa Anda telah melakukan tugas-tugas berikut sebagai bagian dari perencanaan keandalan Anda:

Strategi pemulihan bencana (DR) yang andal dibangun berdasarkan fondasi arsitektur beban kerja yang andal. Atasi keandalan di setiap tahap membangun beban kerja Anda untuk memastikan bahwa bagian yang diperlukan untuk pemulihan yang dioptimalkan ada sebelum Anda mulai merancang strategi DR Anda. Fondasi ini memastikan bahwa target keandalan beban kerja Anda, seperti tujuan waktu pemulihan (RTO) dan tujuan titik pemulihan (RPO), realistis dan dapat dicapai.

Mempertahankan rencana pemulihan bencana

Landasan strategi DR yang andal untuk beban kerja adalah rencana DR. Rencana Anda harus menjadi dokumen hidup yang secara rutin ditinjau dan diperbarui saat lingkungan Anda berkembang. Sajikan rencana tersebut kepada tim yang sesuai (operasi, kepemimpinan teknologi, dan pemangku kepentingan bisnis) secara teratur (misalnya setiap enam bulan). Simpan di penyimpanan data yang sangat tersedia dan aman seperti OneDrive for Business.

Ikuti rekomendasi ini untuk mengembangkan rencana DR Anda:

  • Tentukan dengan jelas apa yang merupakan bencana dan karenanya memerlukan aktivasi rencana DR.

    • Bencana adalah masalah skala besar. Mereka mungkin pemadaman regional, pemadaman layanan seperti ID Microsoft Entra atau Azure DNS, atau serangan berbahaya yang parah seperti serangan ransomware atau serangan DDoS.

    • Identifikasi mode kegagalan yang tidak dianggap sebagai bencana, seperti kegagalan satu sumber daya, sehingga operator tidak keliru memanggil eskalasi DR mereka.

  • Buat rencana DR pada dokumentasi FMA Anda. Pastikan rencana DR Anda menangkap mode kegagalan dan strategi mitigasi untuk pemadaman yang didefinisikan sebagai bencana. Perbarui paket DR dan dokumen FMA Anda secara paralel sehingga akurat saat lingkungan berubah atau saat pengujian mengungkap perilaku yang tidak terduga.

    • Apakah Anda mengembangkan paket DR untuk lingkungan nonproduksi tergantung pada kebutuhan bisnis dan dampak biaya Anda. Misalnya, jika Anda menawarkan lingkungan jaminan kualitas (QA) kepada pelanggan tertentu untuk pengujian prarilis, Anda mungkin ingin menyertakan lingkungan tersebut dalam perencanaan DR Anda.

  • Tentukan peran dan tanggung jawab dengan jelas dalam tim beban kerja dan pahami peran eksternal terkait dalam organisasi Anda. Peran harus mencakup:

    • Pihak yang bertanggung jawab untuk menyatakan bencana.

    • Pihak yang bertanggung jawab untuk menyatakan penutupan insiden.

    • Peran operasi.

    • Peran pengujian dan validasi.

    • Peran komunikasi internal dan eksternal.

    • Peran utama analisis retrospektif dan akar penyebab (RCA).

  • Tentukan jalur eskalasi yang harus diikuti tim beban kerja untuk memastikan bahwa status pemulihan dikomunikasikan kepada pemangku kepentingan.

  • Menangkap prosedur pemulihan tingkat komponen, pemulihan tingkat estat data, dan proses pemulihan di seluruh beban kerja. Sertakan urutan operasi yang ditentukan untuk memastikan bahwa komponen dipulihkan dengan cara yang paling tidak berdampak. Misalnya, pulihkan dan periksa database sebelum Anda memulihkan aplikasi.

    • Detail setiap prosedur pemulihan tingkat komponen sebagai panduan langkah demi langkah. Sertakan cuplikan layar jika memungkinkan.

    • Tentukan tanggung jawab tim Anda versus tanggung jawab penyedia hosting cloud Anda. Misalnya, Microsoft bertanggung jawab untuk memulihkan PaaS (platform sebagai layanan), tetapi Anda bertanggung jawab untuk merehidrasi data dan menerapkan konfigurasi Anda ke layanan.

    • Sertakan prasyarat untuk menjalankan prosedur. Misalnya, cantumkan skrip atau kredensial yang diperlukan yang perlu dikumpulkan.

    • Ambil akar penyebab insiden dan lakukan mitigasi sebelum Anda memulai pemulihan. Misalnya, jika penyebab insiden adalah masalah keamanan, mitigasi masalah tersebut sebelum Anda memulihkan sistem yang terpengaruh di lingkungan failover Anda.

  • Bergantung pada desain redundansi untuk beban kerja Anda, Anda mungkin perlu melakukan pekerjaan pasca-failover yang signifikan sebelum Anda membuat beban kerja tersedia untuk pelanggan Anda lagi. Pekerjaan pasca-failover dapat mencakup pembaruan DNS, pembaruan string koneksi database, dan perubahan perutean lalu lintas. Ambil semua pekerjaan pasca-failover dalam prosedur pemulihan Anda.

    Catatan

    Desain redundansi Anda mungkin memungkinkan Anda untuk secara otomatis pulih dari insiden besar sepenuhnya atau sebagian, jadi pastikan rencana Anda mencakup proses dan prosedur di sekitar skenario ini. Misalnya, jika Anda memiliki desain aktif-aktif sepenuhnya yang mencakup zona ketersediaan atau wilayah, Anda mungkin dapat melakukan failover secara transparan secara otomatis setelah pemadaman zona ketersediaan atau regional dan meminimalkan langkah-langkah dalam rencana DR Anda yang perlu dilakukan. Demikian pula, jika Anda merancang beban kerja dengan menggunakan stempel penyebaran, Anda mungkin hanya mengalami pemadaman parsial jika stempel disebarkan secara zonal. Dalam hal ini, rencana DR Anda harus mencakup cara memulihkan stempel di zona atau wilayah yang tidak terpengaruh.

  • Jika Anda perlu menyebarkan ulang aplikasi Anda di lingkungan failover, gunakan alat untuk mengotomatiskan proses penyebaran sebanyak mungkin. Pastikan bahwa alur DevOps Anda telah disebarkan sebelumnya dan dikonfigurasi di lingkungan failover sehingga Anda dapat segera memulai penyebaran aplikasi Anda. Gunakan penyebaran end-to-end otomatis, dengan gerbang persetujuan manual jika perlu, untuk memastikan proses penyebaran yang konsisten dan efisien. Durasi penyebaran penuh perlu selaras dengan target pemulihan Anda.

    • Saat tahap proses penyebaran memerlukan intervensi manual, dokumentasikan langkah-langkah manual. Tentukan peran dan tanggung jawab dengan jelas.

  • Otomatiskan prosedur sebanyak mungkin. Dalam skrip Anda, gunakan pemrograman deklaratif karena memungkinkan idempotensi. Saat Anda tidak dapat menggunakan pemrograman deklaratif, perhatikan cara mengembangkan dan menjalankan kode kustom Anda. Gunakan logika coba lagi dan logika pemutus arus untuk menghindari membuang-buang waktu pada skrip yang terjebak pada tugas yang rusak. Karena Anda menjalankan skrip ini hanya dalam keadaan darurat, Anda tidak ingin skrip yang salah dikembangkan menyebabkan lebih banyak kerusakan atau memperlambat proses pemulihan Anda.

    Catatan

    Automation menimbulkan risiko. Operator terlatih perlu memantau proses otomatis dengan hati-hati dan campur tangan jika ada proses yang mengalami masalah. Untuk meminimalkan risiko bahwa otomatisasi akan bereaksi terhadap positif palsu, telitilah latihan DR Anda. Uji semua fase rencana. Simulasikan deteksi untuk menghasilkan pemberitahuan, lalu lanjutkan melalui seluruh prosedur pemulihan.

    Ingatlah bahwa latihan DR Anda harus memvalidasi atau menginformasikan pembaruan untuk metrik target pemulihan Anda. Jika Anda menemukan bahwa otomatisasi Anda rentan terhadap positif palsu, Anda mungkin perlu meningkatkan ambang kegagalan Anda.

  • Pisahkan rencana failback dari rencana DR untuk menghindari potensi kebingungan dengan prosedur DR. Rencana failback harus mengikuti semua rekomendasi pengembangan dan pemeliharaan rencana DR dan harus disusun dengan cara yang sama. Setiap langkah manual yang diperlukan untuk failover harus dicerminkan dalam rencana failback. Failback mungkin terjadi dengan cepat setelah failover, atau mungkin memakan waktu berhari-hari atau berpekan-minggu. Pertimbangkan failback sebagai terpisah dari failover.

    • Kebutuhan untuk failback bersifat situasi. Jika Anda merutekan lalu lintas antar wilayah karena alasan performa, failback beban yang awalnya di wilayah failover penting. Dalam kasus lain, Anda mungkin telah merancang beban kerja Anda agar berfungsi sepenuhnya terlepas dari lingkungan produksi mana yang berada kapan saja.

Melakukan latihan pemulihan bencana

Praktik pengujian DR sama pentingnya dengan rencana DR yang dikembangkan dengan baik. Banyak industri memiliki kerangka kerja kepatuhan yang memerlukan sejumlah latihan DR tertentu untuk dilakukan secara teratur. Terlepas dari industri Anda, latihan DR reguler sangat penting untuk kesuksesan Anda.

Ikuti rekomendasi ini untuk latihan DR yang berhasil:

  • Lakukan setidaknya satu latihan DR produksi per tahun. Latihan tabletop (dry run) atau latihan nonproduksi membantu memastikan bahwa pihak yang terlibat terbiasa dengan peran dan tanggung jawab mereka. Latihan ini juga membantu operator membangun keakraban ("memori otot") dengan mengikuti proses pemulihan. Tetapi hanya latihan produksi yang benar-benar menguji validitas rencana DR dan metrik RTO dan RPO. Gunakan latihan produksi Anda untuk waktu proses pemulihan untuk komponen dan alur untuk memastikan bahwa target RTO dan RPO yang telah ditentukan untuk beban kerja Anda dapat dicapai. Untuk fungsi yang berada di luar kontrol Anda, seperti propagasi DNS, pastikan bahwa target RTO dan RPO untuk alur yang melibatkan fungsi tersebut mempertanggungjawabkan kemungkinan penundaan di luar kontrol Anda.

  • Gunakan latihan tabletop tidak hanya untuk membangun keakraban bagi operator berpengalaman tetapi juga untuk mendidik operator baru tentang proses dan prosedur DR. Operator senior harus meluangkan waktu untuk membiarkan operator baru menjalankan peran mereka dan harus watch untuk peluang perbaikan. Jika operator baru ragu atau bingung dengan langkah dalam prosedur, tinjau prosedur tersebut untuk memastikan bahwa itu ditulis dengan jelas.

Pertimbangan

  • Melakukan latihan DR dalam produksi dapat menyebabkan kegagalan bencana yang tidak terduga. Pastikan untuk menguji prosedur pemulihan di lingkungan nonproduksi selama penyebaran awal Anda.

  • Berikan tim Anda waktu pemeliharaan sebanyak mungkin selama latihan. Saat merencanakan waktu pemeliharaan, gunakan metrik pemulihan yang Anda ambil selama pengujian sebagai alokasi waktu minimum yang diperlukan .

  • Saat praktik drill DR Anda matang, Anda mempelajari prosedur mana yang dapat Anda jalankan secara paralel dan mana yang harus Anda jalankan secara berurutan. Di awal praktik latihan Anda, asumsikan bahwa setiap prosedur harus dijalankan secara berurutan dan Bahwa Anda membutuhkan waktu tambahan di setiap langkah untuk menangani masalah yang tidak diduga.

Fasilitasi Azure

Banyak produk Azure memiliki kemampuan failover bawaan. Biasakan diri Anda dengan kemampuan ini dan sertakan dalam prosedur pemulihan.

Untuk sistem IaaS (infrastruktur sebagai layanan), gunakan Azure Site Recovery untuk mengotomatiskan failover dan pemulihan. Lihat artikel berikut untuk produk PaaS umum:

Contoh

Lihat seri platform data DR untuk Azure untuk panduan tentang menyiapkan properti data perusahaan untuk DR.

Daftar periksa keandalan

Lihat kumpulan rekomendasi lengkap.

Daftar periksa keandalan