Manajemen keberlangsungan bisnis di Azure
Azure mempertahankan salah satu program manajemen kelangsungan bisnis yang paling matang dan dihargai di industri ini. Tujuan dari kelangsungan bisnis di Azure adalah untuk membangun dan memajukan pemulihan dan ketahanan untuk semua layanan yang dapat dipulihkan secara independen, baik layanan yang dihadapi pelanggan (bagian dari penawaran Azure) atau layanan platform pendukung internal.
Dalam memahami kelangsungan bisnis, penting untuk dicatat bahwa banyak penawaran yang terdiri dari beberapa layanan. Di Azure, setiap layanan diidentifikasi secara statis melalui alat dan merupakan unit ukuran yang digunakan untuk privasi, keamanan, inventaris, manajemen kelangsungan bisnis risiko, dan fungsi lainnya. Untuk mengukur kemampuan layanan dengan tepat, terdapat tiga elemen orang, proses, dan teknologi yang disertakan untuk setiap layanan, apa pun jenisnya.
Contohnya:
- Jika ada proses bisnis berdasarkan orang, seperti staf atau tim dukungan, pengiriman layanan adalah hal yang mereka lakukan. Orang-orang menggunakan proses dan teknologi untuk menjalankan layanan.
- Jika ada teknologi sebagai layanan, seperti Azure Virtual Machines, pengiriman layanan adalah teknologinya beserta orang-orang dan proses yang mendukung operasinya.
Model tanggung jawab bersama
Banyak penawaran yang disediakan Azure mengharuskan Anda menyiapkan pemulihan bencana di beberapa wilayah dan bukan tanggung jawab Microsoft. Tidak semua layanan Azure secara otomatis mereplikasi data atau secara otomatis melakukan fall back dari wilayah yang gagal untuk direplikasi silang ke wilayah lain yang diaktifkan. Dalam kasus ini, Anda bertanggung jawab untuk mengonfigurasi pemulihan dan replikasi.
Microsoft memastikan bahwa infrastruktur dasar dan layanan platform tersedia. Tetapi dalam beberapa skenario, penggunaan menuntut Anda menduplikasi penyebaran dan penyimpanan dalam kapasitas multi-wilayah, jika Anda memilihnya. Contoh-contoh ini menggambarkan model tanggung jawab bersama. Ini adalah pilar mendasar dalam kelangsungan bisnis dan strategi pemulihan bencana Anda.
Pembagian tanggung jawab
Di pusat data lokal mana pun, Anda memiliki seluruh tumpukan. Saat Anda memindahkan aset ke cloud, beberapa tanggung jawab ditransfer ke Microsoft. Diagram berikut menggambarkan area dan pembagian tanggung jawab antara Anda dan Microsoft sesuai dengan jenis penyebarannya.
Salah satu contoh yang baik dari model tanggung jawab bersama adalah penyebaran mesin virtual. Jika Anda ingin menyiapkan replikasi lintas wilayah untuk ketahanan jika ada kegagalan wilayah, Anda harus menyebarkan sekumpulan komputer virtual duplikat di wilayah alternatif yang diaktifkan. Azure tidak secara otomatis mereplikasi layanan ini jika terjadi kegagalan. Anda bertanggung jawab untuk menyebarkan aset yang diperlukan. Anda harus memiliki proses untuk mengubah wilayah utama secara manual, atau Anda harus menggunakan manajer lalu lintas untuk mendeteksi dan melakukan failover secara otomatis.
Semua layanan pemulihan bencana yang diaktifkan pelanggan memiliki dokumentasi yang dapat dilihat publik untuk memberikan Anda panduan. Untuk contoh dokumentasi yang dapat dilihat publik untuk pemulihan bencana yang diaktifkan pelanggan, lihat Azure Data Lake Analytics.
Selengkapnya tentang model tanggung jawab bersama, lihat Pusat Kepercayaan Microsoft.
Kepatuhan kelangsungan bisnis: Tanggung jawab tingkat layanan
Setiap layanan diperlukan untuk melengkapi catatan Pemulihan Bencana Kelangsungan Bisnis di Azure Business Continuity Manager Tool. Pemilik layanan dapat menggunakan alat ini untuk bekerja dalam model federasi untuk melengkapi dan memasukkan persyaratan yang mencakup:
Properti layanan: Menentukan layanan dan cara mencapai pemulihan bencana dan ketahanan serta mengidentifikasi pihak yang bertanggung jawab untuk pemulihan bencana (untuk teknologi). Untuk detail tentang kepemilikan pemulihan, lihat diskusi tentang model tanggung jawab bersama di bagian dan diagram sebelumnya.
Analisis dampak bisnis: Analisis ini membantu pemilik layanan menentukan tujuan waktu pemulihan (RTO) dan tujuan titik pemulihan (RPO) berdasarkan kekritisan layanan di seluruh tabel dampak. Dampak operasional, hukum, peraturan, citra merek, dan keuangan digunakan sebagai sasaran untuk pemulihan.
Catatan
Microsoft tidak menerbitkan RTO atau RPO untuk layanan karena data ini hanya untuk pengukuran internal. Semua janji dan pengukuran pelanggan berbasis SLA karena mencakup rentang yang lebih luas dibandingkan RTO atau RPO, yang hanya berlaku dalam kerugian besar.
Dependensi: Setiap layanan memetakan dependensi (layanan lain) yang diperlukan untuk beroperasi tidak peduli seberapa pentingnya, dan dipetakan ke runtime, diperlukan hanya untuk pemulihan, atau keduanya. Jika ada dependensi penyimpanan, data lain dipetakan untuk menentukan apa yang disimpan, dan misalnya jika memerlukan salinan bayangan titik waktu.
Tenaga Kerja: Sebagaimana disebutkan dalam definisi layanan, penting untuk mengetahui lokasi dan jumlah tenaga kerja yang dapat mendukung layanan, memastikan tidak ada satu pun titik kegagalan, dan jika karyawan penting disebarkan untuk menghindari kegagalan dengan kohabitasi di satu lokasi.
Pemasok eksternal: Microsoft menyimpan daftar lengkap pemasok eksternal, dan pemasok yang dianggap penting diukur kemampuannya. Jika teridentifikasi oleh layanan sebagai sebuah dependensi, kemampuan pemasok dibandingkan dengan kebutuhan layanan untuk memastikan gangguan pihak ketiga tidak mengganggu layanan Azure.
Peringkat pemulihan: Peringkat ini unik untuk program Manajemen Kelangsungan Bisnis Azure. Peringkat ini mengukur beberapa elemen kunci untuk membuat skor ketahanan:
- Kesediaan untuk failover: Meskipun mungkin ada proses tertentu, itu mungkin bukan pilihan pertama untuk penghentian jangka pendek.
- Automasi failover.
- Automasi keputusan untuk failover.
Waktu yang paling andal dan tersingkat untuk failover adalah layanan yang otomatis dan tidak memerlukan keputusan manusia. Layanan otomatis menggunakan pemantauan heartbeat atau transaksi sintetis untuk menentukan layanan sedang tidak aktif dan untuk segera memulai perbaikan.
Rencana dan pengujian pemulihan: Azure mengharuskan setiap layanan memiliki rencana pemulihan terperinci dan menguji rencana tersebut seakan-akan layanan telah gagal karena gangguan bencana. Rencana pemulihan harus ditulis sehingga seseorang dengan keterampilan dan akses yang sama dapat menyelesaikan tugas. Rencana tertulis menghindari ketergantungan pada pakar materi pelajaran yang tersedia.
Pengujian dilakukan dengan beberapa cara, termasuk tes mandiri di lingkungan produksi atau dekat produksi, dan sebagai bagian dari latihan lintas wilayah penuh Azure di set wilayah kenari. Wilayah yang diaktifkan ini identik dengan wilayah produksi tetapi dapat dinonaktifkan tanpa memengaruhi layanan Anda. Pengujian dianggap terintegrasi karena semua layanan terpengaruh secara bersamaan.
Pengaktifan pelanggan: Saat Anda bertanggung jawab untuk menyiapkan pemulihan bencana, Azure diharuskan memiliki panduan dokumentasi yang menghadap publik. Untuk semua layanan tersebut, tautan diberikan ke dokumentasi dan detail tentang prosesnya.
Verifikasi kepatuhan kelangsungan bisnis Anda
Ketika suatu layanan telah menyelesaikan catatan manajemen kelangsungan bisnisnya, Anda harus menyerahkannya untuk persetujuan. Ini ditugaskan untuk praktisi manajemen kelangsungan bisnis berpengalaman yang meninjau seluruh catatan untuk kelengkapan dan kualitas. Jika catatan memenuhi semua persyaratan, maka itu disetujui. Jika tidak, catatan tersebut ditolak dengan permintaan untuk pengerjaan ulang. Proses ini memastikan bahwa kedua belah pihak setuju bahwa kepatuhan terhadap kelangsungan bisnis telah dipenuhi dan bahwa pekerjaan hanya dibuktikan oleh pemilik layanan. Audit internal dan tim kepatuhan Azure juga melakukan pengambilan sampel acak secara berkala untuk memastikan data terbaik sedang dikirimkan.
Pengujian layanan
Microsoft dan Azure melakukan pengujian ekstensif untuk pemulihan bencana dan untuk kesiapan zona ketersediaan. Layanan diuji sendiri dalam lingkungan produksi atau pra-produksi untuk menunjukkan pemulihan independen untuk layanan yang tidak bergantung pada failover platform utama.
Untuk memastikan layanan juga dapat pulih dalam skenario region-down yang sebenarnya, pengujian "pull-the-plug"-type dilakukan di lingkungan kenari yang sepenuhnya disebarkan wilayah yang cocok dengan produksi. Misalnya, kluster, rak, dan unit daya benar-benar dimatikan untuk menstimulasi kegagalan wilayah total.
Selama tes ini, Azure menggunakan proses produksi yang sama untuk deteksi, pemberitahuan, respons, dan pemulihan. Tidak ada seorang pun yang mengharapkan latihan, dan teknisi yang diandalkan untuk pemulihan adalah sumber daya rotasi panggilan normal. Pemilihan waktu ini menghindari ketergantungan pada para ahli materi pelajaran yang mungkin tidak ada dalam peristiwa yang sebenarnya.
Termasuk dalam pengujian ini adalah layanan di mana Anda bertanggung jawab untuk menyiapkan pemulihan bencana setelah dokumentasi yang menghadap publik Microsoft. Tim layanan membuat instans seperti pelanggan untuk menunjukkan bahwa pemulihan bencana yang memungkinkan pelanggan bekerja seperti yang diharapkan dan bahwa instruksi yang diberikan akurat.
Selengkapnya tentang sertifikasi, lihat Pusat Kepercayaan Microsoft dan bagian tentang kepatuhan.