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 potensi titik kegagalan dalam beban kerja Anda dan alur terkait serta 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.
Prinsip utama FMA adalah bahwa kegagalan terjadi tidak peduli berapa banyak lapisan ketahanan yang Anda terapkan. Lingkungan yang lebih kompleks terpapar lebih banyak jenis kegagalan. Mengingat realitas ini, FMA memungkinkan Anda merancang beban kerja untuk menahan sebagian besar jenis kegagalan dan pulih dengan baik ketika kegagalan terjadi.
Jika Anda melewati FMA sama sekali atau melakukan analisis yang tidak lengkap, beban kerja Anda berisiko mengalami 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 hingga tidak tersedia. |
| Mitigasi | Aktivitas yang telah Anda identifikasi untuk mengatasi masalah baik secara proaktif maupun reaktif. |
| Deteksi | Infrastruktur, data, dan pemantauan aplikasi Serta proses dan prosedur pemberitahuan Anda. |
Strategi desain utama
Prasyarat
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.
Pendekatan FMA
Setelah menentukan alur kritis, 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 internal dan eksternal terhadap beban kerja.
Dependensi internal adalah komponen dalam cakupan beban kerja yang diperlukan agar beban kerja berfungsi. Dependensi internal yang umum mencakup 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 Microsoft Entra ID, dan solusi konektivitas cloud, seperti Azure ExpressRoute.
Identifikasi dan dokumentasikan dependensi dalam beban kerja Anda, dan sertakan dalam artefak dokumentasi alur Anda.
Titik kegagalan
Dalam alur penting beban kerja Anda, pertimbangkan setiap komponen dan tentukan bagaimana komponen tersebut, dan dependensinya, mungkin 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, 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 dan layanan mikro yang terisolasi. Untuk informasi selengkapnya, lihat Rekomendasi untuk redundansi dan Rekomendasi untuk pemeliharaan 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. Mengklasifikasikan dependensi sebagai kuat atau lemah untuk membantu Anda mengidentifikasi komponen mana yang penting untuk aplikasi.
Jika aplikasi memiliki dependensi kuat yang tidak dapat beroperasi tanpanya, 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.
Deteksi
Deteksi kegagalan sangat penting untuk memastikan bahwa Anda telah mengidentifikasi titik kegagalan 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 di sekitar. Misalnya, mungkin ada beberapa mode kegagalan yang sangat jarang terjadi atau deteksi. Merancang strategi mitigasi di sekitarnya tidak sebanding dengan biayanya.
Lihat tabel contoh 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 diperbarui dengan beban kerja Anda. Pengujian kekacauan dan pengalaman dunia nyata akan membantu Anda menyempurnakan analisis Anda 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 pada instans Azure App Service dengan database Azure SQL dan di depan 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 | Rendah | Pemadaman beban kerja penuh. Bergantung pada Microsoft untuk memulihkan. | Data |
| Microsoft Entra ID | Salah konfigurasi | Medium | Pengguna tidak dapat masuk. Tidak ada efek hilir. Staf dukungan melaporkan masalah konfigurasi ke tim identitas. | Tidak ada |
| Azure Front Door | Pemadaman layanan | Rendah | 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 terpengaruh. | Tidak ada |
| 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 | Rendah | Pemadaman beban kerja penuh. Bergantung pada Microsoft untuk memulihkan. | Data |
| 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 | Rendah | Tidak ada efek | Tidak ada |
| 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 | Rendah | Pemadaman beban kerja penuh. Bergantung pada Microsoft untuk memulihkan. | Data |
| App Service | Pemadaman regional | Sangat rendah | Efek minimal. Latensi untuk pengguna di wilayah yang diberlakukan. Azure Front Door secara otomatis merutekan lalu lintas ke wilayah yang tidak terpengaruh. | Tidak ada |
| App Service | Pemadaman zona ketersediaan | Rendah | Tidak berpengaruh. Layanan aplikasi telah disebarkan sebagai zona redundan. Tanpa redundansi zona, ada potensi efeknya. | Tidak ada |
| App Service | Serangan DDoS | Medium | Efek minimal. Lalu lintas masuk dilindungi oleh Azure Front Door dan Azure Web Application Firewall. | Tidak ada |
Tautan terkait
Daftar periksa keandalan
Lihat kumpulan rekomendasi lengkap.
Saran dan Komentar
Segera hadir: Sepanjang tahun 2024 kami akan menghentikan penggunaan GitHub Issues sebagai mekanisme umpan balik untuk konten dan menggantinya dengan sistem umpan balik baru. Untuk mengetahui informasi selengkapnya, lihat: https://aka.ms/ContentUserFeedback.
Kirim dan lihat umpan balik untuk