# REL 12 Bagaimana cara menguji keandalan?
Setelah Anda mendesain beban kerja Anda agar tangguh terhadap tekanan produksi, pengujian adalah satu-satunya cara untuk memastikannya akan beroperasi sesuai desain, dan memberikan ketangguhan yang Anda harapkan.
**Topics**
+ [REL12-BP01 Menggunakan buku pedoman untuk menyelidiki kegagalan](rel_testing_resiliency_playbook_resiliency.md)
+ [REL12-BP02 Menjalankan analisis setelah insiden](rel_testing_resiliency_rca_resiliency.md)
+ [REL12-BP03 Menguji persyaratan fungsional](rel_testing_resiliency_test_functional.md)
+ [REL12-BP04 Menguji persyaratan penskalaan dan kinerja](rel_testing_resiliency_test_non_functional.md)
+ [REL12-BP05 Menguji ketahanan menggunakan chaos engineering](rel_testing_resiliency_failure_injection_resiliency.md)
+ [REL12-BP06 Mengadakan game day secara rutin](rel_testing_resiliency_game_days_resiliency.md)
# REL12-BP01 Menggunakan buku pedoman untuk menyelidiki kegagalan
Dokumentasikan proses penyelidikan di buku pedoman agar dapat memberikan respons yang cepat dan konsisten terhadap skenario kegagalan yang tidak benar-benar dipahami. Buku pedoman adalah langkah-langkah yang telah ditetapkan di awal untuk mengidentifikasi faktor yang menyebabkan skenario kegagalan. Hasil dari langkah proses apa pun digunakan untuk menentukan langkah berikutnya yang akan dilakukan sampai masalah diidentifikasi atau dieskalasi.
Buku pedoman adalah perencanaan proaktif yang harus Anda lakukan, agar Anda dapat mengambil tindakan reaktif secara efektif. Ketika skenario kegagalan yang tidak tercakup dalam buku pedoman dialami di lingkungan produksi, tangani masalah terlebih dahulu (padamkan api). Lalu lihat kembali langkah-langkah yang telah Anda ambil untuk mengatasi masalah tersebut dan gunakan untuk menambahkan entri baru dalam buku pedoman.
Ingat bahwa buku pedoman digunakan untuk merespons insiden tertentu, sedangkan runbook digunakan untuk mencapai hasil tertentu. Sering kali, runbook digunakan untuk untuk aktivitas rutin, dan buku pedoman digunakan untuk merespons peristiwa nonrutin.
**Antipola umum:**
+ Berencana untuk melakukan deployment beban kerja tanpa mengetahui proses untuk mendiagnosis masalah atau merespons insiden.
+ Keputusan yang tidak direncanakan tentang sistem mana saja yang dikumpulkan log dan metriknya saat menyelidiki peristiwa.
+ Tidak mempertahankan metrik dan peristiwa cukup lama agar dapat mengambil data.
**Manfaat menjalankan praktik terbaik ini:** Pencatatan runbook memastikan prosedur dapat diikuti secara konsisten. Kodifikasi runbook membatasi munculnya kesalahan dari aktivitas manual. Buku pedoman otomatis dapat menghemat waktu respons peristiwa dengan menghilangkan keharusan campur tangan anggota tim atau memberikan informasi tambahan ketika campur tangan mereka dimulai.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Tinggi
## Panduan implementasi
+ Gunakan buku pedoman untuk mengidentifikasi masalah. Buku pedoman adalah proses yang didokumentasikan untuk menyelidiki masalah. Dokumentasikan proses penyelidikan di buku pedoman agar dapat memberikan respons yang cepat dan konsisten terhadap skenario kegagalan. Buku pedoman harus memuat informasi dan panduan yang dapat digunakan oleh orang yang cukup terampil untuk mengumpulkan informasi, mengidentifikasi potensi sumber kegagalan, mengisolasi kesalahan, dan menentukan faktor penyebabnya (lakukan analisis pascainsiden).
+ Implementasikan buku pedoman sebagai kode. Jalankan operasi sebagai kode dengan membuat skrip buku pedoman Anda untuk memastikan konsistensi dan mengurangi kesalahan yang disebabkan proses manual. Buku pedoman dapat terdiri dari beberapa skrip sesuai dengan banyaknya langkah yang diperlukan untuk mengidentifikasi faktor penyebab masalah. Aktivitas runbook dapat dipicu atau dijalankan sebagai bagian dari aktivitas buku pedoman, atau mempercepat eksekusi buku pedoman untuk merespons peristiwa yang teridentifikasi.
+ [Otomatiskan buku pedoman operasional Anda dengan AWS Systems Manager](https://aws.amazon.com/about-aws/whats-new/2019/11/automate-your-operational-playbooks-with-aws-systems-manager/)
+ [AWS Systems Manager Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html)
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [Apa itu AWS Lambda?](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)
+ [Apa Itu Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Menggunakan Alarm Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
## Sumber daya
**Dokumen terkait:**
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [AWS Systems Manager Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html)
+ [Otomatiskan buku pedoman operasional Anda dengan AWS Systems Manager](https://aws.amazon.com/about-aws/whats-new/2019/11/automate-your-operational-playbooks-with-aws-systems-manager/)
+ [Menggunakan Alarm Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Menggunakan Canary (Amazon CloudWatch Synthetics)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [Apa Itu Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Apa itu AWS Lambda?](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)
**Contoh terkait:**
+ [Mengotomatiskan operasi dengan Buku Pedoman dan Runbook](https://wellarchitectedlabs.com/operational-excellence/200_labs/200_automating_operations_with_playbooks_and_runbooks/)
# REL12-BP02 Menjalankan analisis setelah insiden
Tinjau peristiwa yang memengaruhi pelanggan, dan identifikasi faktor yang berkontribusi serta tindakan pencegahannya. Gunakan informasi ini untuk mengembangkan mitigasi guna meminimalkan atau mencegah kemungkinan terjadi lagi. Kembangkan prosedur untuk respons efektif dan cepat. Komunikasikan faktor yang berkontribusi dan tindakan koreksi yang diperlukan, yang disesuaikan dengan audiens target. Miliki metode untuk mengomunikasikan penyebab ini ke personel lain sebagaimana yang diperlukan.
Menilai alasan mengapa pengujian yang ada tidak dapat menemukan masalahnya. Menambahkan pengujian untuk kasus ini jika pengujian belum ada.
**Antipola umum:**
+ Menemukan faktor-faktor yang berkontribusi, tetapi tidak terus mencari lebih dalam untuk masalah potensial dan pendekatan lainnya untuk memitigasi.
+ Hanya mengidentifikasi penyebab kesalahan manusia, dan tidak memberikan pelatihan atau otomatisasi apa pun yang dapat mencegah kesalahan manusia.
**Manfaat menerapkan praktik terbaik ini:** Dengan melakukan analisis setelah insiden dan membagikan hasilnya, beban kerja lain akan dapat memitigasi risiko jika beban kerja sudah mengimplementasikan faktor yang berkontribusi yang sama, sehingga mitigasi atau pemulihan otomatis dapat diimplementasikan sebelum insiden terjadi.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Tinggi
## Panduan implementasi
+ Tetapkan standar untuk analisis setelah insiden. Analisis setelah insiden yang baik memberikan peluang untuk mengusulkan solusi umum terhadap masalah dengan pola arsitektur yang digunakan di tempat lainnya dalam sistem.
+ Pastikan bahwa faktor yang berkontribusi bersifat jujur dan tidak menyalahkan.
+ Jika Anda tidak mendokumentasikan masalah, Anda tidak dapat mengoreksinya.
+ Pastikan analisis setelah insiden bebas dari kesalahan sehingga Anda bersikap rasional terhadap tindakan korektif yang diusulkan dan mendorong penilaian mandiri yang jujur serta kolaborasi pada tim aplikasi.
+ Gunakan proses untuk menentukan faktor yang berkontribusi. Buat sebuah proses untuk mengidentifikasi dan mendokumentasi faktor yang berkontribusi terhadap peristiwa agar Anda dapat mengembangkan mitigasi untuk membatasi atau mencegah kejadian serupa serta mengembangkan prosedur untuk respons efektif dan cepat. Mengomunikasikan faktor yang berkontribusi dan disesuaikan dengan audiens target.
+ [Apa itu analitik log?](https://aws.amazon.com/log-analytics/)
## Sumber daya
**Dokumen terkait:**
+ [Apa itu analitik log?](https://aws.amazon.com/log-analytics/)
+ [Mengapa Anda harus mengembangkan koreksi kesalahan (COE)](https://aws.amazon.com/blogs/mt/why-you-should-develop-a-correction-of-error-coe/)
# REL12-BP03 Menguji persyaratan fungsional
Gunakan teknik seperti pengujian unit dan pengujian integrasi yang memvalidasi fungsionalitas.
Anda akan meraih hasil terbaik saat pengujian ini dijalankan secara otomatis sebagai bagian dari tindakan deployment dan build. Misalnya, dengan menggunakan AWS CodePipeline, developer melakukan perubahan ke repositori sumber tempat CodePipeline mendeteksi perubahan secara otomatis. Perubahan tersebut dibangun, dan pengujian dijalankan. Setelah pengujian selesai, kode yang dibangun di-deploy ke server penahapan untuk pengujian. Dari server penahapan, CodePipeline menjalankan lebih banyak pengujian, seperti integrasi atau pengujian beban. Setelah berhasil menyelesaikan pengujian tersebut, CodePipeline melakukan deployment kode yang telah diuji dan disetujui ke instans produksi.
Selain itu, pengalaman menunjukkan bahwa pengujian transaksi sintetis (juga disebut sebagai *pengujian canary*, tetapi bedakan dengan deployment canary) yang dapat menjalankan dan menyimulasikan perilaku pelanggan adalah salah satu proses pengujian yang paling penting. Jalankan pengujian ini secara konstan terhadap titik akhir beban kerja dari berbagai lokasi jarak jauh. Amazon CloudWatch Synthetics memungkinkan Anda untuk [membuat canary](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) untuk memantau titik akhir dan API.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Tinggi
## Panduan implementasi
+ Uji persyaratan fungsional. Hal ini termasuk pengujian unit dan pengujian integrasi yang memvalidasi fungsionalitas yang disyaratkan.
+ [Gunakan CodePipeline dengan AWS CodeBuild untuk menguji kode dan menjalankan build](https://docs.aws.amazon.com/codebuild/latest/userguide/how-to-create-pipeline.html)
+ [AWS CodePipeline Menambahkan Dukungan untuk Unit dan Pengujian Integrasi Kustom dengan AWS CodeBuild](https://aws.amazon.com/about-aws/whats-new/2017/03/aws-codepipeline-adds-support-for-unit-testing/)
+ [Pengiriman Berkelanjutan dan Integrasi Berkelanjutan](https://docs.aws.amazon.com/codepipeline/latest/userguide/concepts-continuous-delivery-integration.html)
+ [Menggunakan Canary (Amazon CloudWatch Synthetics)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [Otomatisasi uji perangkat lunak](https://aws.amazon.com/marketplace/solutions/devops/software-test-automation)
## Sumber daya
**Dokumen terkait:**
+ [Partner APN: partner yang dapat membantu implementasi pipeline integrasi berkelanjutan](https://aws.amazon.com/partners/find/results/?keyword=Continuous+Integration)
+ [AWS CodePipeline Menambahkan Dukungan untuk Unit dan Pengujian Integrasi Kustom dengan AWS CodeBuild](https://aws.amazon.com/about-aws/whats-new/2017/03/aws-codepipeline-adds-support-for-unit-testing/)
+ [AWS Marketplace: produk yang dapat digunakan untuk integrasi berkelanjutan](https://aws.amazon.com/marketplace/search/results?searchTerms=Continuous+integration)
+ [Pengiriman Berkelanjutan dan Integrasi Berkelanjutan](https://docs.aws.amazon.com/codepipeline/latest/userguide/concepts-continuous-delivery-integration.html)
+ [Otomatisasi uji perangkat lunak](https://aws.amazon.com/marketplace/solutions/devops/software-test-automation)
+ [Gunakan CodePipeline dengan AWS CodeBuild untuk menguji kode dan menjalankan build](https://docs.aws.amazon.com/codebuild/latest/userguide/how-to-create-pipeline.html)
+ [Menggunakan Canary (Amazon CloudWatch Synthetics)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
# REL12-BP04 Menguji persyaratan penskalaan dan kinerja
Gunakan teknik-teknik seperti pengujian beban untuk memvalidasi bahwa beban kerja memenuhi persyaratan kinerja dan penskalaan.
Di dalam cloud, Anda dapat membuat lingkungan pengujian dalam skala produksi sesuai permintaan untuk beban kerja Anda. Jika Anda menjalankan pengujian ini di infrastruktur yang skalanya diturunkan, Anda harus menskalakan hasil observasi Anda menurut apa yang Anda perkirakan terjadi di dalam produksi. Pengujian kinerja dan beban juga dapat dilakukan dalam produksi jika Anda ingin berhati-hati agar tidak berdampak pada pengguna aktual. Tandai data pengujian Anda agar tidak tercampur dengan data pengguna nyata dan mengubah laporan statistik atau produksi.
Dengan pengujian, Anda dapat memastikan bahwa sumber daya dasar, pengaturan penskalaan, kuota layanan, dan desain ketahanan Anda beroperasi sebagaimana mestinya saat menerima beban.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Tinggi
## Panduan implementasi
+ Uji persyaratan penskalaan dan kinerja. Jalankan pengujian beban untuk memvalidasi bahwa beban kerja memenuhi persyaratan kinerja dan penskalaan.
+ [Pengujian Beban Terdistribusi di AWS: simulasikan ribuan pengguna terhubung](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/)
+ [Apache JMeter](https://github.com/apache/jmeter?ref=wellarchitected)
+ Lakukan deployment aplikasi ke lingkungan yang menyerupai lingkungan produksi Anda, lalu eksekusi pengujian beban.
+ Gunakan infrastruktur sebagai konsep kode untuk membuat lingkungan semirip mungkin dengan lingkungan produksi Anda.
## Sumber daya
**Dokumen terkait:**
+ [Pengujian Beban Terdistribusi di AWS: simulasikan ribuan pengguna terhubung](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/)
+ [Apache JMeter](https://github.com/apache/jmeter?ref=wellarchitected)
# REL12-BP05 Menguji ketahanan menggunakan chaos engineering
Jalankan eksperimen chaos secara rutin di lingkungan yang berada dalam atau sedekat mungkin dengan produksi untuk memahami bagaimana sistem Anda merespons kondisi yang merugikan.
** Hasil yang diinginkan: **
Ketahanan beban kerja diverifikasi secara rutin dengan menerapkan chaos engineering dalam bentuk eksperimen injeksi kesalahan atau injeksi beban tak terduga. Selain itu, terdapat pengujian ketahanan yang memvalidasi perilaku sesuai ekspektasi yang diketahui dari beban kerja Anda selama berlangsungnya sebuah peristiwa. Gabungkan chaos engineering dan pengujian ketahanan agar Anda percaya bahwa beban kerja dapat bertahan dari kegagalan komponen dan dapat pulih dari gangguan tak terduga dengan dampak minimal atau tanpa dampak.
** Antipola umum: **
+ Menentukan desain untuk mendapatkan ketahanan, tetapi tidak memverifikasi bagaimana beban kerja berfungsi secara keseluruhan saat terjadi kesalahan.
+ Tidak pernah bereksperimen dalam kondisi dunia nyata dan dengan beban yang diharapkan.
+ Tidak memperlakukan eksperimen Anda sebagai kode atau memeliharanya melalui siklus pengembangan.
+ Tidak menjalankan eksperimen chaos baik sebagai bagian dari alur CI/CD Anda maupun di luar deployment.
+ Tidak menggunakan analisis pascainsiden terdahulu saat menentukan kesalahan mana yang akan digunakan dalam eksperimen.
** Manfaat menjalankan praktik terbaik ini:** Injeksi kesalahan untuk memverifikasi ketahanan beban kerja Anda akan membuat Anda percaya bahwa prosedur pemulihan dari desain Anda yang tangguh akan efektif jika terjadi kesalahan nyata.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Sedang
## Panduan implementasi
Chaos engineering memberi tim Anda kemampuan untuk terus menginjeksi gangguan (simulasi) dunia nyata dengan cara yang terkontrol di tingkat penyedia layanan, infrastruktur, beban kerja, dan komponen, dengan dampak minimal atau tanpa dampak bagi pelanggan Anda. Hal ini memungkinkan tim Anda belajar dari kesalahan serta mengamati, mengukur, dan meningkatkan ketahanan beban kerja Anda, serta memvalidasi bahwa peringatan akan diluncurkan dan tim mendapatkan notifikasi jika terjadi suatu peristiwa.
Jika dilakukan terus-menerus, chaos engineering dapat menunjukkan kekurangan dalam beban kerja Anda yang, jika dibiarkan tidak ditangani, dapat berdampak negatif pada ketersediaan dan pengoperasian.
**catatan**
Chaos engineering adalah bidang ilmu yang bereksperimen pada sistem guna membangun kepercayaan pada kemampuan sistem untuk bertahan dari kondisi gangguan dalam produksi. – [Prinsip-prinsip Chaos Engineering](https://principlesofchaos.org/)
Jika sistem mampu bertahan dari gangguan ini, eksperimen chaos harus dipertahankan sebagai pengujian regresi otomatis. Dengan demikian, eksperimen chaos harus dilakukan sebagai bagian dari siklus hidup pengembangan sistem (SDLC) Anda dan sebagai bagian dari alur CI/CD Anda.
Untuk memastikan bahwa beban kerja Anda dapat bertahan dari kegagalan komponen, lakukan injeksi peristiwa dunia nyata sebagai bagian dari eksperimen Anda. Misalnya, lakukan eksperimen dengan kehilangan instans Amazon EC2 atau failover instans basis data Amazon RDS utama, lalu verifikasi bahwa beban kerja Anda tidak terpengaruh (atau hanya sedikit terpengaruh). Gunakan kombinasi kesalahan komponen untuk menyimulasikan peristiwa yang mungkin disebabkan oleh gangguan di Zona Ketersediaan.
Untuk kesalahan tingkat aplikasi (seperti crash), Anda dapat memulai dengan stressor seperti kehabisan memori dan daya CPU.
Untuk memvalidasi [mekanisme fallback atau failover](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems/) untuk dependensi eksternal karena gangguan jaringan yang terputus-putus, komponen Anda harus menyimulasikan peristiwa tersebut dengan memblokir akses ke penyedia pihak ketiga selama durasi tertentu yang dapat berlangsung dari hitungan detik hingga jam.
Mode degradasi lainnya dapat menyebabkan berkurangnya fungsionalitas dan respons yang lambat, sehingga sering kali mengakibatkan gangguan pada layanan Anda. Degradasi ini umumnya disebabkan oleh peningkatan latensi pada layanan yang sangat penting dan komunikasi jaringan yang tidak dapat diandalkan (paket yang tidak dikirim). Eksperimen dengan kesalahan ini, termasuk efek jaringan seperti latensi, pesan yang tidak terkirim, dan kegagalan DNS, dapat mencakup ketidakmampuan untuk meresolusi nama, menjangkau layanan DNS, atau membuat koneksi ke layanan yang dependen.
**Alat chaos engineering:**
AWS Fault Injection Service (AWS FIS) adalah layanan terkelola penuh untuk menjalankan eksperimen injeksi kesalahan yang dapat digunakan sebagai bagian dari alur CD Anda, atau di luar alur. AWS FIS adalah pilihan yang baik untuk digunakan selama game day chaos engineering. Layanan ini mendukung penerapan kesalahan secara bersamaan di berbagai jenis sumber daya, termasuk Amazon EC2, Amazon Elastic Container Service (Amazon ECS), Amazon Elastic Kubernetes Service (Amazon EKS), dan Amazon RDS. Kesalahan ini termasuk menghentikan sumber daya, memaksa failover, membebani CPU atau memori, throttling, latensi, dan kehilangan paket. Karena layanan ini terintegrasi dengan Amazon CloudWatch Alarms, Anda dapat mengatur kondisi berhenti sebagai pagar pembatas untuk melakukan rollback jika eksperimen menyebabkan dampak tak terduga.
![\[Diagram yang menunjukkan AWS Fault Injection Service terintegrasi dengan sumber daya AWS untuk memungkinkan Anda menjalankan eksperimen injeksi kesalahan untuk beban kerja Anda.\]](http://docs.aws.amazon.com/id_id/wellarchitected/2022-03-31/framework/images/fault-injection-simulator.png)
Ada juga beberapa opsi pihak ketiga untuk eksperimen injeksi kesalahan. Opsi ini mencakup alat sumber terbuka seperti [Chaos Toolkit](https://chaostoolkit.org/), [Chaos Mesh](https://chaos-mesh.org/), dan [Litmus Chaos](https://litmuschaos.io/), serta opsi komersial seperti Gremlin. Untuk memperluas cakupan kesalahan yang dapat diinjeksikan di AWS, AWS FIS [terintegrasi dengan Chaos Mesh dan Litmus Chaos](https://aws.amazon.com/about-aws/whats-new/2022/07/aws-fault-injection-simulator-supports-chaosmesh-litmus-experiments/), sehingga Anda dapat mengoordinasikan alur kerja injeksi kesalahan di antara beberapa alat. Misalnya, Anda dapat menjalankan pengujian pada CPU sebuah pod menggunakan kesalahan Chaos Mesh atau Litmus sambil menghentikan sebagian simpul klaster yang dipilih secara acak menggunakan tindakan kesalahan AWS FIS.
## Langkah implementasi
+ Tentukan kesalahan mana yang akan digunakan untuk eksperimen.
Lakukan penilaian desain beban kerja Anda untuk mengetahui ketahanannya. Desain tersebut (yang dibuat menggunakan praktik terbaik dari [Well-Architected Framework](https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html)) memperhitungkan risiko berdasarkan dependensi krusial, peristiwa terdahulu, masalah yang diketahui, dan persyaratan kepatuhan. Buat daftar yang berisi setiap elemen desain yang dimaksudkan untuk menjaga ketahanan dan kesalahan yang akan dimitigasi oleh elemen desain tersebut. Untuk informasi lebih lanjut tentang cara membuat daftar tersebut, lihat [laporan resmi Operational Readiness Review](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html) yang memandu Anda tentang cara membuat proses untuk mencegah pengulangan insiden sebelumnya. Proses Analisis Mode dan Efek Kegagalan (FMEA) memberi Anda kerangka kerja untuk melakukan analisis tingkat komponen terhadap kegagalan dan bagaimana dampaknya terhadap beban kerja Anda. FMEA diuraikan secara lebih mendetail oleh Adrian Cockcroft dalam [Failure Modes and Continuous Resilience](https://adrianco.medium.com/failure-modes-and-continuous-resilience-6553078caad5).
+ Tetapkan prioritas untuk setiap kesalahan.
Mulailah dengan kategorisasi yang umum seperti tinggi, sedang, atau rendah. Untuk menilai prioritas, pertimbangkan frekuensi kesalahan dan dampak kegagalan terhadap beban kerja secara keseluruhan.
Saat mempertimbangkan frekuensi kesalahan tertentu, lakukan analisis pada data terdahulu untuk beban kerja ini jika tersedia. Jika tidak tersedia, gunakan data dari beban kerja lain yang berjalan di lingkungan yang serupa.
Ketika mempertimbangkan dampak dari kesalahan tertentu, makin besar cakupan kesalahan, biasanya makin besar dampaknya. Pertimbangkan juga desain dan tujuan beban kerja. Misalnya, kemampuan untuk mengakses penyimpanan data sumber sangat krusial untuk beban kerja yang melakukan transformasi dan analisis data. Dalam hal ini, Anda akan memprioritaskan eksperimen untuk kesalahan akses, serta akses yang di-throttling dan penyisipan latensi.
Analisis pascainsiden adalah sumber data yang baik untuk memahami frekuensi dan dampak mode kegagalan.
Gunakan prioritas yang ditetapkan untuk menentukan kesalahan mana yang akan digunakan terlebih dahulu dalam eksperimen beserta urutannya agar dapat mengembangkan eksperimen injeksi kesalahan baru.
+ Untuk setiap eksperimen yang Anda lakukan, gunakan roda chaos engineering dan ketahanan berkelanjutan.
![\[Diagram roda chaos engineering dan ketahanan berkelanjutan, yang menunjukkan fase Peningkatan, Kondisi stabil, Hipotesis, Pelaksanaan eksperimen, dan Verifikasi.\]](http://docs.aws.amazon.com/id_id/wellarchitected/2022-03-31/framework/images/chaos-engineering-flywheel.png)
+ Definisikan kondisi stabil sebagai output terukur dari beban kerja yang menunjukkan perilaku normal.
Beban kerja Anda menunjukkan kondisi stabil jika beroperasi dengan andal dan seperti yang diharapkan. Oleh karena itu, validasikan bahwa beban kerja Anda berkondisi baik sebelum menentukan kondisi stabil. Dalam kondisi stabil, bukan berarti tidak akan ada dampak pada beban kerja saat terjadi kesalahan, karena sejumlah kesalahan tertentu mungkin berada dalam batas yang dapat diterima. Kondisi stabil adalah acuan dasar yang akan Anda amati selama eksperimen, yang akan menunjukkan anomali jika hipotesis yang Anda tentukan pada langkah berikutnya tidak berjalan seperti yang diharapkan.
Misalnya, kondisi stabil sistem pembayaran dapat didefinisikan sebagai pemrosesan 300 TPS dengan tingkat keberhasilan 99% dan waktu round-trip 500 md.
+ Bentuk hipotesis tentang bagaimana beban kerja akan bereaksi terhadap kesalahan.
Hipotesis yang baik didasarkan pada bagaimana beban kerja diharapkan akan memitigasi kesalahan untuk mempertahankan kondisi stabil. Hipotesis menyatakan bahwa dengan kesalahan jenis tertentu, sistem atau beban kerja akan terus berkondisi stabil karena beban kerja ini dirancang dengan mitigasi tertentu. Jenis spesifik kesalahan dan mitigasi harus ditentukan dalam hipotesis.
Templat berikut dapat digunakan untuk hipotesis (tetapi pernyataan lain juga dapat diterima):
**catatan**
Jika *[kesalahan tertentu]* terjadi, beban kerja *[nama beban kerja]* akan *[deskripsikan kontrol mitigasi]* untuk mempertahankan *[dampak metrik bisnis atau teknis]*.
Misalnya:
+ Jika 20% dari total simpul dalam grup simpul Amazon EKS dihapus, Transaction Create API akan terus melayani persentil ke-99 dari permintaan dalam waktu kurang dari 100 md (kondisi stabil). Simpul Amazon EKS akan pulih dalam waktu lima menit, dan pod akan dijadwalkan dan memproses lalu lintas dalam waktu delapan menit setelah dimulainya eksperimen. Peringatan akan diaktifkan dalam waktu tiga menit.
+ Jika terjadi kegagalan instans Amazon EC2 tunggal, pemeriksaan kondisi Elastic Load Balancing untuk sistem pemesanan akan membuat Elastic Load Balancing hanya mengirim permintaan ke instans berkondisi baik yang tersisa, sedangkan Amazon EC2 Auto Scaling mengganti instans yang gagal, sehingga mempertahankan peningkatan kesalahan sisi server (5xx) sebanyak kurang dari 0,01% (kondisi stabil).
+ Jika instans basis data Amazon RDS utama gagal, beban kerja pengumpulan data Rantai Pasokan akan melakukan failover dan terhubung ke instans basis data Amazon RDS yang siaga untuk mempertahankan kesalahan baca atau tulis basis data selama kurang dari 1 menit (kondisi stabil).
+ Jalankan eksperimen dengan menginjeksikan kesalahan.
Eksperimen secara default harus memiliki kemampuan fail-safe dan ditoleransi oleh beban kerja. Jika Anda tahu bahwa beban kerja akan gagal, jangan jalankan eksperimen. Chaos engineering harus digunakan untuk menemukan “known-unknown” atau “unknown-unknown”. *“Known-unknown”* adalah hal-hal yang Anda ketahui, tetapi tidak sepenuhnya dipahami, dan *“unknown-unknown”* adalah hal-hal yang tidak Anda ketahui atau pahami sepenuhnya. Bereksperimen dengan beban kerja yang Anda tahu dalam kondisi rusak tidak akan memberi Anda wawasan baru. Eksperimen Anda harus direncanakan dengan cermat, memiliki cakupan dampak yang jelas, dan menyediakan mekanisme rollback yang dapat diterapkan jika terjadi gangguan tak terduga. Jika uji tuntas Anda menunjukkan bahwa beban kerja Anda dapat bertahan dalam eksperimen, lanjutkan eksperimen. Ada beberapa opsi untuk menginjeksikan kesalahan. Untuk beban kerja di AWS, [AWS FIS](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html) menyediakan banyak simulasi kesalahan standar yang disebut [tindakan](https://docs.aws.amazon.com/fis/latest/userguide/actions.html). Anda juga dapat menentukan tindakan kustom yang berjalan di AWS FIS menggunakan [dokumen AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-ssm-docs.html).
Kami tidak menyarankan penggunaan skrip kustom untuk eksperimen chaos, kecuali jika skrip tersebut memiliki kemampuan untuk memahami status terkini beban kerja, mampu menghasilkan log, dan menyediakan mekanisme untuk rollback dan kondisi berhenti jika memungkinkan.
Kerangka kerja atau kumpulan alat efektif yang mendukung chaos engineering harus melacak kondisi terkini eksperimen, menghasilkan log, dan menyediakan mekanisme rollback untuk mendukung pelaksanaan eksperimen yang terkontrol. Mulailah dengan layanan andal seperti AWS FIS yang memungkinkan Anda melakukan eksperimen dengan cakupan yang jelas dan mekanisme keamanan yang melakukan rollback jika eksperimen menimbulkan gangguan tak terduga. Untuk mempelajari tentang beragam variasi eksperimen menggunakan AWS FIS, lihat juga [lab Aplikasi Tangguh dan Well-Architected dengan Chaos Engineering](https://catalog.us-east-1.prod.workshops.aws/workshops/44e29d0c-6c38-4ef3-8ff3-6d95a51ce5ac/en-US). Selain itu, [AWS Resilience Hub](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html) akan menganalisis beban kerja Anda dan membuat eksperimen yang dapat Anda pilih untuk diterapkan dan dijalankan di AWS FIS.
**catatan**
Untuk setiap eksperimen, pahami dengan jelas cakupan dan dampaknya. Kami merekomendasikan bahwa kesalahan harus disimulasikan terlebih dahulu di lingkungan nonproduksi sebelum dijalankan dalam produksi.
Eksperimen harus dijalankan dalam produksi dengan beban dunia nyata menggunakan [deployment canary](https://medium.com/the-cloud-architect/chaos-engineering-q-a-how-to-safely-inject-failure-ced26e11b3db) yang melakukan deployment sistem kontrol dan eksperimental, jika memungkinkan. Menjalankan eksperimen selama waktu sepi adalah praktik yang baik untuk mengurangi potensi dampak saat pertama kali bereksperimen dalam produksi. Selain itu, jika menggunakan lalu lintas pelanggan yang sebenarnya akan menimbulkan terlalu banyak risiko, Anda dapat menjalankan eksperimen menggunakan lalu lintas sintetis di infrastruktur produksi terhadap deployment kontrol dan eksperimental. Jika tidak dapat menggunakan produksi, jalankan eksperimen di lingkungan praproduksi yang semirip mungkin dengan produksi.
Anda harus membuat dan memantau pagar pembatas untuk memastikan eksperimen tidak memengaruhi lalu lintas produksi atau sistem lain di luar batas yang dapat diterima. Tetapkan kondisi berhenti untuk menghentikan eksperimen jika mencapai ambang batas pada metrik pagar pembatas yang Anda tentukan. Hal ini harus mencakup metrik untuk kondisi stabil beban kerja, serta metrik berdasarkan komponen yang diinjeksi dengan kesalahan. Sebuah [pemantauan sintetis](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) (juga dikenal sebagai user canary) adalah salah satu metrik yang biasanya harus Anda sertakan sebagai proksi pengguna. [Kondisi berhenti untuk AWS FIS](https://docs.aws.amazon.com/fis/latest/userguide/stop-conditions.html) didukung sebagai bagian dari templat eksperimen, sehingga memungkinkan maksimal lima kondisi berhenti per templat.
Salah satu prinsip chaos adalah meminimalkan cakupan eksperimen dan dampaknya:
Meskipun harus ada kelonggaran untuk beberapa dampak negatif dalam jangka pendek, Chaos Engineer bertanggung jawab dan berkewajiban untuk memastikan gangguan dari eksperimen diminimalkan dan dikendalikan.
Metode untuk memverifikasi cakupan dan dampak potensial adalah dengan melakukan eksperimen di lingkungan nonproduksi terlebih dahulu, memverifikasi bahwa ambang batas untuk kondisi berhenti diaktifkan seperti yang diharapkan selama eksperimen dan kemampuan pengamatan diterapkan untuk menemukan pengecualian, bukan langsung bereksperimen dalam produksi.
Saat menjalankan eksperimen injeksi kesalahan, verifikasikan bahwa semua pihak yang bertanggung jawab sudah mengetahui informasi yang jelas. Berkomunikasilah dengan tim yang sesuai seperti tim operasi, tim keandalan layanan, dan dukungan pelanggan untuk memberi tahu mereka kapan eksperimen akan dijalankan dan apa yang diharapkan. Berikan alat komunikasi kepada berbagai tim ini untuk memberi tahu tim tertentu yang menjalankan eksperimen jika muncul efek yang merugikan.
Anda harus memulihkan beban kerja dan sistem yang mendasarinya kembali ke kondisi awal yang diketahui berfungsi baik. Sering kali, desain beban kerja yang tangguh akan pulih sendiri. Namun, beberapa desain yang salah atau eksperimen yang gagal dapat membuat beban kerja Anda berada dalam kondisi kegagalan yang tidak terduga. Pada akhir eksperimen, Anda harus menyadari hal ini dan memulihkan beban kerja dan sistem. Dengan AWS FIS, Anda dapat mengatur konfigurasi rollback (juga disebut post action) dalam parameter tindakan. Post action mengembalikan target ke keadaan sebelum tindakan dijalankan. Baik diotomatiskan (seperti menggunakan AWS FIS) maupun manual, post action ini harus menjadi bagian dari playbook yang menjelaskan cara mendeteksi dan menangani kegagalan.
+ Verifikasikan hipotesisnya.
[Prinsip-prinsip Chaos Engineering](https://principlesofchaos.org/) memberikan panduan tentang cara memverifikasi kondisi stabil beban kerja Anda:
Fokus pada output terukur dari suatu sistem, bukan atribut internal sistem. Pengukuran output tersebut selama periode waktu yang singkat merupakan proksi untuk kondisi stabil sistem. Throughput sistem secara keseluruhan, tingkat kesalahan, dan persentil latensi semuanya dapat menjadi metrik penting yang merepresentasikan perilaku kondisi stabil. Dengan berfokus pada pola perilaku sistemik selama eksperimen, chaos engineering memverifikasi bahwa sistem berfungsi, bukan mencoba memvalidasi cara kerjanya.
Dalam dua contoh sebelumnya, kami menyertakan metrik kondisi stabil dengan peningkatan kesalahan sisi server (5xx) sebanyak kurang dari 0,01% serta kesalahan baca dan tulis basis data selama kurang dari satu menit.
Kesalahan 5xx adalah metrik yang baik karena merupakan konsekuensi dari mode kegagalan yang akan dialami langsung oleh klien yang menggunakan beban kerja. Pengukuran kesalahan basis data cocok digunakan sebagai konsekuensi langsung dari kesalahan, tetapi juga harus dilengkapi dengan pengukuran dampak klien seperti permintaan pelanggan yang gagal atau kesalahan yang muncul bagi klien. Selain itu, sertakan pemantauan sintetis (juga dikenal sebagai user canary) pada API atau URI apa pun yang diakses langsung oleh klien yang menggunakan beban kerja Anda.
+ Tingkatkan desain beban kerja agar memiliki ketahanan.
Jika kondisi stabil tidak dipertahankan, selidiki cara desain beban kerja dapat ditingkatkan untuk mengurangi kesalahan, dengan menerapkan praktik terbaik dari [pilar Keandalan AWS Well-Architected](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html). Panduan dan sumber daya tambahan dapat ditemukan di [AWS Builder’s Library](https://aws.amazon.com/builders-library/), yang berisi artikel tentang cara [meningkatkan pemeriksaan kondisi Anda](https://aws.amazon.com/builders-library/implementing-health-checks/) atau [menerapkan percobaan ulang dengan backoff dalam kode aplikasi Anda](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/), dll.
Setelah perubahan ini diterapkan, jalankan eksperimen lagi (ditunjukkan dengan garis putus-putus pada roda chaos engineering) untuk mengetahui keefektifannya. Jika langkah verifikasi menunjukkan bahwa hipotesisnya benar, beban kerja akan berada dalam kondisi stabil, dan siklusnya berlanjut.
+ Jalankan eksperimen secara rutin.
Eksperimen chaos adalah sebuah siklus, dan eksperimen harus dijalankan secara rutin sebagai bagian dari chaos engineering. Setelah beban kerja memenuhi hipotesis eksperimen, eksperimen harus diotomatiskan untuk terus berjalan sebagai bagian regresi dalam alur CI/CD Anda. Untuk mempelajari cara melakukannya, lihat blog tentang [cara menjalankan eksperimen AWS FIS menggunakan AWS CodePipeline](https://aws.amazon.com/blogs/architecture/chaos-testing-with-aws-fault-injection-simulator-and-aws-codepipeline/). Lab tentang [eksperimen AWS FIS berulang dalam alur CI/CD](https://chaos-engineering.workshop.aws/en/030_basic_content/080_cicd.html) memungkinkan Anda melakukan praktik langsung.
Eksperimen injeksi kesalahan juga merupakan bagian dari game day (lihat [REL12-BP06 Mengadakan game day secara rutin](rel_testing_resiliency_game_days_resiliency.md)). Game day mensimulasikan kegagalan atau peristiwa untuk memverifikasi sistem, proses, dan respons tim. Tujuannya adalah untuk benar-benar menerapkan tindakan yang perlu dilakukan oleh tim seolah memang terjadi peristiwa yang tidak diharapkan.
+ Catat dan simpan hasil eksperimen.
Hasil eksperimen injeksi kesalahan harus dicatat dan dijadikan persisten. Sertakan semua data yang diperlukan (seperti waktu, beban kerja, dan kondisi) agar dapat menganalisis hasil dan tren eksperimen nantinya. Contoh hasilnya dapat mencakup tangkapan layar dasbor, dump CSV dari basis data metrik Anda, atau catatan ketik manual yang berisi peristiwa dan pengamatan dari eksperimen. [Pencatatan log eksperimen dengan AWS FIS](https://docs.aws.amazon.com/fis/latest/userguide/monitoring-logging.html) dapat menjadi bagian dari pencatatan data ini.
## Sumber daya
**Praktik terbaik terkait:**
+ [REL08-BP03 Mengintegrasikan pengujian ketahanan sebagai bagian dari deployment Anda](rel_tracking_change_management_resiliency_testing.md)
+ [REL13-BP03 Menguji implementasi pemulihan bencana untuk memvalidasi implementasi](rel_planning_for_recovery_dr_tested.md)
**Dokumen terkait:**
+ [Apa itu AWS Fault Injection Service?](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html)
+ [Apa itu AWS Resilience Hub?](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html)
+ [Prinsip-prinsip Chaos Engineering](https://principlesofchaos.org/)
+ [Chaos Engineering: Merencanakan eksperimen pertama Anda](https://medium.com/the-cloud-architect/chaos-engineering-part-2-b9c78a9f3dde)
+ [Rekayasa Ketahanan: Belajar untuk Mengatasi Kegagalan](https://queue.acm.org/detail.cfm?id=2371297)
+ [Kisah Chaos Engineering](https://github.com/ldomb/ChaosEngineeringPublicStories)
+ [Menghindari fallback dalam sistem terdistribusi](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems/)
+ [Deployment Canary untuk Eksperimen Chaos](https://medium.com/the-cloud-architect/chaos-engineering-q-a-how-to-safely-inject-failure-ced26e11b3db)
**Video terkait:**
+ [AWS re:Invent 2020: Menguji ketahanan menggunakan chaos engineering (ARC316)](https://www.youtube.com/watch?v=OlobVYPkxgg)
+ [AWS re:Invent 2019: Meningkatkan ketahanan dengan chaos engineering (DOP309-R1)](https://youtu.be/ztiPjey2rfY)
+ [AWS re:Invent 2019: Melakukan chaos engineering di dunia nirserver (CMY301)](https://www.youtube.com/watch?v=vbyjpMeYitA)
**Contoh terkait:**
+ [Lab Well-Architected: Level 300: Pengujian Ketahanan Amazon EC2, Amazon RDS, dan Amazon S3](https://wellarchitectedlabs.com/reliability/300_labs/300_testing_for_resiliency_of_ec2_rds_and_s3/)
+ [Lab Chaos Engineering di AWS](https://chaos-engineering.workshop.aws/en/)
+ [lab Aplikasi Tangguh dan Well-Architected dengan Chaos Engineering](https://catalog.us-east-1.prod.workshops.aws/workshops/44e29d0c-6c38-4ef3-8ff3-6d95a51ce5ac/en-US)
+ [Lab Chaos Nirserver](https://catalog.us-east-1.prod.workshops.aws/workshops/3015a19d-0e07-4493-9781-6c02a7626c65/en-US/serverless)
+ [Lab Ukur dan Tingkatkan Ketahanan Aplikasi Anda dengan AWS Resilience Hub](https://catalog.us-east-1.prod.workshops.aws/workshops/2a54eaaf-51ee-4373-a3da-2bf4e8bb6dd3/en-US/200-labs/1wordpressapplab)
** Alat terkait: **
+ [AWS Fault Injection Service](https://aws.amazon.com/fis/)
+ AWS Marketplace: [Platform Chaos Engineering Gremlin](https://aws.amazon.com/marketplace/pp/prodview-tosyg6v5cyney)
+ [Chaos Toolkit](https://chaostoolkit.org/)
+ [Chaos Mesh](https://chaos-mesh.org/)
+ [Litmus](https://litmuschaos.io/)
# REL12-BP06 Mengadakan game day secara rutin
Manfaatkan game day untuk secara rutin melatih prosedur Anda dalam merespons peristiwa dan kegagalan. Buat game day semirip mungkin dengan produksi (termasuk lingkungan produksi) bersama orang-orang yang akan terlibat dalam skenario kegagalan aktual. Game day menerapkan tindakan yang diperlukan guna memastikan peristiwa produksi tidak berdampak pada pengguna.
Game day menyimulasikan kegagalan atau peristiwa untuk menguji respons tim, sistem, dan proses. Tujuannya adalah untuk benar-benar menerapkan tindakan yang perlu dilakukan oleh tim seolah memang terjadi peristiwa yang tidak diharapkan. Hal ini akan membantu Anda memahami sisi mana yang perlu ditingkatkan dan membantu mengembangkan pengalaman organisasi dalam menangani peristiwa. Aktivitas ini harus dilakukan secara rutin untuk memperkuat *memori otot* dalam merespons kejadian tersebut.
Setelah desain ketangguhan Anda diterapkan dan diuji dalam lingkungan nonproduksi, game day dapat menjadi cara untuk memastikan bahwa segala sesuatu akan berjalan sesuai rencana ketika produksi. Game day, terutama yang dilakukan untuk pertama kali, merupakan aktivitas “wajib untuk semua tim”. Rekayasawan dan operasi akan diberitahu kapan ini dilakukan, dan apa yang akan terjadi. Runbook telah diterapkan. Simulasi peristiwa, termasuk peristiwa kegagalan yang mungkin terjadi, dieksekusi di sistem produksi dengan cara yang sudah ditentukan, dan dampaknya dievaluasi. Jika sistem beroperasi sesuai rancangan, deteksi dan pemulihan mandiri akan berlangsung dengan sedikit atau tanpa dampak. Namun, jika timbul dampak negatif, pengujian akan diulang dan masalah beban kerja diperbaiki, secara manual jika perlu (menggunakan runbook). Karena game day biasanya berlangsung di dalam produksi, semua pencegahan harus dilakukan guna memastikan bahwa ketersediaan untuk pelanggan tidak terganggu.
**Antipola umum:**
+ Mendokumentasikan prosedur Anda, tetapi tidak pernah melatihnya.
+ Tidak melibatkan pembuat keputusan bisnis dalam pengujian pelatihan.
**Manfaat menerapkan praktik terbaik ini:** Mengadakan game day secara rutin memastikan bahwa staf mengikuti kebijakan dan prosedur ketika insiden aktual terjadi, dan memvalidasi bahwa kebijakan dan prosedur tersebut sudah sesuai.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Sedang
## Panduan implementasi
+ Jadwalkan game day untuk menggunakan runbook dan buku pedoman Anda secara rutin. Game day harus mengikutsertakan semua orang yang akan terlibat dalam kejadian produksi: pemilik bisnis, staf pengembangan, staf operasional, dan tim respons insiden.
+ Jalankan pengujian beban atau kinerja Anda, kemudian jalankan injeksi kegagalan.
+ Cari anomali dalam runbook Anda dan peluang untuk menggunakan buku pedoman Anda.
+ Jika Anda tidak mengikuti runbook, perbaiki runbook atau koreksi perilakunya. Jika Anda menggunakan buku pedoman, identifikasi buku pedoman yang seharusnya digunakan atau buat yang baru.
## Sumber daya
**Dokumen terkait:**
+ [Apa itu AWS GameDay?](https://aws.amazon.com/gameday/)
**Video terkait:**
+ [AWS re:Invent 2019: Meningkatkan ketahanan dengan chaos engineering (DOP309-R1)](https://youtu.be/ztiPjey2rfY)
**Contoh terkait:**
+ [Lab AWS Well-Architected - Pengujian Ketangguhan](https://wellarchitectedlabs.com/reliability/300_labs/300_testing_for_resiliency_of_ec2_rds_and_s3/)