Apa yang harus dilakukan selama gangguan layanan Azure

Di Microsoft, kami bekerja keras untuk memastikan bahwa layanan kami selalu tersedia untuk Anda saat Anda membutuhkannya. Namun, gangguan layanan yang tidak diencana terjadi. Artikel ini menjelaskan apa yang terjadi ketika mereka melakukannya.

Microsoft menyediakan Perjanjian Tingkat Layanan (SLA) untuk banyak layanannya sebagai komitmen untuk waktu aktif dan konektivitas. SLA untuk masing-masing layanan Azure dapat ditemukan di Perjanjian Tingkat Layanan Azure.

Memahami cakupan insiden

Ketika ada insiden, jika Anda memahami cakupan insiden tersebut, Anda dapat menentukan tindakan terbaik.

Untuk memahami cakupan insiden, ikuti langkah-langkah berikut:

1. Buka Azure Service Health, yang menyediakan:

   • Informasi tentang masalah atau peristiwa yang mungkin memengaruhi layanan Anda.

   • Pemberitahuan pembaruan insiden otomatis, sehingga Anda dapat diberi tahu tentang pembaruan status insiden apa pun secara otomatis. Saat Microsoft memahami cakupan insiden, kami memperbarui status insiden. Anda dapat mengonfigurasi pembaruan status ini untuk masuk ke grup tindakan Azure Monitor, yang dapat mengirim pemberitahuan ke berbagai tempat seperti alamat email atau ke sistem manajemen insiden Anda sendiri.

2. Jika Anda mengalami masalah saat mengakses portal Microsoft Azure, buka status Azure.

   Nota

   Status Azure hanya menunjukkan masalah yang tersebar luas yang memenuhi kriteria tertentu. Karena halaman Status Azure tidak mengetahui langganan dan penyewa mana yang Anda kelola, halaman tersebut tidak dapat memberikan tampilan yang akurat tentang masalah yang lebih kecil yang mungkin memengaruhi layanan Anda.

3. Jika ada masalah dengan halaman status, periksa postingan dari @AzureSupport di platform sosial X.

Insiden zona ketersediaan dan pusat data

Banyak masalah terbatas pada satu zona ketersediaan. Zona ketersediaan mewakili pusat data, atau grup pusat data, yang diisolasi dari zona ketersediaan lain di wilayah yang sama. Saat zona ketersediaan mengalami masalah, dampak yang Anda lihat bergantung pada cara layanan disebarkan:

• Layanan zonal yang disematkan ke zona ketersediaan yang terdampak mungkin akan terpengaruh.
• Layanan yang berlebihan di berbagai zona tidak mungkin terpengaruh. Anda tidak perlu mengambil tindakan remediasi apa pun untuk sumber daya zona-redundan.
• Layanan regional (non-zonal) mungkin terpengaruh karena dapat menggunakan zona ketersediaan yang terpengaruh.

Untuk mempelajari selengkapnya tentang dukungan zona ketersediaan di layanan Azure dan perbedaan antara layanan zona, redundan zona, dan regional (non-zonal), lihat Layanan Azure dengan dukungan zona ketersediaan.

Jika ada kekhawatiran dengan sumber daya zonal atau regional yang disebarkan di zona ketersediaan yang terpengaruh, pertimbangkan untuk memulai rencana kelangsungan bisnis dan pemulihan bencana (BC/DR) Anda.

Zona ketersediaan logis vs. fisik

Setiap langganan Azure melihat daftar zona ketersediaan yang berbeda. Zona logis yang digunakan oleh setiap langganan mungkin sesuai dengan zona fisik yang berbeda. Anda dapat memetakan antara zona logis dan zona fisik untuk mengonfirmasi sumber daya mana yang berjalan di zona ketersediaan fisik yang terpengaruh. Untuk informasi selengkapnya, lihat zona ketersediaan fisik dan logis.

Insiden di seluruh wilayah

Terkadang, masalah memengaruhi seluruh wilayah. Masalah di seluruh wilayah dapat terjadi ketika suatu wilayah tidak memiliki zona ketersediaan. Ketika insiden di seluruh wilayah terjadi, Anda mungkin perlu mempertimbangkan untuk memulai rencana pemulihan bencana Anda. Rencana Anda mungkin termasuk failover ke wilayah lain.

Memprioritaskan kelangsungan bisnis

Ketika dihadapkan dengan insiden, prioritas utamanya adalah menjaga operasi bisnis Anda tetap berjalan. Terlalu banyak fokus pada mengisolasi atau memperbaiki penyebab masalah dapat mengalihkan perhatian Anda dari memulihkan operasi solusi Anda dan mempertahankan kelangsungan bisnis.

Faktor-faktor berikut menyajikan situasi di mana Anda tidak perlu melakukan apa pun untuk menjaga kelangsungan bisnis:

• Dampak aktual dari masalah pada sumber daya produksi Anda, dan pada pengguna atau beban kerja Anda. Misalnya, masalah yang terjadi di luar jam kerja standar mungkin tidak mengharuskan Anda untuk segera melakukan apa pun.

• Ruang lingkup insiden. Untuk masalah yang diisolasi ke satu zona ketersediaan, Anda mungkin tidak perlu melakukan apa pun jika Anda menggunakan sumber daya zona redundan atau jika sumber daya yang Anda gunakan berada di zona ketersediaan fisik yang tidak terpengaruh.

• Perkiraan waktu resolusi, jika tersedia. Microsoft berusaha untuk memberikan garis waktu yang jelas untuk pemulihan sesegera mungkin. Jika prosedur pemulihan Anda membutuhkan waktu yang signifikan untuk beroperasi, pertimbangkan apakah masalah diharapkan diselesaikan pada saat selesai.

• Tujuan tingkat layanan (SLO) yang ditetapkan dengan pengguna dari beban kerja yang terkena dampak, jika memang ada. SLO ada untuk memandu pengambilan keputusan dalam situasi semacam ini. Misalnya, dalam beberapa situasi, Anda mungkin dapat beralih ke operasi manual hingga layanan Anda pulih, dan hal ini mungkin tercermin dalam SLO sistem Anda. Untuk mempelajari selengkapnya tentang SCO dan cara menentukannya, lihat Rekomendasi untuk menentukan target keandalan di Azure Well-Architected Framework.

Namun, jika kelangsungan bisnis memerlukan beberapa bentuk tindakan, dan Anda memiliki rencana pemulihan bencana, maka langkah Anda selanjutnya adalah mempertimbangkan apakah akan memulai rencana tersebut.

Pertimbangkan rencana pemulihan bencana Anda

Rencana pemulihan bencana menjelaskan apa yang Anda harapkan untuk dilakukan jika terjadi insiden besar. Rencana pemulihan bencana umumnya mencakup tindakan seperti berikut:

• Untuk pemadaman terbatas dalam zona ketersediaan, perluas sumber daya jika Anda bisa.
• Untuk pemadaman zona ketersediaan saat Anda menggunakan layanan zonal, alihkan ke zona ketersediaan lainnya dan teruskan operasi di sana.
• Untuk pemadaman zona ketersediaan saat Anda menggunakan layanan zona redundan, Anda mungkin tidak perlu melakukan apa pun. Jika Anda mengamati masalah kinerja, pertimbangkan untuk memperluas sumber daya Anda sehingga instans di zona yang tersisa dapat memproses masuknya lalu lintas yang mereka terima.
• Untuk pemadaman regional, alihkan layanan ke wilayah lain dan lakukan failover (beralih cadangan).

Penting

Jangan mengambil tindakan apa pun tanpa memikirkannya. Keputusan terburu-buru terkadang dapat memperburuk keadaan. Jika Anda telah mengembangkan rencana pemulihan bencana yang mencakup skenario, biasanya lebih baik menggunakannya alih-alih membuat rencana saat ini.

Failover bisa menjadi proses yang kompleks. Anda hanya boleh memicu failover ketika Anda dapat membenarkan biaya dan risiko. Dalam beberapa situasi, hal ini dapat mengakibatkan hilangnya data, seperti jika perubahan terbaru tidak direplikasi antar wilayah sebelum waktu henti dimulai. Anda juga mungkin mengalami waktu henti, terutama jika Anda perlu mengalihkan lalu lintas ke penyebaran di wilayah yang berbeda. Bergantung pada cara solusi Anda dirancang, Anda mungkin perlu memperbarui catatan DNS dan menunggunya disebarluaskan.

Failover yang dimulai oleh Microsoft

Beberapa layanan Azure secara otomatis melakukan failover ke wilayah alternatif selama insiden. Microsoft mengelola proses failover untuk layanan tersebut. Namun, failover yang dilakukan oleh Microsoft biasanya dilakukan sebagai upaya terakhir dan setelah waktu yang cukup lama telah dihabiskan untuk upaya pemulihan. Secara umum, kebijakan Microsoft adalah meminimalkan kehilangan data meskipun itu berarti waktu pemulihan yang lebih lama. Jangan hanya bergantung pada failover yang diprakarsai oleh Microsoft untuk solusi Anda sendiri, terutama jika Anda perlu meminimalkan waktu pemulihan. Jika memungkinkan, gunakan failover yang dipicu oleh pelanggan untuk layanan seperti Azure Storage.

Dukungan Azure

Jika insiden layanan sudah dikomunikasikan di Azure Service Health, maka semua informasi terbaru disediakan di sana, dan tidak perlu membuka permintaan dukungan.

Namun, Anda mungkin mempertimbangkan untuk membuka kasus dukungan saat:

• Anda melihat masalah yang tidak tercakup dalam deskripsi insiden di Azure Service Health.

• Anda memerlukan bantuan dari Microsoft sebagai bagian dari upaya pemulihan Anda.

  Petunjuk / Saran

  Jika Anda terpengaruh oleh gangguan layanan, Anda akan dapat mengajukan tiket dukungan gratis hingga 72 jam setelah masalah dimitigasi untuk membantu langkah-langkah apa pun yang mungkin perlu Anda ambil untuk pemulihan.

Saat membuka kasus dukungan, jelaskan dengan jelas sumber daya yang terpengaruh dan dampak masalah. Tentukan ID langganan Azure dan wilayah yang mengalami masalah. Tetapkan tingkat keparahan kasus dukungan berdasarkan dampak terhadap bisnis Anda. Ketahuilah bahwa banyak pelanggan mungkin secara reaktif menghubungi dukungan Azure selama gangguan layanan Azure di luar kondisi yang diuraikan ini. Beban tambahan pada sumber daya dukungan Azure ini sayangnya dapat menunda memenuhi kebutuhan dukungan Anda.

Setelah insiden

1. Untuk memahami apa yang dipelajari Microsoft dari insiden tersebut, baca Post Incident Review (PIR) dari panel Riwayat kesehatan Azure Service Health, atau melalui pemberitahuan Service Health yang dikonfigurasi pelanggan. Insiden yang berbeda mungkin menerima jenis PIR yang berbeda. PIR awal biasanya diterbitkan beberapa hari setelah insiden, dan PIR yang lebih komprehensif mengikuti beberapa minggu kemudian.

2. Untuk insiden utama yang tercantum di halaman status publik kami, bergabunglah dengan livestream Azure Incident Retrospective untuk mendapatkan jawaban atas pertanyaan apa pun, atau tonton rekaman.

3. Jika Anda merasa memenuhi syarat untuk kredit SLA, buat permintaan dukungan baru dengan jenis masalah "Permintaan Pengembalian Dana" - dan sertakan ID Pelacakan insiden.

4. Pertimbangkan apa yang dapat Anda pelajari dari insiden untuk meningkatkan ketahanan dan proses Anda sendiri. Pertimbangkan pertanyaan seperti:

   • Seberapa baik rencana pemulihan bencana Anda bekerja? Apakah ada perbaikan yang bisa Anda lakukan? Untuk informasi selengkapnya, lihat panduan Azure Well-Architected Framework tentang strategi pemulihan bencana.

   • Apakah respons Anda terhadap insiden sesuai dengan tingkat keparahannya? Jika tidak, apakah ada cara Anda dapat mendapatkan informasi yang lebih baik dan membuat keputusan yang lebih baik tentang apa yang harus dilakukan?

   • Apakah ada panduan keandalan layanan Azure untuk layanan yang Anda gunakan? Panduan keandalan memberikan informasi tentang berapa banyak layanan Azure yang dapat dikonfigurasi untuk memenuhi persyaratan ketahanan Anda.

   • Apakah ada kompromi desain yang dapat Anda buat untuk meningkatkan resiliensi Anda di masa depan untuk masalah seperti ini? Untuk informasi selengkapnya, lihat pilar keandalan Azure Well-Architected Framework.

   • Apakah SLO atau SLA yang ditawarkan kepada pengguna Anda masih sesuai sekarang setelah Anda mengalami pemadaman yang tidak terencana ini? Sekarang adalah saat yang tepat untuk mengunjungi kembali komitmen yang Anda buat ke basis pengguna Anda untuk menyelaraskan harapan dengan apa yang Anda pelajari dari insiden ini.

   • Haruskah Anda mengonfigurasi pemberitahuan Azure Service Health untuk diberi tahu secara otomatis tentang insiden di masa mendatang?

5. Jika Anda memiliki umpan balik tentang bagaimana kami dapat meningkatkan respons insiden kami, beri tahu kami melalui perwakilan Microsoft yang ditetapkan, atau melalui situs umpan balik Azure.