# Rancang beban kerja Anda agar bertahan dalam kegagalan komponen
Beban kerja yang membutuhkan ketersediaan tinggi dan waktu rata-rata untuk pemulihan (MTTR) rendah harus didesain dan dikonfigurasi agar tangguh.
**Topics**
+ [REL11-BP01 Memantau semua komponen beban kerja untuk mendeteksi kegagalan](rel_withstand_component_failures_monitoring_health.md)
+ [REL11-BP02 Melakukan failover ke sumber daya yang sehat](rel_withstand_component_failures_failover2good.md)
+ [REL11-BP03 Melakukan otomatisasi pemulihan di semua lapisan](rel_withstand_component_failures_auto_healing_system.md)
+ [REL11-BP04 Mengandalkan bidang data dan bukan bidang kontrol selama pemulihan](rel_withstand_component_failures_avoid_control_plane.md)
+ [REL11-BP05 Menggunakan stabilitas statis untuk mencegah perilaku bimodal](rel_withstand_component_failures_static_stability.md)
+ [REL11-BP06 Mengirimkan notifikasi ketika peristiwa memengaruhi ketersediaan](rel_withstand_component_failures_notifications_sent_system.md)
+ [REL11-BP07 Merancang produk Anda agar memenuhi target-target ketersediaan dan perjanjian tingkat layanan (SLA) waktu aktif](rel_withstand_component_failures_service_level_agreements.md)
# REL11-BP01 Memantau semua komponen beban kerja untuk mendeteksi kegagalan
Lakukan pemantauan terus-menerus terhadap kondisi beban kerja agar Anda dan sistem otomatis Anda langsung mengetahui adanya penurunan kualitas atau kegagalan ketika muncul. Pantau indikator kinerja utama (KPI) berdasarkan nilai bisnis.
Semua mekanisme pemulihan dan penyembuhan harus dimulai dengan kemampuan untuk mendeteksi adanya masalah secara cepat. Kegagalan teknis harus dideteksi terlebih dahulu sehingga dapat diselesaikan. Namun demikian, ketersediaan didasarkan pada kemampuan beban kerja Anda untuk menghadirkan nilai bisnis, sehingga indikator performa utama (KPI) yang mengukurnya harus menjadi bagian dari strategi deteksi dan perbaikan Anda.
**Hasil yang diinginkan:** Komponen penting dari suatu beban kerja dipantau secara independen untuk mendeteksi dan memperingatkan adanya kegagalan pada saat dan di bagian mana kegagalan tersebut terjadi.
**Anti-pola umum:**
+ Tidak ada alarm yang dikonfigurasi, sehingga pemadaman (outage) terjadi tanpa notifikasi.
+ Alarm tersedia, tetapi pada ambang batas yang tidak menyediakan waktu yang cukup untuk bereaksi.
+ Metrik tidak dikumpulkan cukup sering untuk memenuhi sasaran waktu pemulihan (RTO).
+ Hanya antarmuka beban kerja yang terlihat oleh pelanggan yang secara aktif dipantau.
+ Hanya mengumpulkan metrik-metrik teknis, dan mengabaikan metrik-metrik fungsi bisnis.
+ Tidak ada metrik yang mengukur pengalaman pengguna beban kerja.
+ Terlalu banyak pemantau yang dibuat.
**Manfaat menerapkan praktik terbaik ini:** Pemantauan yang sesuai di semua lapisan akan memungkinkan Anda untuk menghemat waktu pemulihan karena berkurangnya waktu deteksi.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Tinggi
## Panduan implementasi
Identifikasi semua beban kerja yang akan ditinjau untuk pemantauan. Setelah Anda mengidentifikasi semua komponen beban kerja yang perlu dipantau, selanjutnya Anda harus menentukan rentang waktu pemantauan. Rentang waktu pemantauan akan berdampak langsung pada seberapa cepat pemulihan dapat dimulai berdasarkan waktu yang diperlukan untuk mendeteksi sebuah kegagalan. Rata-rata waktu deteksi (MTTD) adalah lamanya waktu antara terjadinya kegagalan dan ketika operasi perbaikan dimulai. Daftar layanan harus luas dan lengkap.
Pemantauan harus mencakup semua lapisan tumpukan aplikasi termasuk aplikasi, platform, infrastruktur, dan jaringan.
Strategi pemantauan Anda harus mempertimbangkan dampak *kegagalan abu-abu*. Untuk detail lebih lanjut tentang kegagalan abu-abu (samar), lihat [ Kegagalan abu-abu](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/gray-failures.html) di laporan resmi Pola Ketahanan Multi-AZ Tingkat Lanjut.
### Langkah-langkah implementasi
+ Rentang waktu pemantauan Anda bergantung pada seberapa cepat waktu pemulihan yang Anda perlukan. Waktu pemulihan Anda ditentukan oleh waktu yang diperlukan untuk pulih, sehingga Anda harus menentukan frekuensi pengumpulan dengan cara menghitung waktu ini dan sasaran waktu pemulihan (RTO) Anda.
+ Konfigurasikan pemantauan mendetail untuk komponen dan layanan terkelola.
+ Tentukan apakah diperlukan [pemantauan mendetail untuk instans EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-cloudwatch-new.html) dan [Auto Scaling (penskalaan otomatis)](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-monitoring.html). Pemantauan mendetail menyediakan metrik rentang waktu satu menit, sedangkan pemantauan default menyediakan metrik rentang waktu lima menit.
+ Tentukan apakah diperlukan [pemantauan yang ditingkatkan](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Monitoring.html) untuk RDS. Pemantauan yang ditingkatkan menggunakan sebuah agen di instans RDS untuk memperoleh informasi bermanfaat tentang berbagai alur atau proses.
+ Tentukan persyaratan-persyaratan pemantauan komponen nirserver penting untuk [Lambda](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-metrics.html), [API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/monitoring_automated_manual.html), [Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/eks-observe.html), [Amazon ECS](https://catalog.workshops.aws/observability/en-US/aws-managed-oss/amp/ecs), dan semua jenis [penyeimbang beban.](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-monitoring.html).
+ Tentukan persyaratan-persyaratan pemantauan komponen penyimpanan untuk [Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/monitoring-overview.html), [Amazon FSx](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/monitoring_overview.html), [Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/monitoring_overview.html), dan [Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-volume-status.html).
+ Buat [metrik kustom](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) untuk mengukur indikator performa utama (KPI) bisnis. Beban kerja mengimplementasikan fungsi-fungsi bisnis utama, yang harus digunakan sebagai KPI yang membantu mengidentifikasi kapan sebuah masalah tidak langsung terjadi.
+ Pantau pengalaman pengguna untuk mendeteksi terjadinya kegagalan menggunakan canary pengguna. [Pengujian transaksi sintetis](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) (juga disebut 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 Anda dari beragam lokasi jarak jauh.
+ Buat [metrik kustom](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) yang melacak pengalaman pengguna. Jika Anda dapat menginstrumentasikan pengalaman pelanggan, Anda dapat menentukan kapan pengalaman pelanggan mengalami degradasi.
+ [Atur alarm](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) untuk mendeteksi saat ada bagian dari beban kerja Anda yang tidak berfungsi dengan baik, dan untuk menunjukkan kapan harus menerapkan penskalaan secara otomatis pada sumber daya. Alarm dapat ditampilkan secara visual di dasbor, mengirimkan peringatan melalui Amazon SNS atau email, dan menggunakan Auto Scaling (penskalaan otomatis) untuk menaikkan atau menurunkan skala sumber daya beban kerja.
+ Buat [dasbor](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html) untuk memvisualisasikan metrik Anda. Dasbor dapat digunakan untuk melihat tren, penyimpangan, dan indikator masalah lain yang mungkin muncul, atau menyediakan penanda untuk masalah yang ingin Anda selidiki.
+ Buat [pemantauan penelusuran terdistribusi](https://aws.amazon.com/xray/faqs/) untuk layanan-layanan Anda. Dengan pemantauan terdistribusi, Anda dapat memahami cara kerja aplikasi Anda dan layanan-layanan yang mendasarinya dalam melakukan identifikasi dan memecahkan akar penyebab masalah dan kesalahan performa.
+ Buat dasbor dan pengumpulan data sistem pemantauan (menggunakan [CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_xaxr_dashboard.html) atau [X-Ray](https://aws.amazon.com/xray/faqs/)) di Wilayah dan akun terpisah.
+ Terus dapatkan informasi tentang penurunan layanan terkait [AWS Health](https://aws.amazon.com/premiumsupport/technology/aws-health/). [Buat notifikasi peristiwa AWS Health sesuai keperluan](https://docs.aws.amazon.com/health/latest/ug/user-notifications.html) yang dikirim ke saluran email dan obrolan melalui [Notifikasi Pengguna AWS](https://docs.aws.amazon.com/notifications/latest/userguide/what-is-service.html) serta integrasikan secara programatis dengan [alat pemantauan dan peringatan Anda](https://docs.aws.amazon.com/health/latest/ug/cloudwatch-events-health.html) melalui Amazon EventBridge.
## Sumber daya
**Praktik-praktik terbaik terkait:**
+ [Definisi Ketersediaan](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+ [REL11-BP06 Mengirimkan Notifikasi ketika peristiwa memengaruhi ketersediaan](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_notifications_sent_system.html)
**Dokumen terkait:**
+ [Amazon CloudWatch Synthetics memungkinkan Anda untuk membuat canary pengguna](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [Aktifkan atau Nonaktifkan Pemantauan Mendetail untuk Instans Anda](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-cloudwatch-new.html)
+ [Pemantauan yang Ditingkatkan](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html)
+ [Memantau Grup Auto Scaling dan Instans Anda Menggunakan Amazon CloudWatch](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-monitoring.html)
+ [Memublikasikan Metrik Kustom](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ [Menggunakan Alarm Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Menggunakan Dasbor CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
+ [Menggunakan Dasbor CloudWatch Lintas Akun dan Lintas Wilayah](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_xaxr_dashboard.html)
+ [Menggunakan Penelusuran X-Ray Lintas Akun dan Lintas Wilayah](https://aws.amazon.com/xray/faqs/)
+ [Memahami ketersediaan](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/understanding-availability.html)
**Video terkait:**
+ [Memitigasi kegagalan abu-abu](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/gray-failures.html)
**Contoh terkait:**
+ [One Observability Workshop: Explore X-Ray](https://catalog.workshops.aws/observability/en-US/aws-native/xray/explore-xray)
**Alat terkait:**
+ [CloudWatch](https://aws.amazon.com/cloudwatch/)
+ [X-Ray CloudWatch](https://docs.aws.amazon.com/xray/latest/devguide/security-logging-monitoring.html)
# REL11-BP02 Melakukan failover ke sumber daya yang sehat
Jika terjadi kegagalan sumber daya, sumber daya yang sehat harus terus melayani permintaan. Untuk kerusakan lokasi (seperti Zona Ketersediaan atau Wilayah AWS) pastikan Anda sudah memiliki sistem untuk melakukan failover ke sumber daya yang sehat di lokasi-lokasi yang tidak terkena gangguan.
Saat merancang sebuah layanan, distribusikan beban di seluruh sumber daya, Zona Ketersediaan, atau Wilayah. Oleh karena itu, kegagalan atau gangguan yang terjadi pada satu sumber daya individu dapat dimitigasi dengan mengalihkan lalu lintas ke sumber daya sehat yang masih ada. Pertimbangkan bagaimana layanan ditemukan dan dirutekan jika ada suatu kegagalan yang terjadi.
Rancang layanan Anda dengan mempertimbangkan pemulihan kesalahan. Di AWS, kami merancang layanan untuk meminimalkan waktu pemulihan dari kegagalan dan dampak yang ditimbulkannya terhadap data. Layanan-layanan kami utamanya menggunakan penyimpanan data yang mengenali permintaan hanya setelah disimpan dalam waktu lama di beberapa replika di dalam suatu Wilayah. Layanan dan sumber daya ini dibangun untuk menggunakan isolasi berbasis sel dan menggunakan isolasi kesalahan yang disediakan oleh Zona Ketersediaan. Kami banyak menggunakan otomatisasi di dalam prosedur-prosedur operasional kami. Kami juga mengoptimalkan fungsionalitas “ganti dan mulai ulang” kami untuk melakukan pemulihan secara cepat dari gangguan.
Pola dan desain yang memungkinkan failover berbeda-beda untuk setiap layanan platform AWS. Banyak layanan terkelola native AWS adalah layanan yang secara native multi-Zona Ketersediaan (seperti Lambda atau API Gateway). Layanan-layanan AWS lain (seperti EC2 dan EKS) memerlukan desain praktik terbaik khusus untuk mendukung failover sumber daya atau penyimpanan data di seluruh AZ.
Pemantauan harus disiapkan untuk memeriksa apakah sumber daya failover sehat, melacak kemajuan sumber daya yang melakukan failover, dan memantau pemulihan proses bisnis.
**Hasil yang diinginkan:** Sistem mampu secara otomatis atau manual menggunakan sumber daya baru untuk pulih dari degradasi.
**Anti-pola umum:**
+ Perencanaan kegagalan bukan bagian dari fase perencanaan dan desain.
+ RTO dan RPO tidak ditetapkan.
+ Pemantauan yang tidak memadai untuk mendeteksi sumber daya yang gagal.
+ Isolasi domain kegagalan yang layak.
+ Kegagalan Multi-Wilayah tidak dipertimbangkan.
+ Deteksi kegagalan terlalu sensitif atau agresif saat memutuskan untuk melakukan failover.
+ Tidak menguji atau memvalidasi desain failover.
+ Melakukan otomatisasi pemulihan otomatis, tetapi tidak memberikan notifikasi bahwa pemulihan diperlukan.
+ Kurangnya periode peredaman untuk menghindari kegagalan berulang yang terlalu cepat.
**Manfaat menerapkan praktik terbaik ini:** Anda dapat membangun sistem-sistem yang lebih tangguh yang mempertahankan keandalan saat mengalami kegagalan dengan melakukan degradasi secara mulus dan pulih dengan cepat.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Tinggi
## Panduan implementasi
Layanan-layanan AWS, seperti [Elastic Load Balancing](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-subnets.html) dan [Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-groups.html), dapat membantu Anda mendistribusikan beban di seluruh sumber daya dan Zona Ketersediaan. Oleh karena itu, kegagalan yang terjadi pada suatu sumber daya individu (seperti instans EC2) atau gangguan pada suatu Zona Ketersediaan dapat dimitigasi dengan mengalihkan lalu lintas ke sumber daya sehat yang masih ada.
Untuk beban kerja multi-Wilayah, desainnya lebih rumit. Misalnya, replika baca lintas Wilayah memungkinkan Anda untuk melakukan deployment data ke beberapa Wilayah AWS. Namun, failover masih diperlukan untuk mempromosikan replika baca ke primer kemudian mengarahkan lalu lintas Anda ke titik akhir baru. Amazon Route 53, [Pengontrol Pemulihan Aplikasi Amazon (ARC)](https://aws.amazon.com/application-recovery-controller/), Amazon CloudFront, dan AWS Global Accelerator dapat membantu merutekan lalu lintas ke berbagai Wilayah AWS.
Layanan-layanan AWS, seperti Amazon S3, Lambda, API Gateway, Amazon SQS, Amazon SNS, Amazon SES, Amazon Pinpoint, Amazon ECR, AWS Certificate Manager, EventBridge, atau Amazon DynamoDB, secara otomatis di-deploy ke beberapa Zona Ketersediaan oleh AWS. Jika terjadi kegagalan, layanan-layanan AWS ini secara otomatis merutekan lalu lintas ke lokasi yang sehat. Data disimpan secara redundan di beberapa Zona Ketersediaan dan tetap tersedia.
Untuk Amazon RDS, Amazon Aurora, Amazon Redshift, Amazon EKS, atau Amazon ECS, Multi-AZ adalah opsi konfigurasi. AWS dapat mengarahkan lalu lintas ke instans yang sehat jika failover dimulai. Tindakan failover ini dapat diambil oleh AWS atau sebagaimana diperlukan oleh pelanggan
Untuk instans-instans Amazon EC2 atau tugas-tugas Amazon Redshift, Amazon ECS, atau pod Amazon EKS, pilihlah Zona Ketersediaan yang akan menjadi tujuan deployment. Untuk beberapa desain, Elastic Load Balancing menyediakan solusi untuk mendeteksi instans yang ada di zona yang tidak sehat, dan kemudian merutekan lalu lintas ke zona yang sehat. Penyeimbang Beban Elastis dapat merutekan lalu lintas ke komponen di pusat data on-premise Anda.
Untuk failover lalu lintas Multi-Wilayah, pengalihan rute dapat memanfaatkan Amazon Route 53, Pengontrol Pemulihan Aplikasi Amazon, AWS Global Accelerator, Route 53 Private DNS for VPC, atau CloudFront untuk menyediakan cara menentukan domain internet dan menetapkan kebijakan perutean, termasuk pemeriksaan kondisi, untuk merutekan lalu lintas ke Wilayah yang berkondisi baik. AWS Global Accelerator menyediakan alamat IP statis yang berfungsi sebagai titik masuk tetap ke aplikasi Anda, lalu merutekan ke titik akhir di Wilayah AWS yang Anda pilih, menggunakan jaringan global AWS, bukan internet, demi performa dan keandalan yang lebih baik.
### Langkah-langkah implementasi
+ Buat desain failover untuk semua aplikasi dan layanan yang sesuai. Isolasi setiap komponen arsitektur dan buat desain failover yang memenuhi RTO dan RPO untuk masing-masing komponen.
+ Konfigurasikan lingkungan yang lebih rendah (seperti pengembangan atau pengujian) dengan semua layanan yang diharuskan memiliki rencana failover. Lakukan deployment solusi dengan menggunakan infrastruktur sebagai kode (IaC) untuk memastikan kemampuan pengulangan.
+ Konfigurasikan lokasi pemulihan, misalnya Wilayah kedua, untuk mengimplementasikan dan menguji desain failover. Jika perlu, sumber daya untuk pengujian dapat dikonfigurasi secara sementara untuk membatasi biaya-biaya tambahan.
+ Tentukan rencana failover mana yang akan diotomatisasi oleh AWS, yang dapat diotomatisasi oleh proses DevOps, dan mana yang mungkin dilakukan secara manual. Dokumentasikan dan ukur RTO dan RPO dari masing-masing layanan.
+ Buatlah sebuah playbook failover dan sertakan semua langkah untuk melakukan failover pada setiap sumber daya, aplikasi, dan layanan.
+ Buatlah sebuah playbook failback dan sertakan semua langkah untuk melakukan failback (dengan pengaturan waktu) pada setiap sumber daya, aplikasi, dan layanan
+ Buatlah sebuah rencana untuk memulai dan melatih playbook. Gunakan simulasi dan pengujian kekacauan untuk menguji langkah-langkah dan otomatisasi playbook.
+ Untuk gangguan lokasi (seperti Zona Ketersediaan atau Wilayah AWS), pastikan Anda memiliki sistem untuk melakukan failover ke sumber daya yang sehat di lokasi-lokasi yang tidak terkena gangguan. Periksa kuota, tingkat penskalaan otomatis, dan sumber daya yang berjalan sebelum pengujian failover.
## Sumber daya
**Praktik terbaik Well-Architected terkait:**
+ [REL13 - Merencanakan DR](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-for-disaster-recovery-dr.html)
+ [REL10 - Menggunakan isolasi kesalahan untuk melindungi beban kerja Anda](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/use-fault-isolation-to-protect-your-workload.html)
**Dokumen terkait:**
+ [Menetapkan Target RTO dan RPO](https://aws.amazon.com/blogs/mt/establishing-rpo-and-rto-targets-for-cloud-applications/)
+ [Failover menggunakan perutean tertimbang Route 53](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-2-multi-region-stack)
+ [Pemulihan Bencana dengan Pengontrol Pemulihan Aplikasi Amazon](https://catalog.us-east-1.prod.workshops.aws/workshops/4d9ab448-5083-4db7-bee8-85b58cd53158/en-US/)
+ [EC2 dengan penskalaan otomatis](https://github.com/adriaanbd/aws-asg-ecs-starter)
+ [Deployment EC2 - Multi-AZ](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
+ [Deployment ECS – Multi-AZ](https://github.com/aws-samples/ecs-refarch-cloudformation)
+ [Beralih lalu lintas menggunakan Pengontrol Pemulihan Aplikasi Amazon](https://docs.aws.amazon.com/r53recovery/latest/dg/routing-control.failover-different-accounts.html)
+ [Lambda dengan Penyeimbang Beban Aplikasi dan Failover](https://docs.aws.amazon.com/lambda/latest/dg/services-alb.html)
+ [Replikasi ACM dan Failover](https://github.com/aws-samples/amazon-ecr-cross-region-replication)
+ [Replikasi Penyimpanan Parameter dan Failover](https://medium.com/devops-techable/how-to-design-an-ssm-parameter-store-for-multi-region-replication-support-aws-infrastructure-db7388be454d)
+ [Replikasi lintas wilayah ECR dan Failover](https://docs.aws.amazon.com/AmazonECR/latest/userguide/registry-settings-configure.html)
+ [Konfigurasi replikasi lintas wilayah manajer rahasia](https://disaster-recovery.workshop.aws/en/labs/basics/secrets-manager.html)
+ [Mengaktifkan replikasi lintas wilayah untuk EFS dan Failover](https://aws.amazon.com/blogs/aws/new-replication-for-amazon-elastic-file-system-efs/)
+ [Replikasi Lintas Wilayah EFS dan Failover](https://aws.amazon.com/blogs/storage/transferring-file-data-across-aws-regions-and-accounts-using-aws-datasync/)
+ [Failover Jaringan](https://docs.aws.amazon.com/whitepapers/latest/hybrid-connectivity/aws-dx-dxgw-with-vgw-multi-regions-and-aws-public-peering.html)
+ [Failover titik akhir S3 menggunakan MRAP](https://catalog.workshops.aws/s3multiregionaccesspoints/en-US/0-setup/1-review-mrap)
+ [Membuat replikasi lintas wilayah untuk S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html)
+ [Panduan untuk Failover Lintas Wilayah dan Graceful Failback di AWS](https://d1.awsstatic.com/solutions/guidance/architecture-diagrams/cross-region-failover-and-graceful-failback-on-aws.pdf)
+ [Failover menggunakan akselerator global multi-wilayah](https://aws.amazon.com/blogs/networking-and-content-delivery/deploying-multi-region-applications-in-aws-using-aws-global-accelerator/)
+ [Failover dengan DRS](https://docs.aws.amazon.com/drs/latest/userguide/failback-overview.html)
**Contoh terkait:**
+ [Pemulihan Bencana di AWS](https://disaster-recovery.workshop.aws/en/)
+ [Pemulihan Bencana Elastis di AWS](https://catalog.us-east-1.prod.workshops.aws/workshops/080af3a5-623d-4147-934d-c8d17daba346/en-US)
# REL11-BP03 Melakukan otomatisasi pemulihan di semua lapisan
Setelah kegagalan dideteksi, gunakan kemampuan otomatis untuk melakukan tindakan perbaikan. Degradasi dapat dipulihkan secara otomatis melalui mekanisme servis internal atau memerlukan sumber daya untuk dimulai ulang atau dihapus melalui tindakan remediasi.
Untuk aplikasi yang dikelola secara mandiri dan perbaikan lintas-Wilayah, desain pemulihan dan proses perbaikan otomatis dapat ditarik dari [praktik terbaik yang ada sekarang](https://aws.amazon.com/blogs/architecture/understand-resiliency-patterns-and-trade-offs-to-architect-efficiently-in-the-cloud/).
Kemampuan untuk memulai ulang atau menghapus sumber daya adalah alat yang penting untuk melakukan remediasi kegagalan. Salah satu praktik terbaiknya adalah membuat layanan menjadi stateless, jika memungkinkan. Praktik ini mencegah hilangnya data atau ketersediaan pada saat sumber daya dimulai ulang. Di cloud, Anda dapat (dan umumnya harus) mengganti seluruh sumber daya (misalnya, instans komputasi atau fungsi nirserver) sebagai bagian dari proses mulai ulang. Tindakan memulai ulang itu sendiri adalah cara yang mudah dan andal untuk pulih dari kegagalan. Ada berbagai jenis kegagalan yang terjadi di dalam beban kerja. Kegagalan dapat terjadi di perangkat keras, perangkat lunak, komunikasi, dan operasi.
Memulai ulang atau mencoba ulang juga berlaku untuk permintaan-permintaan jaringan. Terapkan pendekatan pemulihan yang sama terhadap peristiwa waktu habis jaringan maupun kegagalan dependensi di mana dependensi menunjukkan kesalahan. Kedua peristiwa tersebut memiliki efek yang serupa terhadap sistem, sehingga alih-alih berupaya untuk menjadikan masing-masing sebagai kasus spesial, terapkan strategi serupa berupa coba ulang terbatas dengan penundaan eksponensial dan jitter. Kemampuan untuk memulai ulang sebuah adalah mekanisme pemulihan yang disertakan dalam komputasi berorientasi pemulihan dan arsitektur klaster ketersediaan tinggi.
**Hasil yang diinginkan:** Tindakan otomatis dilakukan untuk meremediasi deteksi kegagalan.
**Anti-pola umum:**
+ Menyediakan sumber daya tanpa penskalaan otomatis.
+ Melakukan deployment aplikasi di instans atau kontainer secara terpisah.
+ Melakukan deployment aplikasi yang tidak dapat dilakukan ke beberapa lokasi tanpa menggunakan pemulihan otomatis.
+ Memulihkan secara manual aplikasi yang gagal dipulihkan oleh penskalaan otomatis dan pemulihan otomatis.
+ Tidak ada otomatisasi untuk failover basis data.
+ Tidak ada metode otomatis untuk mengalihkan rute lalu lintas ke titik akhir baru.
+ Tidak ada replikasi penyimpanan.
**Manfaat menerapkan praktik terbaik ini:** Pemulihan otomatis dapat mengurangi waktu rata-rata pemulihan dan meningkatkan ketersediaan Anda.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Tinggi
## Panduan implementasi
Desain untuk Amazon EKS atau layanan Kubernetes lainnya harus mencakup replika minimum dan maksimum atau set stateful dan penyesuaian ukuran klaster dan grup simpul minimum. Mekanisme ini menyediakan jumlah minimum sumber daya pemrosesan yang tersedia secara terus-menerus sambil secara otomatis memulihkan kegagalan apa pun menggunakan bidang kontrol Kubernetes.
Pola desain yang diakses melalui penyeimbang beban menggunakan klaster komputasi harus memanfaatkan grup Auto Scaling (penskalaan otomatis). Elastic Load Balancing (ELB) secara otomatis mendistribusikan lalu lintas aplikasi yang masuk di beberapa target dan perangkat virtual di satu atau beberapa Zona Ketersediaan (AZ).
Desain berbasis komputasi terklaster yang tidak menggunakan penyeimbangan beban harus dirancang ukurannya untuk kehilangan setidaknya satu simpul. Dengan begitu, layanan dapat terus berjalan dalam kapasitas yang kemungkinan lebih rendah saat layanan memulihkan simpul baru. Contoh layanannya adalah Mongo, DynamoDB Accelerator, Amazon Redshift, Amazon EMR, Cassandra, Kafka, MSK-EC2, Couchbase, ELK, dan Amazon OpenSearch Service. Banyak dari layanan-layanan ini dapat dirancang dengan fitur pemulihan otomatis tambahan. Beberapa teknologi klaster harus menghasilkan peringatan atas hilangnya sebuah simpul yang memicu alur kerja otomatis atau manual untuk membuat ulang simpul baru. Alur kerja ini dapat diotomatisasi dengan menggunakan AWS Systems Manager untuk meremediasi masalah dengan cepat.
Amazon EventBridge dapat digunakan untuk memantau dan memfilter peristiwa seperti alarm CloudWatch atau perubahan status di layanan AWS lainnya. Berdasarkan informasi peristiwa, layanan ini kemudian dapat menginvokasi AWS Lambda, Systems Manager Automation, atau target lainnya untuk menjalankan logika remediasi kustom pada beban kerja Anda. Amazon EC2 Auto Scaling dapat dikonfigurasi untuk memeriksa kondisi instans EC2. Jika instans tidak berada dalam status berjalan, atau jika status sistem adalah terganggu, Amazon EC2 Auto Scaling akan menganggap instans tersebut sebagai instans tidak sehat dan kemudian meluncurkan instans pengganti. Untuk penggantian skala besar (seperti hilangnya seluruh Zona Ketersediaan), sebaiknya gunakan stabilitas statis karena ketersediaannya yang tinggi.
### Langkah-langkah implementasi
+ Gunakan grup Auto Scaling (penskalaan otomatis) untuk melakukan deployment tingkatan di sebuah beban kerja. [Penskalaan otomatis](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html) dapat melakukan pemulihan mandiri pada aplikasi tanpa status, dan menambahkan atau menghapus kapasitas.
+ Untuk instans komputasi yang disebutkan sebelumnya, gunakan [penyeimbangan beban](https://docs.aws.amazon.com/autoscaling/ec2/userguide/autoscaling-load-balancer.html) dan pilih jenis penyeimbang beban yang sesuai.
+ Pertimbangkan pemulihan untuk Amazon RDS. Dengan instans siaga, konfigurasikan untuk [failover otomatis](https://repost.aws/questions/QU4DYhqh2yQGGmjE_x0ylBYg/what-happens-after-failover-in-rds) ke instans siaga tersebut. Untuk Amazon RDS Read Replica, alur kerja otomatis diperlukan untuk membuat replika baca primer.
+ Implementasikan [pemulihan otomatis pada instans EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html) dengan aplikasi ter-deploy yang tidak dapat di-deploy di beberapa lokasi, dan dapat mentoleransi boot ulang setelah kegagalan. Pemulihan otomatis dapat digunakan untuk mengganti perangkat keras yang mengalami kegagalan dan memulai ulang instans ketika aplikasi tidak dapat diterapkan di beberapa lokasi. Metadata instans dan alamat IP terkait akan disimpan, begitu juga dengan [volume EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html) dan titik pemasangan (mount) ke [Amazon Elastic File System](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEFS.html) atau [File Systems untuk Lustre](https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html) dan [Windows](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html). Dengan menggunakan [AWS OpsWorks](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html), Anda dapat mengonfigurasi pemulihan otomatis instans EC2 pada tingkat lapisan.
+ Implementasikan pemulihan otomatis dengan menggunakan [AWS Step Functions](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html) dan [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) ketika Anda tidak dapat menggunakan penskalaan otomatis atau pemulihan otomatis, atau ketika pemulihan otomatis gagal. Ketika Anda tidak dapat menggunakan penskalaan otomatis, dan tidak dapat menggunakan pemulihan otomatis atau pemulihan otomatis gagal, Anda dapat mengotomatiskan pemulihan dengan menggunakan AWS Step Functions dan AWS Lambda.
+ [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html) dapat digunakan untuk memantau dan memfilter peristiwa seperti [alarm CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) atau perubahan status di layanan AWS lainnya. Berdasarkan informasi peristiwa, layanan ini kemudian dapat menginvokasi AWS Lambda (atau target-target lainnya) untuk menjalankan logika remediasi kustom pada beban kerja Anda.
## Sumber daya
**Praktik-praktik terbaik terkait:**
+ [Definisi Ketersediaan](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+ [REL11-BP01 Memantau semua komponen beban kerja untuk mendeteksi kegagalan](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_notifications_sent_system.html)
**Dokumen terkait:**
+ [Cara Kerja AWS Auto Scaling](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ [Pemulihan Otomatis Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html)
+ [Amazon Elastic Block Store (Amazon EBS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html)
+ [Amazon Elastic File System (Amazon EFS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEFS.html)
+ [Apa itu Amazon FSx for Lustre?](https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html)
+ [Apa itu Amazon FSx for Windows File Server?](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html)
+ [AWS OpsWorks: Menggunakan Auto Healing untuk Mengganti Instans yang Gagal](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html)
+ [Apa itu AWS Step Functions?](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.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)
+ [Failover Amazon RDS](https://d1.awsstatic.com/rdsImages/IG1_RDS1_AvailabilityDurability_Final.pdf)
+ [SSM - Systems Manager Automation](https://docs.aws.amazon.com/resilience-hub/latest/userguide/integrate-ssm.html)
+ [Praktik Terbaik Arsitektur Tangguh](https://aws.amazon.com/blogs/architecture/understand-resiliency-patterns-and-trade-offs-to-architect-efficiently-in-the-cloud/)
**Video terkait:**
+ [Penyediaan Secara Otomatis dan Menskalakan Layanan OpenSearch](https://www.youtube.com/watch?v=GPQKetORzmE)
+ [Failover Otomatis Amazon RDS](https://www.youtube.com/watch?v=Mu7fgHOzOn0)
**Contoh terkait:**
+ [Lokakarya Failover Amazon RDS](https://catalog.workshops.aws/resilient-apps/en-US/rds-multi-availability-zone/failover-db-instance)
**Alat terkait:**
+ [CloudWatch](https://aws.amazon.com/cloudwatch/)
+ [X-Ray CloudWatch](https://docs.aws.amazon.com/xray/latest/devguide/security-logging-monitoring.html)
# REL11-BP04 Mengandalkan bidang data dan bukan bidang kontrol selama pemulihan
bidang kontrol menyediakan API administratif yang digunakan untuk membuat, membaca, dan mendeskripsikan, memperbarui, menghapus, dan mencantumkan (CRUDL) sumber daya, sedangkan bidang data menangani lalu lintas layanan sehari-hari. Saat mengimplementasikan respons pemulihan atau mitigasi terhadap peristiwa yang berpotensi berdampak pada ketahanan, fokuslah pada penggunaan operasi bidang kontrol dalam jumlah minim untuk memulihkan, mengubah skala, mengembalikan, memperbaiki, atau melakukan failover layanan. Tindakan bidang data harus menggantikan aktivitas apa pun selama terjadi peristiwa degradasi ini.
Misalnya, berikut ini adalah semua tindakan bidang kontrol: meluncurkan instans komputasi baru, membuat penyimpanan blok, dan mendeskripsikan layanan antrean. Saat Anda meluncurkan instans komputasi, bidang kontrol harus melakukan beberapa tugas seperti menemukan temuan host fisik dengan kapasitas, mengalokasikan antarmuka jaringan, menyiapkan volume penyimpanan blok lokal, menghasilkan kredensial, dan menambahkan aturan keamanan. Orkestrasi bidang kontrol cenderung rumit.
**Hasil yang diinginkan:** Ketika sumber daya memasuki keadaan terganggu, sistem mampu pulih secara otomatis atau manual dengan mengalihkan lalu lintas dari sumber daya yang terganggu ke sumber daya yang sehat.
**Anti-pola umum:**
+ Ketergantungan pada pengubahan catatan DNS untuk merutekan ulang lalu lintas.
+ Ketergantungan pada operasi penskalaan bidang kontrol untuk menggantikan komponen yang terganggu karena sumber daya yang disediakan tidak memadai.
+ Mengandalkan tindakan bidang kontrol ekstensif multi-API dan multi layanan untuk meremediasi kategori gangguan apa pun.
**Manfaat menerapkan praktik terbaik ini:** Peningkatan tingkat keberhasilan untuk remediasi otomatis dapat mengurangi waktu rata-rata pemulihan Anda dan meningkatkan ketersediaan beban kerja.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Sedang: Untuk jenis degradasi layanan tertentu, bidang kontrol terpengaruh. Ketergantungan pada penggunaan bidang kontrol secara ekstensif untuk remediasi dapat meningkatkan waktu pemulihan (RTO) dan rata-rata waktu untuk pulih (MTTR).
## Panduan implementasi
Untuk membatasi tindakan bidang data, lakukan penilaian atas setiap layanan untuk menemukan tindakan-tindakan yang diperlukan untuk memulihkan layanan.
Manfaatkan Pengendali Pemulihan Aplikasi Amazon untuk menggeser lalu lintas DNS. Fitur-fitur ini akan terus-menerus memantau kemampuan aplikasi Anda untuk pulih dari kegagalan, dan memampukan Anda untuk mengontrol pemulihan aplikasi di beberapa Wilayah AWS, Zona Ketersediaan, dan on-premise.
Kebijakan perutean Route 53 menggunakan bidang kontrol, jadi jangan mengandalkannya untuk pemulihan. Bidang data Route 53 menjawab kueri DNS, dan melakukan serta mengevaluasi pemeriksaan kondisi. Mereka didistribusikan secara global dan dirancang untuk [perjanjian tingkat layanan (SLA) ketersediaan 100%](https://aws.amazon.com/route53/sla/).
Konsol dan API manajemen Route 53 di mana Anda membuat, memperbarui, dan menghapus sumber daya Route 53 dijalankan di bidang kontrol yang didesain untuk memprioritaskan durabilitas dan konsistensi tinggi yang Anda perlukan ketika mengelola DNS. Untuk mencapai hal ini, bidang kontrol ditempatkan di satu Wilayah: AS Timur (Virginia Utara). Walaupun kedua sistem dibangun agar sangat andal, bidang kontrol tidak disertakan dalam SLA. Mungkin ada peristiwa langka di mana desain tangguh bidang data memungkinkannya untuk mempertahankan ketersediaan sedangkan bidang kontrol tidak. Untuk mekanisme failover dan pemulihan bencana, Anda harus menggunakan fungsi bidang data untuk memberikan keandalan yang sebaik mungkin.
Rancang infrastruktur komputasi Anda agar mencapai stabilitas statis, sehingga Anda dapat menghindari penggunaan bidang kontrol selama insiden. Misalnya, jika Anda menggunakan instans Amazon EC2, jangan menyediakan instans baru secara manual atau menginstruksikan Grup Auto Scaling untuk menambahkan instans sebagai respons. Untuk tingkat ketahanan tertinggi, berikan kapasitas yang cukup di klaster yang digunakan untuk failover. Jika ambang kapasitas ini harus dibatasi, tetapkan throttling pada keseluruhan sistem menyeluruh untuk membatasi lalu lintas total yang mencapai set sumber daya terbatas.
Untuk layanan-layanan seperti Amazon DynamoDB, Amazon API Gateway, penyeimbang beban dan nirserver AWS Lambda, penggunaan layanan-layanan tersebut memanfaatkan bidang data. Namun, pembuatan fungsi baru, penyeimbang beban, API gateway, atau tabel DynamoDB adalah tindakan bidang kontrol dan harus diselesaikan sebelum degradasi sebagai persiapan peristiwa dan latihan tindakan failover. Untuk Amazon RDS, tindakan bidang data memungkinkan akses ke data.
Untuk informasi selengkapnya tentang bidang data, bidang kontrol, dan bagaimana AWS membangun layanan untuk memenuhi target ketersediaan tinggi, silakan lihat [Stabilitas statis menggunakan Zona Ketersediaan](https://aws.amazon.com/builders-library/static-stability-using-availability-zones/).
Pahami operasi mana yang ada di bidang data dan mana yang ada di bidang kontrol.
### Langkah-langkah implementasi
Untuk setiap beban kerja yang perlu dipulihkan setelah terjadinya peristiwa degradasi, lakukan evaluasi terhadap runbook failover, desain ketersediaan tinggi, desain perbaikan otomatis, atau rencana pemulihan sumber daya HA. Identifikasi setiap tindakan yang mungkin dianggap sebagai tindakan bidang kontrol.
Pertimbangkan mengubah tindakan kontrol ke tindakan bidang data:
+ Auto Scaling (bidang kontrol) menjadi sumber daya Amazon EC2 yang telah diskalakan sebelumnya (bidang data)
+ Penskalaan instans Amazon EC2 (bidang kontrol) menjadi penskalaan AWS Lambda (bidang data)
+ Nilai desain apa pun menggunakan Kubernetes dan sifat tindakan bidang kontrol. Menambahkan pod adalah tindakan bidang data di Kubernetes. Tindakan harus dibatasi ke penambahan pod dan bukan ke penambahan simpul. Menggunakan [simpul yang disediakan secara berlebihan](https://www.eksworkshop.com/docs/autoscaling/compute/cluster-autoscaler/overprovisioning/) adalah metode yang lebih disukai untuk membatasi tindakan bidang kontrol
Pertimbangkan pendekatan alternatif yang memungkinkan tindakan-tindakan bidang data untuk memengaruhi remediasi yang sama.
+ Perubahan Catatan Route 53 (bidang kontrol) atau Pengontrol Pemulihan Aplikasi Amazon (bidang data)
+ [ Pemeriksaan kondisi Route 53 untuk pembaruan yang lebih otomatis ](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/)
Pertimbangkan beberapa layanan di Wilayah sekunder, jika layanan sangat penting, untuk memungkinkan lebih banyak tindakan bidang kontrol dan bidang data di Wilayah yang tidak terdampak.
+ Amazon EC2 Auto Scaling atau Amazon EKS di Wilayah primer dibandingkan dengan Amazon EC2 Auto Scaling atau Amazon EKS di Wilayah sekunder dan merutekan lalu lintas ke Wilayah sekunder (tindakan bidang kontrol)
+ Membuat replika baca di primer sekunder atau mencoba tindakan yang sama di Wilayah primer (tindakan bidang kontrol)
## Sumber daya
**Praktik-praktik terbaik terkait:**
+ [Definisi Ketersediaan](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+ [REL11-BP01 Memantau semua komponen beban kerja untuk mendeteksi kegagalan](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_notifications_sent_system.html)
**Dokumen terkait:**
+ [Partner APN: partner yang dapat membantu dengan otomatisasi toleransi kesalahan Anda](https://aws.amazon.com/partners/find/results/?keyword=automation)
+ [AWS Marketplace: produk yang dapat digunakan untuk toleransi kesalahan](https://aws.amazon.com/marketplace/search/results?searchTerms=fault+tolerance)
+ [Amazon Builders’ Library: Menghindari kelebihan beban dalam sistem terdistribusi dengan mengontrol layanan yang lebih kecil](https://aws.amazon.com/builders-library/avoiding-overload-in-distributed-systems-by-putting-the-smaller-service-in-control/)
+ [API Amazon DynamoDB (bidang kontrol dan bidang data)](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.API.html)
+ [Eksekusi AWS Lambda](https://docs.aws.amazon.com/whitepapers/latest/security-overview-aws-lambda/lambda-executions.html) (dibagi menjadi bidang kontrol dan bidang data)
+ [Bidang Data AWS Elemental MediaStore](https://docs.aws.amazon.com/mediastore/latest/apireference/API_Operations_AWS_Elemental_MediaStore_Data_Plane.html)
+ [Membangun aplikasi yang sangat tangguh dengan menggunakan Pengontrol Pemulihan Aplikasi Amazon, Bagian 1: Tumpukan Wilayah Tunggal](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-1-single-region-stack/)
+ [Membangun aplikasi yang sangat tangguh dengan menggunakan Pengontrol Pemulihan Aplikasi Amazon, Bagian 2: Tumpukan Multi-Wilayah](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-2-multi-region-stack/)
+ [Membuat Mekanisme Pemulihan Bencana Menggunakan Amazon Route 53](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/)
+ [Apa itu Pengontrol Pemulihan Aplikasi Amazon?](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
+ [ Bidang kontrol dan bidang data Kubernetes ](https://aws.amazon.com/blogs/containers/managing-kubernetes-control-plane-events-in-amazon-eks/)
**Video terkait:**
+ [ Kembali ke Dasar - Menggunakan Stabilitas Statis ](https://www.youtube.com/watch?v=gy1RITZ7N7s)
+ [ Membangun beban kerja multi-lokasi yang tangguh menggunakan layanan global AWS](https://www.youtube.com/watch?v=62ZQHTruBnk)
**Contoh terkait:**
+ [Memperkenalkan Pengontrol Pemulihan Aplikasi Amazon](https://aws.amazon.com/blogs/aws/amazon-route-53-application-recovery-controller/)
+ [ Amazon Builders' Library: Menghindari kelebihan beban dalam sistem terdistribusi dengan mengontrol layanan yang lebih kecil ](https://aws.amazon.com/builders-library/avoiding-overload-in-distributed-systems-by-putting-the-smaller-service-in-control/)
+ [ Membangun aplikasi yang sangat tangguh dengan menggunakan Pengontrol Pemulihan Aplikasi Amazon, Bagian 1: Tumpukan Wilayah Tunggal ](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-1-single-region-stack/)
+ [ Membangun aplikasi yang sangat tangguh dengan menggunakan Pengontrol Pemulihan Aplikasi Amazon, Bagian 2: Tumpukan Multi-Wilayah ](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-2-multi-region-stack/)
+ [ Stabilitas statis menggunakan Zona Ketersediaan ](https://aws.amazon.com/builders-library/static-stability-using-availability-zones/)
**Alat terkait:**
+ [ Amazon CloudWatch ](https://aws.amazon.com/cloudwatch/)
+ [AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/security-logging-monitoring.html)
# REL11-BP05 Menggunakan stabilitas statis untuk mencegah perilaku bimodal
Beban kerja harus stabil secara statis dan hanya beroperasi dalam mode normal tunggal. Perilaku bimodal adalah ketika beban kerja Anda menunjukkan perilaku yang berbeda dalam mode normal dan mode kegagalan.
Misalnya, Anda mungkin mencoba untuk melakukan pemulihan dari kegagalan Zona Ketersediaan dengan meluncurkan instans baru di Zona Ketersediaan yang berbeda. Hal ini dapat menyebabkan respons bimodal saat berada dalam mode kegagalan. Sebagai gantinya, Anda harus membangun beban kerja yang stabil secara statis dan beroperasi dalam satu mode saja. Dalam contoh ini, instans-instans tersebut seharusnya telah disediakan di Zona Ketersediaan kedua sebelum terjadinya kegagalan. Desain stabilitas statis ini memastikan beban kerja hanya beroperasi dalam satu mode tunggal.
**Hasil yang diinginkan:** Beban kerja tidak menunjukkan perilaku bimodal selama mode normal dan mode kegagalan.
**Anti-pola umum:**
+ Asumsikan bahwa sumber daya selalu dapat disediakan terlepas dari ruang lingkup kegagalannya.
+ Mencoba memperoleh sumber daya secara dinamis selama terjadi kegagalan.
+ Tidak menyediakan sumber daya yang memadai di seluruh zona atau Wilayah sampai terjadi kegagalan.
+ Mempertimbangkan desain stabil statis hanya untuk sumber daya komputasi.
**Manfaat menerapkan praktik terbaik ini:** Beban kerja yang berjalan dengan desain yang stabil secara statis mampu memiliki hasil-hasil yang dapat diprediksi selama terjadi peristiwa normal dan kegagalan.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Sedang
## Panduan implementasi
Perilaku bimodal terjadi ketika beban kerja Anda menunjukkan perilaku yang berbeda dalam mode normal dan mode gagal, (misalnya, mengandalkan peluncuran instans baru jika Zona Ketersediaan gagal). Contoh perilaku bimodal adalah ketika desain Amazon EC2 yang stabil menyediakan instans yang cukup di setiap Zona Ketersediaan untuk menangani beban dari beban kerja jika satu AZ disingkirkan. Penyeimbang Beban Elastis atau kesehatan Amazon Route 53 akan memeriksa untuk mengalihkan beban dari instans yang terganggu. Setelah lalu lintas dipindahkan, gunakan AWS Auto Scaling untuk mengganti instans secara tak selaras dari zona yang gagal dan luncurkan di zona sehat. Stabilitas statis untuk deployment komputasi (seperti kontainer atau instans EC2) akan menghasilkan keandalan yang paling tinggi.
![\[Diagram yang menunjukkan stabilitas statis instans EC2 di seluruh Zona Ketersediaan\]](http://docs.aws.amazon.com/id_id/wellarchitected/latest/reliability-pillar/images/static-stability.png)
Ini harus ditimbang berdasarkan biaya untuk model ini serta nilai bisnis untuk memelihara beban kerja berdasarkan semua kasus ketahanan. Menyediakan kapasitas komputasi yang lebih sedikit dan mengandalkan peluncuran instans baru apabila terjadi kegagalan memang lebih murah, tetapi untuk kegagalan-kegagalan berskala besar (seperti gangguan pada Zona Ketersediaan atau Regional), pendekatan ini kurang efektif karena bergantung pada bidang operasional serta sumber daya yang tersedia di zona atau Wilayah yang tidak terdampak.
Solusi Anda harus mengukur keandalan berdasarkan kebutuhan biaya untuk beban kerja Anda. Arsitektur stabilitas statis berlaku untuk berbagai arsitektur termasuk instans komputasi yang tersebar di Zona Ketersediaan, desain replika baca basis data, desain klaster Kubernetes (Amazon EKS), dan arsitektur failover multi-Wilayah.
Anda juga dapat menerapkan desain yang lebih stabil secara statis dengan menggunakan lebih banyak sumber daya di setiap zona. Dengan menggunakan lebih banyak zona, Anda mengurangi jumlah komputasi tambahan yang Anda perlukan untuk stabilitas statis.
Contoh perilaku bimodal adalah batas waktu jaringan yang dapat menyebabkan sebuah sistem untuk mencoba melakukan refresh status konfigurasi seluruh sistem. Ini akan menambahkan beban yang tak terduga ke komponen lain dan dapat menyebabkan komponen tersebut mengalami kegagalan, sehingga menimbulkan konsekuensi-konsekuensi lain yang tak diharapkan. Putaran umpan balik negatif ini memengaruhi ketersediaan beban kerja Anda. Sebagai gantinya, Anda dapat membangun sistem yang stabil secara statis dan beroperasi dalam satu mode saja. Desain yang stabil secara statis akan melakukan tugas yang konstan, dan selalu menyegarkan status konfigurasi dengan irama yang teratur. Ketika sebuah panggilan gagal, beban kerja akan menggunakan nilai yang sebelumnya di-cache, dan memulai alarm.
Contoh perilaku bimodal lainnya adalah memperbolehkan klien untuk melewati cache beban kerja Anda ketika kegagalan terjadi. Ini mungkin terlihat seperti solusi yang mengakomodasi kebutuhan klien, tetapi hal ini secara signifikan dapat mengubah permintaan di beban kerja Anda dan kemungkinan akan mengakibatkan kegagalan.
Lakukan penilaian beban kerja kritis untuk menentukan beban kerja apa yang memerlukan jenis desain ketahanan ini. Untuk beban kerja yang dianggap kritis, setiap komponen aplikasi harus ditinjau. Contoh jenis layanan yang memerlukan evaluasi stabilitas statis adalah:
+ **Komputasi**: Amazon EC2, EKS-EC2, ECS-EC2, EMR-EC2
+ **Basis Data**: Amazon Redshift, Amazon RDS, Amazon Aurora
+ **Penyimpanan**: Amazon S3 (Zona Tunggal), Amazon EFS (dudukan), Amazon FSx (dudukan)
+ **Penyeimbang beban:** Menggunakan desain tertentu
### Langkah-langkah implementasi
+ Bangun sistem yang stabil secara statis dan hanya beroperasi dalam satu mode saja. Dalam hal ini, sediakan cukup instans di setiap Zona Ketersediaan atau Wilayah untuk menangani kapasitas beban kerja jika satu Zona Ketersediaan atau Wilayah dihapus. Berbagai layanan dapat digunakan untuk perutean ke sumber daya yang sehat, seperti:
+ [Perutean DNS Lintas Wilayah](https://docs.aws.amazon.com/whitepapers/latest/real-time-communication-on-aws/cross-region-dns-based-load-balancing-and-failover.html)
+ [Perutean MRAP Amazon S3 MultiRegion](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiRegionAccessPointRequestRouting.html)
+ [AWS Global Accelerator](https://aws.amazon.com/global-accelerator/)
+ [Pengontrol Pemulihan Aplikasi Amazon](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
+ Konfigurasikan [replika baca basis data](https://aws.amazon.com/rds/features/multi-az/) untuk memperhitungkan hilangnya satu instans utama atau replika baca. Jika lalu lintas dilayani oleh replika baca, maka kuantitas di setiap Zona Ketersediaan dan setiap Wilayah harus sama dengan kebutuhan keseluruhan jika terjadi kegagalan zona atau Wilayah.
+ Konfigurasikan data kritis di dalam penyimpanan Amazon S3 yang dirancang agar stabil secara statis untuk data yang disimpan jika terjadi kegagalan Zona Ketersediaan. Jika kelas penyimpanan [Amazon S3 One Zone-IA](https://aws.amazon.com/about-aws/whats-new/2018/04/announcing-s3-one-zone-infrequent-access-a-new-amazon-s3-storage-class/) digunakan, ini tidak boleh dianggap stabil secara statis, karena hilangnya zona tersebut akan meminimalkan akses ke data yang disimpan.
+ [Penyeimbang beban](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/disable-cross-zone.html) terkadang dikonfigurasi secara salah atau secara bawaan untuk melayani satu Zona Ketersediaan tertentu. Dalam hal ini, desain yang stabil secara statis mungkin adalah menyebarkan beban kerja di beberapa AZ dalam desain yang lebih kompleks. Desain asli dapat digunakan untuk mengurangi lalu lintas antar zona karena alasan keamanan, latensi, atau biaya.
## Sumber daya
**Praktik terbaik Well-Architected terkait:**
+ [Definisi Ketersediaan](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+ [REL11-BP01 Memantau semua komponen beban kerja untuk mendeteksi kegagalan](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_notifications_sent_system.html)
+ [REL11-BP04 Mengandalkan bidang data dan bukan bidang kontrol selama pemulihan](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_avoid_control_plane.html)
**Dokumen terkait:**
+ [Meminimalkan Ketergantungan dalam Rencana Pemulihan Bencana](https://aws.amazon.com/blogs/architecture/minimizing-dependencies-in-a-disaster-recovery-plan/)
+ [Amazon Builders' Library: Stabilitas statis menggunakan Zona Ketersediaan](https://aws.amazon.com/builders-library/static-stability-using-availability-zones)
+ [Batas Isolasi Kesalahan](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/appendix-a---partitional-service-guidance.html)
+ [Stabilitas statis menggunakan Zona Ketersediaan](https://aws.amazon.com/builders-library/static-stability-using-availability-zones)
+ [RDS Multi-Zona](https://aws.amazon.com/rds/features/multi-az/)
+ [Meminimalkan Ketergantungan dalam Rencana Pemulihan Bencana](https://aws.amazon.com/blogs/architecture/minimizing-dependencies-in-a-disaster-recovery-plan/)
+ [Perutean DNS Lintas Wilayah](https://docs.aws.amazon.com/whitepapers/latest/real-time-communication-on-aws/cross-region-dns-based-load-balancing-and-failover.html)
+ [Perutean MRAP Amazon S3 MultiRegion](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiRegionAccessPointRequestRouting.html)
+ [AWS Global Accelerator](https://aws.amazon.com/global-accelerator/)
+ [Pengontrol Pemulihan Aplikasi Amazon](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
+ [Amazon S3 Zona Tunggal](https://aws.amazon.com/about-aws/whats-new/2018/04/announcing-s3-one-zone-infrequent-access-a-new-amazon-s3-storage-class/)
+ [Penyeimbangan Beban Lintas Zona](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/disable-cross-zone.html)
**Video terkait:**
+ [Stabilitas statis di AWS: AWS re:Invent 2019: Memperkenalkan Amazon Builders' Library (DOP328)](https://youtu.be/sKRdemSirDM?t=704)
# REL11-BP06 Mengirimkan notifikasi ketika peristiwa memengaruhi ketersediaan
Notifikasi dikirimkan setelah pelanggaran ambang batas terdeteksi, bahkan apabila peristiwa yang menyebabkan masalah tersebut sudah diatasi secara otomatis.
Pemulihan otomatis menjadikan beban kerja Anda andal. Namun demikian, kemampuan ini juga menyembunyikan masalah dasar yang perlu diatasi. Implementasikan pemantauan peristiwa yang baik agar Anda dapat mendeteksi setiap pola masalah, termasuk masalah-masalah yang ditangani oleh pemulihan otomatis, sehingga Anda dapat mengatasi akar penyebab masalahnya.
Sistem yang tangguh dirancang sedemikian rupa sehingga setiap terjadi peristiwa degradasi langsung dikomunikasikan kepada tim yang tepat. Notifikasi ini harus dikirim melalui satu atau banyak saluran komunikasi.
**Hasil yang diinginkan: **Pemberitahuan langsung dikirim ke tim operasi ketika ambang batas dilanggar, seperti tingkat kesalahan, latensi, atau metrik indikator performa utama (KPI) penting lainnya, sehingga masalah ini diselesaikan sesegera mungkin dan dampak terhadap pengguna dapat dicegah atau diminimalkan.
**Anti-pola umum:**
+ Mengirimkan terlalu banyak alarm.
+ Mengirimkan alarm yang tidak dapat ditindaklanjuti.
+ Mengatur ambang alarm terlalu tinggi (terlalu sensitif) atau terlalu rendah (kurang sensitif).
+ Tidak mengirimkan alarm untuk dependensi eksternal.
+ Tidak mempertimbangkan [kegagalan abu-abu](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/gray-failures.html) saat merancang pemantauan dan alarm.
+ Melakukan otomatisasi pemulihan, tetapi tidak memberikan notifikasi kepada tim yang tepat bahwa pemulihan diperlukan.
**Manfaat menerapkan praktik terbaik ini:** Notifikasi pemulihan membuat tim operasional dan bisnis menyadari adanya degradasi layanan sehingga mereka dapat segera bereaksi untuk meminimalkan waktu deteksi rata-rata (MTTD) dan waktu perbaikan rata-rata (MTTR). Notifikasi peristiwa pemulihan juga menjamin bahwa Anda tidak mengabaikan masalah yang jarang terjadi.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Sedang. Kegagalan mengimplementasikan mekanisme pemantauan dan notifikasi peristiwa secara tepat dapat mengakibatkan terjadinya kegagalan dalam mendeteksi pola masalah, termasuk masalah yang ditangani oleh pemulihan otomatis. Sebuah tim hanya akan menyadari adanya degradasi sistem ketika pengguna menghubungi layanan pelanggan atau secara kebetulan.
## Panduan implementasi
Saat menetapkan strategi pemantauan, alarm yang dipicu adalah sebuah peristiwa umum. Peristiwa ini kemungkinan berisi pengidentifikasi untuk alarm, status alarm (seperti `IN ALARM` dan `OK`), dan detail tentang apa yang memicunya. Dalam banyak kasus, sebuah peristiwa alarm seharusnya dideteksi dan email notifikasi dikirimkan. Ini adalah contoh tindakan pada alarm. Notifikasi alarm sangat penting dalam hal observabilitas karena notifikasi ini memberi tahu orang yang tepat bahwa ada masalah. Namun demikian, ketika tindakan terhadap peristiwa sudah matang di dalam solusi observabilitas Anda, tindakan tersebut dapat secara otomatis memperbaiki masalah tanpa memerlukan campur tangan manusia.
Setelah alarm pemantauan KPI ditetapkan, peringatan seharusnya dikirimkan ke tim yang tepat ketika ambang batas terlampaui. Peringatan tersebut juga dapat digunakan untuk memicu proses otomatis yang akan mencoba memperbaiki degradasi.
Untuk pemantauan ambang batas yang lebih kompleks, alarm gabungan harus dipertimbangkan. Alarm gabungan menggunakan sejumlah alarm pemantauan KPI untuk membuat peringatan berdasarkan logika bisnis operasional. Alarm CloudWatch dapat dikonfigurasi untuk mengirimkan email, atau untuk mencatatkan log insiden di dalam sistem pelacakan insiden pihak ketiga menggunakan integrasi Amazon SNS atau Amazon EventBridge.
### Langkah-langkah implementasi
Buat berbagai jenis alarm berdasarkan cara yang digunakan untuk memantau beban kerja, seperti:
+ Alarm aplikasi digunakan untuk mendeteksi ketika ada bagian dari beban kerja Anda yang tidak berfungsi dengan baik.
+ [Alarm infrastruktur](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) menunjukkan kapan Anda harus menskalakan sumber daya. Alarm dapat ditampilkan secara visual di dasbor, mengirimkan peringatan melalui Amazon SNS atau email, dan menggunakan Penskalaan Otomatis untuk menaikkan atau menurunkan skala sumber daya beban kerja.
+ [Alarm statis](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html) dapat dibuat untuk memantau ketika sebuah metrik melanggar ambang batas statis selama periode evaluasi tertentu.
+ [Alarm gabungan](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Composite_Alarm.html) dapat memperhitungkan alarm-alarm kompleks dari berbagai sumber.
+ Setelah alarm dibuat, buatlas peristiwa-peristiwa notifikasi yang sesuai. Anda dapat langsung menginvokasi sebuah [Amazon SNS API](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) untuk mengirim notifikasi dan menautkan otomatisasi apa pun untuk remediasi atau komunikasi.
+ Terus dapatkan informasi tentang penurunan layanan terkait [AWS Health](https://aws.amazon.com/premiumsupport/technology/aws-health/). [Buat notifikasi peristiwa AWS Health sesuai keperluan](https://docs.aws.amazon.com/health/latest/ug/user-notifications.html) yang dikirim ke saluran email dan obrolan melalui [Notifikasi Pengguna AWS](https://docs.aws.amazon.com/notifications/latest/userguide/what-is-service.html) serta integrasikan secara programatis dengan [alat pemantauan dan peringatan Anda](https://docs.aws.amazon.com/health/latest/ug/cloudwatch-events-health.html) melalui Amazon EventBridge.
## Sumber daya
**Praktik terbaik Well-Architected terkait:**
+ [Definisi Ketersediaan](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
**Dokumen terkait:**
+ [Membuat Alarm Berdasarkan Ambang Batas Statis](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html)
+ [Apa itu Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Apa itu Amazon Simple Notification Service?](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)
+ [Memublikasikan Metrik Kustom](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ [Menggunakan Alarm Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Menyiapkan alarm CloudWatch Composite](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Composite_Alarm.html)
+ [Yang baru di Observabilitas AWS di re:Invent 2022](https://aws.amazon.com/blogs/mt/whats-new-in-aws-observability-at-reinvent-2022/)
**Alat terkait:**
+ [CloudWatch](https://aws.amazon.com/cloudwatch/)
+ [X-Ray CloudWatch](https://docs.aws.amazon.com/xray/latest/devguide/security-logging-monitoring.html)
# REL11-BP07 Merancang produk Anda agar memenuhi target-target ketersediaan dan perjanjian tingkat layanan (SLA) waktu aktif
Rancang produk Anda agar memenuhi target-target ketersediaan dan perjanjian tingkat layanan (SLA) waktu aktif. Jika Anda memublikasi atau secara pribadi menyetujui target-target ketersediaan atau SLA yang berlaku, verifikasikan bahwa proses operasional dan arsitektur Anda didesain untuk mendukungnya.
**Hasil yang diinginkan:** Setiap aplikasi memiliki target yang ditentukan untuk ketersediaan dan SLA untuk metrik kinerja, yang dapat Anda pantau dan pelihara untuk memenuhi hasil bisnis.
**Anti-pola umum:**
+ Mendesain dan melakukan deployment beban kerja tanpa menetapkan SLA apa pun.
+ Metrik SLA ditetapkan ke tingkat tinggi tanpa rasional atau persyaratan bisnis.
+ Menetapkan SLA tanpa memperhitungkan dependensi dan SLA yang mendasarinya.
+ Desain aplikasi dibuat tanpa mempertimbangkan Model Tanggung Jawab Bersama untuk Ketangguhan.
**Manfaat menerapkan praktik terbaik ini:** Merancang aplikasi berdasarkan target ketahanan utama akan membantu Anda dalam memenuhi tujuan bisnis dan harapan pelanggan. Tujuan-tujuan ini membantu mendorong proses desain aplikasi yang mengevaluasi berbagai macam teknologi dan mempertimbangkan beragam kompromi.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Sedang
## Panduan implementasi
Desain aplikasi harus memperhitungkan berbagai rangkaian persyaratan yang didapatkan dari tujuan bisnis, operasional, dan finansial. Dalam persyaratan operasional, beban kerja harus memiliki target-target metrik ketangguhan tertentu sehingga dapat dipantau dan dukung dengan sesuai. Metrik-metrik ketangguhan tidak boleh ditetapkan atau didapatkan setelah melakukan deployment beban kerja. Metrik-metrik ketangguhan tersebut harus ditetapkan selama fase desain dan membantu memandu berbagai keputusan dan kompromi.
+ Setiap beban kerja harus memiliki rangkaian metrik-metrik ketangguhannya sendiri. Metrik-metrik tersebut mungkin berbeda dari aplikasi bisnis yang lain.
+ Mengurangi dependensi dapat memiliki dampak positif pada ketersediaan. Setiap beban kerja harus mempertimbangkan dependensinya serta SLA-nya. Secara umum, pilihlah dependensi dengan target ketersediaan yang setara dengan atau lebih besar dari target beban kerja Anda.
+ Pertimbangkan desain yang mengunakan penggabungan longgar sehingga beban kerja Anda dapat beroperasi dengan benar meskipun ada gangguan dependensi, apabila mungkin.
+ Kurangi dependensi bidang kontrol, terutama selama pemulihan atau degradasi. Evaluasi desain yang secara statis stabil untuk beban kerja yang penting bagi misi. Gunakan penghematan sumber daya untuk meningkatkan ketersediaan dependensi tersebut di sebuah beban kerja.
+ Observabilitas dan instrumentasi sangat penting untuk mencapai SLA dengan mengurangi Waktu Rata-Rata ke Deteksi (MTTD) dan Waktu Rata-Rata ke Perbaikan (MTTR).
+ Kegagalan lebih jarang (MTBF lebih lama), waktu deteksi kegagalan lebih pendek (MTTD lebih singkat), dan waktu perbaikan lebih singkat (MTTR lebih singkat) adalah tiga faktor yang digunakan untuk meningkatkan ketersediaan di sistem terdistribusi.
+ Menetapkan dan memenuhi metrik-metrik ketangguhan untuk beban kerja merupakan fondasi dari desain yang efektif. Desain tersebut harus memperhitungkan berbagai kompromi terkait kompleksitas desain, dependensi layanan, performa, penskalaan, dan biaya.
**Langkah-langkah implementasi**
+ Tinjau dan dokumentasikan desain beban kerja sambil mempertimbangkan pertanyaan-pertanyaan berikut:
+ Di mana bidang kontrol digunakan di beban kerja?
+ Bagaimana beban kerja mengimplementasikan toleransi kesalahan?
+ Apa saja pola desain untuk penskalaan, penskalaan otomatis, redundansi, dan komponen dengan ketersediaan tinggi?
+ Apa saja persyaratan untuk ketersediaan dan konsistensi data?
+ Apakah ada pertimbangan untuk penghematan sumber daya atau stabilitas statis sumber daya?
+ Apa saja dependensi layanan?
+ Tetapkan metrik-metrik SLA berdasarkan arsitektur beban kerja sambil bekerja sama dengan para pemangku kepentingan. Pertimbangkan SLA semua dependensi yang digunakan oleh beban kerja.
+ Setelah target SLA ditetapkan, optimalkan arsitektur untuk memenuhi SLA.
+ Setelah desain yang akan memenuhi SLA dibuat, implementasikan perubahan operasional, otomatisasi proses, dan runbook yang juga akan memiliki fokus pada pengurangan MTTD dan MTTR.
+ Setelah di-deploy, pantau dan buat laporan SLA.
## Sumber daya
**Praktik-praktik terbaik terkait:**
+ [REL03-BP01 Pilih cara mengelompokkan beban kerja Anda](rel_service_architecture_monolith_soa_microservice.md)
+ [REL10-BP01 Melakukan deployment beban kerja ke beberapa lokasi](rel_fault_isolation_multiaz_region_system.md)
+ [REL11-BP01 Memantau semua komponen beban kerja untuk mendeteksi kegagalan](rel_withstand_component_failures_monitoring_health.md)
+ [REL11-BP03 Melakukan otomatisasi pemulihan di semua lapisan](rel_withstand_component_failures_auto_healing_system.md)
+ [REL12-BP04 Menguji ketahanan menggunakan chaos engineering](rel_testing_resiliency_failure_injection_resiliency.md)
+ [REL13-BP01 Menetapkan sasaran pemulihan untuk waktu henti dan kehilangan data](rel_planning_for_recovery_objective_defined_recovery.md)
+ [ Memahami kesehatan beban kerja ](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/understanding-workload-health.html)
**Dokumen terkait:**
+ [Ketersediaan dengan redundansi](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/availability-with-redundancy.html)
+ [ Pilar keandalan - Ketersediaan ](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+ [ Mengukur ketersediaan ](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/measuring-availability.html)
+ [Batas Isolasi Kesalahan AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/abstract-and-introduction.html)
+ [ Model Tanggung Jawab Bersama untuk Ketangguhan ](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/shared-responsibility-model-for-resiliency.html)
+ [Stabilitas statis menggunakan Zona Ketersediaan](https://aws.amazon.com/builders-library/static-stability-using-availability-zones/)
+ [Perjanjian Tingkat Layanan (SLA) AWS](https://aws.amazon.com/legal/service-level-agreements/)
+ [ Panduan untuk Arsitektur Berbasis Sel pada AWS](https://aws.amazon.com/solutions/guidance/cell-based-architecture-on-aws/)
+ [Infrastruktur AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/aws-infrastructure.html)
+ [ Laporan resmi Pola Ketangguhan Multi-AZ Lanjutan ](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/advanced-multi-az-resilience-patterns.html)
**Layanan terkait:**
+ [ Amazon CloudWatch ](https://aws.amazon.com/cloudwatch/)
+ [AWS Config](https://aws.amazon.com/config/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)