Bagikan melalui

Strategi arsitektur untuk pemulihan bencana

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

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

Bencana adalah insiden signifikan yang memerlukan perencanaan yang cermat dan persiapan proaktif oleh beban kerja dan tim operasi.

Artikel ini menguraikan strategi utama untuk pemulihan bencana, menekankan desain beban kerja yang tangguh, integritas data, dan tujuan yang ditentukan dengan jelas untuk failover dan pemulihan. Ini berfokus pada tujuan dan prinsip panduan DR daripada prosedur langkah demi langkah. Untuk panduan implementasi terperinci, termasuk proses bertahap dan panduan praktis, lihat artikel pendamping: Mengembangkan rencana pemulihan bencana untuk penyebaran multi-wilayah.

Definisi

Istilah Definisi
Siaga dingin aktif-pasif Pola penyebaran Disaster Recovery (DR) di mana wilayah sekunder tidak memiliki infrastruktur yang berjalan atau hanya minimal hingga bencana terjadi, membutuhkan penyebaran penuh ketika terjadi failover.
Siaga hangat aktif-pasif Pola penyebaran DR di mana wilayah sekunder memiliki beberapa infrastruktur yang telah disebarkan sebelumnya dan berjalan pada kapasitas yang berkurang, memungkinkan failover yang lebih cepat daripada siaga dingin.
Backup Salinan data yang disimpan secara terpisah dari sistem utama untuk mengaktifkan pemulihan data jika kehilangan, kerusakan, atau bencana terjadi
Kekritisan bisnis Klasifikasi beban kerja atau komponen berdasarkan kepentingannya terhadap operasi bisnis, yang berpengaruh pada prioritas pemulihan dan tingkat investasi.
Kriteria aktivasi DR Ambang batas dan kondisi yang telah ditentukan sebelumnya yang menentukan kapan harus mendeklarasikan bencana dan memicu prosedur pemulihan.
DR drill Latihan yang direncanakan untuk menguji prosedur pemulihan bencana dan memvalidasi kemampuan pemulihan dalam kondisi terkontrol.
Gagal kembali Pergeseran otomatis dan/atau manual lalu lintas beban kerja produksi dari wilayah failover kembali ke wilayah utama.
Pengalihan Cadangan Pergeseran otomatis dan/atau manual lalu lintas beban kerja produksi dari wilayah yang tidak tersedia ke wilayah geografis yang tidak terpengaruh.
Pemulihan ke titik waktu tertentu Kemampuan untuk memulihkan data ke momen tertentu dalam waktu tertentu, biasanya digunakan untuk memulihkan dari kerusakan data atau perubahan yang tidak disengaja.
Tujuan Titik Pemulihan (RPO) Jumlah maksimum kehilangan data yang dapat diterima, diukur dalam satuan waktu, menentukan berapa banyak data yang dapat ditanggung oleh bisnis selama bencana.
Tujuan Waktu Pemulihan (RTO) Waktu maksimum yang dapat diterima untuk memulihkan operasi bisnis setelah bencana terjadi.
Replikasi sinkron Replikasi data di mana perubahan ditulis ke beberapa lokasi secara bersamaan, memastikan tanpa kehilangan data tetapi dengan potensi latensi yang lebih tinggi.
Replikasi asinkron Replikasi data di mana perubahan ditulis ke lokasi utama terlebih dahulu dan kemudian disalin ke lokasi sekunder, memungkinkan beberapa kehilangan data tetapi latensi yang lebih rendah.
Ruang perang Lokasi terpusat atau saluran komunikasi tempat personel utama berkoordinasi selama operasi pemulihan bencana.

Prioritaskan oleh dampak bisnis

Kategorikan beban kerja Anda berdasarkan tingkat kekritisan yang ditentukan oleh organisasi Anda, seperti misi penting, penting bagi bisnis, operasional bisnis, dan sebagainya. Kenali bahwa setiap tingkatan menjamin tingkat investasi, ketahanan, dan urutan pemulihan yang berbeda. Jika beban kerja berisi beberapa alur atau komponen dengan berbagai kekritisan, dokumentasikan pendekatan pemulihan untuk masing-masing untuk menghindari ambiguitas selama peristiwa.

Tingkat kekritisan ini memengaruhi tujuan pemulihan yang sesuai. Komponen dengan kekritisan yang lebih tinggi menuntut pemulihan yang lebih cepat dan perlindungan data yang lebih sering, sementara komponen kekritisan yang lebih rendah dapat mentolerir pemulihan yang lebih lambat. Dari persyaratan ini, dapatkan target RTO dan RPO yang jelas yang menyelaraskan ekspektasi pemulihan langsung dengan nilai bisnis.

Menentukan ambang bencana

Pastikan tim dan pemangku kepentingan bisnis memahami dengan tepat apa yang dihitung sebagai bencana dan apa yang tidak. Strategi Anda harus membedakan antara bencana penuh, gangguan besar, dan masalah kecil yang dapat diperbaiki dengan cepat. Jangan hanya mendasarkan ini pada komponen mana yang gagal. Sebaliknya, perhitungkan berapa banyak masalah yang berdampak pada pengguna dan bisnis secara keseluruhan.

Setelah Anda menentukan ambang batas yang memisahkan insiden kecil dari situasi DR yang sebenarnya, buatlah ke dalam model kesehatan Anda. Dengan cara ini, pemantauan dapat melihat tanda peringatan dini dan proses pemulihan yang sesuai dipicu.

Membuat protokol komunikasi

Tanpa komunikasi yang jelas, bahkan rencana pemulihan bencana yang dirancang dengan baik dapat gagal. Bangun strategi komunikasi yang jelas yang menentukan siapa yang membuat keputusan, siapa yang mendapatkan informasi, dan bagaimana informasi mengalir selama peristiwa DR.

Mulailah dengan menguraikan peran dan tanggung jawab dalam tim beban kerja, serta grup eksternal apa pun yang terlibat. Ini harus mencakup pihak yang bertanggung jawab untuk deklarasi bencana, penutupan insiden, menjalankan tugas operasi, melakukan pengujian dan validasi, mengelola komunikasi internal dan eksternal, serta memimpin retrospektif atau analisis akar masalah.

Berikan instruksi langkah demi langkah, cantumkan semua prasyarat (seperti skrip, kredensial, dan konfigurasi), dan tentukan tanggung jawab antara tim Anda dan penyedia cloud. Pastikan masalah akar penyebab ditangani sebelum pemulihan mulai mencegah kegagalan berulang.

Bangun ruang perang lintas fungsi untuk memastikan orang yang tepat dapat berkoordinasi dengan cepat, dan menyiapkan saluran komunikasi dan templat pesan terlebih dahulu sehingga tim tidak berdaya improvisasi di bawah tekanan.

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

Desain arsitektur sadar pemulihan

Proses pemulihan bencana Anda harus mencerminkan bagaimana beban kerja Anda dirancang dan, sebaliknya, persyaratan pemulihan Anda harus memengaruhi keputusan arsitektur sejak awal. Saat merancang sistem Anda, pertimbangkan bagaimana Anda berniat untuk pulih selama bencana dan memilih pola (seperti siaga dingin pasif aktif atau siaga hangat pasif aktif) yang mendukung persyaratan pemulihan Anda.

Untuk pemulihan data, gunakan strategi replikasi berdasarkan target RPO. Misalnya, sinkron di seluruh zona ketersediaan untuk data berprioritas tinggi, asinkron di seluruh wilayah untuk prioritas yang lebih rendah. Pastikan model konsistensi mendukung pemulihan, menerapkan backup lengkap secara berkala dan pemulihan ke titik waktu tertentu, memperhitungkan ketergantungan antar penyimpanan data, dan mengotomatiskan pemeriksaan integritas otomatis selama proses pemulihan.

Nota

Merancang beban kerja dengan pengendalian dan isolasi untuk memungkinkan proses failover parsial komponen individual. Ini mengurangi kompleksitas, biaya, dan RTO, dan dapat mempertahankan ketersediaan parsial tanpa menyatakan bencana secara penuh. Uji failover parsial secara terpisah dan mendokumentasikan kapan failover harus dipicu.

Menyiapkan infrastruktur dan prosedur pemulihan

Siapkan wilayah sekunder terlebih dahulu. Buat daftar periksa sehingga tim siap ketika insiden terjadi, seperti:

  • Lapisan komputasi: Untuk beban kerja aktif/pasif yang hangat, siapkan sumber daya komputasi minimal untuk mendukung failover yang cepat.
  • Infrastruktur jaringan: Mereplikasi topologi, termasuk VNet, subnet, rute, firewall, dan grup keamanan, dan konfirmasi semua konfigurasi.
  • Manajemen identitas dan akses: Penyiapan akun duplikat, izin RBAC, dan kebijakan, memastikan dasar keamanan yang sama dengan lingkungan produksi.
  • Pemantauan: Menyebarkan infrastruktur pemantauan dengan peringatan dan dashboard yang dikonfigurasi agar terlihat jelas.

Susun proses pemulihan Anda. Prosedur struktur di tingkat komponen, tingkat data estate, dan tingkat beban kerja. Tentukan urutan yang tepat untuk meminimalkan dampak. Misalnya, pulihkan database sebelum aplikasi yang bergantung padanya. Tentukan cakupan berdasarkan dampak bisnis. Tentukan apakah lingkungan produksi dan, jika perlu, non-produksi memerlukan cakupan DR, dengan mempertimbangkan dampak terhadap pelanggan dan biaya.

Pisahkan strategi failback dari failover.

Risiko: Kebutuhan untuk failback tergantung pada situasi: misalnya, jika lalu lintas dialihkan antar wilayah demi meningkatkan performa, memulihkan lalu lintas ke wilayah asalnya adalah penting. Dalam kasus lain, beban kerja dapat berfungsi sepenuhnya terlepas dari lingkungan mana yang aktif. Jika failback tidak diperlakukan sebagai proses yang terpisah dan terdefinisi dengan baik dari failover, tim mungkin mengalami kebingungan, yang dapat menyebabkan pemulihan tidak lengkap atau waktu henti yang berkepanjangan.

Untuk mengurangi risiko tersebut, buat rencana failback, bangun dan pertahankan rencana failback Anda menggunakan prinsip yang sama dengan rencana DR Anda, termasuk mencerminkan langkah manual apa pun dari failover. Failback dapat terjadi segera atau dalam jangka waktu beberapa hari atau minggu, tetapi perlakukanlah sebagai proses yang terpisah.

Rencanakan untuk pekerjaan pasca-failover. Ambil semua tugas yang diperlukan setelah failover, seperti pembaruan DNS, perutean lalu lintas, dan penyesuaian string koneksi, untuk mengembalikan beban kerja sepenuhnya secara online.

Menerapkan strategi pencadangan yang kuat

Pilih solusi cadangan yang disesuaikan dengan setiap layanan Azure, tentukan periode retensi, dan kenali bahwa tidak ada alat tunggal yang mencakup semuanya. Pertimbangkan penyimpanan multi-wilayah untuk pemulihan antar wilayah, dan untuk beberapa sumber daya, gunakan penyebaran ulang dari repositori yang memiliki ketersediaan tinggi. Uji pemulihan secara teratur untuk memvalidasi cadangan, dan meninjau dan memperbarui rencana secara berkala, menyimpannya dengan aman dan membuatnya dapat diakses oleh tim yang relevan.

Berlatih dengan latihan reguler

Paket DR hanya bermakna ketika divalidasi dalam kondisi realistis. Uji beberapa skenario, termasuk kasus tepi, dan gabungkan latihan terjadwal dengan hari permainan kejutan untuk melihat bagaimana sistem dan tim merespons di bawah tekanan.

Dalam rencana DR Anda, sertakan prosedur dan irama untuk latihan simulasi, uji coba di lingkungan non-produksi, dan latihan di level produksi. Latihan tabletop membantu tim mempraktikkan peran mereka, membangun keakraban, dan melatih anggota baru, sementara latihan produksi adalah satu-satunya cara untuk memverifikasi bahwa rencana Anda memenuhi target RTO dan RPO dalam kondisi nyata. Untuk proses di luar kontrol Anda, seperti penyebaran DNS, validasi potensi penundaan saat mengevaluasi waktu pemulihan.

Risiko: Melakukan latihan DR secara langsung dalam produksi dapat memperkenalkan kegagalan yang tidak terduga dan berpotensi parah. Uji prosedur pemulihan di lingkungan non-produksi terlebih dahulu untuk memvalidasi masalah keamanan dan mengungkap sebelum menjalankan latihan dalam produksi.

Memiliki proses di tempat yang memperlakukan hasil pengujian sebagai input untuk meningkatkan postur DR secara keseluruhan. Misalnya, jika operator baru ragu-ragu, tinjau prosedur tersebut untuk memastikan bahwa prosedur tersebut ditulis dengan jelas.

Uji dan verifikasi RTO dan RPO baik di tingkat keseluruhan maupun tingkat komponen secara terpisah dari latihan Pemulihan Bencana (DR) penuh. Sertakan skenario seperti memindahkan data di seluruh wilayah atau memulihkan dari penyimpanan dingin untuk memastikan target dapat dicapai.

Menjaga rencana tetap terkini dan dapat ditindakkan

Perlakukan rencana DR sebagai dokumen hidup. Rencana Anda harus berkembang seiring perubahan lingkungan Anda dan harus ditinjau secara teratur dengan semua tim, operasi, kepemimpinan teknologi, dan pemangku kepentingan bisnis yang relevan, idealnya setiap enam bulan.

Jaga agar rencana DR Anda selaras dengan dokumentasi FMA Anda, menangkap bagaimana sistem bereaksi selama bencana dan cara merespons. Saat Anda menemukan kasus kegagalan baru, melalui pengujian, pemantauan, atau insiden nyata, perbarui rencana Anda untuk menyertakannya. Pastikan paket DR dan dokumentasi FMA Anda diperbarui setiap kali lingkungan berubah atau pengujian mengungkap perilaku tak terduga.

Perbaiki prosedur dari waktu ke waktu. Di awal praktik DR Anda, asumsikan setiap prosedur harus berjalan secara berurutan dan memungkinkan waktu tambahan untuk masalah yang tidak terduga. Saat praktik DR Anda matang, identifikasi langkah-langkah mana yang dapat berjalan dengan aman secara paralel. Penyempurnaan juga harus menangkap perubahan arsitektur. Setiap kali arsitektur beban kerja berubah, perbarui rencana DR untuk menentukan dengan jelas penyesuaian apa pun pada kriteria aktivasi atau proses pemulihan.

Rencanakan waktu pemulihan realistis. Gunakan metrik dari pengujian sebagai waktu minimum yang diperlukan untuk langkah-langkah pemulihan saat menjadwalkan latihan.

Memastikan aksesibilitas selama pemadaman

Pemulihan bencana hanya berhasil ketika rencana dan alat yang diperlukan untuk menjalankannya tetap tersedia dalam semua kondisi kegagalan.

Simpan dokumentasi pemulihan bencana, skrip, dan komponen pemulihan di lokasi yang sangat tersedia dan aman sehingga tetap dapat diakses bahkan selama pemadaman regional. Lindungi semua aset DR, termasuk rencana, kredensial, sertifikat, dan skrip, serta replikasikan di berbagai wilayah. Pertahankan salinan offline atau cetak untuk skenario kasus terburuk. Siapkan alur CI/CD di setiap wilayah sehingga siap untuk segera dijalankan jika diperlukan.

Mengotomatiskan prosedur pemulihan dengan aman

Otomatiskan prosedur penyebaran dan pemulihan di lingkungan failover sedapat mungkin, memastikan mereka memenuhi target RTO. Gunakan skrip deklaratif dan idempoten untuk keandalan, dan bangun perlindungan seperti logika coba lagi dan pemutus sirkuit untuk kode kustom apapun. Persiapkan dan konfigurasi alur DevOps sehingga penyebaran dapat segera dimulai, dengan menggunakan proses otomatis end-to-end dengan gerbang persetujuan manual hanya ketika diperlukan. Pastikan garis waktu penyebaran selaras dengan target pemulihan Anda.

Terapkan persetujuan manual jika perlu untuk menyeimbangkan kecepatan dengan kontrol. Saat langkah manual diperlukan, dokumentasikan dengan jelas dan tentukan peran dan tanggung jawab.

Risiko: Automation menimbulkan risiko. Bahkan dengan otomatisasi, operator terlatih harus mengawasi proses pemulihan dan campur tangan jika masalah muncul. Gunakan latihan DR menyeluruh untuk menguji setiap fase, memvalidasi target pemulihan, dan menyesuaikan ambang kegagalan untuk mengurangi risiko positif palsu.

Dukungan Azure

Banyak produk Azure memiliki kemampuan failover bawaan. Biasakan diri Anda dengan kemampuan ini dan sertakan dalam prosedur pemulihan. Lihat seri platform data DR untuk Azure untuk panduan tentang menyiapkan properti data perusahaan untuk DR.

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

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

Untuk sistem IaaS (infrastruktur sebagai layanan), gunakan Azure Backup untuk memfasilitasi pencadangan VM dan layanan terkait VM dan beberapa layanan data. Lihat artikel berikut untuk produk umum:

Daftar periksa keandalan

Lihat kumpulan rekomendasi lengkap.

Daftar periksa keandalan

  • Last updated on