Apa itu kelangsungan bisnis, ketersediaan tinggi, dan pemulihan bencana?

Artikel ini mendefinisikan dan menjelaskan kelangsungan bisnis dan perencanaan kelangsungan bisnis dalam hal manajemen risiko melalui ketersediaan tinggi dan desain pemulihan bencana. Meskipun artikel ini tidak memberikan panduan eksplisit tentang cara memenuhi kebutuhan kelangsungan bisnis Anda sendiri, artikel ini membantu Anda memahami konsep yang digunakan di seluruh panduan keandalan Microsoft.

Kelangsungan bisnis adalah keadaan di mana bisnis dapat melanjutkan operasi selama kegagalan, pemadaman, atau bencana. Kelangsungan bisnis membutuhkan perencanaan, persiapan, dan implementasi sistem dan proses yang tangguh secara proaktif.

Merencanakan kelangsungan bisnis memerlukan identifikasi, pemahaman, klasifikasi, dan pengelolaan risiko. Berdasarkan risiko dan kemungkinannya, desain untuk ketersediaan tinggi (HA) dan pemulihan bencana (DR).

Ketersediaan tinggi adalah tentang merancang solusi agar tahan terhadap masalah sehari-hari dan untuk memenuhi kebutuhan bisnis akan ketersediaan.

Pemulihan bencana adalah tentang merencanakan cara menangani risiko yang tidak biasa dan pemadaman bencana yang dapat diakibatkan.

Keberlangsungan bisnis

Secara umum, solusi cloud terkait langsung dengan operasi bisnis. Setiap kali solusi cloud tidak tersedia atau mengalami masalah serius, dampaknya pada operasi bisnis bisa parah. Dampak yang parah dapat memutus kelangsungan bisnis.

Dampak parah pada kelangsungan bisnis dapat meliputi:

• Hilangnya pendapatan bisnis.
• Ketidakmampuan untuk memberikan layanan penting kepada pengguna.
• Pelanggaran komitmen yang telah dilakukan kepada pelanggan atau pihak lain.

Penting untuk memahami dan mengomunikasikan harapan bisnis, dan konsekuensi kegagalan, kepada pemangku kepentingan penting termasuk mereka yang merancang, mengimplementasikan, dan mengoperasikan beban kerja. Para pemangku kepentingan tersebut kemudian merespons dengan membagikan biaya yang terlibat dalam memenuhi visi tersebut. Biasanya ada proses negosiasi dan revisi visi tersebut berdasarkan anggaran dan batasan lainnya.

Perencanaan kelangsungan bisnis

Untuk mengontrol atau sepenuhnya menghindari dampak negatif pada kelangsungan bisnis, penting untuk secara proaktif membuat rencana kelangsungan bisnis. Rencana kelangsungan bisnis didasarkan pada penilaian risiko dan mengembangkan metode pengendalian risiko tersebut melalui berbagai pendekatan. Risiko dan pendekatan khusus untuk mengurangi bervariasi untuk setiap organisasi dan beban kerja.

Rencana kelangsungan bisnis tidak hanya mempertimbangkan fitur ketahanan platform cloud itu sendiri tetapi juga fitur aplikasi. Rencana kelangsungan bisnis yang kuat juga menggabungkan semua aspek dukungan dalam bisnis termasuk orang-orang, proses manual atau otomatis terkait bisnis, dan teknologi lainnya.

Perencanaan kelangsungan bisnis harus mencakup langkah-langkah berurutan berikut:

1. Identifikasi risiko. Identifikasi risiko terhadap ketersediaan atau fungsionalitas beban kerja. Kemungkinan risiko bisa menjadi masalah jaringan, kegagalan perangkat keras, kesalahan manusia, pemadaman wilayah, dll. Pahami dampak setiap risiko.

2. Klasifikasi risiko. Mengklasifikasikan setiap risiko sebagai risiko umum, yang harus diperhitungkan ke dalam rencana untuk KETERSEDIAAN TINGGI, atau risiko yang tidak umum, yang harus menjadi bagian dari perencanaan DR.

3. Mitigasi risiko. Merancang strategi mitigasi untuk HA atau DR untuk meminimalkan atau mengurangi risiko seperti dengan menggunakan redundansi, replikasi, failover, dan cadangan. Selain itu, pertimbangkan mitigasi dan kontrol nonteknis dan berbasis proses.

Perencanaan kelangsungan bisnis adalah proses, bukan peristiwa satu kali. Setiap rencana kelangsungan bisnis yang dibuat harus ditinjau dan diperbarui secara teratur untuk memastikan bahwa rencana tersebut tetap relevan dan efektif, dan mendukung kebutuhan bisnis saat ini.

Identifikasi risiko

Fase awal dalam perencanaan kelangsungan bisnis adalah mengidentifikasi risiko terhadap ketersediaan atau fungsionalitas beban kerja. Setiap risiko harus dianalisis untuk memahami kemungkinan dan tingkat keparahannya. Tingkat keparahan perlu mencakup potensi waktu henti atau kehilangan data, serta apakah ada aspek dari sisa desain solusi yang mungkin mengkompensasi efek negatif.

Tabel berikut adalah daftar risiko yang tidak lengkap, diurutkan dengan mengurangi kemungkinan:

Perencanaan kelangsungan bisnis bukan hanya tentang platform dan infrastruktur cloud. Penting untuk mempertimbangkan risiko kesalahan manusia. Selain itu, beberapa risiko yang mungkin secara tradisional dianggap sebagai risiko keamanan, performa, atau operasional juga harus dianggap sebagai risiko keandalan karena memengaruhi ketersediaan solusi.

Berikut adalah beberapa contoh:

Analisis mode kegagalan (FMA) adalah proses mengidentifikasi cara potensial di mana beban kerja atau komponennya dapat gagal, dan bagaimana solusi bersifat di bawah situasi tersebut. Untuk mempelajari selengkapnya, lihat Rekomendasi untuk melakukan analisis mode kegagalan.

Klasifikasi risiko

Rencana kelangsungan bisnis harus mengatasi risiko umum dan tidak umum.

• Risiko umum direncanakan dan diharapkan. Misalnya, di lingkungan cloud, umum terjadi kegagalan sementara termasuk pemadaman jaringan singkat, mulai ulang peralatan karena patch, batas waktu saat layanan sibuk, dan sebagainya. Karena peristiwa ini terjadi secara teratur, beban kerja harus tahan terhadapnya.

  Strategi ketersediaan tinggi harus mempertimbangkan dan mengontrol setiap risiko jenis ini.

• Risiko yang jarang terjadi umumnya adalah akibat dari peristiwa yang tidak terduga, seperti bencana alam atau serangan jaringan besar, yang dapat menyebabkan pemadaman bencana.

  Proses pemulihan bencana menangani risiko langka ini.

Ketersediaan tinggi dan pemulihan bencana saling terkait, sehingga penting untuk merencanakan strategi untuk keduanya bersama-sama.

Penting untuk dipahami bahwa klasifikasi risiko tergantung pada arsitektur beban kerja dan persyaratan bisnis, dan beberapa risiko dapat diklasifikasikan sebagai HA untuk satu beban kerja dan DR untuk beban kerja lain. Misalnya, pemadaman wilayah Azure penuh umumnya akan dianggap sebagai risiko DR terhadap beban kerja di wilayah tersebut. Tetapi untuk beban kerja yang menggunakan beberapa wilayah Azure dalam konfigurasi aktif-aktif dengan replikasi penuh, redundansi, dan failover wilayah otomatis, pemadaman wilayah diklasifikasikan sebagai risiko HA.

Mitigasi

Mitigasi risiko terdiri dari strategi pengembangan ha atau DR untuk meminimalkan atau mengurangi risiko terhadap kelangsungan bisnis. Mitigasi risiko dapat berbasis teknologi atau berbasis manusia.

Mitigasi risiko berbasis teknologi

Mitigasi risiko berbasis teknologi menggunakan kontrol risiko yang didasarkan pada bagaimana beban kerja diimplementasikan dan dikonfigurasi, seperti:

• Redundansi geografis
• Replikasi data
• Failover
• Pencadangan

Kontrol risiko berbasis teknologi harus dipertimbangkan di dalam konteks rencana kelangsungan bisnis.

Contohnya:

• Persyaratan waktu henti rendah. Beberapa rencana kelangsungan bisnis tidak dapat mentolerir segala bentuk risiko waktu henti karena persyaratan ketersediaan tinggi yang ketat. Ada kontrol berbasis teknologi tertentu yang mungkin memerlukan waktu bagi manusia untuk diberi tahu dan kemudian merespons. Kontrol risiko berbasis teknologi yang mencakup proses manual yang lambat kemungkinan tidak layak untuk dimasukkan dalam strategi mitigasi risikonya.

• Toleransi terhadap kegagalan parsial. Beberapa rencana kelangsungan bisnis dapat mentolerir alur kerja yang berjalan dalam keadaan terdegradasi. Ketika solusi beroperasi dalam keadaan terdegradasi, beberapa komponen mungkin dinonaktifkan atau tidak berfungsi, tetapi operasi bisnis inti dapat terus dilakukan. Untuk mempelajari lebih lanjut, lihat Rekomendasi untuk penyembuhan diri dan pelestarian diri.

Mitigasi risiko berbasis manusia

Mitigasi risiko berbasis manusia menggunakan kontrol risiko yang didasarkan pada proses bisnis, seperti:

• Memicu playbook respons.
• Kembali ke operasi manual.
• Perubahan pelatihan dan budaya.

Karena kontrol risiko berbasis manusia sering lebih lambat daripada kontrol berbasis teknologi, dan lebih rentan terhadap kesalahan manusia, rencana kelangsungan bisnis yang baik harus mencakup proses kontrol perubahan formal untuk apa pun yang akan mengubah keadaan sistem yang sedang berjalan. Misalnya, pertimbangkan untuk menerapkan proses berikut:

• Uji beban kerja Anda dengan ketat sesuai dengan kekritisan beban kerja. Untuk mencegah masalah terkait perubahan, pastikan untuk menguji perubahan apa pun yang dilakukan pada beban kerja.
• Perkenalkan gerbang kualitas strategis sebagai bagian dari praktik penyebaran aman beban kerja Anda. Untuk mempelajari selengkapnya, lihat Rekomendasi untuk praktik penyebaran yang aman.
• Prosedur formalisasi untuk akses produksi ad-hoc dan manipulasi data. Kegiatan ini, tidak peduli seberapa kecil, dapat menimbulkan risiko tinggi menyebabkan insiden keandalan. Prosedur mungkin termasuk memasangkan dengan teknisi lain, menggunakan daftar periksa, dan mendapatkan tinjauan serekan sebelum menjalankan skrip atau menerapkan perubahan.

Ketersediaan tinggi

Ketersediaan tinggi adalah keadaan di mana beban kerja tertentu dapat mempertahankan tingkat waktu aktif yang diperlukan setiap hari, bahkan selama kesalahan sementara dan kegagalan terputus-putus. Karena peristiwa ini terjadi secara teratur, penting bahwa setiap beban kerja dirancang dan dikonfigurasi untuk ketersediaan tinggi sesuai dengan persyaratan aplikasi tertentu dan harapan pelanggan. KETERSEDIAAN setiap beban kerja berkontribusi pada rencana kelangsungan bisnis Anda.

Karena KETERSEDIAAN TINGGI dapat bervariasi dengan setiap beban kerja, penting untuk memahami persyaratan dan harapan pelanggan saat menentukan ketersediaan tinggi. Misalnya, aplikasi yang digunakan organisasi Anda untuk memesan persediaan kantor mungkin memerlukan tingkat waktu aktif yang relatif rendah, sementara aplikasi keuangan penting mungkin memerlukan waktu aktif yang jauh lebih tinggi. Bahkan dalam beban kerja, alur yang berbeda mungkin memiliki persyaratan yang berbeda. Misalnya, dalam aplikasi eCommerce, alur yang mendukung pelanggan menjelajah dan menempatkan pesanan mungkin lebih penting daripada pemenuhan pesanan dan alur pemrosesan back-office. Untuk mempelajari selengkapnya tentang alur, lihat Rekomendasi untuk mengidentifikasi dan memberi peringkat alur.

Umumnya, waktu aktif diukur berdasarkan jumlah "sembilan" dalam persentase waktu aktif. Persentase waktu aktif berkaitan dengan berapa banyak waktu henti yang Anda izinkan selama periode waktu tertentu. Berikut adalah beberapa contoh:

• Persyaratan waktu aktif 99,9% (tiga sembilan) memungkinkan waktu henti sekitar 43 menit dalam sebulan.
• Persyaratan waktu aktif 99,95% (tiga setengah sembilan) memungkinkan waktu henti sekitar 21 menit dalam sebulan.

Semakin tinggi persyaratan waktu aktif, semakin sedikit toleransi yang Anda miliki untuk pemadaman, dan semakin banyak pekerjaan yang harus Anda lakukan untuk mencapai tingkat ketersediaan tersebut. Waktu aktif tidak diukur oleh waktu aktif satu komponen seperti node, tetapi dengan ketersediaan keseluruhan seluruh beban kerja.

Elemen desain ketersediaan tinggi

Untuk mencapai persyaratan HA, beban kerja dapat menyertakan sejumlah elemen desain. Beberapa elemen umum tercantum dan dijelaskan di bawah ini di bagian ini.

Layanan dan tingkatan Azure yang mendukung ketersediaan tinggi

Banyak layanan Azure dirancang agar sangat tersedia, dan dapat digunakan untuk membangun beban kerja yang sangat tersedia. Berikut adalah beberapa contoh:

• Azure Virtual Machine Scale Sets memberikan ketersediaan tinggi untuk komputer virtual (VM) dengan secara otomatis membuat dan mengelola instans VM dan mendistribusikan instans VM tersebut untuk mengurangi dampak kegagalan infrastruktur.
• Azure App Service menyediakan ketersediaan tinggi melalui berbagai pendekatan, termasuk memindahkan pekerja secara otomatis dari simpul yang tidak sehat ke simpul yang sehat, dan dengan menyediakan kemampuan untuk pemulihan mandiri dari banyak jenis kesalahan umum.

Gunakan setiap panduan keandalan layanan untuk memahami kemampuan layanan, memutuskan tingkat mana yang akan digunakan, dan menentukan kemampuan mana yang akan disertakan dalam strategi ketersediaan tinggi Anda.

Tinjau perjanjian tingkat layanan (SLA) untuk setiap layanan guna memahami tingkat ketersediaan yang diharapkan dan kondisi yang perlu Anda penuhi. Anda mungkin perlu memilih atau menghindari tingkat layanan tertentu untuk mencapai tingkat ketersediaan tertentu. Beberapa layanan dari Microsoft ditawarkan dengan pemahaman bahwa tidak ada SLA yang disediakan, seperti pengembangan atau tingkat dasar, atau bahwa sumber daya dapat diklaim kembali dari sistem anda yang sedang berjalan, seperti penawaran berbasis spot. Selain itu, beberapa tingkatan telah menambahkan fitur keandalan, seperti dukungan untuk zona ketersediaan.

Toleransi kegagalan

Toleransi kesalahan adalah kemampuan sistem untuk terus beroperasi, dalam beberapa kapasitas yang ditentukan, jika terjadi kegagalan. Misalnya, aplikasi web mungkin dirancang untuk terus beroperasi meskipun satu server web gagal. Toleransi kesalahan dapat dicapai melalui redundansi, failover, partisi, degradasi yang anggun, dan teknik lainnya.

Toleransi kesalahan juga mengharuskan aplikasi Anda menangani kesalahan sementara. Saat membuat kode Sendiri, Anda mungkin perlu mengaktifkan penanganan kesalahan sementara sendiri. Beberapa layanan Azure menyediakan penanganan kesalahan sementara bawaan untuk beberapa situasi. Misalnya, secara default Azure Logic Apps secara otomatis mencoba kembali permintaan yang gagal ke layanan lain. Untuk mempelajari lebih lanjut, lihat Rekomendasi untuk menangani kesalahan sementara.

Redundansi geografis

Redundansi adalah praktik duplikat instans atau data untuk meningkatkan keandalan beban kerja.

Redundansi dapat dicapai dengan mendistribusikan replika atau instans redundan dalam satu lagi semua cara berikut:

• Di dalam pusat data (redundansi lokal)
• Antara zona ketersediaan dalam suatu wilayah (redundansi zona)
• Di seluruh wilayah (geo-redundansi).

Berikut adalah beberapa contoh bagaimana beberapa layanan Azure menyediakan opsi redundansi:

• Azure App Service memungkinkan Anda menjalankan beberapa instans aplikasi Anda, untuk memastikan bahwa aplikasi tetap tersedia meskipun satu instans gagal. Jika Anda mengaktifkan redundansi zona, instans tersebut tersebar di beberapa zona ketersediaan di wilayah Azure yang Anda gunakan.
• Azure Storage menyediakan ketersediaan tinggi dengan mereplikasi data secara otomatis setidaknya tiga kali. Anda dapat mendistribusikan replika tersebut di seluruh zona ketersediaan dengan mengaktifkan penyimpanan redundan zona (ZRS), dan di banyak wilayah Anda juga dapat mereplikasi data penyimpanan Anda di seluruh wilayah dengan menggunakan penyimpanan geo-redundan (GRS).
• Azure SQL Database memiliki beberapa replika untuk memastikan bahwa data tetap tersedia meskipun satu replika gagal.

Untuk mempelajari selengkapnya tentang redundansi, lihat Rekomendasi untuk merancang redundansi dan Rekomendasi untuk menggunakan zona dan wilayah ketersediaan.

Skalabilitas dan elastisitas

Skalabilitas dan elastisitas adalah kemampuan sistem untuk menangani peningkatan beban dengan menambahkan dan menghapus sumber daya (skalabilitas), dan melakukannya dengan cepat saat persyaratan Anda berubah (elastisitas). Skalabilitas dan elastisitas dapat membantu sistem mempertahankan ketersediaan selama beban puncak.

Banyak layanan Azure mendukung skalabilitas. Berikut adalah beberapa contoh:

• Azure Virtual Machine Scale Sets, Azure API Management, dan beberapa layanan lainnya mendukung skala otomatis Azure Monitor. Dengan skala otomatis Azure Monitor, Anda dapat menentukan kebijakan seperti "ketika CPU saya secara konsisten berada di atas 80%, tambahkan instans lain".
• Azure Functions dapat menyediakan instans secara dinamis untuk melayani permintaan Anda.
• Azure Cosmos DB mendukung throughput skala otomatis, di mana layanan dapat secara otomatis mengelola sumber daya yang ditetapkan ke database Anda berdasarkan kebijakan yang Anda tentukan.

Skalabilitas adalah faktor kunci yang perlu dipertimbangkan selama kerusakan parsial atau lengkap. Jika replika atau instans komputasi tidak tersedia, komponen yang tersisa mungkin perlu menanggung lebih banyak beban untuk menangani beban yang sebelumnya ditangani oleh node yang rusak. Pertimbangkan provisi berlebih jika sistem Anda tidak dapat menskalakan dengan cukup cepat untuk menangani perubahan beban yang diharapkan.

Untuk informasi selengkapnya tentang cara merancang sistem yang dapat diskalakan dan elastis, lihat Rekomendasi untuk merancang strategi penskalaan yang andal.

Teknik penyebaran zero-downtime

Penyebaran dan perubahan sistem lainnya menimbulkan risiko waktu henti yang signifikan. Karena risiko waktu henti adalah tantangan untuk persyaratan ketersediaan tinggi, penting untuk menggunakan praktik penyebaran zero-downtime untuk membuat pembaruan dan perubahan konfigurasi tanpa waktu henti yang diperlukan.

Teknik penyebaran zero-downtime dapat mencakup:

• Memperbarui subset sumber daya Anda pada satu waktu.
• Mengontrol jumlah lalu lintas yang mencapai penyebaran baru.
• Memantau dampak apa pun kepada pengguna atau sistem Anda.
• Memulihkan masalah dengan cepat, seperti dengan menggulirkan kembali ke penyebaran yang diketahui baik sebelumnya.

Untuk mempelajari selengkapnya tentang teknik penyebaran zero-downtime, lihat Praktik penyebaran yang aman.

Azure sendiri menggunakan pendekatan penyebaran zero-downtime untuk layanan kami sendiri. Saat membuat aplikasi sendiri, Anda dapat mengadopsi penyebaran zero-downtime melalui berbagai pendekatan, seperti:

• Azure Container Apps menyediakan beberapa revisi aplikasi Anda, yang dapat digunakan untuk mencapai penyebaran waktu henti nol.
• Azure Kubernetes Service (AKS) mendukung berbagai teknik penyebaran zero-downtime.

Meskipun penyebaran waktu henti nol sering dikaitkan dengan penyebaran aplikasi, penyebaran tersebut juga harus digunakan untuk perubahan konfigurasi. Berikut adalah beberapa cara Anda dapat menerapkan perubahan konfigurasi dengan aman:

• Azure Storage memungkinkan Anda mengubah kunci akses akun penyimpanan dalam beberapa tahap, yang mencegah waktu henti selama operasi rotasi kunci.
• Azure App Configuration menyediakan bendera fitur, rekam jepret, dan kemampuan lainnya untuk membantu Anda mengontrol bagaimana perubahan konfigurasi diterapkan.

Jika Anda memutuskan untuk tidak menerapkan penyebaran waktu henti nol, pastikan Anda menentukan jendela pemeliharaan sehingga Anda dapat membuat perubahan sistem pada saat pengguna Mengharapkannya.

Pengujian otomatis

Penting untuk menguji kemampuan solusi Anda untuk menahan pemadaman dan kegagalan yang Anda anggap berada dalam cakupan ketersediaan tinggi. Banyak dari kegagalan ini dapat disimulasikan di lingkungan pengujian. Menguji kemampuan solusi Anda untuk secara otomatis mentolerir atau memulihkan dari berbagai jenis kesalahan disebut rekayasa chaos. Rekayasa chaos sangat penting untuk organisasi dewasa dengan standar yang ketat untuk KETERSEDIAAN TINGGI. Azure Chaos Studio adalah alat rekayasa chaos yang dapat mensimulasikan beberapa jenis kesalahan umum.

Untuk mempelajari selengkapnya, lihat Rekomendasi untuk merancang strategi pengujian keandalan.

Pemantauan dan Pemberitahuan

Pemantauan memungkinkan Anda mengetahui kesehatan sistem Anda, bahkan ketika mitigasi otomatis berlangsung. Pemantauan sangat penting untuk memahami bagaimana solusi Anda bertingkah laku, dan untuk mengawasi sinyal awal kegagalan seperti peningkatan tingkat kesalahan atau konsumsi sumber daya yang tinggi. Dengan pemberitahuan, Anda dapat secara proaktif menerima perubahan penting di lingkungan Anda.

Azure menyediakan berbagai kemampuan pemantauan dan pemberitahuan, termasuk yang berikut ini:

• Azure Monitor mengumpulkan log dan metrik dari sumber daya dan aplikasi Azure, dan dapat mengirim pemberitahuan dan menampilkan data di dasbor.
• Azure Monitor Application Insights menyediakan pemantauan terperinci aplikasi Anda.
• Azure Service Health dan Azure Resource Health memantau kesehatan platform Azure dan sumber daya Anda.
• Peristiwa Terjadwal menyarankan kapan pemeliharaan direncanakan untuk komputer virtual.

Untuk informasi selengkapnya, lihat Rekomendasi untuk merancang strategi pemantauan dan pemberitahuan yang andal.

Pemulihan dari bencana

Bencana adalah peristiwa besar yang berbeda, jarang, yang memiliki dampak yang lebih besar dan tahan lama daripada aplikasi dapat mengurangi melalui aspek ketersediaan tinggi dari desainnya. Contoh bencana meliputi:

• Bencana alam, seperti badai, gempa bumi, banjir, atau kebakaran.
• Kesalahan manusia yang mengakibatkan dampak besar, seperti menghapus data produksi secara tidak sengaja, atau firewall yang salah dikonfigurasi yang mengekspos data sensitif.
• Insiden keamanan utama, seperti penolakan layanan atau serangan ransomware yang menyebabkan kerusakan data, kehilangan data, atau pemadaman layanan.

Pemulihan bencana adalah tentang merencanakan bagaimana Anda merespons jenis situasi ini.

Persyaratan pemulihan bencana

Karena kelangkaan dan tingkat keparahan peristiwa bencana, perencanaan DR membawa harapan yang berbeda untuk respons Anda. Banyak organisasi menerima fakta bahwa, dalam skenario bencana, beberapa tingkat waktu henti atau kehilangan data tidak dapat ditolak. Paket DR lengkap harus menentukan persyaratan bisnis penting berikut untuk setiap alur:

• Tujuan Titik Pemulihan (RPO) adalah durasi maksimum kehilangan data yang dapat diterima jika terjadi bencana. RPO diukur dalam satuan waktu, seperti "30 menit data" atau "empat jam data."

• Tujuan Waktu Pemulihan (RTO) adalah durasi maksimum waktu henti yang dapat diterima jika terjadi bencana, di mana "waktu henti" ditentukan oleh spesifikasi Anda. RTO juga diukur dalam satuan waktu, seperti "delapan jam waktu henti."

Setiap komponen atau alur dalam beban kerja mungkin memiliki nilai RPO dan RTO individual. Periksa risiko skenario bencana dan strategi pemulihan potensial saat memutuskan persyaratan. Proses menentukan RPO dan RTO secara efektif menciptakan persyaratan DR untuk beban kerja Anda sebagai akibat dari masalah bisnis unik Anda (biaya, dampak, kehilangan data, dll.).

Rencana pemulihan bencana

Terlepas dari penyebab bencana, penting bagi Anda untuk membuat rencana DR yang terdefinisi dengan baik dan dapat diuji. Rencana itu akan digunakan sebagai bagian dari infrastruktur dan desain aplikasi untuk secara aktif mendukungnya. Anda dapat membuat beberapa paket DR untuk berbagai jenis situasi. Rencana DR sering mengandalkan kontrol proses dan intervensi manual.

DR bukan fitur otomatis Azure. Namun, banyak layanan menyediakan fitur dan kemampuan yang dapat Anda gunakan untuk mendukung strategi DR Anda. Anda harus meninjau panduan keandalan untuk setiap layanan Azure untuk memahami cara kerja layanan dan kemampuannya, lalu memetakan kemampuan tersebut ke paket DR Anda.

Bagian berikut mencantumkan beberapa elemen umum dari rencana pemulihan bencana, dan menjelaskan bagaimana Azure dapat membantu Anda mencapainya.

Failover dan failback

Beberapa rencana pemulihan bencana melibatkan penyediaan penyebaran sekunder di lokasi lain. Jika bencana memengaruhi penyebaran utama solusi, lalu lintas kemudian dapat di-failover ke situs lain. Failover membutuhkan perencanaan dan implementasi yang cermat. Azure menyediakan berbagai layanan untuk membantu failover, seperti:

• Azure Site Recovery menyediakan failover otomatis untuk lingkungan lokal dan solusi yang dihosting komputer virtual di Azure.
• Azure Front Door dan Azure Traffic Manager mendukung failover otomatis lalu lintas masuk antara berbagai penyebaran solusi Anda, seperti di berbagai wilayah.

Biasanya diperlukan beberapa waktu untuk proses failover untuk mendeteksi bahwa instans utama telah gagal dan beralih ke instans sekunder. Pastikan bahwa RTO beban kerja selaras dengan waktu failover.

Penting juga untuk mempertimbangkan failback, yang merupakan proses di mana Anda memulihkan operasi di wilayah utama setelah dipulihkan. Failback dapat menjadi kompleks untuk merencanakan dan mengimplementasikan. Misalnya, data di wilayah utama mungkin telah ditulis setelah failover dimulai. Anda harus membuat keputusan bisnis yang cermat tentang cara Anda menangani data tersebut.

Pencadangan

Pencadangan melibatkan pengambilan salinan data Anda dan menyimpannya dengan aman untuk jangka waktu yang ditentukan. Dengan cadangan, Anda dapat pulih dari bencana ketika failover otomatis ke replika lain tidak dimungkinkan, atau ketika kerusakan data telah terjadi.

Saat menggunakan cadangan sebagai bagian dari rencana pemulihan bencana, penting untuk mempertimbangkan hal berikut:

• Lokasi penyimpanan. Saat Anda menggunakan cadangan sebagai bagian dari rencana pemulihan bencana, cadangan tersebut harus disimpan secara terpisah ke data utama. Biasanya cadangan disimpan di wilayah Azure lain.

• Kehilangan data. Karena pencadangan biasanya jarang diambil, pemulihan cadangan biasanya melibatkan kehilangan data. Untuk alasan ini, pemulihan cadangan harus digunakan sebagai upaya terakhir dan rencana pemulihan bencana harus menentukan urutan langkah-langkah dan upaya pemulihan yang harus dilakukan sebelum memulihkan dari cadangan. Penting untuk memastikan bahwa RPO beban kerja selaras dengan interval cadangan.

• Waktu pemulihan. Pemulihan cadangan sering membutuhkan waktu, jadi sangat penting untuk menguji pencadangan dan proses pemulihan Anda untuk memverifikasi integritasnya dan memahami berapa lama proses pemulihan berlangsung. Pastikan RTO beban kerja memperhitungkan waktu yang diperlukan untuk memulihkan cadangan Anda.

Banyak data Azure dan layanan penyimpanan mendukung pencadangan, seperti berikut ini:

• Azure Backup menyediakan cadangan otomatis untuk disk komputer virtual, akun penyimpanan, AKS, dan berbagai sumber lainnya.
• Banyak layanan database Azure, termasuk Azure SQL Database dan Azure Cosmos DB, memiliki kemampuan pencadangan otomatis untuk database Anda.
• Azure Key Vault menyediakan fitur untuk mencadangkan rahasia, sertifikat, dan kunci Anda.

Penyebaran otomatis

Untuk menyebarkan dan mengonfigurasi sumber daya yang diperlukan dengan cepat jika terjadi bencana, gunakan aset Infrastructure as code (IaC), seperti file Bicep, templat ARM, atau file konfigurasi Terraform. Menggunakan IaC mengurangi waktu pemulihan Anda dan potensi kesalahan, dibandingkan dengan menyebarkan dan mengonfigurasi sumber daya secara manual.

Pengujian dan latihan

Sangat penting untuk memvalidasi dan menguji rencana DR Anda secara rutin, serta strategi keandalan Anda yang lebih luas. Sertakan semua proses manusia dalam latihan Anda, dan jangan hanya fokus pada proses teknis.

Jika Anda belum menguji proses pemulihan dalam simulasi bencana, Anda lebih mungkin menghadapi masalah besar saat menggunakannya dalam bencana aktual. Selain itu, dengan menguji rencana DR dan proses yang diperlukan, Anda dapat memvalidasi kelayakan RTO Anda.

Untuk mempelajari selengkapnya, lihat Rekomendasi untuk merancang strategi pengujian keandalan.

Konten terkait

• Gunakan panduan keandalan layanan Azure untuk memahami bagaimana setiap layanan Azure mendukung keandalan dalam desainnya, dan untuk mempelajari tentang kemampuan yang dapat Anda bangun ke dalam paket HA dan DR Anda.
• Gunakan pilar Azure Well-Architected Framework: Keandalan untuk mempelajari selengkapnya tentang cara merancang beban kerja yang andal di Azure.
• Gunakan perspektif Well-Architected Framework pada layanan Azure untuk mempelajari selengkapnya tentang cara mengonfigurasi setiap layanan Azure untuk memenuhi persyaratan Anda untuk keandalan dan di seluruh pilar lain dari Well-Architected Framework.
• Untuk mempelajari selengkapnya tentang perencanaan pemulihan bencana, lihat Rekomendasi untuk merancang strategi pemulihan bencana.