Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

# Strategi mitigasi umum
<a name="mitigation-strategies"></a>

Untuk memulai, pikirkan tentang menggunakan mitigasi *pencegahan* untuk mencegah mode kegagalan memengaruhi cerita pengguna. Maka Anda harus memikirkan mitigasi *korektif*. Mitigasi korektif membantu sistem menyembuhkan diri sendiri atau beradaptasi dengan kondisi yang berubah. Berikut adalah daftar mitigasi umum untuk setiap kategori kegagalan yang selaras dengan properti ketahanan.


| 
| 
| **Kategori kegagalan** | **Sifat ketahanan yang diinginkan** | **Mitigasi** | 
| --- |--- |--- |
| Titik kegagalan tunggal (SPOFs) | Redundansi dan toleransi kesalahan |   Menerapkan [redundansi](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/availability-with-redundancy.html) ―misalnya, dengan menggunakan beberapa EC2 instance di belakang Elastic Load Balancing (ELB).   Hapus dependensi pada [bidang kontrol layanan AWS global dan ambil dependensi hanya pada pesawat](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/aws-service-types.html#global-services) data layanan global.   Gunakan [degradasi yang anggun](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_mitigate_interaction_failure_graceful_degradation.html) saat sumber daya tidak tersedia, sehingga sistem Anda stabil secara statis hingga satu titik kegagalan.   | 
| Beban berlebihan | Kapasitas yang cukup |   [https://aws.amazon.com/autoscaling/](https://aws.amazon.com/autoscaling/)   Anda juga harus mempertimbangkan rencana kapasitas Anda dan memikirkan batas kapasitas dan penskalaan future, baik yang terkait dengan sumber daya AWS maupun batasan dalam sistem Anda, yang mungkin Anda capai.   | 
| Latensi berlebihan | Output tepat waktu |   Terapkan [batas waktu](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/) yang dikonfigurasi dengan tepat atau batas waktu adaptif (mengubah nilai batas waktu berdasarkan kondisi latensi saat ini dan yang diprediksi untuk berpotensi memungkinkan ketergantungan yang lambat membuat kemajuan alih-alih menyerah pada permintaan lambat).   [https://aws.amazon.com/builders-library/caching-challenges-and-strategies](https://aws.amazon.com/builders-library/caching-challenges-and-strategies)   | 
| Kesalahan konfigurasi dan bug | Output yang benar |   [Cara utama untuk menangkap kesalahan fungsional berulang dalam perangkat lunak adalah pengujian ketat melalui mekanisme seperti [analisis statis](https://en.wikipedia.org/wiki/Static_program_analysis), [pengujian unit, uji integrasi, uji](https://en.wikipedia.org/wiki/Unit_testing)[regresi, uji](https://en.wikipedia.org/wiki/Integration_testing)[[beban](https://docs.aws.amazon.com/prescriptive-guidance/latest/load-testing/welcome.html), dan pengujian](https://en.wikipedia.org/wiki/Regression_testing) ketahanan.](https://aws.amazon.com/blogs/architecture/chaos-engineering-in-the-cloud/)   Menerapkan strategi seperti [infrastruktur sebagai kode (IAc)](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/infrastructure-as-code.html) dan [otomatisasi integrasi berkelanjutan dan pengiriman berkelanjutan (CI/CD)](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments) untuk membantu mengurangi ancaman kesalahan konfigurasi.   [Gunakan teknik penerapan seperti [one-box](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/), [canary deployment, fraksional deployment](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/canary-deployments.html) yang selaras dengan batas isolasi kesalahan, atau penerapan biru/hijau untuk mengurangi kesalahan konfigurasi dan bug.](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/blue-green-deployments.html)   | 
| Nasib bersama | Isolasi kesalahan |   Terapkan [toleransi kesalahan](https://aws.amazon.com/builders-library/minimizing-correlated-failures-in-distributed-systems) di sistem Anda dan gunakan batas isolasi kesalahan logis dan fisik seperti beberapa cluster komputasi atau kontainer, beberapa akun AWS, beberapa prinsip AWS Identity and Access Management (IAM), beberapa Availability Zone, dan mungkin beberapa. Wilayah AWS   Teknik seperti [arsitektur berbasis sel](https://youtu.be/swQbA4zub20) dan [sharding shuffle](https://aws.amazon.com/builders-library/workload-isolation-using-shuffle-sharding) juga dapat meningkatkan isolasi kesalahan.   Pertimbangkan pola seperti [kopling longgar](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_prevent_interaction_failure_loosely_coupled_system.html) dan [degradasi yang anggun](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_mitigate_interaction_failure_graceful_degradation.html) untuk mencegah kegagalan berjenjang. Saat memprioritaskan cerita pengguna, Anda juga dapat menggunakan prioritas tersebut untuk membedakan antara cerita pengguna yang penting untuk fungsi bisnis utama dan cerita pengguna yang dapat terdegradasi dengan anggun. Misalnya, di situs e-commerce, Anda tidak ingin penurunan widget promosi di situs web memengaruhi kemampuan memproses pesanan baru.   | 

Meskipun beberapa mitigasi ini memerlukan upaya minimal untuk diterapkan, yang lain (seperti mengadopsi arsitektur berbasis sel untuk isolasi kesalahan yang dapat diprediksi dan kegagalan nasib bersama yang minimal) dapat memerlukan desain ulang seluruh beban kerja dan bukan hanya komponen cerita pengguna tertentu. Seperti yang telah dibahas sebelumnya, penting untuk mempertimbangkan kemungkinan dan dampak mode kegagalan terhadap trade-off yang Anda lakukan untuk menguranginya.

Selain teknik mitigasi yang berlaku untuk setiap kategori mode kegagalan, Anda harus memikirkan mitigasi yang diperlukan untuk pemulihan cerita pengguna atau seluruh sistem. Misalnya, kegagalan dapat menghentikan alur kerja dan mencegah data ditulis ke tujuan yang dituju. Dalam hal ini, Anda mungkin memerlukan perkakas operasional untuk menggerakkan ulang alur kerja atau memperbaiki data secara manual. Anda mungkin juga harus membangun mekanisme checkpointing ke dalam beban kerja Anda untuk membantu mencegah kehilangan data saat terjadi kegagalan. Atau Anda mungkin harus membuat kabel andon untuk menjeda alur kerja dan berhenti menerima pekerjaan baru untuk mencegah kerusakan lebih lanjut. Dalam kasus ini, Anda harus memikirkan alat operasional dan pagar pembatas yang Anda butuhkan.

Akhirnya, Anda harus selalu berasumsi bahwa manusia akan membuat kesalahan saat Anda mengembangkan strategi mitigasi Anda. Meskipun DevOps praktik modern berusaha untuk mengotomatiskan operasi, manusia masih harus berinteraksi dengan beban kerja Anda karena berbagai alasan. Tindakan manusia yang salah dapat menyebabkan kegagalan di salah satu kategori SEEMS, seperti menghapus terlalu banyak node selama pemeliharaan dan menyebabkan kelebihan beban, atau salah menyetel flag fitur. Skenario ini benar-benar kegagalan dalam pagar pembatas pencegahan. Analisis akar penyebab tidak boleh berakhir dengan kesimpulan bahwa “manusia membuat kesalahan.” Sebaliknya, itu harus membahas alasan mengapa kesalahan mungkin terjadi sejak awal. Oleh karena itu, strategi mitigasi Anda harus mempertimbangkan bagaimana operator manusia dapat berinteraksi dengan komponen beban kerja dan cara mencegah atau meminimalkan dampak dari kesalahan operator manusia melalui pagar pembatas keselamatan.