Rekomendasi untuk melakukan analisis mode kegagalan
Berlaku untuk rekomendasi daftar periksa Keandalan Azure Well-Architected Framework ini:
| RE:03 | Gunakan analisis mode kegagalan (FMA) untuk mengidentifikasi dan memprioritaskan potensi kegagalan dalam komponen solusi Anda. Lakukan FMA untuk membantu Anda menilai risiko dan efek dari setiap mode kegagalan. Tentukan bagaimana beban kerja merespons dan memulihkan. |
|---|
Panduan ini menjelaskan praktik terbaik untuk melakukan analisis mode kegagalan (FMA) untuk beban kerja Anda. FMA adalah praktik mengidentifikasi titik kegagalan potensial dalam beban kerja Anda dan alur terkait dan merencanakan tindakan mitigasi yang sesuai. Pada setiap langkah alur, Anda mengidentifikasi radius ledakan dari beberapa jenis kegagalan, yang membantu Anda merancang beban kerja baru atau merefaktor beban kerja yang ada untuk meminimalkan efek kegagalan yang meluas.
Tenet kunci FMA adalah bahwa kegagalan terjadi tidak peduli berapa banyak lapisan ketahanan yang Anda terapkan. Lingkungan yang lebih kompleks terekspos ke lebih banyak jenis kegagalan. Mengingat realitas ini, FMA memungkinkan Anda merancang beban kerja Anda untuk menahan sebagian besar jenis kegagalan dan pulih dengan anggun ketika kegagalan terjadi.
Jika Anda melewati FMA sama sekali atau melakukan analisis yang tidak lengkap, beban kerja Anda berisiko terhadap perilaku yang tidak diprediksi dan potensi pemadaman yang disebabkan oleh desain suboptimal.
Definisi
| Istilah | Definisi |
|---|---|
| Mode kegagalan | Jenis masalah yang dapat menyebabkan satu atau beberapa komponen beban kerja terdegradasi atau sangat terpengaruh ke titik tidak tersedia. |
| Mitigasi | Aktivitas yang telah Anda identifikasi untuk mengatasi masalah baik secara proaktif atau reaktif. |
| Detection | Infrastruktur, data, dan aplikasi Anda memantau dan memperingatkan proses dan prosedur. |
Strategi desain utama
Tinjau dan terapkan rekomendasi untuk mengidentifikasi alur. Diasumsikan bahwa Anda telah mengidentifikasi dan memprioritaskan alur pengguna dan sistem berdasarkan kekritisan.
Data yang telah Anda kumpulkan dan artefak yang telah Anda buat dalam pekerjaan memberi Anda deskripsi konkret tentang jalur data Anda yang terlibat di seluruh alur. Agar berhasil dalam pekerjaan FMA Anda, akurasi dan ketelitian dalam artefak Anda sangat penting.
Setelah menentukan alur penting, Anda dapat merencanakan komponen yang diperlukan. Selanjutnya, ikuti setiap alur langkah demi langkah untuk mengidentifikasi dependensi, termasuk layanan pihak ketiga dan titik potensi kegagalan, dan merencanakan strategi mitigasi Anda.
Mengurai beban kerja
Saat Anda berpindah dari ideasi ke desain, Anda perlu mengidentifikasi jenis komponen yang diperlukan untuk mendukung beban kerja Anda. Beban kerja Anda menentukan komponen yang diperlukan yang harus Anda rencanakan. Biasanya, Anda perlu merencanakan kontrol ingress, jaringan, komputasi, data, penyimpanan, layanan pendukung (seperti autentikasi, olahpesan, dan manajemen rahasia atau kunci), dan kontrol keluar. Pada tahap ini dalam pekerjaan desain Anda, Anda mungkin tidak tahu teknologi spesifik yang akan Anda sebarkan, sehingga desain Anda mungkin terlihat seperti contoh berikut.
Setelah membuat desain arsitektur awal, Anda dapat melapisi alur untuk mengidentifikasi komponen diskrit yang digunakan dalam alur tersebut dan membuat daftar atau diagram alur kerja yang menjelaskan alur dan komponennya. Untuk memahami kekritisan komponen, gunakan definisi kekritisan yang telah Anda tetapkan ke alur. Pertimbangkan efek kerusakan komponen pada alur Anda.
Mengidentifikasi dependensi
Identifikasi dependensi beban kerja Anda untuk melakukan analisis titik kegagalan tunggal Anda. Menguraikan beban kerja dan alur overlay memberikan wawasan tentang dependensi yang bersifat internal dan eksternal terhadap beban kerja.
Dependensi internal adalah komponen dalam cakupan beban kerja yang diperlukan agar beban kerja berfungsi. Dependensi internal umum termasuk API atau solusi manajemen rahasia/kunci seperti Azure Key Vault. Untuk dependensi ini, ambil data keandalan, seperti SLA ketersediaan dan batas penskalaan. Dependensi eksternal diperlukan komponen di luar cakupan beban kerja, seperti aplikasi lain atau layanan pihak ketiga. Dependensi eksternal yang khas mencakup solusi autentikasi, seperti ID Microsoft Entra, dan solusi konektivitas cloud, seperti Azure ExpressRoute.
Identifikasi dan dokumentasikan dependensi dalam beban kerja Anda, dan sertakan dalam artefak dokumentasi alur Anda.
Mengevaluasi titik kegagalan
Dalam alur penting beban kerja Anda, pertimbangkan setiap komponen dan tentukan bagaimana komponen tersebut, dan dependensinya, dapat dipengaruhi oleh mode kegagalan. Ingatlah bahwa ada banyak mode kegagalan yang perlu dipertimbangkan saat merencanakan ketahanan dan pemulihan. Satu komponen apa pun dapat dipengaruhi oleh lebih dari satu mode kegagalan pada waktu tertentu. Mode kegagalan ini meliputi:
Pemadaman regional. Seluruh wilayah Azure tidak tersedia.
Pemadaman zona ketersediaan. Zona ketersediaan Azure tidak tersedia.
Pemadaman layanan. Satu atau beberapa layanan Azure tidak tersedia.
Penolakan layanan terdistribusi (DDoS) atau serangan berbahaya lainnya.
Kesalahan konfigurasi aplikasi atau komponen.
Kesalahan operator.
Pemadaman pemeliharaan terencana.
Komponen kelebihan beban.
Analisis harus selalu dalam konteks alur yang coba Anda analisis, jadi pastikan untuk mendokumentasikan efek pada pengguna dan hasil yang diharapkan dari alur tersebut. Misalnya, jika Anda memiliki aplikasi e-niaga dan menganalisis alur pelanggan Anda, efek mode kegagalan tertentu pada satu atau beberapa komponen mungkin bahwa semua pelanggan tidak dapat menyelesaikan checkout.
Pertimbangkan kemungkinan setiap jenis mode kegagalan. Beberapa sangat tidak mungkin, seperti pemadaman multi-zona atau multi-wilayah, dan menambahkan perencanaan mitigasi di luar redundansi bukanlah penggunaan sumber daya dan waktu yang baik.
Mitigasi
Strategi mitigasi termasuk dalam dua kategori luas: membangun lebih banyak ketahanan dan merancang untuk performa yang terdegradasi.
Membangun lebih banyak ketahanan termasuk menambahkan redundansi ke komponen Anda, seperti infrastruktur, data, dan jaringan, dan memastikan bahwa desain aplikasi Anda mengikuti praktik terbaik untuk durabilitas, misalnya memecah aplikasi monolitik menjadi aplikasi terisolasi dan layanan mikro. Untuk informasi selengkapnya, lihat Rekomendasi redundansi dan Rekomendasi untuk pelestarian mandiri.
Untuk merancang performa yang terdegradasi, identifikasi potensi titik kegagalan yang mungkin menonaktifkan satu atau beberapa komponen alur Anda tetapi tidak sepenuhnya menonaktifkan alur tersebut. Untuk mempertahankan fungsionalitas alur end-to-end, Anda mungkin perlu mengalihkan satu atau beberapa langkah ke komponen lain atau menerima bahwa komponen yang gagal menjalankan fungsi, sehingga fungsi tidak lagi tersedia dalam pengalaman pengguna. Untuk kembali ke contoh aplikasi e-niaga, komponen yang gagal seperti layanan mikro dapat menyebabkan mesin rekomendasi Anda tidak tersedia, tetapi pelanggan masih dapat mencari produk dan menyelesaikan transaksi mereka.
Anda juga perlu merencanakan mitigasi sekeliling dependensi. Dependensi yang kuat memainkan peran penting dalam fungsi dan ketersediaan aplikasi. Jika mereka tidak ada atau mengalami kerusakan, mungkin ada efek yang signifikan. Tidak adanya dependensi yang lemah mungkin hanya memengaruhi fitur tertentu dan tidak memengaruhi ketersediaan keseluruhan. Perbedaan ini mencerminkan biaya untuk mempertahankan hubungan ketersediaan tinggi antara layanan dan dependensinya. Klasifikasikan dependensi sebagai kuat atau lemah untuk membantu Anda mengidentifikasi komponen mana yang penting untuk aplikasi.
Jika aplikasi memiliki dependensi kuat yang tidak dapat beroperasi tanpa, target ketersediaan dan pemulihan dependensi ini harus selaras dengan target aplikasi itu sendiri. Minimalkan dependensi untuk mencapai kontrol atas keandalan aplikasi. Untuk informasi selengkapnya, lihat Meminimalkan koordinasi antara layanan aplikasi untuk mencapai skalabilitas.
Jika siklus hidup aplikasi digabungkan erat dengan siklus hidup dependensinya, kelincahan operasional aplikasi mungkin terbatas, terutama untuk rilis baru.
Detection
Deteksi kegagalan sangat penting untuk memastikan bahwa Anda memiliki titik kegagalan yang diidentifikasi dengan benar dalam analisis Anda dan merencanakan strategi mitigasi Anda dengan benar. Deteksi dalam konteks ini berarti pemantauan infrastruktur, data, dan aplikasi Anda, dan pemberitahuan saat masalah muncul. Otomatiskan deteksi sebanyak mungkin, dan bangun redundansi ke dalam proses operasi Anda untuk memastikan bahwa pemberitahuan selalu tertangkap dan ditanggapi dengan cukup cepat untuk memenuhi persyaratan bisnis Anda. Untuk informasi selengkapnya, lihat Rekomendasi untuk pemantauan.
Hasil
Untuk hasil analisis Anda, buat sekumpulan dokumen yang secara efektif mengkomunikasikan temuan Anda, keputusan yang telah Anda buat relatif terhadap komponen dan mitigasi alur, dan efek kegagalan pada beban kerja Anda.
Dalam analisis Anda, prioritaskan mode kegagalan dan strategi mitigasi yang telah Anda identifikasi berdasarkan tingkat keparahan dan kemungkinan. Gunakan prioritas ini untuk memfokuskan dokumentasi Anda pada mode kegagalan yang umum dan cukup parah untuk menjamin menghabiskan waktu, upaya, dan sumber daya untuk merancang strategi mitigasi. Misalnya, mungkin ada beberapa mode kegagalan yang sangat jarang terjadi atau deteksi. Merancang strategi mitigasi di sekitarnya tidak sepadan dengan biayanya.
Lihat contoh tabel berikut untuk titik awal dokumentasi.
Selama latihan FMA awal Anda, dokumen yang Anda hasilkan sebagian besar akan menjadi perencanaan teoritis. Dokumen FMA harus ditinjau dan diperbarui secara berkala untuk memastikan bahwa dokumen tersebut tetap terbarui dengan beban kerja Anda. Pengujian chaos dan pengalaman dunia nyata akan membantu Anda memperbaiki analisis dari waktu ke waktu.
Fasilitasi Azure
Gunakan Azure Monitor dan Analitik Log untuk mendeteksi masalah dalam beban kerja Anda. Untuk wawasan lebih lanjut tentang masalah yang terkait dengan infrastruktur, aplikasi, dan database Anda, gunakan alat seperti Application Insights, Container Insights, Network Insights, VM Insights, dan SQL Insights.
Azure Chaos Studio adalah layanan terkelola yang menggunakan rekayasa chaos untuk membantu Anda mengukur, memahami, dan meningkatkan ketahanan aplikasi dan layanan cloud Anda.
Untuk informasi tentang menerapkan prinsip FMA ke layanan Azure umum, lihat Analisis mode kegagalan untuk aplikasi Azure.
Contoh
Tabel berikut ini memperlihatkan contoh FMA untuk situs web e-niaga yang dihosting di instans Azure App Service dengan database Azure SQL dan dihadirkan oleh Azure Front Door.
Alur pengguna: Masuk pengguna, pencarian produk, dan interaksi ke cart belanja
| Komponen | Risiko | Kecenderungan | Efek/Mitigasi/Catatan | Penghentian |
|---|---|---|---|---|
| Microsoft Entra ID | Pemadaman layanan | Kurang Penting | Pemadaman beban kerja penuh. Bergantung pada Microsoft untuk memulihkan. | Penuh |
| Microsoft Entra ID | Salah konfigurasi | Medium | Pengguna tidak dapat masuk. Tidak ada efek hilir. Staf dukungan melaporkan masalah konfigurasi ke tim identitas. | Tidak |
| Azure Front Door | Pemadaman layanan | Kurang Penting | Pemadaman penuh untuk pengguna eksternal. Bergantung pada Microsoft untuk memulihkan. | Hanya eksternal |
| Azure Front Door | Pemadaman regional | Sangat rendah | Efek minimal. Azure Front Door adalah layanan global, sehingga perutean lalu lintas global mengarahkan lalu lintas melalui wilayah Azure yang tidak berpengaruh. | Tidak |
| Azure Front Door | Salah konfigurasi | Medium | Kesalahan konfigurasi harus ditangkap selama penyebaran. Jika ini terjadi selama pembaruan konfigurasi, administrator harus mengembalikan perubahan. Pembaruan konfigurasi menyebabkan pemadaman eksternal singkat. | Hanya eksternal |
| Azure Front Door | Serangan DDoS | Medium | Potensi gangguan. Microsoft mengelola perlindungan DDoS (L3 dan L4) dan Azure Web Application Firewall memblokir sebagian besar ancaman. Potensi risiko efek dari serangan L7. | Potensi pemadaman parsial |
| Azure SQL | Pemadaman layanan | Kurang Penting | Pemadaman beban kerja penuh. Bergantung pada Microsoft untuk memulihkan. | Penuh |
| Azure SQL | Pemadaman regional | Sangat rendah | Grup failover otomatis gagal ke wilayah sekunder. Potensi pemadaman selama failover. Tujuan waktu pemulihan (RTO) dan tujuan titik pemulihan (RPO) yang akan ditentukan selama pengujian keandalan. | Potensi penuh |
| Azure SQL | Pemadaman zona ketersediaan | Kurang Penting | Tidak ada efek | Tidak |
| Azure SQL | Serangan berbahaya (injeksi) | Medium | Risiko minimal. Semua instans Azure SQL terikat jaringan virtual melalui titik akhir privat dan kelompok keamanan jaringan (NSG) menambahkan perlindungan jaringan intra-virtual lebih lanjut. | Potensi risiko rendah |
| App Service | Pemadaman layanan | Kurang Penting | Pemadaman beban kerja penuh. Bergantung pada Microsoft untuk memulihkan. | Penuh |
| App Service | Pemadaman regional | Sangat rendah | Efek minimal. Latensi untuk pengguna di wilayah yang diterapkan. Azure Front Door secara otomatis merutekan lalu lintas ke wilayah yang tidak terpengaruh. | Tidak |
| App Service | Pemadaman zona ketersediaan | Kurang Penting | Tidak ada efek. Layanan aplikasi telah disebarkan sebagai zona redundan. Tanpa redundansi zona, ada potensi efeknya. | Tidak |
| App Service | Serangan DDoS | Medium | Efek minimal. Lalu lintas masuk dilindungi oleh Azure Front Door dan Azure Web Application Firewall. | Tidak |
Tautan terkait
Daftar periksa keandalan
Lihat kumpulan rekomendasi lengkap.