# Manajemen kegagalan
**Topics**
+ [REL 9. Bagaimana cara mencadangkan data?](rel-09.md)
+ [REL 10. Bagaimana cara menggunakan isolasi kesalahan untuk melindungi beban kerja?](rel-10.md)
+ [REL 11. Bagaimana Anda mendesain beban kerja agar dapat bertahan jika terjadi kegagalan komponen?](rel-11.md)
+ [REL 12. Bagaimana cara menguji keandalan?](rel-12.md)
+ [REL 13. Bagaimana cara Anda mempersiapkan pemulihan bencana (DR)?](rel-13.md)
# REL 9. Bagaimana cara mencadangkan data?
Cadangkan data, aplikasi, dan konfigurasi untuk memenuhi persyaratan Anda untuk sasaran waktu pemulihan (RTO) dan sasaran titik pemulihan (RPO).
**Topics**
+ [REL09-BP01 Mengidentifikasi dan mencadangkan data yang perlu dicadangkan, atau melakukan reproduksi ulang data dari sumber](rel_backing_up_data_identified_backups_data.md)
+ [REL09-BP02 Mengamankan dan mengenkripsikan cadangan](rel_backing_up_data_secured_backups_data.md)
+ [REL09-BP03 Melakukan pencadangan data secara otomatis](rel_backing_up_data_automated_backups_data.md)
+ [REL09-BP04 Melakukan pemulihan data secara berkala untuk memverifikasi integritas dan proses pencadangan](rel_backing_up_data_periodic_recovery_testing_data.md)
# REL09-BP01 Mengidentifikasi dan mencadangkan data yang perlu dicadangkan, atau melakukan reproduksi ulang data dari sumber
Pahami dan gunakan kemampuan-kemampuan pencadangan sumber daya dan layanan data yang digunakan oleh beban kerja. Sebagian besar layanan menyediakan kemampuan untuk mencadangkan data beban kerja.
**Hasil yang diinginkan:** Sumber data telah diidentifikasi dan diklasifikasikan berdasarkan tingkat kekritisan. Kemudian, bangun strategi untuk pemulihan data berdasarkan RPO. Strategi ini melibatkan pencadangan sumber-sumber data, atau memiliki kemampuan untuk memproduksi ulang data dari sumber yang lain. Untuk kasus kehilangan data, strategi yang diimplementasikan akan memungkinkan pemulihan atau produksi ulang data dalam RPO dan RTO yang ditetapkan.
**Fase kematangan cloud:** Dasar
**Anti-pola umum:**
+ Tidak mengetahui semua sumber data untuk beban kerja serta tingkat kekritisannya.
+ Tidak melakukan pencadangan sumber data kritis.
+ Melakukan pencadangan hanya beberapa sumber data tanpa menggunakan tingkat kekritisan sebagai kriteria.
+ Tidak ada RPO yang ditetapkan, atau frekuensi pencadangan tidak memenuhi RPO.
+ Tidak mengevaluasi apakah cadangan diperlukan atau apakah data dapat diproduksi ulang dari sumber yang lain.
**Manfaat menerapkan praktik terbaik ini:** Mengidentifikasi tempat-tempat yang memerlukan pencadangan dan mengimplementasikan mekanisme untuk membuat cadangan, atau mampu memproduksi ulang data dari sumber eksternal, semuanya dapat meningkatkan kemampuan untuk memulihkan dan mengembalikan data selama pemadaman.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Tinggi
## Panduan implementasi
Semua penyimpanan data AWS menawarkan kemampuan pencadangan. Layanan-layanan seperti Amazon RDS dan Amazon DynamoDB memberikan dukungan tambahan pada pencadangan otomatis yang memungkinkan pemulihan titik waktu (PITR), yang akan memungkinkan Anda untuk memulihkan cadangan ke waktu kapan pun hingga lima menit atau kurang sebelum waktu saat ini. Banyak layanan AWS yang menawarkan kemampuan untuk menyalin cadangan ke Wilayah AWS yang lain. AWS Backup adalah sebuah alat yang akan memberi Anda kemampuan untuk melakukan sentralisasi dan otomatisasi terhadap perlindungan data di seluruh layanan AWS. [AWS Elastic Disaster Recovery](https://aws.amazon.com/disaster-recovery/) akan memungkinkan Anda untuk menyalin beban kerja server penuh dan mempertahankan perlindungan data berkelanjutan dari on-premise, lintas Zona Ketersediaan atau lintas Wilayah, dengan Sasaran Titik Pemulihan (RPO) yang diukur dalam hitungan detik.
Amazon S3 dapat digunakan sebagai tujuan pencadangan untuk sumber data yang dikelola mandiri dan yang dikelola oleh AWS. Layanan-layanan AWS seperti Amazon EBS, Amazon RDS, dan Amazon DynamoDB memiliki kemampuan bawaan untuk membuat cadangan. Perangkat lunak pencadangan pihak ketiga juga dapat digunakan.
Data on-premise dapat dicadangkan ke AWS Cloud dengan menggunakan [AWS Storage Gateway](https://docs.aws.amazon.com/storagegateway/latest/vgw/WhatIsStorageGateway.html) atau [AWS DataSync](https://docs.aws.amazon.com/datasync/latest/userguide/what-is-datasync.html). Bucket Amazon S3 dapat digunakan untuk menyimpan data ini di AWS. Amazon S3 menawarkan beberapa tingkatan penyimpanan seperti [Amazon Glacier atau Amazon Glacier Deep Archive](https://docs.aws.amazon.com/prescriptive-guidance/latest/backup-recovery/amazon-s3-glacier.html) untuk mengurangi biaya penyimpanan data.
Anda mungkin dapat memenuhi kebutuhan pemulihan data Anda dengan memproduksi ulang data dari sumber yang lain. Misalnya, [simpul replika Amazon ElastiCache](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Replication.Redis.Groups.html) atau [replika baca Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html) dapat digunakan untuk memproduksi ulang data jika data primer hilang. Dalam kasus di mana sumber-sumber data seperti ini dapat digunakan untuk memenuhi [Sasaran Titik Pemulihan (RPO) dan Sasaran Waktu Pemulihan (RTO)](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/disaster-recovery-dr-objectives.html), Anda mungkin tidak memerlukan cadangan. Contoh lainnya, jika Anda menggunakan Amazon EMR, pencadangan penyimpanan data HDFS Anda mungkin tidak diperlukan, selama Anda dapat [memproduksi ulang data ke Amazon EMR dari Amazon S3](https://aws.amazon.com/premiumsupport/knowledge-center/copy-s3-hdfs-emr/).
Ketika memilih strategi pencadangan, pertimbangkan waktu yang diperlukan untuk melakukan pemulihan data. Waktu yang diperlukan untuk melakukan pemulihan data tergantung pada tipe cadangan (untuk kasus strategi pencadangan), atau kompleksitas mekanisme produksi ulang data. Waktu ini termasuk dalam RTO untuk beban kerja.
**Langkah-langkah implementasi**
1. **Mengidentifikasi semua sumber daya untuk beban kerja**. Data dapat disimpan pada sejumlah sumber daya seperti [basis data](https://aws.amazon.com/products/databases/), [volume](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html), [sistem file](https://docs.aws.amazon.com/efs/latest/ug/whatisefs.html), [sistem pencatatan log](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html), dan [penyimpanan objek](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html). Lihat bagian **Sumber Daya** untuk menemukan **Dokumen terkait** mengenai berbagai layanan AWS tempat data disimpan, dan kemampuan cadangan yang disediakan oleh layanan-layanan ini.
1. **Klasifikasikan sumber data berdasarkan tingkat kekritisan**. Set data yang berbeda akan memiliki tingkat kekritisan yang berbeda untuk suatu beban kerja, sehingga memiliki persyaratan ketahanan yang berbeda pula. Misalnya, beberapa data mungkin kritis dan memerlukan RPO hampir nol, sedangkan data lain mungkin tidak terlalu kritis dan dapat mentoleransi RPO yang lebih tinggi dan beberapa kehilangan data. Demikian juga, set data yang berbeda mungkin memiliki persyaratan RTO yang berbeda.
1. **Gunakan AWS atau layanan pihak ketiga untuk membuat cadangan data**. [AWS Backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html) adalah sebuah layanan terkelola yang memungkinkan pembuatan cadangan dari berbagai sumber data di AWS. [AWS Elastic Disaster Recovery](https://aws.amazon.com/disaster-recovery/) menangani replikasi data otomatis di bawah satu detik (sub-second) ke Wilayah AWS. Sebagian besar layanan AWS juga memiliki kemampuan native untuk membuat cadangan. AWS Marketplace juga memiliki banyak solusi untuk menyediakan kemampuan-kemampuan ini. Lihat **Sumber Daya** yang disebutkan di bawah ini untuk mendapatkan informasi tentang cara membuat cadangan data dari berbagai layanan AWS.
1. **Untuk data yang tidak dicadangkan, bangun mekanisme produksi ulang data**. Anda mungkin memilih untuk tidak mencadangkan data yang dapat diproduksi ulang dari sumber yang lain karena berbagai alasan. Mungkin terdapat situasi di mana produksi ulang data dari sumber yang lain saat diperlukan lebih murah daripada membuat cadangan, karena mungkin ada biaya-biaya yang timbul terkait penyimpanan cadangan. Contoh lainnya adalah ketika pemulihan dari cadangan memerlukan waktu lebih lama daripada produksi ulang data dari sumber-sumber lain, sehingga mengakibatkan pelanggaran RTO. Pada situasi-situasi demikian, pertimbangkan semua kompromi dan bangun sebuah proses yang ditetapkan dengan baik terkait bagaimana data dapat diproduksi ulang dari sumber-sumber ini saat pemulihan data diperlukan. Misalnya, jika Anda telah memuat data dari Amazon S3 ke gudang data (seperti Amazon Redshift), atau klaster MapReduce (seperti Amazon EMR) untuk melakukan analisis pada data tersebut, ini mungkin adalah contoh data yang dapat diproduksi ulang dari sumber lain. Selama hasil dari semua analisis ini disimpan di suatu tempat atau dapat diproduksi ulang, Anda tidak akan mengalami kehilangan data akibat kegagalan pada gudang data atau klaster MapReduce. Contoh lain data yang dapat diproduksi ulang dari sumber lain adalah cache (seperti Amazon ElastiCache) atau replika baca RDS.
1. **Buat jadwal pencadangan data**. Membuat cadangan sumber data adalah proses berkala dan frekuensinya seharusnya tergantung pada RPO.
**Tingkat upaya untuk Rencana Implementasi:** Sedang
## Sumber daya
**Praktik-Praktik Terbaik Terkait:**
[REL13-BP01 Menetapkan sasaran pemulihan untuk waktu henti dan kehilangan data](rel_planning_for_recovery_objective_defined_recovery.md)
[REL13-BP02 Menggunakan strategi pemulihan untuk memenuhi sasaran pemulihan](rel_planning_for_recovery_disaster_recovery.md)
**Dokumen terkait:**
+ [Apa itu AWS Backup?](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html)
+ [Apa itu AWS DataSync?](https://docs.aws.amazon.com/datasync/latest/userguide/what-is-datasync.html)
+ [Apa itu Volume Gateway?](https://docs.aws.amazon.com/storagegateway/latest/vgw/WhatIsStorageGateway.html)
+ [Partner APN: partner yang dapat membantu terkait pencadangan](https://aws.amazon.com/partners/find/results/?keyword=Backup)
+ [AWS Marketplace: produk yang dapat digunakan untuk pencadangan](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup)
+ [Snapshot Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSSnapshots.html)
+ [Mencadangkan Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/efs-backup-solutions.html)
+ [Mencadangkan Amazon FSx for Windows File Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/using-backups.html)
+ [Pencadangan dan pemulihan untuk ElastiCache for Redis](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/backups.html)
+ [Membuat Snapshot Klaster DB di Neptune](https://docs.aws.amazon.com/neptune/latest/userguide/backup-restore-create-snapshot.html)
+ [Membuat Snapshot DB](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CreateSnapshot.html)
+ [Membuat Aturan EventBridge yang Memicu Berdasarkan Jadwal](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-scheduled-rule.html)
+ [Replikasi Lintas Wilayah](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr.html) dengan Amazon S3
+ [AWS Backup EFS ke EFS](https://aws.amazon.com/solutions/efs-to-efs-backup-solution/)
+ [Mengekspor Data Log ke Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/S3Export.html)
+ [Manajemen siklus aktif objek](https://docs.aws.amazon.com/AmazonS3/latest/dev/object-lifecycle-mgmt.html)
+ [Pencadangan Sesuai Permintaan dan Pemulihan untuk DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/backuprestore_HowItWorks.html)
+ [Pemulihan titik waktu untuk DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/PointInTimeRecovery.html)
+ [Menggunakan Snapshot Indeks Amazon OpenSearch Service](https://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/es-managedomains-snapshots.html)
+ [ Apa itu AWS Elastic Disaster Recovery? ](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)
**Video terkait:**
+ [AWS re:Invent 2021 - Pencadangan, pemulihan bencana, dan perlindungan ransomware dengan AWS](https://www.youtube.com/watch?v=Ru4jxh9qazc)
+ [Demo AWS Backup: Pencadangan Lintas Akun dan Lintas Wilayah](https://www.youtube.com/watch?v=dCy7ixko3tE)
+ [AWS re:Invent 2019: Memahami lebih dalam mengenai AWS Backup, ft. Rackspace (STG341)](https://youtu.be/av8DpL0uFjc)
# REL09-BP02 Mengamankan dan mengenkripsikan cadangan
Kontrol dan deteksi akses ke cadangan menggunakan autentikasi dan otorisasi. Gunakan enkripsi untuk mencegah dan mendeteksi jika integritas data cadangan terancam.
Implementasikan kontrol keamanan untuk mencegah akses tidak sah ke data cadangan. Enkripsi cadangan untuk melindungi kerahasiaan dan integritas data Anda.
**Anti-pola umum:**
+ Buatlah akses yang sama ke cadangan dan otomatisasi pemulihan seperti yang dilakukan pada data.
+ Tidak mengenkripsi cadangan.
+ Tidak menerapkan imutabilitas untuk perlindungan terhadap penghapusan atau manipulasi.
+ Menggunakan domain keamanan yang sama untuk sistem produksi dan pencadangan.
+ Tidak memvalidasi integritas cadangan melalui pengujian reguler.
**Manfaat menjalankan praktik terbaik ini:**
+ Mengamankan cadangan Anda akan mencegah manipulasi terhadap data, dan enkripsi data mencegah akses ke data tersebut jika tidak sengaja terekspos.
+ Meningkatkan perlindungan terhadap ransomware dan ancaman siber lainnya yang menarget infrastruktur pencadangan.
+ Mengurangi waktu pemulihan setelah insiden siber melalui proses pemulihan yang divalidasi.
+ Meningkatkan kemampuan kontinuitas bisnis selama insiden keamanan.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Tinggi
## Panduan implementasi
Kontrol dan deteksi akses ke cadangan dengan menggunakan autentikasi dan otorisasi seperti AWS Identity and Access Management (IAM). Gunakan enkripsi untuk mencegah dan mendeteksi jika integritas data cadangan terancam.
Amazon S3 mendukung beberapa metode enkripsi data diam. Dengan menggunakan enkripsi di sisi server, Amazon S3 dapat menerima objek sebagai data yang tidak terenkripsi dan mengenkripsinya saat disimpan. Dengan menggunakan enkripsi di sisi klien, aplikasi beban kerja bertanggung jawab untuk mengenkripsi data sebelum mengirimkannya ke Amazon S3. Kedua metode tersebut akan memungkinkan Anda menggunakan AWS Key Management Service (AWS KMS) guna menciptakan dan menyimpan kunci data. Anda dapat menyediakan kunci Anda sendiri dan bertanggung jawab atas kunci tersebut. Dengan menggunakan AWS KMS, Anda dapat menetapkan kebijakan menggunakan IAM terkait siapa yang dapat dan tidak dapat mengakses kunci data dan data terdekripsi.
Untuk Amazon RDS, cadangan juga akan dienkripsi jika Anda memilih untuk mengenkripsi basis data Anda. Pencadangan DynamoDB selalu dienkripsi. Ketika menggunakan AWS Elastic Disaster Recovery, semua data bergerak dan data diam dienkripsi. Dengan Pemulihan Bencana Elastis, data diam dapat dienkripsi dengan menggunakan Kunci Enkripsi Volume enkripsi Amazon EBS atau kunci kustom yang dikelola pelanggan.
**Pertimbangan ketahanan siber**
Guna meningkatkan keamanan cadangan terhadap ancaman siber, pertimbangkan untuk menerapkan kontrol tambahan berikut selain enkripsi:
+ Implementasikan imutabilitas menggunakan Kunci Penyimpanan AWS Backup atau Kunci Objek Amazon S3 untuk mencegah data cadangan diubah atau dihapus selama periode retensi sehingga melindungi terhadap ransomware dan penghapusan berniat jahat.
+ Tetapkan isolasi logis antara lingkungan produksi dan pencadangan menggunakan penyimpanan yang terisolasi secara logis dari AWS Backup untuk sistem krusial, sehingga menciptakan pemisahan yang membantu mencegah disusupinya kedua lingkungan tersebut secara bersamaan.
+ Validasikan integritas cadangan secara teratur menggunakan uji pemulihan AWS Backup untuk memverifikasi bahwa cadangan tidak rusak dan dapat berhasil dipulihkan setelah insiden siber.
+ Implementasikan persetujuan multipihak untuk operasi pemulihan krusial menggunakan persetujuan multipihak AWS Backup guna mencegah upaya pemulihan yang tidak sah atau berniat jahat dengan meminta otorisasi dari beberapa pemberi persetujuan yang ditunjuk.
### Langkah-langkah implementasi
1. Gunakan enkripsi untuk setiap penyimpanan data. Jika sumber data terenkripsi, maka cadangannya juga akan terenkripsi.
+ [Gunakan enkripsi di Amazon RDS.](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html) . Anda dapat mengonfigurasi enkripsi diam dengan menggunakan AWS Key Management Service saat membuat instans RDS.
+ [Gunakan enkripsi pada volume Amazon EBS.](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html). Anda dapat mengonfigurasi enkripsi default atau menentukan sebuah kunci unik saat pembuatan volume.
+ Gunakan [enkripsi Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/EncryptionAtRest.html) yang diperlukan. DynamoDB mengenkripsi semua data diam. Anda dapat menggunakan kunci AWS KMS yang dimiliki AWS atau kunci KMS yang dikelola AWS, yang menentukan sebuah kunci yang disimpan di akun Anda.
+ [Lakukan enkripsi pada data Anda yang disimpan di Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/encryption.html). Konfigurasikan enkripsi saat Anda membuat sistem file.
+ Konfigurasikan enkripsi di Wilayah sumber dan tujuan. Anda dapat mengonfigurasikan enkripsi saat diam di Amazon S3 dengan menggunakan kunci yang disimpan di KMS, tetapi kunci tersebut bersifat spesifik Wilayah. Anda dapat menentukan kunci tujuan saat Anda mengonfigurasikan replikasi.
+ Pilih apakah akan Anda akan menggunakan [enkripsi Amazon EBS default atau eknripsi kustom untuk Pemulihan Bencana Elastis](https://docs.aws.amazon.com/drs/latest/userguide/volumes-drs.html#ebs-encryption). Opsi ini akan mengenkripsi data diam yang direplikasi di disk Subnet Area Staging dan disk yang direplikasi.
1. Implementasikan izin hak akses paling rendah untuk mengakses cadangan Anda. Ikuti praktik-praktik terbaik untuk membatasi akses ke cadangan, snapshot, dan replika sesuai dengan [praktik terbaik untuk keamanan](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html).
1. Konfigurasikan imutabilitas untuk pencadangan penting. Untuk data krusial, terapkan Kunci Penyimpanan AWS Backup atau Kunci Objek S3 untuk mencegah penghapusan atau perubahan selama periode retensi yang ditentukan. Untuk detail implementasi, lihat [Kunci Penyimpanan AWS Backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/vault-lock.html).
1. Buat pemisahan logis untuk lingkungan pencadangan. Implementasikan penyimpanan yang terisolasi secara logis dari AWS Backup untuk sistem krusial yang membutuhkan perlindungan yang ditingkatkan terhadap ancaman siber. Untuk panduan implementasi, lihat [Membangun ketahanan siber dengan penyimpanan yang terisolasi secara logis dari AWS Backup](https://aws.amazon.com/blogs/storage/building-cyber-resiliency-with-aws-backup-logically-air-gapped-vault/).
1. Implementasikan proses validasi cadangan. Konfigurasikan uji pemulihan AWS Backup untuk memverifikasi secara teratur bahwa cadangan tidak rusak dan dapat berhasil dipulihkan setelah insiden siber. Untuk informasi selengkapnya, lihat [Validasikan kesiapan pemulihan dengan uji pemulihan AWS Backup](https://aws.amazon.com/blogs/storage/validate-recovery-readiness-with-aws-backup-restore-testing/).
1. Konfigurasikan persetujuan multipihak untuk operasi pemulihan sensitif. Untuk sistem krusial, terapkan persetujuan multipihak AWS Backup untuk meminta otorisasi dari beberapa pemberi persetujuan yang ditunjuk sebelum pemulihan dapat dilanjutkan. Untuk detail implementasi, lihat [Tingkatkan ketahanan pemulihan dengan dukungan AWS Backup untuk persetujuan multipihak](https://aws.amazon.com/blogs/storage/improve-recovery-resilience-with-aws-backup-support-for-multi-party-approval/).
## Sumber daya
**Dokumen terkait:**
+ [AWS Marketplace: produk yang dapat digunakan untuk pencadangan](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup)
+ [Enkripsi Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html)
+ [Amazon S3: Melindungi Data Menggunakan Enkripsi](https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingEncryption.html)
+ [Konfigurasi Tambahan CRR: Mereplika Objek yang Dibuat dengan Enkripsi di Sisi Server (SSE) Menggunakan Kunci Enkripsi yang disimpan di AWS KMS](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr-replication-config-for-kms-objects.html)
+ [Enkripsi DynamoDB Saat Diam](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/EncryptionAtRest.html)
+ [Mengenkripsi Sumber Daya Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html)
+ [Mengenkripsi Data dan Metadata di Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/encryption.html)
+ [Enkripsi untuk Cadangan di AWS](https://docs.aws.amazon.com/aws-backup/latest/devguide/encryption.html)
+ [Mengelola Tabel yang Dienkripsi](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/encryption.tutorial.html)
+ [Pilar Keamanan - Kerangka Kerja AWS Well-Architected](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html)
+ [ Apa itu AWS Elastic Disaster Recovery? ](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)
+ [FSISEC11: Bagaimana cara melindungi terhadap ransomware?](https://docs.aws.amazon.com/wellarchitected/latest/financial-services-industry-lens/fsisec11.html)
+ [ Manajemen Risiko Ransomware di AWS Menggunakan Kerangka Kerja Keamanan Siber NIST ](https://docs.aws.amazon.com/whitepapers/latest/ransomware-risk-management-on-aws-using-nist-csf/welcome.html)
+ [Membangun ketahanan siber dengan penyimpanan yang terisolasi secara logis dari AWS Backup](https://aws.amazon.com/blogs/storage/building-cyber-resiliency-with-aws-backup-logically-air-gapped-vault/)
+ [Validasikan kesiapan pemulihan dengan uji pemulihan AWS Backup](https://aws.amazon.com/blogs/storage/validate-recovery-readiness-with-aws-backup-restore-testing/)
+ [Tingkatkan ketahanan pemulihan dengan dukungan AWS Backup untuk persetujuan multipihak](https://aws.amazon.com/blogs/storage/improve-recovery-resilience-with-aws-backup-support-for-multi-party-approval/)
**Contoh terkait:**
+ [ Mengimplementasikan Replikasi Lintas-Wilayah (CRR) Dua Arah untuk Amazon S3 ](https://wellarchitectedlabs.com/reliability/200_labs/200_bidirectional_replication_for_s3/)
# REL09-BP03 Melakukan pencadangan data secara otomatis
Konfigurasikan pencadangan untuk dilakukan secara otomatis berdasarkan jadwal berkala yang diberikan oleh Sasaran Titik Pemulihan (RPO), atau berdasarkan perubahan dalam set data. Set data kritis dengan persyaratan data hilang yang rendah perlu dicadangkan otomatis secara rutin, sedangkan data yang tidak terlalu kritis yang apabila hilang masih dapat dimaklumi dapat dicadangkan tidak terlalu sering.
**Hasil yang Diinginkan:** Sebuah proses otomatis yang membuat cadangan sumber data dengan jadwal yang ditetapkan.
**Anti-pola umum:**
+ Melakukan pencadangan secara manual.
+ Menggunakan sumber daya yang memiliki kemampuan pencadangan, tetapi tidak termasuk pencadangan dalam otomatisasi Anda.
**Manfaat menerapkan praktik terbaik ini:** Melakukan otomatisasi pencadangan yang memverifikasi bahwa pencadangan dilakukan secara teratur berdasarkan RPO Anda dan memberi tahu Anda jika pencadangan tidak dilakukan.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Sedang
## Panduan implementasi
AWS Backup dapat digunakan untuk membuat cadangan data secara otomatis dari berbagai sumber data AWS. Instans Amazon RDS dapat dicadangkan hampir secara berkelanjutan setiap lima menit dan objek Amazon S3 dapat dicadangkan hampir secara berkelanjutan setiap lima belas menit, dan memungkinkan pemulihan titik waktu (PITR) ke titik waktu tertentu di dalam riwayat pencadangan. Untuk sumber data AWS lainnya, seperti volume Amazon EBS, tabel Amazon DynamoDB, atau sistem file Amazon FSx, AWS Backup dapat menjalankan pencadangan secara otomatis setiap satu jam. Layanan ini juga menawarkan kemampuan cadangan native. Layanan-layanan AWS yang menawarkan pencadangan otomatis dengan pemulihan titik waktu termasuk [Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/PointInTimeRecovery_Howitworks.html), [Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PIT.html), dan [Amazon Keyspaces (untuk Apache Cassandra)](https://docs.aws.amazon.com/keyspaces/latest/devguide/PointInTimeRecovery.html) – ini dapat dikembalikan ke titik waktu tertentu dalam riwayat pencadangan. Sebagian besar layanan penyimpanan data AWS lainnya menawarkan kemampuan untuk menjadwalkan pencadangan secara berkala, dengan frekuensi setiap satu jam.
Amazon RDS dan Amazon DynamoDB menawarkan pencadangan berkelanjutan dengan pemulihan titik waktu. Penentuan versi Amazon S3, setelah dihidupkan, akan berjalan otomatis. [Amazon Data Lifecycle Manager](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/snapshot-lifecycle.html) dapat digunakan untuk melakukan otomatisasi terhadap pembuatan, penyalinan dan penghapusan snapshot Amazon EBS. Layanan ini juga dapat mengotomatiskan pembuatan, penyalinan, penghentian, dan pembatalan registrasi Amazon Machine Image (AMI) yang dicadangkan Amazon EBS dan snapshot Amazon EBS yang melandasinya.
AWS Elastic Disaster Recovery memberikan replikasi tingkat blok yang berkelanjutan dari lingkungan sumber (on-premise atau AWS) ke wilayah pemulihan target. Snapshot titik waktu Amazon EBS dibuat dan dikelola secara otomatis oleh layanan tersebut.
Untuk tampilan otomatisasi dan riwayat pencadangan tersentralisasi, AWS Backup menyediakan solusi pencadangan berbasis kebijakan yang terkelola penuh. Layanan ini memusatkan dan mengotomatiskan pencadangan data di beberapa layanan AWS di cloud serta on-premise dengan menggunakan AWS Storage Gateway.
Selain penentuan versi, Amazon S3 dilengkapi dengan fitur replikasi. Seluruh bucket S3 dapat direplikasi secara otomatis ke bucket lain yang ada di Wilayah AWS yang sama atau berbeda.
**Langkah-langkah implementasi**
1. **Identifikasi sumber data** yang sedang dicadangkan secara manual. Untuk detail selengkapnya, lihat [REL09-BP01 Mengidentifikasi dan mencadangkan data yang perlu dicadangkan, atau melakukan reproduksi ulang data dari sumber](rel_backing_up_data_identified_backups_data.md).
1. **Tentukan RPO** untuk beban kerja. Untuk detail selengkapnya, lihat [REL13-BP01 Menetapkan sasaran pemulihan untuk waktu henti dan kehilangan data](rel_planning_for_recovery_objective_defined_recovery.md).
1. **Gunakan solusi pencadangan otomatis atau layanan terkelola**. AWS Backup adalah sebuah layanan terkelola sepenuhnya yang memudahkan untuk [memusatkan dan mengotomatiskan perlindungan data di seluruh layanan AWS, di cloud, dan on-premise](https://docs.aws.amazon.com/aws-backup/latest/devguide/creating-a-backup.html#creating-automatic-backups). Dengan menggunakan rencana cadangan di AWS Backup, buatlah aturan yang menetapkan sumber daya yang akan dicadangkan, dan frekuensi pembuatan cadangan ini. Frekuensi ini harus mengacu pada RPO yang ditetapkan pada Langkah 2. Untuk panduan langsung tentang cara membuat cadangan otomatis dengan menggunakan AWS Backup, silakan lihat [Menguji Cadangan dan Penyimpanan Kembali Data](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/). Kemampuan pencadangan native ditawarkan oleh sebagian besar layanan AWS yang menyimpan data. Misalnya, RDS dapat dimanfaatkan untuk pencadangan secara otomatis dengan pemulihan titik waktu (PITR).
1. **Untuk sumber data yang tidak didukung** oleh solusi pencadangan otomatis atau layanan terkelola seperti sumber data on-premise atau antrean pesan, pertimbangkan untuk menggunakan solusi pihak ketiga tepercaya untuk membuat cadangan secara otomatis. Pilihan lainnya, Anda dapat membuat otomatisasi untuk melakukannya dengan menggunakan AWS CLI atau SDK. Anda dapat menggunakan Fungsi AWS Lambda atau AWS Step Functions untuk menetapkan logika yang terlibat dalam pembuatan cadangan data, dan gunakan Amazon EventBridge untuk menginvokasinya dengan frekuensi yang didasarkan pada RPO Anda.
**Tingkat upaya untuk Rencana Implementasi:** Rendah
## Sumber daya
**Dokumen terkait:**
+ [Partner APN: partner yang dapat membantu terkait pencadangan](https://aws.amazon.com/partners/find/results/?keyword=Backup)
+ [AWS Marketplace: produk yang dapat digunakan untuk pencadangan](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup)
+ [Membuat Aturan EventBridge yang Memicu Berdasarkan Jadwal](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-scheduled-rule.html)
+ [Apa itu AWS Backup?](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html)
+ [Apa itu AWS Step Functions?](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)
+ [ Apa itu AWS Elastic Disaster Recovery? ](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)
**Video terkait:**
+ [AWS re:Invent 2019: Memahami lebih dalam mengenai AWS Backup, ft. Rackspace (STG341)](https://youtu.be/av8DpL0uFjc)
# REL09-BP04 Melakukan pemulihan data secara berkala untuk memverifikasi integritas dan proses pencadangan
Validasikan bahwa implementasi proses pencadangan Anda memenuhi Sasaran Waktu Pemulihan (RTO) dan Sasaran Titik Pemulihan (RPO) dengan melakukan uji pemulihan.
**Hasil yang Diinginkan:** Data dari cadangan dipulihkan secara berkala dengan menggunakan mekanisme yang ditentukan dengan baik untuk memverifikasi bahwa pemulihan tersebut dapat dilakukan dalam sasaran waktu pemulihan (RTO) yang ditetapkan untuk beban kerja. Pastikan bahwa pemulihan dari pencadangan menghasilkan sumber daya yang berisi data asli tanpa ada data yang rusak atau tidak dapat diakses, serta dengan kehilangan data dalam sasaran titik pemulihan (RPO).
**Anti-pola umum:**
+ Memulihkan cadangan, tetapi tidak mengambil data atau membuat kueri data apa pun untuk memastikan bahwa data hasil pemulihan dapat digunakan.
+ Dengan anggapan bahwa cadangan sudah ada.
+ Dengan anggapan bahwa cadangan sistem dapat dioperasikan sepenuhnya dan data dapat dipulihkan dari sistem.
+ Dengan anggapan bahwa waktu untuk memulihkan data dari cadangan termasuk dalam RTO untuk beban kerja.
+ Dengan anggapan bahwa data dalam cadangan termasuk dalam RPO untuk beban kerja
+ Melakukan pemulihan apabila diperlukan, tanpa menggunakan runbook, atau di luar prosedur otomatis yang ditetapkan.
**Manfaat menerapkan praktik terbaik ini:** Pengujian pemulihan cadangan akan memverifikasi bahwa data dapat dipulihkan saat dibutuhkan tanpa perlu khawatir data akan hilang atau rusak, bahwa pemulihan dapat dilakukan dalam RTO untuk beban kerja, dan kehilangan data apa pun masih termasuk dalam RPO untuk beban kerja.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Sedang
## Panduan implementasi
Pengujian kemampuan pencadangan dan pemulihan akan meningkatkan keyakinan Anda pada kemampuan untuk menjalankan tindakan ini selama terjadi pemadaman (outage). Pulihkan cadangan ke lokasi baru secara berkala dan lakukan pengujian untuk memastikan integritas data. Beberapa pengujian umum yang harus dilakukan adalah memeriksa apakah semua data tersedia, tidak mengalami kerusakan, dapat diakses, dan setiap kehilangan data masih termasuk dalam RPO untuk beban kerja. Pengujian tersebut dapat juga membantu memastikan apakah mekanisme pemulihan cukup cepat untuk mengakomodasi RTO beban kerja.
Dengan menggunakan AWS, Anda dapat mempertahankan lingkungan pengujian dan memulihkan cadangan Anda untuk menilai kemampuan RTO dan RPO, serta menjalankan pengujian pada konten dan integritas data.
Selain itu, Amazon RDS dan Amazon DynamoDB dapat memungkinkan pemulihan titik waktu (PITR). Dengan menggunakan pencadangan yang berkelanjutan, Anda dapat memulihkan set data ke statusnya sesuai dengan waktu dan tanggal yang ditentukan.
Jika semua data tersedia, tidak mengalami kerusakan, dapat diakses, dan kehilangan data apa pun masih termasuk dalam RPO untuk beban kerja. Pengujian tersebut dapat juga membantu memastikan apakah mekanisme pemulihan cukup cepat untuk mengakomodasi RTO beban kerja.
AWS Elastic Disaster Recovery menawarkan snapshot pemulihan titik waktu volume Amazon EBS secara berkelanjutan. Saat server sumber direplikasi, status point-in-time dicatat dari waktu ke waktu berdasarkan kebijakan yang dikonfigurasi. Pemulihan Bencana Elastis dapat membantu Anda untuk memverifikasi integritas snapshot ini dengan meluncurkan instans untuk tujuan pengujian dan latihan tanpa mengarahkan lalu lintas.
**Langkah-langkah implementasi**
1. **Identifikasi sumber data** yang dicadangkan saat ini dan lokasi penyimpanan cadangan tersebut. Untuk panduan implementasi, lihat [REL09-BP01 Mengidentifikasi dan mencadangkan data yang perlu dicadangkan, atau melakukan reproduksi ulang data dari sumber](rel_backing_up_data_identified_backups_data.md).
1. **Menetapkan kriteria untuk validasi data** untuk masing-masing sumber data. Jenis data yang berbeda akan memiliki properti data yang berbeda, yang dapat memerlukan mekanisme validasi yang berbeda. Pertimbangkan bagaimana data ini dapat divalidasi sebelum Anda yakin untuk menggunakannya dalam produksi. Beberapa cara umum untuk memvalidasi data adalah dengan menggunakan data dan properti pencadangan seperti jenis data, format, checksum, ukuran, atau gabungan darinya dengan logika validasi kustom. Misalnya, hal ini dapat dilakukan dengan perbandingan nilai checksum antara sumber daya yang dipulihkan dan sumber data pada waktu cadangan dibuat.
1. **Menetapkan RTO dan RPO** untuk memulihkan data berdasarkan tingkat kekritisan data. Untuk panduan implementasi, lihat [REL13-BP01 Menetapkan sasaran pemulihan untuk waktu henti dan kehilangan data](rel_planning_for_recovery_objective_defined_recovery.md).
1. **Menilai kemampuan pemulihan Anda**. Tinjau strategi pencadangan dan pemulihan untuk memahami apakah hal tersebut memenuhi RTO dan RPO, serta sesuaikan strategi sesuai keperluan. Dengan menggunakan [AWS Resilience Hub](https://docs.aws.amazon.com/resilience-hub/latest/userguide/create-policy.html), Anda dapat menjalankan penilaian terhadap beban kerja Anda. Penilaian tersebut mengevaluasi konfigurasi aplikasi terhadap kebijakan dan pelaporan ketahanan jika target RTO dan RPO dapat dipenuhi.
1. **Lakukan penyimpanan kembali pengujian** dengan menggunakan proses yang ditetapkan saat ini yang digunakan dalam produksi untuk pemulihan data. Proses ini bergantung pada cara sumber data asli dicadangkan, format dan lokasi penyimpanan cadangan tersebut, atau apakah data diproduksi ulang dari sumber-sumber lainnya. Misalnya, jika Anda menggunakan sebuah layanan terkelola seperti [AWS Backup, hal ini mungkin sesederhana memulihkan cadangan ke sumber daya baru](https://docs.aws.amazon.com/aws-backup/latest/devguide/restoring-a-backup.html). Jika Anda menggunakan AWS Elastic Disaster Recovery, maka Anda dapat [meluncurkan latihan pemulihan](https://docs.aws.amazon.com/drs/latest/userguide/failback-preparing.html).
1. **Validasi pemulihan data** dari sumber daya yang dipulihkan berdasarkan kriteria validasi data yang sebelumnya Anda buat. Apakah data yang direstorasi dan dipulihkan memiliki sebagian besar catatan atau item terbaru pada waktu pencadangan? Apakah data ini masih termasuk dalam RPO untuk beban kerja?
1. **Ukur waktu yang diperlukan** untuk menyimpan kembali dan melakukan pemulihan dan kemudian bandingkan dengan RTO Anda yang sudah ditetapkan. Apakah data ini masih termasuk dalam RTO untuk beban kerja? Misalnya, bandingkan stempel waktu dari kapan proses restorasi dimulai dan kapan validasi pemulihan selesai untuk menghitung waktu yang diperlukan proses ini. Semua panggilan API AWS diberi stempel waktu dan informasi ini tersedia di [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html). Meskipun informasi ini dapat menyediakan detail waktu kapan proses pemulihan dimulai, namun stempel waktu akhir yang menunjukkan kapan validasi diselesaikan harus dicatat berdasarkan logika validasi Anda. Jika Anda menggunakan proses otomatis, maka layanan-layanan seperti [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) dapat digunakan untuk menyimpan informasi ini. Selain itu, banyak layanan AWS yang menyediakan riwayat peristiwa yang berisi informasi dengan yang dilengkapi stempel waktu tentang kapan tindakan-tindakan diambil. Dalam AWS Backup, tindakan pembuatan cadangan dan penyimpanan kembali disebut sebagai *tugas*, dan tugas tersebut berisi informasi stempel waktu sebagai bagian dari metadata yang dapat digunakan untuk mengukur waktu yang diperlukan untuk pemulihan.
1. **Berikan notifikasi untuk pemangku kepentingan** jika validasi data gagal, atau jika waktu yang diperlukan untuk pemulihan melebihi RTO yang ditetapkan untuk beban kerja. Saat menerapkan otomatisasi untuk melakukan langkah ini, [seperti di lab ini](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/), layanan-layanan seperti Amazon Simple Notification Service (Amazon SNS) dapat digunakan untuk mengirim pemberitahuan push seperti email atau SMS kepada para pemangku kepentingan. [Pesan-pesan ini juga dapat dipublikasikan ke aplikasi perpesanan seperti Amazon Chime, Slack, atau Microsoft Teams](https://aws.amazon.com/premiumsupport/knowledge-center/sns-lambda-webhooks-chime-slack-teams/) atau digunakan untuk [membuat tugas sebagai OpsItems dengan menggunakan AWS Systems Manager OpsCenter](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-creating-OpsItems.html).
1. **Otomatiskan proses ini untuk menjalankannya secara berkala**. Sebagai contoh, layanan-layanan seperti AWS Lambda atau State Machine di AWS Step Functions dapat digunakan untuk melakukan otomatisasi proses pemulihan, dan Amazon EventBridge dapat digunakan untuk menginvokasi alur kerja otomatisasi ini secara berkala seperti yang ditampilkan dalam diagram arsitektur di bawah ini. Pelajari cara [Mengotomatiskan validasi pemulihan data dengan AWS Backup](https://aws.amazon.com/blogs/storage/automate-data-recovery-validation-with-aws-backup/). Selain itu, [lab Well-Architected ini](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/) memberikan pengalaman langsung tentang satu cara untuk melakukan otomatisasi untuk beberapa langkah yang diuraikan di sini.
![\[Diagram yang menampilkan proses pencadangan dan pemulihan otomatis\]](http://docs.aws.amazon.com/id_id/wellarchitected/latest/framework/images/automated-backup-restore-process.png)
**Tingkat upaya untuk Rencana Implementasi:** Sedang hingga tinggi tergantung pada kompleksitas kriteria validasinya.
## Sumber daya
**Dokumen terkait:**
+ [Mengotomatiskan validasi pemulihan data dengan AWS Backup](https://aws.amazon.com/blogs/storage/automate-data-recovery-validation-with-aws-backup/)
+ [Partner APN: partner yang dapat membantu terkait pencadangan](https://aws.amazon.com/partners/find/results/?keyword=Backup)
+ [AWS Marketplace: produk yang dapat digunakan untuk pencadangan](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup)
+ [Membuat Aturan EventBridge yang Memicu Berdasarkan Jadwal](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-scheduled-rule.html)
+ [Pencadangan sesuai permintaan dan pemulihan untuk DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/BackupRestore.html)
+ [Apa itu AWS Backup?](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html)
+ [Apa itu AWS Step Functions?](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)
+ [Apa itu AWS Elastic Disaster Recovery](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)
+ [AWS Elastic Disaster Recovery](https://aws.amazon.com/disaster-recovery/)
# REL 10. Bagaimana cara menggunakan isolasi kesalahan untuk melindungi beban kerja?
Isolasi kesalahan membatasi dampak kegagalan komponen atau sistem ke batas yang ditentukan. Dengan isolasi yang baik, komponen-komponen yang ada di luar batas ini tidak terpengaruh oleh kegagalan. Menjalankan beban kerja Anda di beberapa batas isolasi kesalahan dapat membuatnya lebih tahan terhadap kegagalan.
**Topics**
+ [REL10-BP01 Melakukan deployment beban kerja ke beberapa lokasi](rel_fault_isolation_multiaz_region_system.md)
+ [REL10-BP02 Mengotomatiskan pemulihan untuk komponen yang dibatasi dalam satu lokasi](rel_fault_isolation_single_az_system.md)
+ [REL10-BP03 Menggunakan arsitektur bulkhead untuk membatasi cakupan dampak](rel_fault_isolation_use_bulkhead.md)
# REL10-BP01 Melakukan deployment beban kerja ke beberapa lokasi
Distribusikan sumber daya dan data beban kerja ke beberapa Zona Ketersediaan atau, jika diperlukan, ke beberapa Wilayah AWS.
Prinsip dasar untuk desain layanan di AWS adalah untuk menghindari titik kegagalan tunggal, termasuk infrastruktur fisik yang mendasarinya. AWS menyediakan sumber daya dan layanan komputasi cloud secara global di berbagai lokasi geografis yang disebut [Wilayah](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/regions.html). Setiap Wilayah berdiri sendiri secara fisik dan logis, dan terdiri dari tiga [Zona Ketersediaan (AZ)](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/availability-zones.html) atau lebih. Zona Ketersediaan terletak berdekatan secara geografis, tetapi terpisah dan terisolasi secara fisik. Ketika Anda mendistribusikan beban kerja Anda di beberapa Zona Ketersediaan dan Wilayah, Anda mengurangi risiko ancaman seperti kebakaran, banjir, bencana terkait cuaca, gempa bumi, dan kesalahan manusia.
Buat strategi lokasi untuk memastikan ketersediaan tinggi yang sesuai dengan beban kerja Anda.
**Hasil yang diinginkan:** Beban kerja produksi didistribusikan di beberapa Zona Ketersediaan (AZ) atau Wilayah untuk mencapai toleransi kesalahan dan ketersediaan tinggi.
**Anti-pola umum:**
+ Anda hanya menempatkan beban kerja produksi di satu Zona Ketersediaan.
+ Anda mengimplementasikan arsitektur multi-Wilayah ketika arsitektur multi-AZ sudah dapat memenuhi persyaratan bisnis.
+ Deployment atau data Anda tidak lagi sinkron, sehingga terjadi penyimpangan konfigurasi atau data yang tidak direplikasi secara memadai.
+ Anda tidak memperhitungkan dependensi antar-komponen aplikasi jika ketahanan dan persyaratan multi-lokasi berbeda di antara komponen-komponen tersebut.
**Manfaat menjalankan praktik terbaik ini:**
+ Beban kerja Anda lebih tahan terhadap insiden, seperti pemadaman listrik atau kegagalan kontrol lingkungan, bencana alam, kegagalan layanan hulu, atau masalah jaringan yang berdampak pada AZ atau seluruh Wilayah.
+ Anda dapat mengakses inventaris instans Amazon EC2 yang lebih luas dan mengurangi kemungkinan InsufficientCapacityExceptions (ICE) saat meluncurkan jenis instans EC2 tertentu.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Tinggi
## Panduan implementasi
Lakukan deployment dan operasikan semua beban kerja produksi di setidaknya dua Zona Ketersediaan (AZ) di sebuah Wilayah.
**Menggunakan beberapa Zona Ketersediaan**
Zona Ketersediaan adalah lokasi hosting sumber daya yang secara fisik terpisah satu sama lain untuk menghindari kegagalan yang berkorelasi akibat risiko seperti kebakaran, banjir, dan tornado. Setiap Zona Ketersediaan memiliki infrastruktur fisik independen, termasuk sambungan listrik lokal, sumber listrik cadangan, sistem mekanis, dan koneksi jaringan. Desain infrastruktur yang independen ini membatasi dampak kegagalan di salah satu komponen ini hanya pada Zona Ketersediaan yang terkena dampak. Misalnya, jika insiden di seluruh AZ membuat instans EC2 tidak tersedia di Zona Ketersediaan yang terpengaruh, instans Anda di Zona Ketersediaan lainnya tetap tersedia.
Meskipun terpisah secara fisik, Zona Ketersediaan di Wilayah AWS yang sama cukup dekat untuk menyediakan jaringan throughput tinggi dengan latensi rendah (milidetik satu digit). Anda dapat mereplikasi data secara sinkron antara Zona Ketersediaan untuk sebagian besar beban kerja tanpa memengaruhi pengalaman pengguna secara signifikan. Artinya Anda dapat menggunakan Zona Ketersediaan di sebuah Wilayah dalam konfigurasi aktif/aktif atau aktif/siaga.
Semua komputasi yang terkait dengan beban kerja Anda harus didistribusikan di antara beberapa Zona Ketersediaan. Hal ini termasuk instans [Amazon EC2](https://aws.amazon.com/ec2/), tugas [AWS Fargate](https://aws.amazon.com/fargate/), dan fungsi [AWS Lambda](https://aws.amazon.com/lambda/) yang terhubung dengan VPC. Layanan komputasi AWS, termasuk [EC2 Auto Scaling](https://aws.amazon.com/ec2/autoscaling/), [Amazon Elastic Container Service (ECS)](https://aws.amazon.com/ecs/), dan [Amazon Elastic Kubernetes Service (EKS)](https://aws.amazon.com/eks/), menyediakan cara bagi Anda untuk meluncurkan dan mengelola komputasi di beberapa Zona Ketersediaan. Konfigurasikan hal-hal tersebut untuk secara otomatis mengganti komputasi sesuai kebutuhan di Zona Ketersediaan yang berbeda untuk menjaga ketersediaan. Untuk mengarahkan lalu lintas ke Zona Ketersediaan yang tersedia, tempatkan penyeimbang beban di depan komputasi Anda, seperti Penyeimbang Beban Aplikasi atau Penyeimbang Beban Jaringan. Penyeimbang beban AWS dapat mengalihkan lalu lintas ke instans yang tersedia jika terjadi gangguan pada suatu Zona Ketersediaan.
Anda juga harus mereplikasi data untuk beban kerja Anda dan membuatnya tersedia di beberapa Zona Ketersediaan. Beberapa layanan data yang dikelola AWS, seperti [Amazon S3](https://aws.amazon.com/s3/), [Amazon Elastic File Service (EFS)](https://aws.amazon.com/efs/), [Amazon Aurora](https://aws.amazon.com/aurora/), [Amazon DynamoDB](https://aws.amazon.com/dynamodb/), [Amazon Simple Queue Service (SQS)](https://aws.amazon.com/sqs/), dan [Amazon Kinesis Data Streams](https://aws.amazon.com/kinesis/data-streams/) mereplikasi data di beberapa Zona Ketersediaan secara default dan tangguh terhadap gangguan Zona Ketersediaan. Dengan layanan data lain yang dikelola AWS, seperti [Amazon Relational Database Service (RDS](https://aws.amazon.com/rds/)), [Amazon Redshift](https://aws.amazon.com/redshift/), dan [Amazon ElastiCache](https://aws.amazon.com/elasticache/), Anda harus mengaktifkan replikasi multi-AZ. Setelah diaktifkan, layanan-layanan ini secara otomatis mendeteksi gangguan pada Zona Ketersediaan, mengalihkan permintaan ke Zona Ketersediaan yang tersedia, dan mereplikasi ulang data sesuai kebutuhan setelah pemulihan tanpa campur tangan pelanggan. Pelajari panduan pengguna untuk setiap layanan data yang dikelola AWS yang Anda gunakan untuk memahami kemampuan, perilaku, dan operasi multi-AZ pada layanan tersebut.
Jika Anda menggunakan penyimpanan yang dikelola sendiri, seperti volume [Amazon Elastic Block Store (EBS)](https://aws.amazon.com/ebs/) atau penyimpanan instans Amazon EC2, Anda harus mengelola sendiri replikasi multi-AZ.
![\[Diagram yang menampilkan arsitektur multi-tingkat di-deploy di tiga Zona Ketersediaan. Perhatikan bahwa Amazon S3 dan Amazon DynamoDB selalu Multi-AZ secara otomatis. ELB juga di-deploy ke tiga zona.\]](http://docs.aws.amazon.com/id_id/wellarchitected/latest/framework/images/multi-tier-architecture.png)
**Menggunakan beberapa Wilayah AWS**
Jika Anda memiliki beban kerja yang memerlukan ketahanan ekstrem (seperti infrastruktur sangat penting, aplikasi terkait kesehatan, atau layanan dengan persyaratan ketersediaan yang ketat dari pelanggan atau berdasarkan peraturan), Anda mungkin memerlukan ketersediaan tambahan di luar apa yang dapat disediakan oleh sebuah Wilayah AWS. Dalam hal ini, Anda harus melakukan deployment dan mengoperasikan beban kerja Anda di setidaknya dua Wilayah AWS (dengan asumsi bahwa persyaratan residensi data Anda memungkinkan hal ini).
Wilayah AWS terletak di wilayah geografis yang berbeda-beda di seluruh dunia dan di berbagai benua. Wilayah AWS memiliki pemisahan dan isolasi fisik yang lebih besar daripada Zona Ketersediaan. Layanan AWS, dengan beberapa pengecualian, memanfaatkan desain ini untuk beroperasi sepenuhnya secara independen di antara Wilayah yang berbeda-beda (juga dikenal sebagai *layanan Regional*). Kegagalan suatu layanan Wilayah AWS dirancang agar tidak memengaruhi layanan di Wilayah yang berbeda.
Ketika Anda mengoperasikan beban kerja Anda di beberapa Wilayah, Anda harus mempertimbangkan persyaratan tambahan. Karena sumber daya di Wilayah yang berbeda-beda saling terpisah dan independen satu sama lain, Anda harus menduplikasi komponen beban kerja Anda di setiap Wilayah. Hal ini termasuk infrastruktur dasar, seperti VPC, selain komputasi dan layanan data.
**CATATAN:** Saat Anda mempertimbangkan desain multi-Regional, pastikan bahwa beban kerja Anda mampu berjalan di satu Wilayah. Jika Anda membuat dependensi antar-Wilayah yang membuat komponen di satu Wilayah bergantung pada layanan atau komponen di Wilayah lain, Anda dapat meningkatkan risiko kegagalan dan melemahkan postur keandalan Anda secara signifikan.
Untuk memudahkan deployment multi-Regional dan menjaga konsistensi, [AWS CloudFormation StackSets](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html) dapat mereplikasi seluruh infrastruktur AWS Anda di beberapa Wilayah. [AWS CloudFormation](https://aws.amazon.com/cloudformation/) juga dapat mendeteksi penyimpangan konfigurasi dan memberi tahu Anda ketika sumber daya AWS Anda di sebuah Wilayah tidak sinkron. Banyak layanan AWS menawarkan replikasi multi-wilayah untuk aset beban kerja penting. Misalnya, [EC2 Image Builder](https://aws.amazon.com/image-builder/) dapat menerbitkan image mesin EC2 (AMI) Anda setelah setiap kali proses build selesai ke setiap Wilayah yang Anda gunakan. [Amazon Elastic Container Registry (ECR)](https://aws.amazon.com/ecr/) dapat mereplikasi image kontainer Anda ke Wilayah yang Anda pilih.
Anda juga harus mereplikasi data Anda di setiap Wilayah yang Anda pilih. Banyak layanan data yang dikelola AWS menyediakan kemampuan replikasi lintas Wilayah, termasuk Amazon S3, Amazon DynamoDB, Amazon RDS, Amazon Aurora, Amazon Redshift, Amazon ElastiCache, dan Amazon EFS. [Tabel global Amazon DynamoDB](https://aws.amazon.com/dynamodb/global-tables/) menerima penulisan di Wilayah mana pun yang didukung dan akan mereplikasi data di antara semua Wilayah lain yang Anda konfigurasikan. Dengan layanan lain, Anda harus menetapkan Wilayah utama untuk penulisan, karena Wilayah lain berisi replika hanya-baca. Untuk setiap layanan data terkelola AWS yang digunakan beban kerja Anda, lihat panduan pengguna dan panduan developernya untuk memahami kemampuan dan batasan multi-Wilayahnya. Perhatikan secara khusus ke mana penulisan harus diarahkan, kemampuan dan batasan transaksi, bagaimana replikasi dilakukan, dan bagaimana memantau sinkronisasi antar-Wilayah.
AWS juga menyediakan kemampuan untuk merutekan lalu lintas permintaan ke deployment Regional Anda dengan fleksibilitas tinggi. Misalnya, Anda dapat mengonfigurasi catatan DNS Anda menggunakan [Amazon Route 53](https://aws.amazon.com/route53/) untuk mengarahkan lalu lintas ke Wilayah terdekat yang tersedia bagi pengguna. Selain itu, Anda dapat mengonfigurasi catatan DNS Anda dalam konfigurasi aktif/siaga, yang menetapkan satu Wilayah sebagai primer dan beralih ke replika Regional hanya jika Wilayah primer mengalami masalah. Anda dapat mengonfigurasi [pemeriksaan kondisi Route 53](https://docs.aws.amazon.com/Route 53/latest/DeveloperGuide/dns-failover.html) untuk mendeteksi titik akhir yang bermasalah dan melakukan failover otomatis. Selain itu Anda juga dapat menggunakan [Amazon Application Recovery Controller (ARC)](https://aws.amazon.com/application-recovery-controller/) untuk menyediakan kontrol perutean dengan ketersediaan tinggi untuk merutekan ulang lalu lintas secara manual sesuai kebutuhan.
Meskipun Anda memilih untuk tidak beroperasi di beberapa Wilayah untuk ketersediaan tinggi, pertimbangkanlah untuk menggunakan beberapa Wilayah sebagai bagian dari strategi pemulihan bencana (DR) Anda. Jika memungkinkan, replikasi data dan komponen infrastruktur beban kerja Anda dalam konfigurasi *warm standby* atau *pilot light* di Wilayah sekunder. Dalam desain ini, Anda mereplikasi infrastruktur dasar dari Wilayah primer seperti VPC, grup Auto Scaling, orkestrator kontainer, dan komponen lainnya, tetapi Anda mengonfigurasi komponen berukuran variabel di Wilayah siaga (seperti jumlah instans EC2 dan replika basis data) menjadi ukuran minimal yang dapat beroperasi. Anda juga mengatur replikasi data berkelanjutan dari Wilayah primer ke Wilayah siaga. Jika suatu insiden terjadi, Anda kemudian dapat menskalakan, atau menambah, sumber daya di Wilayah siaga, lalu mengubahnya menjadi Wilayah primer.
### Langkah-langkah implementasi
1. Bekerjasamalah dengan pemangku kepentingan bisnis dan ahli residensi data untuk menentukan Wilayah AWS mana yang dapat digunakan untuk meng-host sumber daya dan data Anda.
1. Libatkan para pemangku kepentingan bisnis dan teknis untuk mengevaluasi beban kerja Anda, dan tentukan apakah kebutuhan ketahanannya dapat dipenuhi dengan pendekatan multi-AZ (Wilayah AWS tunggal) atau jika kebutuhannya adalah pendekatan multi-Wilayah (jika penggunaan beberapa Wilayah diizinkan). Penggunaan beberapa Wilayah dapat mencapai ketersediaan yang lebih besar, tetapi juga dapat meningkatkan kompleksitas dan biaya. Pertimbangkan faktor-faktor berikut dalam evaluasi Anda:
1. **Tujuan bisnis dan persyaratan pelanggan**: Berapa lama waktu henti yang diizinkan jika insiden yang berdampak pada beban kerja terjadi di sebuah Zona Ketersediaan atau Wilayah? Evaluasi tujuan titik pemulihan Anda seperti yang dibahas dalam [REL13-BP01 Menetapkan sasaran pemulihan untuk waktu henti dan kehilangan data](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_objective_defined_recovery.html).
1. **Persyaratan pemulihan bencana (DR)**: Potensi bencana seperti apa yang ingin Anda antisipasi? Pertimbangkan kemungkinan kehilangan data atau ketidaktersediaan dalam jangka panjang pada berbagai cakupan dampak, mulai dari satu Zona Ketersediaan hingga keseluruhan Wilayah. Jika Anda mereplikasi data dan sumber daya di beberapa Zona Ketersediaan, dan satu Zona Ketersediaan mengalami gangguan berkepanjangan, Anda dapat memulihkan layanan di Zona Ketersediaan lainnya. Jika Anda mereplikasi data dan sumber daya di beberapa Wilayah, Anda dapat memulihkan layanan di Wilayah lain.
1. Lakukan deployment sumber daya komputasi Anda ke beberapa Zona Ketersediaan.
1. Di VPC Anda, buat beberapa subnet di Zona Ketersediaan yang berbeda-beda. Konfigurasikan setiap subnet agar cukup besar untuk mengakomodasi sumber daya yang dibutuhkan untuk melayani beban kerja, bahkan saat terjadi gangguan. Untuk detail selengkapnya, lihat [REL02-BP03 Pastikan alokasi subnet IP memperhitungkan ekspansi dan ketersediaan](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_network_topology_ip_subnet_allocation.html).
1. Jika Anda menggunakan instans Amazon EC2, gunakan [EC2 Auto Scaling](https://aws.amazon.com/ec2/autoscaling/) untuk mengelola instans Anda. Tentukan subnet yang Anda pilih pada langkah sebelumnya saat Anda membuat grup Auto Scaling.
1. Jika Anda menggunakan komputasi AWS Fargate untuk [Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/AWS_Fargate.html) atau [Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/fargate.html), pilih subnet yang Anda pilih pada langkah pertama saat Anda membuat Layanan ECS, luncurkan tugas ECS, atau buat [profil Fargate](https://docs.aws.amazon.com/eks/latest/userguide/fargate-profile.html) untuk EKS.
1. Jika Anda menggunakan fungsi AWS Lambda yang perlu dijalankan di VPC Anda, pilih subnet yang Anda pilih pada langkah pertama saat Anda membuat fungsi Lambda. Untuk fungsi apa pun yang tidak memiliki konfigurasi VPC, AWS Lambda mengelola ketersediaan untuk Anda secara otomatis.
1. Tempatkan pengarah lalu lintas seperti penyeimbang beban di depan sumber daya komputasi Anda. Jika penyeimbangan beban lintas zona diaktifkan, [Penyeimbang Beban Aplikasi AWS](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html) dan [Penyeimbang Beban Jaringan](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html) akan mendeteksi saat target seperti instans dan kontainer EC2 tidak dapat dijangkau karena gangguan Zona Ketersediaan lalu mengalihkan lalu lintas ke target di Zona Ketersediaan yang sehat. Jika Anda menonaktifkan penyeimbangan beban lintas zona, gunakan Amazon Application Recovery Controller (ARC) untuk menyediakan kemampuan peralihan zona. Jika Anda menggunakan penyeimbang beban pihak ketiga atau telah menerapkan penyeimbang beban Anda sendiri, konfigurasikan dengan beberapa frontend di Zona Ketersediaan yang berbeda-beda.
1. Replikasi data beban kerja Anda di beberapa Zona Ketersediaan.
1. Jika Anda menggunakan layanan data yang dikelola AWS seperti Amazon RDS, Amazon ElastiCache, atau Amazon FSx, pelajari panduan penggunanya untuk memahami kemampuan replikasi data dan ketahanannya. Aktifkan replikasi dan failover lintas-AZ jika perlu.
1. Jika Anda menggunakan layanan penyimpanan yang dikelola AWS seperti Amazon S3, Amazon EFS, dan Amazon FSx, jangan menggunakan konfigurasi satu AZ atau Satu Zona untuk data yang memerlukan daya tahan tinggi. Gunakan konfigurasi multi-AZ untuk layanan-layanan ini. Periksa panduan pengguna layanan masing-masing untuk menentukan apakah replikasi multi-AZ diaktifkan secara default atau apakah Anda harus mengaktifkannya.
1. Jika Anda menjalankan basis data, antrean, atau layanan penyimpanan lainnya yang Anda kelola sendiri, atur replikasi multi-AZ sesuai dengan petunjuk atau praktik terbaik aplikasi. Pahami prosedur failover untuk aplikasi Anda.
1. Konfigurasikan layanan DNS Anda untuk mendeteksi gangguan pada AZ dan mengalihkan lalu lintas ke Zona Ketersediaan yang sehat. Amazon Route 53, apabila penggunaannya dikombinasikan dengan Penyeimbang Beban Elastis, dapat melakukan hal ini secara otomatis. Route 53 juga dapat dikonfigurasikan dengan catatan failover yang menggunakan pemeriksaan kondisi untuk merespons kueri dengan alamat IP yang sehat saja. Untuk data DNS apa pun yang digunakan untuk failover, tentukan nilai time to live (TTL) yang singkat (misalnya, 60 detik atau kurang) untuk membantu mencegah caching data menghambat pemulihan (data alias Route 53 menyediakan TTL yang sesuai untuk Anda).
**Langkah-langkah tambahan saat menggunakan beberapa Wilayah AWS**
1. Buat replikasi semua sistem operasi (OS) dan kode aplikasi yang digunakan oleh beban kerja Anda di seluruh Wilayah yang Anda pilih. Buat replikasi Amazon Machine Image (AMI) yang digunakan oleh instans EC2 Anda jika perlu menggunakan solusi seperti Amazon EC2 Image Builder. Buat replikasi image kontainer yang disimpan dalam registri menggunakan solusi seperti replikasi lintas Wilayah Amazon ECR. Aktifkan replikasi Regional untuk bucket Amazon S3 apa pun yang digunakan untuk menyimpan sumber daya aplikasi.
1. Lakukan deployment sumber daya komputasi dan metadata konfigurasi Anda (seperti parameter yang disimpan di Penyimpanan Parameter AWS Systems Manager) ke beberapa Wilayah. Gunakan prosedur yang sama yang dijelaskan dalam langkah sebelumnya, tetapi replikasikan konfigurasi untuk setiap Wilayah yang Anda gunakan untuk beban kerja Anda. Gunakan solusi infrastruktur sebagai kode seperti AWS CloudFormation untuk mereproduksi konfigurasi antar-Wilayah secara seragam. Jika Anda menggunakan Wilayah sekunder dalam konfigurasi pilot light untuk pemulihan bencana, Anda dapat mengurangi jumlah sumber daya komputasi Anda ke nilai minimum untuk menghemat biaya, dengan peningkatan waktu pemulihan yang sesuai.
1. Buat replikasi data Anda dari Wilayah primer Anda ke Wilayah sekunder Anda.
1. Tabel global Amazon DynamoDB menyediakan replika global data Anda yang dapat ditulis dari dan ke Wilayah mana pun yang didukung. Dengan layanan data lain yang dikelola AWS, seperti Amazon RDS, Amazon Aurora, dan Amazon ElastiCache, Anda menetapkan Wilayah primer (baca/tulis) dan Wilayah replika (hanya-baca). Lihat panduan pengguna dan developer layanan masing-masing untuk detail tentang replikasi Regional.
1. Jika Anda menjalankan basis data yang Anda kelola sendiri, atur replikasi multi-Wilayah sesuai dengan petunjuk atau praktik terbaik aplikasi tersebut. Pahami prosedur failover untuk aplikasi Anda.
1. Jika beban kerja Anda menggunakan AWS EventBridge, Anda mungkin perlu meneruskan peristiwa yang dipilih dari Wilayah primer Anda ke Wilayah sekunder Anda. Untuk melakukannya, tentukan bus peristiwa di Wilayah sekunder Anda sebagai target untuk peristiwa yang cocok di Wilayah primer Anda.
1. Pertimbangkan apakah Anda ingin menggunakan kunci enkripsi yang identik di seluruh Wilayah dan sejauh apa penggunaannya. Pendekatan umum yang menyeimbangkan keamanan dan kemudahan penggunaan adalah melalui penggunaan kunci dengan cakupan Wilayah untuk data dan autentikasi lokal Wilayah, dan penggunaan kunci dengan cakupan global untuk enkripsi data yang direplikasi di antara Wilayah yang berbeda. [AWS Key Management Service (KMS)](https://aws.amazon.com/kms/) mendukung [kunci multi-wilayah](https://docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-overview.html) untuk mendistribusikan dan melindungi kunci yang dibagikan secara aman di berbagai Wilayah.
1. Pertimbangkan AWS Global Accelerator untuk meningkatkan ketersediaan aplikasi Anda dengan mengarahkan lalu lintas ke Wilayah yang berisi titik akhir yang sehat.
## Sumber daya
**Praktik-praktik terbaik terkait:**
+ [REL02-BP03 Pastikan alokasi subnet IP memperhitungkan ekspansi dan ketersediaan](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_network_topology_ip_subnet_allocation.html)
+ [REL11-BP05 Menggunakan stabilitas statis untuk mencegah perilaku bimodal](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_static_stability.html)
+ [REL13-BP01 Menetapkan sasaran pemulihan untuk waktu henti dan kehilangan data](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_objective_defined_recovery.html)
**Dokumen terkait:**
+ [Infrastruktur Global AWS](https://aws.amazon.com/about-aws/global-infrastructure)
+ [Laporan resmi: Batas Isolasi Kesalahan AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/availability-zones.html)
+ [Ketahanan di Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/disaster-recovery-resiliency.html)
+ [Amazon EC2 Auto Scaling: Contoh: Mendistribusikan instans di beberapa Zona Ketersediaan](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#arch-AutoScalingMultiAZ)
+ [Cara kerja EC2 Image Builder](https://docs.aws.amazon.com/imagebuilder/latest/userguide/how-image-builder-works.html#image-builder-distribution)
+ [Bagaimana Amazon ECS menempatkan tugas pada instans kontainer (termasuk Fargate)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement.html)
+ [Ketahanan di AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/security-resilience.html)
+ [Ikhtisar Amazon S3: Mereplikasi objek](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html)
+ [Replikasi image privat di Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/replication.html)
+ [Tabel Global: Replikasi Multi-Wilayah dengan DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GlobalTables.html)
+ [Amazon ElastiCache for Redis OSS: Replikasi di beberapa Wilayah AWS menggunakan penyimpanan data global](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Redis-Global-Datastore.html)
+ [Ketahanan dalam Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/disaster-recovery-resiliency.html)
+ [Menggunakan basis data global Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.html)
+ [Panduan Developer AWS Global Accelerator](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html)
+ [Kunci Multi-Wilayah di AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-overview.html)
+ [Amazon Route 53: Mengonfigurasi failover DNS](https://docs.aws.amazon.com/Route 53/latest/DeveloperGuide/dns-failover-configuring.html)
+ [Panduan Developer Amazon Application Recovery Controller (ARC)](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
+ [Mengirim dan menerima peristiwa Amazon EventBridge antara Wilayah AWS](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-cross-region.html)
+ [Membuat Aplikasi Multi-Wilayah dengan seri blog Layanan AWS](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/)
+ [Arsitektur Pemulihan Bencana (DR) di AWS, Bagian I: Strategi untuk Pemulihan di Cloud](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-i-strategies-for-recovery-in-the-cloud/)
+ [Arsitektur Pemulihan Bencana (DR) di AWS, Bagian III: Pilot Light dan Warm Standby](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/)
**Video terkait:**
+ [AWS re:Invent 2018: Pola Arsitektur untuk Aplikasi Aktif-Aktif Multi-Wilayah](https://youtu.be/2e29I3dA8o4)
+ [AWS re:Invent 2019: Inovasi dan operasi infrastruktur jaringan global AWS](https://youtu.be/UObQZ3R9_4c)
# REL10-BP02 Mengotomatiskan pemulihan untuk komponen yang dibatasi dalam satu lokasi
Jika komponen beban kerja hanya dapat dijalankan di satu Zona Ketersediaan atau di pusat data on-premise, implementasikan kemampuan untuk membangun kembali beban kerja sepenuhnya dalam lingkup tujuan pemulihan yang telah ditetapkan.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Sedang
## Panduan implementasi
Jika praktik terbaik untuk melakukan deployment beban kerja ke beberapa lokasi tidak mungkin dilakukan karena adanya kendala teknologi, Anda harus mengimplementasikan jalur alternatif untuk mewujudkan ketahanan. Anda harus melakukan otomatisasi terhadap kemampuan untuk membuat ulang infrastruktur yang dibutuhkan, melakukan deployment ulang aplikasi, dan membuat ulang data yang diperlukan untuk kasus ini.
Misalnya, Amazon EMR meluncurkan semua simpul untuk klaster tertentu yang tersedia dalam Zona Ketersediaan yang sama karena menjalankan klaster di zona yang sama dapat meningkatkan kinerja aliran tugas berkat tingkat akses data yang lebih tinggi. Jika komponen ini tidak dibutuhkan untuk ketahanan beban kerja, maka Anda harus mencari cara lain untuk melakukan deployment ulang klaster dan datanya. Selain itu, untuk Amazon EMR, Anda harus menyediakan redundansi selain dengan menggunakan Multi-AZ. Anda dapat menyediakan [beberapa simpul](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-ha-launch.html). Menggunakan [EMR File System (EMRFS)](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-fs.html), data yang ada dalam EMR dapat disimpan dalam Amazon S3, sehingga nantinya dapat direplikasi di seluruh Zona Ketersediaan atau Wilayah AWS.
Dengan cara yang serupa, untuk Amazon Redshift, secara default menyediakan klaster dalam Zona Ketersediaan yang dipilih secara acak dalam Wilayah AWS pilihan Anda. Semua simpul klaster disediakan dalam zona yang sama.
Untuk beban kerja stateful berbasis server yang di-deploy ke sebuah pusat data on-premise, Anda dapat menggunakan AWS Elastic Disaster Recovery untuk melindungi beban kerja Anda yang ada di AWS. Jika Anda sudah di-hosting di AWS, Anda dapat menggunakan Elastic Disaster Recovery untuk memberikan proteksi terhadap beban kerja Anda ke Zona Ketersediaan atau Wilayah alternatif. Elastic Disaster Recovery menggunakan replikasi tingkat blok berkelanjutan ke area staging yang ringan untuk menyediakan pemulihan aplikasi berbasis cloud dan on-premise yang cepat dan andal.
**Langkah-langkah implementasi**
1. Implementasikan pemulihan mandiri. Deploy instans dan kontainer Anda dengan menggunakan penskalaan otomatis jika memungkinkan. Jika tidak dapat menggunakan penskalaan otomatis, Anda harus menggunakan pemulihan otomatis untuk instans EC2 atau implementasikan otomatisasi pemulihan mandiri berdasarkan peristiwa siklus hidup kontainer Amazon EC2 atau ECS.
+ Gunakan [grup Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html) untuk instans atau beban kerja kontainer yang tidak memiliki persyaratan untuk alamat IP instans tunggal, alamat IP pribadi, alamat IP Elastis, dan metadata instans.
+ Data pengguna templat peluncuran dapat Anda gunakan untuk mengimplementasikan otomatisasi yang dapat memulihkan sebagian besar beban kerja secara mandiri.
+ Gunakan [pemulihan otomatis instans Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html) untuk beban kerja yang memerlukan instans tunggal alamat ID, alamat IP pribadi, alamat IP Elastis, dan instans metadata.
+ Pemulihan Otomatis akan mengirimkan peringatan status pemulihan kepada sebuah topik SNS saat ada kegagalan instans yang terdeteksi.
+ Gunakan [peristiwa siklus hidup instans Amazon EC2](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html) atau [peristiwa Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_cwe_events.html) untuk mengotomatiskan pemulihan mandiri jika penskalaan otomatis atau pemulihan EC2 tidak dapat digunakan.
+ Gunakan peristiwa untuk menginvokasi otomatisasi yang akan memulihkan komponen Anda berdasarkan proses logika yang diperlukan.
+ Berikan proteksi terhadap beban kerja stateful yang terbatas pada satu lokasi dengan menggunakan [AWS Elastic Disaster Recovery](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html).
## Sumber daya
**Dokumen terkait:**
+ [Peristiwa Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_cwe_events.html)
+ [Pengait siklus hidup Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html)
+ [Pulihkan instans Anda.](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html)
+ [Penskalaan otomatis layanan](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-auto-scaling.html)
+ [Apa itu Amazon EC2 Auto Scaling?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
+ [AWS Elastic Disaster Recovery](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)
# REL10-BP03 Menggunakan arsitektur bulkhead untuk membatasi cakupan dampak
Implementasikan arsitektur bulkhead (juga disebut sebagai arsitektur berbasis sel) untuk membatasi efek kegagalan dalam beban kerja hingga jumlah komponen yang terbatas.
**Hasil yang diinginkan:** Arsitektur berbasis sel menggunakan beberapa instans beban kerja yang terisolasi, di mana setiap instans dikenal sebagai sel. Setiap sel bersifat mandiri, tidak berbagi status dengan sel yang lain, dan menangani subset permintaan beban kerja secara keseluruhan. Hal ini dapat mengurangi potensi dampak yang mungkin ditimbulkan oleh sebuah kegagalan, seperti pembaruan perangkat lunak yang buruk, sehingga hanya berdampak pada satu sel individu dan permintaan yang diprosesnya. Jika beban kerja menggunakan 10 sel untuk melayani 100 permintaan, ketika ada satu kegagalan yang terjadi, 90% dari seluruh permintaan tidak akan terpengaruh oleh kegagalan tersebut.
**Anti-pola umum:**
+ Membiarkan sel bertumbuh tanpa batas.
+ Menerapkan pembaruan kode atau deployment ke semua sel pada waktu yang sama.
+ Berbagi status atau komponen antara sel (dengan pengecualian lapisan router).
+ Menambahkan bisnis yang kompleks atau mengarahkan rute logika ke lapisan router.
+ Tidak meminimalkan interaksi lintas sel.
**Manfaat menerapkan praktik terbaik ini:** Dengan arsitektur berbasis sel, banyak jenis kegagalan umum akan dibatasi di dalam sel itu sendiri, sehingga memberikan isolasi kesalahan tambahan. Batasan-batasan kesalahan ini dapat memberikan ketahanan terhadap berbagai tipe kegagalan yang sulit ditampung, seperti deployment kode yang tidak berhasil atau permintaan yang rusak atau menginvokasi mode kegagalan tertentu (juga dikenal sebagai *permintaan pil racun)*.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Tinggi
## Panduan implementasi
Di sebuah kapal, bulkhead memastikan kebocoran lambung kapal hanya dibatasi dalam satu bagian lambung kapal saja. Di sistem yang kompleks, pola ini sering kali direplikasi untuk memungkinkan Anda melakukan isolasi kesalahan. Batasan-batasan isolasi kesalahan ini akan membatasi efek yang ditimbulkan kegagalan di dalam sebuah beban kerja sehingga hanya berdampak pada sejumlah komponen yang terbatas saja. Komponen-komponen yang ada di luar batasan-batasan ini tidak terpengaruh oleh kegagalan tersebut. Menggunakan beberapa batasan isolasi kesalahan, Anda dapat membatasi dampak pada beban kerja Anda. Di AWS, pelanggan dapat menggunakan beberapa Zona Ketersediaan dan Wilayah untuk menyediakan isolasi kesalahan, tetapi konsep isolasi kesalahan ini dapat diperluas ke arsitektur beban kerja juga.
Beban kerja secara keseluruhan adalah sel-sel yang dipartisi oleh sebuah kunci partisi. Kunci ini harus selaras dengan *grain* layanan, atau cara alami beban kerja layanan dapat dibagi lebih lanjut dengan interaksi lintas sel yang minim. Contoh kunci partisi ini antara lain ID pelanggan, ID sumber daya, atau parameter lainnya yang dapat diakses dengan mudah dalam sebagian besar panggilan API. Lapisan perutean sel mendistribusikan permintaan ke masing-masing sel berdasarkan kunci partisi tersebut dan memberikan satu titik akhir ke klien.
![\[Diagram menampilkan Arsitektur berbasis sel\]](http://docs.aws.amazon.com/id_id/wellarchitected/latest/framework/images/cell-based-architecture.png)
**Langkah-langkah implementasi**
Ketika mendesain sebuah arsitektur berbasis sel, ada beberapa pertimbangan desain yang harus Anda pikirkan:
1. **Kunci partisi**: Pertimbangan khusus harus diambil saat memilih kunci partisi.
+ Kunci ini harus sesuai dengan grain layanan, atau cara alami beban kerja dari sebuah layanan dapat dibagi lebih lanjut dengan interaksi lintas sel yang minimum. Contohnya adalah `customer ID` atau `resource ID`.
+ Kunci partisi harus tersedia dalam semua permintaan, baik secara langsung atau dengan cara yang dapat disimpulkan dengan pasti dan mudah berdasarkan parameter-parameter lain.
1. **Pemetaan sel persisten**: Layanan-layanan hulu seharusnya hanya berinteraksi dengan satu sel untuk siklus hidup sumber daya mereka.
+ Bergantung pada beban kerjanya, strategi migrasi sel mungkin perlu digunakan untuk memigrasikan data dari satu sel ke yang lain. Kemungkinan skenario ketika migrasi sel mungkin diperlukan adalah jika sumber daya atau pengguna tertentu yang ada di dalam beban kerja Anda menjadi terlalu besar dan memerlukan sebuah sel khusus.
+ Sel tidak boleh berbagi status atau komponen antara sel.
+ Oleh karena itu, interaksi lintas sel harus dihindari atau dijaga agar tetap minimum, karena interaksi tersebut akan menimbulkan dependensi antara sel, dan karena itu akan mengurangi peningkatan isolasi kesalahan.
1. **Lapisan router**: Lapisan router adalah sebuah komponen bersama antar sel, dan karena itu tidak dapat mengikuti strategi kompartementalisasi yang sama seperti sel.
+ Sebaiknya lapisan router mendistribusikan permintaan ke masing-masing sel dengan menggunakan algoritma pemetaan partisi dengan cara yang efisien secara komputasional, seperti menggabungkan fungsi hash kriptografi dan aritmetika modul untuk memetakan kunci partisi ke sel.
+ Untuk menghindari dampak yang timbul terhadap banyak sel, lapisan perutean harus dibuat sesederhana mungkin dan dapat diskalakan sehorizontal mungkin, sehingga Anda harus menghindari logika bisnis kompleks di dalam lapisan ini. Hal ini memiliki manfaat tambahan yakni mempermudah pemahaman terhadap harapan perilakunya di setiap waktu, sehingga memberikan kemampuan untuk diuji secara menyeluruh. Seperti yang dijelaskan oleh Colm MacCárthaigh dalam [Keandalan, kerja konstan, dan secangkir kopi yang enak](https://aws.amazon.com/builders-library/reliability-and-constant-work/), desain sederhana dan pola kerja yang konstan akan menghasilkan sistem yang andal dan mengurangi anti-kerapuhan.
1. **Ukuran sel**: Sel harus memiliki ukuran maksimum dan tidak boleh dibiarkan tumbuh melampaui ukuran itu.
+ Ukuran maksimum harus diidentifikasi dengan melakukan pengujian menyeluruh, sampai titik rusak tercapai dan margin pengoperasian yang aman ditetapkan. Untuk detail selengkapnya tentang cara mengimplementasikan praktik pengujian, lihat [REL07-BP04 Beban uji beban kerja Anda](rel_adapt_to_changes_load_tested_adapt.md)
+ Beban kerja secara keseluruhan harus bertumbuh dengan menambahkan sel-sel tambahan, sehingga beban kerja dapat diskalakan seiring dengan peningkatan permintaan.
1. **Strategi Multi-AZ atau Multi-Wilayah**: Beberapa lapisan ketahanan harus dimanfaatkan untuk memberikan perlindungan dari domain kegagalan yang berbeda.
+ Untuk ketahanan, Anda harus menggunakan sebuah pendekatan yang membangun berlapis-lapis pertahanan. Satu lapisan melindungi Anda dari gangguan yang lebih kecil dan lebih umum dengan membangun arsitektur yang memiliki ketersediaan tinggi dengan menggunakan beberapa AZ. Lapisan pertahanan lainnya ditujukan untuk memberikan proteksi dari peristiwa-peristiwa langka seperti bencana alam yang meluas dan gangguan tingkat Wilayah. Lapisan kedua ini melibatkan perancangan aplikasi agar menjangkau beberapa Wilayah AWS. Mengimplementasikan strategi multi-Wilayah untuk beban kerja dapat membantu Anda melindunginya dari bencana alam yang menjangkau dan memengaruhi wilayah geografis yang luas di suatu negara, atau kegagalan-kegagalan teknis yang mencakup seluruh Wilayah. Perhatikan bahwa mengimplementasikan arsitektur multi-Wilayah dapat menjadi suatu hal yang sangat kompleks, dan biasanya tidak diperlukan untuk sebagian besar beban kerja. Untuk detail selengkapnya, lihat [REL10-BP01 Melakukan deployment beban kerja ke beberapa lokasi](rel_fault_isolation_multiaz_region_system.md).
1. **Kode deployment**: Strategi deployment kode yang bertahap seharusnya lebih disarankan untuk digunakan daripada menerapkan deployment perubahan kode ke semua sel secara bersamaan.
+ Hal ini akan membantu Anda dalam meminimalkan potensi kegagalan pada beberapa sel karena deployment yang buruk atau kesalahan manusia. Untuk detail selengkapnya, silakan lihat [Melakukan otomatisasi deployment secara aman dan otonom](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/).
## Sumber daya
**Praktik-praktik terbaik terkait:**
+ [REL07-BP04 Beban uji beban kerja Anda](rel_adapt_to_changes_load_tested_adapt.md)
+ [REL10-BP01 Melakukan deployment beban kerja ke beberapa lokasi](rel_fault_isolation_multiaz_region_system.md)
**Dokumen terkait:**
+ [Keandalan, kerja konstan, dan secangkir kopi yang enak](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
+ [AWS dan Kompartementalisasi](https://aws.amazon.com/blogs/architecture/aws-and-compartmentalization/)
+ [Isolasi beban kerja dengan menggunakan shuffle-sharding](https://aws.amazon.com/builders-library/workload-isolation-using-shuffle-sharding/)
+ [Melakukan otomatisasi deployment secara aman dan otonom](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/)
**Video terkait:**
+ [AWS re:Invent 2018: Loop Tertutup dan Pikiran Terbuka: Cara Mengendalikan Sistem, Besar dan Kecil](https://www.youtube.com/watch?v=O8xLxNje30M)
+ [AWS re:Invent 2018: Cara AWS Meminimalkan Radius Dampak Kegagalan (ARC338)](https://youtu.be/swQbA4zub20)
+ [Shuffle-sharding: AWS re:Invent 2019: Memperkenalkan Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1373)
+ [AWS Summit ANZ 2021 - Semuanya gagal, sepanjang waktu: Merancang untuk ketahanan ](https://www.youtube.com/watch?v=wUzSeSfu1XA)
# REL 11. Bagaimana Anda mendesain beban kerja agar dapat bertahan jika terjadi 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/framework/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/)
# REL 12. Bagaimana cara menguji keandalan?
Setelah Anda mendesain beban kerja Anda agar tangguh terhadap tekanan produksi, pengujian adalah satu-satunya cara untuk memverifikasi bahwa beban kerja akan beroperasi sesuai desain, dan memberikan ketangguhan yang Anda harapkan.
**Topics**
+ [REL12-BP01 Menggunakan playbook 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 skalabilitas dan kinerja](rel_testing_resiliency_test_non_functional.md)
+ [REL12-BP04 Menguji ketahanan menggunakan chaos engineering](rel_testing_resiliency_failure_injection_resiliency.md)
+ [REL12-BP05 Mengadakan game day secara rutin](rel_testing_resiliency_game_days_resiliency.md)
# REL12-BP01 Menggunakan playbook untuk menyelidiki kegagalan
Dokumentasikan proses penyelidikan di dalam playbook agar dapat memberikan respons yang cepat dan konsisten terhadap skenario kegagalan yang tidak benar-benar dipahami. Playbook adalah langkah-langkah yang telah ditetapkan di awal untuk mengidentifikasi faktor yang menyebabkan skenario kegagalan. Hasil dari setiap langkah proses digunakan untuk menentukan langkah berikutnya yang harus diambil sampai masalah teridentifikasi atau dieskalasi.
Palybook ini adalah perencanaan proaktif yang harus Anda lakukan, agar Anda dapat mengambil tindakan reaktif secara efektif. Ketika skenario kegagalan yang tidak tercakup dalam playbook dialami di lingkungan produksi, tangani masalah terlebih dahulu (put our the fire). Lalu lihat kembali langkah-langkah yang telah Anda ambil untuk mengatasi masalah tersebut dan gunakan itu semua untuk menambahkan entri baru dalam playbook.
Perhatikan, playbook digunakan untuk merespons insiden tertentu, sedangkan runbook digunakan untuk mencapai hasil tertentu. Sering kali, runbook digunakan untuk untuk aktivitas rutin, dan playbook digunakan untuk merespons peristiwa non-rutin.
**Anti-pola 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 menerapkan praktik terbaik ini:** Merekam playbook akan memastikan bahwa proses dapat diikuti secara konsisten. Melakukan kodifikasi pada playbook dapat membatasi munculnya kesalahan dari aktivitas manual. Melakukan otomatisasi pada playbook 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 diterapkan:** Tinggi
## Panduan implementasi
+ Gunakan playbook untuk mengidentifikasi masalah. Playbook adalah proses-proses yang didokumentasikan untuk menyelidiki masalah. Dokumentasikan proses penyelidikan di playbook 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 pasca-insiden).
+ Implementasikan playbook sebagai kode. Jalankan operasi sebagai kode dengan membuat skrip playbook Anda untuk memastikan konsistensi dan mengurangi kesalahan yang disebabkan proses manual. Playbook dapat terdiri dari beberapa skrip sesuai dengan banyaknya langkah yang diperlukan untuk mengidentifikasi faktor-faktor penyebab masalah. Aktivitas runbook dapat diinvokasi atau dijalankan sebagai bagian dari aktivitas buku pedoman, atau mempercepat eksekusi buku pedoman untuk merespons peristiwa yang teridentifikasi.
+ [Lakukan otomatisasi pada playbook operasional Anda dengan Systems Manager AWS](https://aws.amazon.com/about-aws/whats-new/2019/11/automate-your-operational-playbooks-with-aws-systems-manager/)
+ [Run Command Systems Manager AWS](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)
+ [Run Command Systems Manager AWS](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html)
+ [Lakukan otomatisasi pada playbook operasional Anda dengan Systems Manager AWS](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:**
+ [Melakukan otomatisasi operasi dengan Playbook dan Runbook](https://wellarchitectedlabs.com/operational-excellence/200_labs/200_automating_operations_with_playbooks_and_runbooks/)
# REL12-BP02 Menjalankan analisis setelah insiden
Lakukan peninjauan terhadap peristiwa-peristiwa yang memengaruhi pelanggan, dan identifikasi faktor yang berkontribusi serta tindakan pencegahannya. Gunakan informasi ini untuk mengembangkan langkah-langkah mitigasi untuk meminimalkan atau mencegah kemungkinan terjadi lagi. Kembangkan prosedur untuk respons efektif dan cepat. Komunikasikan faktor-faktor yang berkontribusi dan tindakan-tindakan korektif yang diperlukan, yang disesuaikan dengan audiens target. Buatlah sebuah metode untuk mengomunikasikan penyebab ini ke pihak-pihak lain sesuai keperluan.
Lakukan penilaian untuk mengidentifikasi alasan mengapa pengujian yang ada tidak dapat menemukan masalahnya. Menambahkan pengujian untuk kasus ini jika pengujian belum ada.
**Hasil yang diinginkan:** Tim Anda memiliki pendekatan yang konsisten dan disepakati untuk menangani analisis pasca-insiden. Salah satu mekanismenya adalah [proses koreksi kesalahan (COE)](https://aws.amazon.com/blogs/mt/why-you-should-develop-a-correction-of-error-coe/). Proses COE akan membantu tim Anda untuk mengidentifikasi, memahami, dan mengatasi akar penyebab insiden, sekaligus membangun mekanisme dan pagar pembatas untuk membatasi kemungkinan insiden yang sama terjadi lagi.
**Anti-pola umum:**
+ Menemukan temuan tentang faktor-faktor yang berkontribusi, tetapi tidak terus-menerus mencari lebih dalam berusaha mencari 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.
+ Fokus menyalahkan, bukan memahami akar penyebabnya, sehingga tercipta budaya ketakutan dan menghambat komunikasi yang terbuka
+ Tidak berbagi wawasan, yang membuat temuan-temuan analisis insiden hanya diketahui kelompok kecil saja, sehingga orang lain tidak dapat belajar dari pengalaman tersebut
+ Tidak ada mekanisme yang digunakan untuk mencatat pengetahuan institusional, sehingga wawasan yang berharga hilang karena pelajaran yang didapat tidak diabadikan dalam bentuk praktik terbaik yang diperbarui secara berkelanjutan dan mengakibatkan insiden berulang dengan akar penyebab yang sama atau serupa
**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
Analisis setelah insiden yang baik memberikan peluang untuk mengusulkan solusi-solusi umum terhadap masalah dengan pola arsitektur yang digunakan di tempat lainnya dalam sistem.
Dokumentasi dan penanganan masalah merupakan landasan proses COE. Sebaiknya tentukan cara standar untuk mendokumentasikan akar penyebab masalah kritis, dan memastikan penyebab tersebut ditinjau dan ditangani. Tetapkan kepemilikan yang jelas untuk proses analisis setelah insiden. Tunjuk individu atau tim penanggung jawab yang akan mengawasi penyelidikan dan tindak lanjut insiden.
Dorong budaya yang berfokus pada pembelajaran dan peningkatan, bukan menyalahkan. Tekankan bahwa tujuannya adalah untuk mencegah insiden di kemudian hari, bukan untuk menghukum individu.
Kembangkan prosedur yang jelas untuk melakukan analisis setelah insiden. Prosedur ini harus menguraikan langkah-langkah yang harus diambil, informasi yang akan dikumpulkan, dan pertanyaan-pertanyaan penting yang harus dicari jawabannya saat melakukan analisis. Selidiki insiden secara menyeluruh, tidak hanya pada penyebab langsung guna mengidentifikasi akar penyebab masalah dan faktor penyumbangnya. Gunakan teknik-teknik seperti *[lima alasan](https://en.wikipedia.org/wiki/Five_whys)* untuk memahami lebih dalam masalah-masalah mendasar.
Buatlah repositori pelajaran yang didapat dari analisis insiden. Pengetahuan institusional ini dapat digunakan sebagai referensi untuk insiden dan upaya pencegahan ke depannya. Bagikan temuan dan wawasan dari analisis yang dilakukan setelah insiden, dan pertimbangkan untuk mengadakan pertemuan peninjauan pasca insiden yang terbuka untuk semua (open-invite) untuk membahas pelajaran yang didapatkan.
### Langkah-langkah implementasi
+ Saat melakukan analisis pasca-insiden, pastikan untuk tidak menyalahkan siapa pun dalam proses tersebut. Dengan begitu, orang-orang yang terlibat dalam insiden tersebut bersikap rasional terhadap tindakan korektif yang diusulkan dan mendorong penilaian mandiri yang jujur serta kolaborasi di seluruh tim.
+ Tentukan cara terstandardisasi untuk mendokumentasikan masalah-masalah kritis. Contoh struktur untuk dokumen tersebut adalah sebagai berikut:
+ Apa yang terjadi?
+ Apa dampaknya terhadap para pelanggan dan bisnis Anda?
+ Apa akar penyebabnya?
+ Data apa yang Anda miliki untuk mendukung hal ini?
+ Misalnya, metrik dan grafik
+ Apa implikasi pilar kritis, terutama keamanan?
+ Saat merancang beban kerja, Anda memilah pilar-pilar sesuai dengan konteks bisnis Anda. Keputusan bisnis ini dapat mendorong prioritas rekayasa Anda. Anda dapat melakukan optimalisasi untuk mengurangi biaya dengan mengorbankan keandalan dalam lingkungan pengembangan, atau, untuk solusi yang sangat penting, Anda dapat melakukan optimalisasi keandalan dengan biaya yang lebih tinggi. Keamanan selalu menjadi hal yang didahulukan dan diutamakan, karena Anda harus melindungi pelanggan Anda.
+ Pelajaran apa hal yang Anda dapatkan?
+ Tindakan-tindakan korektif apa yang Anda ambil?
+ Item tindakan
+ Item terkait
+ Buat prosedur-prosed operasi terstandardisasi yang jelas untuk melakukan analisis pasca insiden.
+ Siapkan proses pelaporan insiden terstandardisasi. Dokumentasikan semua insiden secara komprehensif, termasuk laporan insiden awal, log, komunikasi, dan tindakan-tindakan yang diambil saat insiden berlangsung.
+ Ingatlah bahwa sebuah insiden tidak harus berupa terhentinya sistem (outage). Insiden juga bisa berupa kejadian yang hampir menyebabkan henti sistem (near-miss), atau performa sistem yang tidak sesuai harapan meski tetap memenuhi fungsi bisnisnya.
+ Terus tingkatkan proses analisis pasca insiden Anda berdasarkan umpan balik dan pelajaran yang dipetik.
+ Rekam temuan-temuan utama dalam sistem manajemen pengetahuan, dan pertimbangkan pola apa pun yang perlu ditambahkan ke dalam panduan developer atau daftar periksa sebelum deployment.
## Sumber daya
**Dokumen terkait:**
+ [Mengapa Anda harus mengembangkan koreksi kesalahan (COE)](https://aws.amazon.com/blogs/mt/why-you-should-develop-a-correction-of-error-coe/)
**Video terkait:**
+ [ Pendekatan Amazon untuk gagal dengan sukses ](https://aws.amazon.com/builders-library/amazon-approach-to-failing-successfully/)
+ [AWS re:Invent 2021 - Amazon Builders' Library: Keunggulan Operasional di Amazon ](https://www.youtube.com/watch?v=7MrD4VSLC_w)
# REL12-BP03 Menguji persyaratan skalabilitas dan kinerja
Gunakan teknik-teknik seperti pengujian beban untuk memvalidasi bahwa beban kerja memenuhi persyaratan kinerja dan penskalaan.
Di dalam cloud, Anda dapat membuat sebuah lingkungan pengujian dalam skala produksi untuk beban kerja Anda sesuai permintaan. Alih-alih mengandalkan lingkungan pengujian dengan skala yang diturunkan, sehingga dapat membuat prediksi perilaku produksi tidak akurat, Anda dapat menggunakan cloud untuk menyediakan lingkungan pengujian yang sangat mirip dengan lingkungan produksi yang Anda harapkan. Lingkungan ini membantu Anda menguji dengan simulasi yang lebih akurat dari kondisi nyata yang dihadapi aplikasi Anda.
Selain upaya pengujian performa, penting juga untuk memvalidasi bahwa sumber daya dasar, pengaturan penskalaan, kuota layanan, dan desain ketahanan Anda beroperasi sebagaimana mestinya saat menerima beban. Pendekatan holistik ini memverifikasi bahwa penskalaaan dan performa aplikasi bisa diandalkan sesuai kebutuhan, bahkan dalam kondisi yang paling berat.
**Hasil yang diinginkan:** Beban kerja Anda tetap memiliki perilaku yang diharapkan bahkan saat mengalami beban puncak. Anda secara proaktif mengatasi masalah terkait performa yang mungkin timbul seiring aplikasi bertumbuh dan berkembang.
**Anti-pola umum:**
+ Anda menggunakan lingkungan pengujian yang tidak mencerminkan lingkungan produksi.
+ Anda memperlakukan pengujian beban sebagai aktivitas satu kali yang terpisah, bukan bagian terintegrasi dari pipeline integrasi berkelanjutan (CI) deployment.
+ Anda tidak menentukan persyaratan performa yang jelas dan terukur, seperti target waktu respons, throughput, dan skalabilitas.
+ Anda melakukan pengujian dengan skenario beban yang tidak realistis atau tidak memadai, dan Anda gagal menguji beban puncak, lonjakan mendadak, dan beban tinggi yang berkelanjutan.
+ Anda tidak melakukan pengujian tekanan pada beban kerja hingga melebihi batas beban yang diharapkan.
+ Anda menggunakan alat pengujian beban dan pembuatan profil performa yang tidak memadai atau tidak tepat.
+ Anda tidak memiliki sistem pemantauan dan peringatan yang komprehensif untuk melacak metrik performa dan mendeteksi anomali.
**Manfaat menjalankan praktik terbaik ini:**
+ Pengujian beban membantu Anda mengidentifikasi potensi hambatan performa dalam sistem Anda sebelum masalah ini masuk ke produksi. Saat Anda menyimulasikan lalu lintas dan beban kerja tingkat produksi, Anda dapat mengidentifikasi di area mana sistem Anda mungkin kesulitan menangani beban, seperti waktu respons yang lambat, keterbatasan sumber daya, atau kegagalan sistem.
+ Dengan menguji sistem Anda dalam berbagai kondisi beban, Anda dapat lebih memahami persyaratan sumber daya yang diperlukan untuk mendukung beban kerja Anda. Informasi ini dapat membantu Anda membuat keputusan yang matang untuk alokasi sumber daya dan mencegah penyediaan sumber daya yang berlebih atau kurang.
+ Untuk mengidentifikasi potensi titik kegagalan, Anda dapat mengamati performa beban kerja Anda dalam kondisi beban tinggi. Informasi ini membantu Anda meningkatkan keandalan dan ketahanan beban kerja Anda dengan menerapkan mekanisme toleransi kesalahan, strategi failover, dan tindakan redundansi yang sesuai.
+ Anda mengidentifikasi dan mengatasi masalah performa lebih dini, sehingga Anda dapat terhindari dari konsekuensi yang merugikan seperti pemadaman sistem, waktu respons yang lambat, dan ketidakpuasan pengguna.
+ Data performa mendetail dan informasi pembuatan profil yang dikumpulkan selama pengujian dapat membantu Anda memecahkan masalah performa yang mungkin muncul dalam produksi. Hal ini dapat menghasilkan respons dan penyelesaian insiden yang lebih cepat, sehingga mengurangi dampak bagi pengguna dan operasi organisasi Anda.
+ Dalam industri tertentu, pengujian performa proaktif dapat membantu beban kerja Anda memenuhi standar kepatuhan, sehingga mengurangi risiko denda atau masalah hukum.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Tinggi
## Panduan implementasi
Langkah pertama adalah menentukan strategi pengujian komprehensif yang mencakup semua aspek penskalaan dan persyaratan performa. Untuk memulai, tentukan dengan jelas sasaran tingkat layanan (SLO) beban kerja Anda berdasarkan kebutuhan bisnis Anda, seperti throughput, histogram latensi, dan tingkat kesalahan. Selanjutnya, rancang serangkaian pengujian yang dapat menyimulasikan berbagai skenario beban yang berkisar dari penggunaan rata-rata hingga lonjakan mendadak dan beban puncak berkelanjutan, dan verifikasi bahwa perilaku beban kerja memenuhi SLO Anda. Pengujian ini harus diotomatisasi dan diintegrasikan ke dalam pipeline integrasi dan deployment berkelanjutan Anda untuk menemukan regresi performa lebih dini dalam proses pengembangan.
Untuk menguji penskalaan dan performa secara efektif, berinvestasilah pada alat dan infrastruktur yang tepat. Hal ini termasuk alat pengujian beban yang dapat menghasilkan lalu lintas pengguna yang realistis, alat profil performa untuk mengidentifikasi hambatan, dan solusi pemantauan untuk melacak metrik utama. Yang penting, Anda harus memverifikasi bahwa lingkungan pengujian Anda sangat mirip dengan lingkungan produksi dalam hal infrastruktur dan kondisi lingkungan untuk mendapatkan hasil pengujian seakurat mungkin. Untuk mempermudah mereplikasi dan menskalakan pengaturan mirip produksi dengan andal, gunakan infrastruktur sebagai kode dan aplikasi berbasis kontainer.
Pengujian penskalaan dan performa adalah proses yang berkelanjutan, tidak hanya dilakukan satu kali saja. Implementasikan pemantauan dan peringatan komprehensif untuk melacak performa aplikasi dalam produksi, serta gunakan data ini untuk terus menyempurnakan strategi pengujian dan upaya pengoptimalan Anda. Analisis data performa secara rutin untuk mengidentifikasi masalah yang muncul, menguji strategi penskalaan baru, dan mengimplementasikan pengoptimalan untuk meningkatkan efisiensi dan keandalan aplikasi. Ketika Anda mengadopsi pendekatan iteratif dan terus belajar dari data produksi, Anda bisa memverifikasi bahwa aplikasi Anda dapat beradaptasi dengan permintaan pengguna yang bervariasi dan menjaga ketahanan serta performa yang optimal dari waktu ke waktu.
### Langkah-langkah implementasi
1. Tentukan persyaratan performa yang jelas dan terukur, seperti target waktu respons, throughput, dan skalabilitas. Persyaratan ini harus didasarkan pada pola penggunaan beban kerja, ekspektasi pengguna, dan kebutuhan bisnis Anda.
1. Pilih dan konfigurasikan alat pengujian beban yang dapat secara akurat meniru pola beban dan perilaku pengguna di lingkungan produksi Anda.
1. Siapkan lingkungan pengujian yang sangat mirip dengan lingkungan produksi, termasuk kondisi infrastruktur dan lingkungan, agar hasil pengujian bisa lebih akurat.
1. Buat rangkaian pengujian yang mencakup berbagai skenario, mulai dari pola penggunaan rata-rata hingga beban puncak, lonjakan mendadak, dan beban tinggi yang berkelanjutan. Integrasikan pengujian ke dalam pipeline integrasi dan deployment berkelanjutan Anda untuk menemukan regresi performa lebih dini dalam proses pengembangan.
1. Lakukan pengujian beban untuk menyimulasikan lalu lintas pengguna di dunia nyata dan memahami bagaimana aplikasi Anda berperilaku dalam berbagai kondisi beban. Untuk melakukan pengujian tekanan terhadap aplikasi Anda, lampaui beban yang diharapkan dan amati perilakunya, seperti penurunan waktu respons, kehabisan sumber daya, atau kegagalan sistem, sehingga membantu mengidentifikasi titik puncak aplikasi Anda dan menentukan strategi penskalaan Anda. Evaluasi skalabilitas beban kerja Anda dengan meningkatkan beban secara bertahap, dan ukur dampak performa untuk mengidentifikasi batas penskalaan serta merencanakan kebutuhan kapasitas ke depannya.
1. Implementasikan pemantauan dan peringatan komprehensif untuk melacak metrik performa, mendeteksi anomali, dan memulai tindakan penskalaan atau pemberitahuan ketika ambang batas terlampaui.
1. Terus pantau dan analisis data performa untuk mengidentifikasi area yang dapat ditingkatkan lebih lanjut. Lakukan iterasi terhadap strategi pengujian dan upaya pengoptimalan Anda.
## Sumber daya
**Praktik-praktik terbaik terkait:**
+ [REL01-BP04 Memantau dan mengelola kuota](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_manage_service_limits_monitor_manage_limits.html)
+ [REL06-BP01 Memantau semua komponen untuk beban kerja (Pembuatan)](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_monitor_resources.html)
+ [REL06-BP03 Mengirimkan notifikasi (Pemrosesan dan pembuatan alarm waktu nyata)](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_notification_monitor.html)
**Dokumen terkait:**
+ [Aplikasi pengujian beban](https://docs.aws.amazon.com/prescriptive-guidance/latest/load-testing/welcome.html)
+ [Pengujian Beban Terdistribusi di AWS](https://aws.amazon.com/solutions/implementations/distributed-load-testing-on-aws/)
+ [Pemantauan Performa Aplikasi](https://aws.amazon.com/what-is/application-performance-monitoring/)
+ [Kebijakan Pengujian Amazon EC2](https://aws.amazon.com/ec2/testing/)
**Contoh terkait:**
+ [Pengujian Beban Terdistribusi di AWS (GitHub)](https://github.com/aws-solutions/distributed-load-testing-on-aws)
**Alat terkait:**
+ [Amazon CodeGuru Profiler](https://docs.aws.amazon.com/codeguru/latest/profiler-ug/what-is-codeguru-profiler.html)
+ [Amazon CloudWatch RUM](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html)
+ [Apache JMeter](https://jmeter.apache.org/)
+ [K6](https://k6.io/)
+ [Vegeta](https://github.com/tsenart/vegeta)
+ [Hey](https://github.com/rakyll/hey)
+ [ab](https://httpd.apache.org/docs/2.4/programs/ab.html)
+ [wrk](https://github.com/wg/wrk)
+ [Pengujian Beban Terdistribusi di AWS](https://aws.amazon.com/solutions/implementations/distributed-load-testing-on-aws/)
# REL12-BP04 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 yang diharapkan yang diketahui dari beban kerja Anda selama berlangsungnya sebuah peristiwa. Gabungkan chaos engineering dan pengujian ketahanan agar Anda meyakini bahwa beban kerja dapat bertahan dari kegagalan komponen dan dapat pulih dari gangguan tak terduga dengan dampak minimal hingga tanpa dampak.
** Anti-pola umum: **
+ Menentukan desain untuk mendapatkan ketahanan, tetapi tidak memastikan bagaimana fungsi beban kerja 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 pipeline CI/CD Anda maupun di luar deployment.
+ Tidak menggunakan analisis pasca-insiden terdahulu saat menentukan kesalahan mana yang akan digunakan dalam eksperimen.
** Manfaat menjalankan praktik terbaik ini:** Menginjeksi kesalahan untuk memverifikasi ketahanan beban kerja Anda akan membuat Anda percaya bahwa prosedur pemulihan yang dimiliki oleh desain Anda yang tangguh akan berfungsi efektif jika terjadi kesalahan nyata.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** 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 terhadap pelanggan Anda. Hal ini akan 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 operasi.
**catatan**
Chaos engineering adalah bidang ilmu yang bereksperimen pada suatu 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 pipeline 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 membuat simulasi 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 melakukan validasi [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 terjadi pada layanan Anda. Degradasi ini umumnya disebabkan oleh terjadinya 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 mengganti nama, menjangkau layanan DNS, atau membuat koneksi ke layanan yang dependen.
**Alat chaos engineering:**
AWS Fault Injection Service (AWS FIS) sebuah adalah layanan terkelola penuh untuk menjalankan eksperimen injeksi kesalahan yang dapat digunakan sebagai bagian dari pipeline CD Anda, atau di luar pipeline. AWS FIS adalah pilihan yang baik untuk digunakan selama game day chaos engineering. Ini mendukung pengenalan kesalahan 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 terhentinya 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/latest/framework/images/fault-injection-simulator.png)
Ada juga beberapa opsi pihak ketiga untuk melakukan eksperimen injeksi kesalahan. Ini termasuk alat-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 pada 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 memungkinkan Anda mengoordinasikan alur kerja injeksi kesalahan di antara beberapa alat. Misalnya, Anda dapat menjalankan pengujian tekanan pada CPU dari sebuah pod dengan menggunakan kesalahan Chaos Mesh atau Litmus sambil menghentikan sebagian simpul klaster yang dipilih secara acak menggunakan tindakan kesalahan AWS FIS.
## Langkah-langkah implementasi
1. Tentukan kesalahan mana yang akan digunakan untuk eksperimen.
Lakukan penilaian desain beban kerja Anda untuk mengetahui ketahanannya. Desain semacam itu (dibuat menggunakan praktik terbaik [Kerangka Well-Architected](https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html)) memperhitungkan risiko berdasarkan dependensi kritis, peristiwa masa lalu, 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 selengkapnya tentang cara membuat daftar tersebut, lihat [laporan resmi Peninjauan Kesiapan Operasional](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html) yang memandu Anda tentang cara membuat proses untuk mencegah terulangnya insiden sebelumnya. Proses Analisis Mode dan Efek Kegagalan (FMEA) memberikan Anda kerangka kerja untuk melakukan analisis tingkat komponen terhadap kegagalan dan bagaimana dampaknya terhadap beban kerja Anda. FMEA diuraikan secara lebih rinci oleh Adrian Cockcroft dalam [Mode Kegagalan dan Ketahanan Berkelanjutan](https://adrianco.medium.com/failure-modes-and-continuous-resilience-6553078caad5).
1. 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 pasca-insiden 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.
1. Untuk setiap eksperimen yang Anda lakukan, gunakan roda chaos engineering dan ketahanan berkelanjutan pada gambar berikut.
![\[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/latest/framework/images/chaos-engineering-flywheel.png)
1. 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.
1. 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 terjadi *kesalahan tertentu*, *nama beban kerja* akan *menjelaskan mitigasi kontrol* 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 Penyeimbangan Beban Elastis akan mengakibatkan Penyeimbangan Beban Elastis 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).
1. 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 paham, 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 aktif pada 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 akan memungkinkan Anda melakukan eksperimen dengan cakupan yang jelas dan mekanisme keamanan yang melakukan rollback jika eksperimen menimbulkan gangguan tak terduga. Untuk mempelajari tentang berbagai eksperimen yang lebih luas 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 berjalan dalam produksi di bawah beban dunia nyata menggunakan [deployment canary](https://medium.com/the-cloud-architect/chaos-engineering-q-a-how-to-safely-inject-failure-ced26e11b3db) yang memutar kontrol dan deployment sistem 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. [Monitor sintetis](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) (juga dikenal sebagai canary pengguna) adalah salah satu metrik yang biasanya harus Anda sertakan sebagai proksi pengguna. [Hentikan kondisi 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 (observabilitas) 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.
1. Verifikasikan hipotesisnya.
[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.
1. 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 Well-Architected AWS](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html). Panduan dan sumber daya tambahan dapat ditemukan di [Perpustakaan Pembangun AWS](https://aws.amazon.com/builders-library/), yang menghosting artikel tentang cara [meningkatkan pemeriksaan kondisi Anda](https://aws.amazon.com/builders-library/implementing-health-checks/) atau [menggunakan percobaan ulang dengan backoff dalam kode aplikasi Anda](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/), antara lain.
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.
1. 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 melakukan ini, lihat blog ini 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/). Laboratorium tentang [eksperimen AWS FIS berulang dalam pipeline CI/CD](https://chaos-engineering.workshop.aws/en/030_basic_content/080_cicd.html) ini memungkinkan Anda untuk bekerja langsung.
Eksperimen injeksi kesalahan juga merupakan bagian dari game day (lihat [REL12-BP05 Mengadakan game day secara rutin](rel_testing_resiliency_game_days_resiliency.md)). Game day menyimulasikan 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.
1. Rekam dan simpan hasil eksperimen.
Hasil eksperimen injeksi kesalahan harus direkam 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 eksperimen dengan AWS FIS](https://docs.aws.amazon.com/fis/latest/userguide/monitoring-logging.html) dapat menjadi bagian dari pengambilan data ini.
## Sumber daya
**Praktik-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 Menerima 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)
** 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-BP05 Mengadakan game day secara rutin
Lakukan game day untuk melatih prosedur Anda secara teratur dalam merespons kejadian dan gangguan yang memengaruhi beban kerja. Libatkan tim yang sama yang akan bertanggung jawab untuk menangani skenario produksi. Latihan-latihan ini membantu menerapkan langkah untuk mencegah dampak pada pengguna yang disebabkan oleh peristiwa produksi. Ketika Anda melatih prosedur respons Anda dalam kondisi realistis, Anda dapat mengidentifikasi dan mengatasi setiap kesenjangan atau kelemahan sebelum kejadian nyata terjadi.
Game day menyimulasikan peristiwa di lingkungan serupa produksi untuk menguji sistem, proses, dan respons tim. Tujuannya adalah untuk melakukan tindakan yang sama yang perlu dilakukan oleh tim seolah-olah peristiwa yang tidak diharapkan benar-benar terjadi. Latihan ini akan membantu Anda memahami sisi mana yang perlu ditingkatkan dan membantu mengembangkan pengalaman organisasi dalam menangani peristiwa dan gangguan. Hal ini harus dilakukan secara teratur sehingga tim Anda akan mengembangkan kebiasaan tentang cara memberikan respons.
Game day mempersiapkan tim untuk menangani peristiwa produksi dengan lebih percaya diri. Tim yang terlatih dengan baik lebih mampu mendeteksi dan merespons berbagai skenario dengan cepat. Hal ini akan jauh meningkatkan kesiapan dan postur ketahanan.
**Hasil yang diinginkan:** Anda menjalankan game day ketahanan secara konsisten dan terjadwal. Game day ini dianggap sebagai hal normal yang sama pentingnya dengan kegiatan bisnis lainnya. Organisasi Anda telah membangun budaya kesiapsiagaan, dan ketika masalah produksi terjadi, tim Anda siap untuk merespons secara efektif, menyelesaikan masalah secara efisien, dan memitigasi dampak terhadap pelanggan.
**Anti-pola umum:**
+ Anda mendokumentasikan prosedur, tetapi tidak pernah mengadakan latihannya.
+ Anda tidak melibatkan pengambil keputusan bisnis dalam latihan pengujian.
+ Anda menjalankan game day, tetapi Anda tidak memberi tahu semua pemangku kepentingan yang relevan.
+ Anda hanya fokus pada kegagalan teknis, tetapi Anda tidak melibatkan pemangku kepentingan bisnis.
+ Anda tidak menerapkan pelajaran yang dipetik dari game day ke dalam proses pemulihan Anda.
+ Anda menyalahkan tim atas kegagalan atau bug.
**Manfaat menjalankan praktik terbaik ini:**
+ Meningkatkan keterampilan respons: Pada game day, tim mempraktikkan tugas mereka dan menguji mekanisme komunikasi mereka selama peristiwa simulasi, sehingga menciptakan respons yang lebih terkoordinasi dan efisien dalam situasi produksi.
+ Mengidentifikasi dan mengatasi dependensi: Lingkungan yang kompleks sering kali melibatkan dependensi yang rumit antara berbagai sistem, layanan, dan komponen. Game day dapat membantu Anda mengidentifikasi dan mengatasi dependensi ini, dan memverifikasi bahwa sistem dan layanan penting Anda tercakup dengan benar dalam prosedur runbook Anda dan dapat dinaikkan skalanya atau dipulihkan dengan segera.
+ Menumbuhkan budaya ketahanan: Game day dapat membantu menumbuhkan pola pikir ketahanan dalam suatu organisasi. Ketika Anda melibatkan tim lintas fungsi dan pemangku kepentingan, latihan ini mempromosikan kesadaran, kolaborasi, dan pemahaman bersama tentang pentingnya ketahanan di seluruh organisasi.
+ Peningkatan dan adaptasi berkelanjutan: Game day reguler membantu Anda untuk terus menilai dan menyesuaikan strategi ketahanan Anda, sehingga membuatnya tetap relevan dan efektif dalam menghadapi keadaan yang berubah-ubah.
+ Meningkatkan kepercayaan pada sistem: Game day yang berhasil dapat membantu Anda membangun kepercayaan pada kemampuan sistem untuk bertahan dan pulih dari gangguan.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Sedang
## Panduan implementasi
Setelah Anda merancang dan mengimplementasikan langkah-langkah ketahanan yang diperlukan, lakukan game day untuk memvalidasi bahwa semuanya berfungsi sesuai rencana dalam produksi. Game day, terutama yang pertama, harus melibatkan semua anggota tim. Semua pemangku kepentingan dan peserta harus diberi tahu terlebih dahulu tentang tanggal, waktu, dan skenario simulasi.
Selama game day, tim yang terlibat menyimulasikan berbagai peristiwa dan skenario potensial sesuai dengan prosedur yang ditentukan. Para peserta memantau dengan cermat dan menilai dampak dari peristiwa simulasi ini. Jika sistem beroperasi sesuai rancangan, deteksi otomatis, penskalaan, dan mekanisme pemulihan mandiri seharusnya aktif dan hanya berdampak sedikit atau sama sekali tidak berdampak pada pengguna. Jika tim menemukan dampak negatif, mereka melakukan rollback pengujian dan memperbaiki masalah yang diidentifikasi, baik melalui cara otomatis atau intervensi manual yang didokumentasikan dalam runbook yang berlaku.
Untuk terus meningkatkan ketahanan, penting untuk mendokumentasikan dan menerapkan pelajaran yang dipetik. Proses ini disebut *siklus umpan balik* yang secara sistematis mengumpulkan wawasan dari game day dan menggunakannya untuk meningkatkan sistem, proses, dan kemampuan tim.
Untuk membantu Anda menciptakan skenario tiruan dunia nyata berupa kegagalan komponen atau layanan sistem secara tak terduga, injeksikan kesalahan tersimulasi sebagai latihan game day. Tim dapat menguji ketahanan dan toleransi kesalahan sistem mereka dan menyimulasikan respons insiden serta proses pemulihan mereka di lingkungan terkontrol.
Di AWS, game day Anda dapat dilakukan dengan replika lingkungan produksi Anda menggunakan infrastruktur sebagai kode. Melalui proses ini, Anda dapat menguji di lingkungan yang aman yang sangat mirip dengan lingkungan produksi Anda. Pertimbangkan [AWS Fault Injection Service](https://aws.amazon.com/fis/) untuk membuat beberapa skenario kegagalan yang berbeda. Gunakan layanan seperti [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) dan [AWS X-Ray](https://aws.amazon.com/xray/) untuk memantau perilaku sistem selama game day. Gunakan [AWS Systems Manager](https://aws.amazon.com/systems-manager/) untuk mengelola serta menjalankan playbook, dan gunakan [AWS Step Functions](https://aws.amazon.com/step-functions/) untuk melakukan orkestrasi alur kerja game day berulang.
### Langkah-langkah implementasi
+ **Buat program game day:** Kembangkan program terstruktur yang menentukan frekuensi, ruang lingkup, dan tujuan game day. Libatkan pemangku kepentingan utama dan ahli bidang studi dalam merencanakan dan menjalankan latihan ini.
+ **Siapkan game day:**
1. Identifikasi layanan paling kritis bagi bisnis yang menjadi fokus game day. Buat katalog dan petakan orang, proses, dan teknologi yang mendukung layanan tersebut.
1. Tetapkan agenda untuk game day, dan persiapkan tim yang terlibat untuk berpartisipasi dalam acara tersebut. Siapkan layanan otomatisasi Anda untuk menyimulasikan skenario yang direncanakan dan menjalankan proses pemulihan yang sesuai. Layanan AWS seperti [AWS Fault Injection Service](https://aws.amazon.com/fis/), [AWS Step Functions](https://aws.amazon.com/step-functions/), dan [AWS Systems Manager](https://aws.amazon.com/systems-manager/) dapat membantu Anda mengotomatiskan berbagai aspek game day, seperti injeksi kesalahan dan inisiasi tindakan pemulihan.
+ **Jalankan simulasi Anda:** Pada game day, jalankan skenario yang direncanakan. Amati dan dokumentasikan bagaimana orang, proses, dan teknologi bereaksi terhadap peristiwa simulasi.
+ **Lakukan peninjauan pasca-latihan:** Setelah game day, lakukan sesi retrospektif untuk meninjau pelajaran yang dipetik. Identifikasi area untuk perbaikan dan tindakan apa pun yang diperlukan untuk meningkatkan ketahanan operasional. Dokumentasikan temuan Anda, dan lacak setiap perubahan yang diperlukan untuk meningkatkan strategi ketahanan dan kesiapan Anda untuk menyelesaikannya.
## Sumber daya
**Praktik-praktik terbaik terkait:**
+ [REL12-BP01 Menggunakan playbook untuk menyelidiki kegagalan](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_testing_resiliency_playbook_resiliency.html)
+ [REL12-BP04 Menguji ketahanan menggunakan chaos engineering](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_testing_resiliency_failure_injection_resiliency.html)
+ [OPS04-BP01 Identifikasikan indikator performa utama](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_observability_identify_kpis.html)
+ [OPS07-BP03 Menggunakan runbook untuk menjalankan prosedur](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ready_to_support_use_runbooks.html)
+ [OPS10-BP01 Menggunakan proses untuk manajemen peristiwa, insiden, dan masalah](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_event_response_event_incident_problem_process.html)
**Dokumen terkait:**
+ [Apa itu GameDay AWS?](https://aws.amazon.com/gameday/)
**Video terkait:**
+ [AWS re:Invent 2023 - Berlatihlah seperti bermain: Bagaimana Amazon meningkatkan ketahanan ke tingkat yang lebih tinggi](https://www.youtube.com/watch?v=r3J0fEgNCLQ&t=1734s)
**Contoh terkait:**
+ [AWS Lokakarya - Menghadapi berbagai tantangan: Menerapkan kekacauan terkendali untuk menciptakan sistem yang tangguh](https://catalog.us-east-1.prod.workshops.aws/workshops/eb89c4d5-7c9a-40e0-b0bc-1cde2df1cb97)
+ [Membuat Game Day Anda Sendiri untuk Mendukung Ketahanan Operasional](https://aws.amazon.com/blogs/architecture/build-your-own-game-day-to-support-operational-resilience/)
# REL 13. Bagaimana cara Anda mempersiapkan pemulihan bencana (DR)?
Memiliki cadangan dan komponen beban kerja berlebih adalah permulaan dari strategi DR Anda. [RTO dan RPO adalah sasaran](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/disaster-recovery-dr-objectives.html) pemulihan beban kerja Anda. Tetapkan ini berdasarkan kebutuhan bisnis. Implementasikan sebuah strategi untuk memenuhi tujuan-tujuan ini, sambil mempertimbangkan lokasi dan fungsi data dan sumber daya beban kerja. Probabilitas gangguan dan biaya pemulihan juga merupakan faktor penting yang akan membantu menginformasikan nilai bisnis dari penyediaan pemulihan bencana untuk beban kerja.
**Topics**
+ [REL13-BP01 Menetapkan sasaran pemulihan untuk waktu henti dan kehilangan data](rel_planning_for_recovery_objective_defined_recovery.md)
+ [REL13-BP02 Menggunakan strategi pemulihan untuk memenuhi sasaran pemulihan](rel_planning_for_recovery_disaster_recovery.md)
+ [REL13-BP03 Menguji implementasi pemulihan bencana untuk memvalidasi implementasi](rel_planning_for_recovery_dr_tested.md)
+ [REL13-BP04 Mengelola penyimpangan konfigurasi di lokasi atau Wilayah Pemulihan Bencana (DR)](rel_planning_for_recovery_config_drift.md)
+ [REL13-BP05 Mengotomatiskan pemulihan](rel_planning_for_recovery_auto_recovery.md)
# REL13-BP01 Menetapkan sasaran pemulihan untuk waktu henti dan kehilangan data
Kegagalan dapat merugikan bisnis Anda dalam banyak hal. Pertama, kegagalan dapat menyebabkan gangguan layanan (waktu henti). Kedua, kegagalan dapat menyebabkan data hilang, tidak konsisten, atau usang. Untuk memandu cara Anda merespons dan memulihkan diri dari kegagalan, tentukan Sasaran Waktu Pemulihan (RTO) dan Sasaran Titik Pemulihan (RPO) untuk setiap beban kerja. *Sasaran Waktu Pemulihan (RTO)* adalah jeda waktu maksimum yang dapat diterima antara gangguan layanan dan pemulihan layanan. *Sasaran Titik Pemulihan (RPO)* adalah waktu maksimum yang dapat diterima sejak titik pemulihan data terakhir.
**Hasil yang diinginkan:** Setiap beban kerja memiliki RTO dan RPO yang ditentukan berdasarkan pertimbangan teknis dan dampak bisnis.
**Anti-pola umum:**
+ Anda belum menentukan sasaran pemulihan.
+ Anda memilih sasaran pemulihan tanpa pertimbangan matang.
+ Anda memilih sasaran pemulihan yang terlalu longgar dan tidak memenuhi sasaran bisnis.
+ Anda belum mengevaluasi dampak waktu henti dan kehilangan data.
+ Anda memilih sasaran pemulihan yang tidak realistis, seperti nol waktu pemulihan atau nol kehilangan data, yang mungkin tidak dapat dicapai untuk konfigurasi beban kerja Anda.
+ Anda memilih sasaran pemulihan yang lebih ketat daripada sasaran bisnis yang sesungguhnya. Hal ini memaksakan implementasi pemulihan yang lebih mahal dan lebih rumit dibandingkan yang dibutuhkan beban kerja.
+ Anda memilih sasaran pemulihan yang tidak kompatibel dengan sasaran beban kerja dependen.
+ Anda tidak mempertimbangkan persyaratan peraturan dan kepatuhan.
**Manfaat menjalankan praktik terbaik ini:** Ketika Anda menetapkan RTO dan RPO untuk beban kerja Anda, Anda menetapkan tujuan yang jelas dan terukur untuk pemulihan berdasarkan kebutuhan bisnis Anda. Setelah Anda menetapkan sasaran-sasaran tersebut, Anda dapat membuat rencana pemulihan bencana (DR) yang disesuaikan untuk memenuhinya.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Tinggi
## Panduan implementasi
Buat matriks atau lembar kerja untuk membantu memandu perencanaan pemulihan bencana Anda. Dalam matriks Anda, buat kategori atau tingkatan beban kerja yang berbeda berdasarkan dampak bisnisnya (seperti kritis, tinggi, sedang, dan rendah) serta RTO dan RPO terkait yang ditargetkan untuk setiap kategori. Matriks berikut memberikan contoh (perhatikan bahwa nilai RTO dan RPO Anda mungkin berbeda) yang dapat Anda ikuti:
![\[Bagan yang memperlihatkan matriks pemulihan bencana\]](http://docs.aws.amazon.com/id_id/wellarchitected/latest/framework/images/disaster-recovery-matrix.png)
Untuk setiap beban kerja, selidiki dan pahami dampak waktu henti serta kehilangan data pada bisnis Anda. Dampaknya biasanya meningkat seiring dengan waktu henti dan kehilangan data, tetapi bentuk dampaknya dapat berbeda berdasarkan jenis beban kerja. Misalnya, waktu henti hingga satu jam mungkin berdampak rendah, tetapi setelah itu, dampaknya bisa meningkat dengan cepat. Dampak dapat berupa banyak hal, termasuk dampak keuangan (seperti kehilangan pendapatan), dampak reputasi (termasuk hilangnya kepercayaan pelanggan), dampak operasional (seperti gaji yang terlambat atau penurunan produktivitas), dan risiko peraturan. Jika sudah, tetapkan beban kerja ke tingkatan yang sesuai.
Pertimbangkan pertanyaan-pertanyaan berikut ketika Anda menganalisis dampak kegagalan:
1. Berapa lama waktu maksimum beban kerja bisa tidak tersedia sebelum menimbulkan dampak yang signifikan pada bisnis?
1. Seberapa besar dampak, dan seperti apa bentuknya, yang akan ditimbulkan pada bisnis dari suatu gangguan beban kerja? Pertimbangkan semua jenis dampak, termasuk keuangan, reputasi, operasional, dan peraturan.
1. Berapakah jumlah data maksimum yang dapat hilang atau tidak dapat dipulihkan sebelum menimbulkan dampak yang signifikan pada bisnis?
1. Apakah data yang hilang bisa dibuat lagi dari sumber lain (juga dikenal sebagai data *turunan*)? Jika demikian, pertimbangkan juga RPO dari semua data sumber yang digunakan untuk membuat ulang data beban kerja.
1. Apa saja sasaran pemulihan dan ekspektasi ketersediaan beban kerja yang bergantung pada sasaran pemulihan ini (hilir)? Sasaran beban kerja Anda harus dapat dicapai mengingat kemampuan pemulihan dependensi hilirnya. Pertimbangkan kemungkinan solusi alternatif atau mitigasi untuk dependensi hilir yang dapat meningkatkan kemampuan pemulihan beban kerja ini.
1. Apa saja sasaran pemulihan dan ekspektasi ketersediaan beban kerja yang bergantung pada sasaran pemulihan ini (hulu)? Sasaran beban kerja hulu mungkin mengharuskan beban kerja ini memiliki kemampuan pemulihan yang lebih ketat daripada yang terlihat pada awalnya.
1. Apakah ada sasaran pemulihan yang berbeda berdasarkan jenis insiden? Misalnya, Anda mungkin memiliki RTO dan RPO yang berbeda, bergantung pada apakah insiden tersebut memengaruhi suatu Zona Ketersediaan atau seluruh Wilayah.
1. Apakah sasaran pemulihan Anda berubah selama peristiwa atau waktu tertentu dalam setahun? Misalnya, Anda mungkin memiliki RTO dan RPO yang berbeda di sekitar musim belanja liburan, acara olahraga, obral khusus, dan peluncuran produk baru.
1. Bagaimana sasaran pemulihan selaras dengan strategi pemulihan bencana lini bisnis dan organisasi yang mungkin Anda miliki?
1. Apakah ada konsekuensi hukum atau kontrak yang perlu dipertimbangkan? Misalnya, apakah Anda secara kontraktual berkewajiban untuk menyediakan layanan dengan RTO atau RPO tertentu? Konsekuensi apa yang mungkin Anda terima jika tidak memenuhi kewajiban tersebut?
1. Apakah Anda diwajibkan untuk menjaga integritas data untuk memenuhi persyaratan peraturan atau kepatuhan?
Lembar kerja berikut dapat membantu evaluasi Anda untuk setiap beban kerja. Anda dapat mengubah lembar kerja ini sesuai kebutuhan spesifik Anda, seperti memasukkan pertanyaan tambahan.
![\[Lembar kerja\]](http://docs.aws.amazon.com/id_id/wellarchitected/latest/framework/images/worksheet.png)
### Langkah-langkah implementasi
1. Identifikasi pemangku kepentingan bisnis dan tim teknis yang bertanggung jawab atas setiap beban kerja, dan libatkan mereka.
1. Buat kategori atau tingkat kekritisan untuk dampak beban kerja di organisasi Anda. Contoh kategori meliputi kritis, tinggi, sedang, dan rendah. Untuk setiap kategori, pilih RTO dan RPO yang mencerminkan tujuan serta persyaratan bisnis Anda.
1. Tetapkan salah satu kategori dampak yang Anda buat di langkah sebelumnya ke setiap beban kerja. Untuk memutuskan bagaimana suatu beban kerja dipetakan ke suatu kategori, pertimbangkan pentingnya beban kerja bagi bisnis serta dampak gangguan atau kehilangan data, lalu gunakan pertanyaan di atas untuk memandu Anda. Hal ini menghasilkan RTO dan RPO untuk setiap beban kerja.
1. Pertimbangkan RTO dan RPO untuk setiap beban kerja yang ditentukan pada langkah sebelumnya. Libatkan tim bisnis dan teknis beban kerja untuk menentukan apakah sasaran harus disesuaikan. Misalnya, pemangku kepentingan bisnis dapat menentukan bahwa target yang lebih ketat diperlukan. Atau, tim teknis dapat menentukan bahwa target harus dimodifikasi untuk membuatnya dapat dicapai dengan sumber daya yang tersedia dan keterbatasan teknologi.
## Sumber daya
**Praktik-praktik terbaik terkait:**
+ [REL09-BP04 Melakukan pemulihan data secara berkala untuk memverifikasi integritas dan proses pencadangan](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_backing_up_data_periodic_recovery_testing_data.html)
+ [REL12-BP01 Menggunakan playbook untuk menyelidiki kegagalan](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_testing_resiliency_playbook_resiliency.html)
+ [REL13-BP02 Menggunakan strategi pemulihan untuk memenuhi sasaran pemulihan](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_disaster_recovery.html)
+ [REL13-BP03 Menguji implementasi pemulihan bencana untuk memvalidasi implementasi](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_dr_tested.html)
**Dokumen terkait:**
+ [AWS Blog Arsitektur : Seri Pemulihan Bencana](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [Pemulihan Bencana Beban Kerja di AWS: Pemulihan di Cloud (Laporan Resmi AWS)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [Mengelola kebijakan ketangguhan dengan AWS Resilience Hub](https://docs.aws.amazon.com/resilience-hub/latest/userguide/resiliency-policies.html)
+ [Partner APN: partner yang dapat membantu Anda melakukan pemulihan bencana](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [AWS Marketplace: produk yang dapat digunakan untuk pemulihan bencana](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
**Video terkait:**
+ [AWS re:Invent 2018: Pola Arsitektur untuk Aplikasi Aktif-Aktif Multi-Wilayah](https://youtu.be/2e29I3dA8o4)
+ [Pemulihan Bencana Beban Kerja di AWS](https://www.youtube.com/watch?v=cJZw5mrxryA)
# REL13-BP02 Menggunakan strategi pemulihan untuk memenuhi sasaran pemulihan
Tentukan strategi pemulihan bencana (DR) yang memenuhi sasaran pemulihan beban kerja. Pilih strategi seperti pencadangan dan pemulihan, standby (aktif/pasif), atau aktif/aktif.
**Hasil yang diinginkan:** Strategi DR ditentukan dan diimplementasikan untuk setiap beban kerja agar beban kerja dapat mencapai sasaran DR. Strategi DR antara beban kerja menggunakan pola yang dapat digunakan kembali (seperti strategi yang telah dijelaskan sebelumnya),
**Anti-pola umum:**
+ Mengimplementasikan prosedur pemulihan yang tidak konsisten untuk beban kerja dengan sasaran DR yang serupa.
+ Membiarkan strategi DR diimplementasikan secara ad-hoc saat bencana terjadi.
+ Tidak memiliki rencana untuk pemulihan bencana.
+ Dependensi pada operasi bidang kontrol selama pemulihan.
**Manfaat menjalankan praktik terbaik ini:**
+ Dengan strategi pemulihan yang ditentukan, Anda dapat menggunakan prosedur tes dan peralatan umum.
+ Menggunakan strategi pemulihan yang ditentukan akan meningkatkan penyebaran pengetahuan antara tim dan implementasi DR pada beban kerja milik mereka.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Tinggi. Tanpa strategi DR yang direncanakan, diimplementasikan, dan diuji, Anda akan kesulitan mencapai sasaran pemulihan ketika bencana terjadi.
## Panduan implementasi
Strategi DR mengandalkan kemampuan untuk mempertahankan beban kerja di situs pemulihan jika lokasi utama tidak dapat menjalankan beban kerja. Sasaran pemulihan yang paling umum adalah RTO dan RPO, seperti yang didiskusikan dalam [REL13-BP01 Menetapkan sasaran pemulihan untuk waktu henti dan kehilangan data](rel_planning_for_recovery_objective_defined_recovery.md).
Strategi DR di beberapa Zona Ketersediaan (AZ) dalam Wilayah AWS tunggal, dapat menyediakan mitigasi bencana seperti kebakaran, banjir, dan pemadaman listrik besar-besaran. Anda dapat menggunakan strategi DR yang menggunakan beberapa Wilayah jika memang perlu mengimplementasikan perlindungan terhadap peristiwa yang membuat beban kerja tidak dapat dijalankan di Wilayah AWS.
Anda harus memilih salah satu dari strategi berikut saat merancang strategi DR di beberapa Wilayah. Mereka terdaftar dalam urutan peningkatan biaya dan kompleksitas, dan penurunan urutan RTO dan RPO. *Wilayah Pemulihan* mengacu pada Wilayah AWS selain dari yang utama yang digunakan untuk beban kerja Anda.
![\[Diagram menampilkan strategi DR\]](http://docs.aws.amazon.com/id_id/wellarchitected/latest/framework/images/disaster-recovery-strategies.png)
+ **Cadangkan dan pulihkan** (RPO dalam hitungan jam, RTO dalam 24 jam atau kurang): Cadangkan data dan aplikasi Anda ke dalam Wilayah pemulihan. Menggunakan pencadangan otomatis atau berkelanjutan dapat mengaktifkan pemulihan titik waktu (PITR), yang dalam beberapa kasus dapat menurunkan RPO hingga 5 menit dalam beberapa kasus. Saat terjadi bencana, Anda akan melakukan deployment infrastruktur (menggunakan infrastruktur sebagai kode untuk mengurangi RTO), melakukan deploymennt kode, dan memulihkan data yang dicadangkan untuk memulihkan dari bencana di Wilayah pemulihan.
+ **Pilot light** (RPO dalam menit, RTO dalam kelipatan sepuluh menit): Sediakan salinan infrastruktur beban kerja inti di Wilayah pemulihan. Replikasikan data ke Wilayah pemulihan dan buat cadangan di sana. Sumber daya yang diperlukan untuk mendukung replikasi dan pencadangan data, misalnya basis data dan penyimpanan objek, selalu aktif. Elemen lainnya seperti server aplikasi atau komputasi nirserver tidak di-deploy, tetapi dapat dibuat saat dibutuhkan dengan kode aplikasi dan konfigurasi yang diperlukan.
+ **Warm standby** (RPO dalam hitungan detik, RTO dalam hitungan menit): Mengaktifkan versi yang diturunkan tetapi berfungsi sepenuhnya dari beban kerja yang selalu dijalankan di Wilayah pemulihan. Sistem yang vital untuk bisnis sepenuhnya digandakan dan selalu aktif, tetapi dengan armada yang diturunkan skalanya. Data direplikasi dan berada dalam Wilayah pemulihan. Ketika pemulihan diperlukan, sistem dinaikkan skalanya dengan cepat untuk menangani beban produksi. Semakin warm standby dinaikkan skalanya, akan semakin rendah pengandalan RTO dan bidang kontrol. Saat skala sesuai sepenuhnya, ini disebut sebagai *hot standby*.
+ **Multi-Wulayah (multi-lokasi) aktif-aktif** (RPO mendekati nol, RTO berpotensi nol): Beban kerja Anda di-deploy ke, dan aktif menangani lalu lintas dari, beberapa Wilayah AWS. Strategi ini perlu menyinkronkan data di seluruh Wilayah. Konflik potensial yang disebabkan oleh menulis catatan yang sama di dua replika wilayah yang berbeda harus dihindari atau ditangani, karena bisa menjadi kompleks. Replikasi data bermanfaat untuk sinkronisasi data dan akan melindungi Anda terhadap beberapa jenis bencana, tetapi tidak melindungi terhadap kerusakan atau kehilangan data kecuali solusi juga disertai opsi untuk pemulihan titik waktu.
**catatan**
Perbedaan antara pilot light dan warm standby terkadang sulit dimengerti. Keduanya menyertakan lingkungan di Wilayah pemulihan dengan salinan aset wilayah utama. Perbedaannya adalah pilot light tidak dapat memproses permintaan tanpa lebih dulu melakukan tindakan tambahan, sedangkan warm standby dapat menangani lalu lintas (pada kapasitas yang dikurangi) dengan cepat. Pilot light mengharuskan Anda mengaktifkan server, menaikkan skala, dan mungkin mengharuskan Anda melakukan deployment infrastruktur tambahan (bukan inti). Sementara itu, warm standby hanya meminta Anda untuk menaikkan skala (semuanya sudah di-deploy dan dijalankan). Pilih berdasarkan kebutuhan RTO dan RPO Anda.
Apabila ada kekhawatiran tentang biaya, dan Anda ingin mencapai sasaran RPO dan RTO yang serupa dengan yang ditetapkan dalam strategi warm standby, Anda dapat mempertimbangkan solusi cloud-native, seperti AWS Elastic Disaster Recovery, yang akan mengambil pendekatan pilot light dan menawarkan target RPO dan RTO lebih baik.
**Langkah-langkah implementasi**
1. **Tentukan strategi DR yang akan memenuhi persyaratan pemulihan untuk beban kerja ini.**
Saat memilih strategi DR, Anda harus memilih antara mengurangi waktu henti dan kehilangan data (RTO dan RPO) dan meningkatkan biaya dan kompleksitas untuk mengimplementasikan strategi, atau sebaliknya. Sebaiknya hindari strategi yang lebih sulit dari yang dibutuhkan, karena hal ini akan menambah biaya yang tidak perlu.
Misalnya, dalam diagram berikut, bisnis telah menentukan RTO maksimum yang diizinkan serta batas yang dapat digunakan pada strategi pemulihan layanan. Berdasarkan sasaran bisnis, strategi DR pilot light atau warm standby akan memenuhi kriteria biaya dan RTO.
![\[Grafik yang menampilkan pemilihan strategi DR berdasarkan RTO dan biaya\]](http://docs.aws.amazon.com/id_id/wellarchitected/latest/framework/images/choosing-a-dr-strategy.png)
Untuk mempelajari lebih lanjut, lihat [Business Continuity Plan (BCP](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/business-continuity-plan-bcp.html)).
1. **Tinjau pola tentang bagaimana strategi DR yang dipilih dapat diimplementasikan.**
Langkah ini digunakan untuk memahami cara Anda mengimplementasikan strategi yang dipilih. Strategi dijelaskan menggunakan Wilayah AWS sebagai situs utama dan pemulihan. Namun, Anda juga dapat memilih untuk menggunakan Zona Ketersediaan dalam Wilayah tunggal sebagai strategi DR, yang menggunakan beberapa elemen dari berbagai strategi tersebut.
Dalam langkah berikut ini, Anda dapat menerapkan strategi pada beban kerja spesifik Anda.
**Pencadangan dan pemulihan**
*Cadangkan dan pulihkan* adalah strategi yang tidak terlalu kompleks untuk diimplementasikan, tetapi akan memerlukan waktu dan usaha lebih untuk mengembalikan beban kerja, sehingga RTO dan RPO menjadi lebih tinggi. Sebaiknya selalu buat cadangan data, dan salin cadangan tersebut ke situs lain (misalnya Wilayah AWS lain).
![\[Diagram menampilkan arsitektur cadangan dan pemulihan\]](http://docs.aws.amazon.com/id_id/wellarchitected/latest/framework/images/backup-restore-architecture.png)
Untuk rincial lebih lanjut pada strategi ini lihat [Arsitektur Pemulihan Bencana (DR) di AWS, Bagian II: Pencadangan dan Pemulihan dengan Pemulihan Cepat](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-ii-backup-and-restore-with-rapid-recovery/).
**Pilot light**
Dengan pendekatan *pilot light*, Anda mereplikasi data dari Wilayah utama ke Wilayah pemulihan. Sumber daya inti yang digunakan untuk infrastruktur beban kerja di-deploy di Wilayah pemulihan. Namun, sumber daya tambahan dan dependensi lainnya masih diperlukan untuk membuat tumpukan fungsional ini. Misalnya, dalam gambar 20, tidak ada instans komputasi yang di-deploy.
![\[Diagram menampilkan arsitektur pilot light\]](http://docs.aws.amazon.com/id_id/wellarchitected/latest/framework/images/pilot-light-architecture.png)
Untuk detail lebih lanjut tentang strategi ini, lihat [Arsitektur Pemulihan Bencana (DR) di AWS, Bagian III: Pilot Light and Warm Standby](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/).
**Warm standby**
Pendekatan *warm standby* melibatkan memastikan ada salinan lingkungan produksi yang skalanya diturunkan tetapi berfungsi sepenuhnya di Wilayah lainnya. Pendekatan ini memperpanjang konsep pilot light dan mempercepat waktu pemulihan karena beban kerja selalu aktif di Wilayah lainnya. Jika Wilayah pemulihan di-deploy pada kapasitas penuh, hal ini disebut dengan *hot standby*.
![\[Diagram menampilkan Gambar 21: Arsitektur warm standby\]](http://docs.aws.amazon.com/id_id/wellarchitected/latest/framework/images/warm-standby-architecture.png)
Saat menggunakan warm standby atau pilot light, Anda perlu menaikkan skala sumber daya di Wilayah pemulihan. Untuk memverifikasi kapasitas yang tersedia bila diperlukan, pertimbangkan penggunaan untuk [reservasi kapasitas](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-reservations.html) untuk instans EC2. Jika menggunakan AWS Lambda, [konkurensi yang disediakan](https://docs.aws.amazon.com/lambda/latest/dg/provisioned-concurrency.html) dapat menyediakan lingkungan runtime sehingga siap untuk segera merespons invokasi fungsi Anda.
Untuk detail lebih lanjut tentang strategi ini, lihat [Arsitektur Pemulihan Bencana (DR) di AWS, Bagian III: Pilot Light and Warm Standby](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/).
**Multi-situs aktif/aktif**
Anda dapat menjalankan beban kerja secara berkelanjutan di beberapa Wilayah sebagai bagian dari strategi *multi-situs aktif/aktif*. Multi-situs aktif/aktif menjalankan lalu lintas dari semua wilayah ke wilayah tempatnya di-deploy. Konsumen dapat memilih strategi ini untuk alasan selain dari DR. Strategi ini dapat digunakan untuk meningkatkan ketersediaan, atau saat melakukan deployment beban kerja ke audiens global (untuk menempatkan titik akhir lebih dekat dengan pengguna dan/atau melakukan deployment tumpukan yang dilokalkan untuk audiens di wilayah tersebut). Sebagai strategi DR, jika beban kerja tidak dapat didukung di salah satu dari Wilayah AWS tempatnya di-deploy, Wilayah tersebut dievakuasi, dan Wilayah sisanya digunakan untuk mempertahankan ketersediaan. Multi-situs aktif/aktif adalah strategi DR yang paling sulit dioperasikan, dan sebaiknya hanya dipilih saat persyaratan bisnis mengharuskannya.
![\[Diagram menampilkan arsitektur multi-situs aktif/aktif\]](http://docs.aws.amazon.com/id_id/wellarchitected/latest/framework/images/multi-site-active-active-architecture.png)
Untuk detail lebih lanjut tentang strategi ini, lihat [Arsitektur Pemulihan Bencana (DR) di AWS, Bagian IV: Multi-situs Aktif/Aktif](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iv-multi-site-active-active/).
**AWS Elastic Disaster Recovery**
Jika Anda mempertimbangkan lampu pilot atau strategi siaga hangat untuk pemulihan bencana, AWS Elastic Disaster Recovery dapat memberikan pendekatan alternatif dengan manfaat yang lebih baik. Elastic Disaster Recovery dapat menawarkan target RPO dan RTO yang mirip dengan siaga hangat, tetapi mempertahankan pendekatan lampu pilot berbiaya rendah. Elastic Disaster Recovery mereplikasi data Anda dari wilayah utama Anda ke Wilayah pemulihan Anda, menggunakan perlindungan data berkelanjutan untuk mencapai RPO yang diukur dalam hitungan detik dan RTO yang dapat diukur dalam hitungan menit. Hanya sumber daya yang diperlukan untuk mereplikasi data yang di-deploy di wilayah pemulihan, sehingga menekan biaya tetap rendah, serupa dengan strategi pilot light. Ketika menggunakan Elastic Disaster Recovery, layanan mengoordinasi dan mengatur pemulihan sumber daya komputasi ketika dimulai sebagai bagian dari failover atau latihan.
![\[Diagram arsitektur yang menjelaskan cara AWS Elastic Disaster Recovery beroperasi.\]](http://docs.aws.amazon.com/id_id/wellarchitected/latest/framework/images/drs-architecture.png)
**Praktik tambahan untuk melindungi data**
Dengan semua strategi, Anda juga harus melakukan mitigasi terhadap bencana data. Replikasi data berkelanjutan melindungi Anda terhadap beberapa jenis bencana, tetapi tidak melindungi terhadap kerusakan atau kehilangan data kecuali strategi juga disertai penentuan versi data yang disimpan atau opsi pemulihan titik waktu. Selain replika, Anda juga harus mencadangkan data yang direplikasi di situs pemulihan untuk membuat pencadangan titik waktu.
**Menggunakan beberapa Zona Ketersediaan (AZ) dalam Wilayah AWS tunggal**
Saat menggunakan beberapa AZ dalam Wilayah tunggal, implementasi DR Anda menggunakan beberapa elemen dari strategi di atas. Anda harus terlebih dahulu membuat arsitektur ketersediaan tinggi (HA) menggunakan beberapa AZ yang ditampilkan dalam Gambar 23. Arsitektur ini menggunakan pendekatan aktif/aktif multi-situs, karena [instans Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html#concepts-availability-zones) dan [Penyeimbang Beban Elastis](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html#availability-zones) memiliki sumber daya yang digunakan di beberapa AZ yang secara aktif memberikan permintaan. Arsitektur juga menunjukkan hot standby, di mana jika instans [Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html) utama gagal (atau AZ itu sendiri gagal), maka instans siaga dipromosikan ke primer.
![\[Diagram menampilkan Gambar 24: Arsitektur Multi-AZ\]](http://docs.aws.amazon.com/id_id/wellarchitected/latest/framework/images/multi-az-architecture2.png)
Selain arsitektur HA ini, Anda perlu menambahkan cadangan data yang dibutuhkan untuk menjalankan beban kerja. Ini sangat penting untuk data yang dibatasi pada satu zona seperti [volume Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volumes.html) atau [cluster Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html). Jika sebuah AZ gagal, Anda perlu memulihkan data ini ke AZ lainnya. Jika memungkinkan, Anda perlu menyalin cadangan data ke Wilayah AWS sebagai lapisan perlindungan tambahan.
Pendekatan alternatif yang kurang umum untuk DR Wilayah tunggal dan Multi-AZ diilustrasikan dalam postingan blog, [Membangun aplikasi yang sangat tangguh 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/). Strategi yang digunakan di sini adalah mempertahankan isolasi sebanyak mungkin di antara AZ, seperti bagaimana Wilayah dioperasikan. Dengan menggunakan strategi alternatif ini, Anda dapat memilih pendekatan aktif/aktif atau aktif/pasif.
**catatan**
Beberapa beban kerja memiliki persyaratan residensi data peraturan. Jika ini diterapkan untuk beban kerja di lokalitas yang saat ini hanya memiliki satu Wilayah AWS, maka multi-Wilayah tidak akan sesuai untuk kebutuhan bisnis. Strategi multi-AZ memberikan perlindungan yang baik terhadap sebagian besar bencana.
1. **Evaluasikan sumber daya beban kerja, dan seperti apa konfigurasinya di Wilayah pemulihan sebelum failover (selama operasi normal).**
Untuk infrastruktur dan sumber daya AWS, gunakan infrastruktur sebagai kode seperti [AWS CloudFormation](https://aws.amazon.com/cloudformation) atau alat pihak ketiga seperti Hashicorp Terraform. Untuk melakukan deployment di beberapa akun dan Wilayah dengan operasi tunggal, Anda dapat menggunakan [AWS CloudFormation StackSets](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html). Untuk strategi Multi-situs aktif/aktif dan Hot Standby, infrastruktur yang di-deploy di Wilayah pemulihan memiliki sumber daya yang sama seperti Wilayah utama. Untuk strategi Pilot Light dan Warm Standby, infrastruktur yang di-deploy memerlukan tindakan tambahan agar berubah menjadi siap produksi. Dengan menggunakan [parameter](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/parameters-section-structure.html) dan [logika bersyarat](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-conditions.html) CloudFormation, Anda dapat mengontrol apakah tumpukan yang diterapkan aktif atau siaga dengan [satu templat](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/). Ketika menggunakan Elastic Disaster Recovery, layanan akan mereplikasi dan mengatur pemulihan konfigurasi aplikasi dan sumber daya komputasi.
Semua strategi DR mengharuskan sumber data dicadangkan di dalam Wilayah AWS, dan kemudian cadangan tersebut disalin ke Wilayah pemulihan. [AWS Backup](https://aws.amazon.com/backup/) akan menyediakan tampilan tersentralisasi di mana Anda dapat mengonfigurasi, menjadwalkan, dan memantau cadangan untuk sumber daya ini. Untuk Pilot Light, Warm Standby, dan Multi-situs aktif/aktif, Anda juga harus mereplikasi data dari Wilayah utama ke sumber daya data di Wilayah pemulihan, seperti instans DB [Amazon Relational Database Service (Amazon RDS)](https://aws.amazon.com/rds) atau tabel [Amazon DynamoDB](https://aws.amazon.com/dynamodb). Dengan demikian, sumber data ini aktif dan siap menangani permintaan di Wilayah pemulihan.
Untuk mempelajari lebih lanjut tentang cara layanan-layanan AWS beroperasi di seluruh Wilayah, lihat seri blog ini tentang [Membuat Aplikasi Multi-Wilayah dengan Layanan AWS](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/).
1. **Tentukan dan implementasikan cara Anda mempersiapkan Wilayah untuk failover saat dibutuhkan (selama peristiwa bencana).**
Untuk multi-situs aktif/aktif, failover berarti mengevakuasi Wilayah dan mengandalkan Wilayah aktif yang tersisa. Secara umum, Wilayah tersebut siap menerima lalu lintas. Untuk strategi Pilot Light dan Warm Standby, tindakan pemulihan perlu mencakup deployment sumber daya yang hilang, seperti instans EC2 dalam Gambar 20, juga sumber daya yang hilang lainnya.
Untuk semua strategi di atas, Anda mungkin perlu mengubah instans hanya-baca basis data menjadi instans baca/tulis.
Untuk pencadangan dan pemulihan, pemulihan data dari cadangan menghasilkan sumber daya untuk data tersebut seperti volume EBS, instans RDS DB, dan tabel DynamoDB. Anda juga perlu memulihkan infrastruktur dan melakukan deployment kode. Anda dapat menggunakan AWS Backup untuk memulihkan data di Wilayah pemulihan. Lihat [REL09-BP01 Mengidentifikasi dan mencadangkan data yang perlu dicadangkan, atau melakukan reproduksi ulang data dari sumber](rel_backing_up_data_identified_backups_data.md) untuk detail selengkapnya. Membangun kembali infrastruktur termasuk membuat sumber daya seperti instans EC2 selain [Amazon Virtual Private Cloud (Amazon VPC)](https://aws.amazon.com/vpc), subnet, dan grup keamanan yang diperlukan. Anda dapat mengotomatiskan banyak proses pemulihan. Untuk mempelajari caranya, silakan lihat [posting blog ini](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-ii-backup-and-restore-with-rapid-recovery/).
1. **Tentukan dan implementasikan cara Anda akan merutekan kembali lalu lintas ke failover saat dibutuhkan (selama peristiwa bencana).**
Operasi failover ini dapat dimulai secara otomatis dan manual. Failover yang dimulai secara otomatis berdasarkan pemeriksaan kondisi atau alarm harus digunakan dengan hati-hati karena failover yang tidak perlu (alarm palsu) dapat dikenakan biaya seperti ketidaktersediaan dan kehilangan data. Oleh karena itu, Failover yang dimulai secara manual sering digunakan. Dalam kasus ini, Anda masih harus mengotomatiskan langkah failover, sehingga inisiasi manual akan seperti menekan tombol.
Ada beberapa opsi manajemen lalu lintas yang perlu dipertimbangkan saat menggunakan layanan AWS. Salah satu opsinya adalah menggunakan [Amazon Route 53](https://aws.amazon.com/route53). Dengan menggunakan Amazon Route 53, Anda dapat mengaitkan beberapa titik akhir IP di satu Wilayah AWS atau lebih dengan nama domain Route 53. Untuk mengimplementasikan failover yang dimulai secara manual, Anda dapat menggunakan [Pengontrol Pemulihan Aplikasi Amazon](https://aws.amazon.com/application-recovery-controller/), yang menyediakan API bidang data dengan ketersediaan yang tinggi untuk mengalihkan lalu lintas ke Wilayah pemulihan. Saat mengimplementasikan failover, gunakan operasi bidang data dan hindari bidang kontrol yang dideskripsikan di [REL11-BP04 Mengandalkan bidang data dan bukan bidang kontrol selama pemulihan](rel_withstand_component_failures_avoid_control_plane.md).
Untuk mempelajari lebih lanjut tentang ini dan opsi lainnya, lihat [bagian ini dari Laporan Resmi Pemulihan Bencana.](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html#pilot-light)
1. **Rancang rencana terkait bagaimana beban kerja akan failback.**
Failback adalah saat Anda mengembalikan operasi beban kerja ke Wilayah utama, setelah bencana berakhir. Penyediaan infrastruktur dan kode untuk Wilayah utama umumnya mengikuti langkah yang sama yang digunakan saat memulai, dengan mengandalkan infrastruktur sebagai kode dan pipeline deployment kode. Tantangan failback adalah mengembalikan penyimpanan data, dan memastikan konsistensi dengan Wilayah pemulihan dalam operasi.
Dalam status failed over, basis data dalam Wilayah pemulihan bersifat waktu nyata dan memiliki data terbaru. Tujuannya adalah untuk menyinkronkan kembali dari Wilayah pemulihan ke Wilayah utama, memastikannya tetap terbaru.
Hal ini dilakukan secara otomatis untuk beberapa layanan AWS. Jika menggunakan [tabel global Amazon DynamoDB](https://aws.amazon.com/dynamodb/global-tables/), meskipun tabel di Wilayah utama menjadi tidak tersedia, saat kembali online, DynamoDB akan melanjutkan penulisan yang tertunda. Jika menggunakan [Basis Data Global Amazon Aurora](https://aws.amazon.com/rds/aurora/global-database/) dan menggunakan [failover terencana dan terkelola](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-disaster-recovery.html#aurora-global-database-disaster-recovery.managed-failover), topologi replikasi Aurora basis data global yang ada dipertahankan. Dengan demikian, instans baca/tulis sebelumnya di Wilayah utama akan menjadi replika dan menerima pembaruan dari Wilayah pemulihan.
Dalam kasus saat ini tidak dibuat otomatis, Anda perlu menetapkan ulang basis data di Wilayah utama sebagai replika dari basis data di Wilayah pemulihan. Dalam banyak kasus, ini akan melibatkan penghapusan basis data utama yang lama dan membuat replika yang baru.
Setelah failover, jika Anda dapat tetap menjalankannya di Wilayah pemulihan, pertimbangkan membuat ini menjadi Wilayah utama yang baru. Anda masih harus melakukan semua langkah di atas untuk membuat Wilayah utama sebelumnya menjadi Wilayah pemulihan. Beberapa organisasi melakukan rotasi terjadwal, menukar Wilayah utama dan pemulihan secara berkala (misalnya setiap tiga bulan).
Semua langkah yang diperlukan untuk failover dan failback harus diperiksa di playbook yang tersedia untuk semua anggota tim dan ditinjau secara berkala.
Ketika menggunakan Elastic Disaster Recovery, layanan akan membantu mengatur dan mengotomatiskan proses failback. Untuk detail selengkapnya, lihat [Melakukan failback](https://docs.aws.amazon.com/drs/latest/userguide/failback-performing-main.html).
**Tingkat upaya untuk Rencana Implementasi:** Tinggi
## Sumber daya
**Praktik-praktik terbaik terkait:**
+ [REL09-BP01 Mengidentifikasi dan mencadangkan data yang perlu dicadangkan, atau melakukan reproduksi ulang data dari sumber](rel_backing_up_data_identified_backups_data.md)
+ [REL11-BP04 Mengandalkan bidang data dan bukan bidang kontrol selama pemulihan](rel_withstand_component_failures_avoid_control_plane.md)
+ [REL13-BP01 Menetapkan sasaran pemulihan untuk waktu henti dan kehilangan data](rel_planning_for_recovery_objective_defined_recovery.md)
**Dokumen terkait:**
+ [Blog Arsitektur AWS: Seri Pemulihan Bencana](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [Pemulihan Bencana Beban Kerja di AWS: Pemulihan di Cloud (Laporan Resmi AWS)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [Opsi pemulihan bencana di cloud](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html)
+ [Bangun solusi backend aktif-aktif nirserver multi-wilayah dalam satu jam](https://read.acloud.guru/building-a-serverless-multi-region-active-active-backend-36f28bed4ecf)
+ [Backend nirserver multi-wilayah — dimuat ulang](https://medium.com/@adhorn/multi-region-serverless-backend-reloaded-1b887bc615c0)
+ [RDS: Mereplikasi Replika Baca di Seluruh Wilayah](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html#USER_ReadRepl.XRgn)
+ [Route 53: Mengonfigurasi failover DNS](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover-configuring.html)
+ [S3: Replika Lintas-Wilayah](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr.html)
+ [Apa itu AWS Backup?](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html)
+ [Apa itu Pengontrol Pemulihan Aplikasi Amazon?](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
+ [AWS Elastic Disaster Recovery](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)
+ [HashiCorp Terraform: Memulai - AWS](https://learn.hashicorp.com/collections/terraform/aws-get-started)
+ [Partner APN: partner yang dapat membantu Anda mengatasi pemulihan bencana](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [AWS Marketplace: produk yang dapat digunakan untuk pemulihan bencana](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
**Video terkait:**
+ [Pemulihan Bencana Beban Kerja di AWS](https://www.youtube.com/watch?v=cJZw5mrxryA)
+ [AWS re:Invent 2018: Pola Arsitektur untuk Aplikasi Aktif-Aktif Multi-Wilayah (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [Memulai AWS Elastic Disaster Recovery \$1 Amazon Web Services](https://www.youtube.com/watch?v=GAMUCIJR5as)
# REL13-BP03 Menguji implementasi pemulihan bencana untuk memvalidasi implementasi
Secara rutin uji failover ke situs pemulihan Anda untuk memastikan operasi yang baik dan RTO serta RPO terpenuhi.
**Anti-pola umum:**
+ Tidak pernah melakukan failover di lingkungan produksi.
**Manfaat menerapkan praktik terbaik ini:** Pengujian rencana pemulihan bencana secara rutin akan memverifikasi bahwa rencana tersebut akan berfungsi saat diperlukan, dan tim Anda tahu cara mengeksekusi strategi.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Tinggi
## Panduan implementasi
Pola untuk dihindari adalah mengembangkan jalur pemulihan yang sangat jarang dilakukan. Misalnya, Anda mungkin memiliki penyimpanan data sekunder yang digunakan untuk kueri hanya-baca. Saat Anda menulis ke penyimpanan data dan penyimpanan primer gagal, Anda mungkin ingin melakukan failover ke penyimpanan data sekunder. Jika Anda tidak sering menguji failover ini, Anda mungkin akan mendapati bahwa asumsi Anda tentang kemampuan penyimpanan data sekunder ternyata salah. Kapasitas sekunder, yang selama ini mungkin mencukupi saat terakhir Anda uji, mungkin sudah tidak mampu mentoleransi beban di bawah skenario ini. Pengalaman kami menunjukkan bahwa satu-satunya pemulihan kesalahan yang dapat diterapkan adalah jalur yang sering Anda uji. Inilah alasan memiliki sedikit jalur pemulihan adalah yang terbaik. Anda dapat membuat pola pemulihan dan mengujinya secara rutin. Jika Anda memiliki jalur pemulihan yang kompleks atau kritis, Anda tetap perlu secara rutin melatih kegagalan tersebut dalam lingkungan produksi agar Anda yakin bahwa jalur pemulihan tersebut berfungsi. Pada contoh yang baru saja kita bahas, Anda harus melakukan failover ke penyimpanan siaga secara rutin, terlepas ada tidaknya kebutuhan.
**Langkah-langkah implementasi**
1. Rekayasa beban kerja Anda untuk pemulihan. Uji jalur pemulihan Anda secara rutin. Komputasi yang berorientasi pada pemulihan mengidentifikasi karakteristik dalam sistem yang meningkatkan pemulihan: isolasi dan redundansi, kemampuan di seluruh sistem untuk membatalkan perubahan, kemampuan untuk memantau dan menentukan kondisi, kemampuan untuk menyediakan diagnostik, pemulihan otomatis, desain modular, dan kemampuan untuk memulai ulang. Latih jalur pemulihan untuk memverifikasi bahwa Anda dapat menyelesaikan pemulihan dalam waktu yang ditentukan ke status yang ditentukan. Gunakan runbook selama pemulihan ini untuk mendokumentasikan masalah dan menemukan solusinya sebelum pengujian berikutnya.
1. Untuk beban kerja berbasis Amazon EC2, gunakan [AWS Elastic Disaster Recovery](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html) untuk menerapkan dan meluncurkan instans latihan untuk strategi DR Anda. AWS Elastic Disaster Recovery menyediakan kemampuan untuk menjalankan latihan secara efisien, yang akan membantu Anda mempersiapkan peristiwa failover. Anda juga dapat sering-sering meluncurkan instans menggunakan Pemulihan Bencana Elastis untuk tujuan pengujian dan latihan tanpa mengarahkan ulang lalu lintas.
## Sumber daya
**Dokumen terkait:**
+ [Partner APN: partner yang dapat membantu Anda mengatasi pemulihan bencana](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [AWS Blog Arsitektur : Seri Pemulihan Bencana](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [AWS Marketplace: produk yang dapat digunakan untuk pemulihan bencana](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
+ [AWS Elastic Disaster Recovery](https://aws.amazon.com/disaster-recovery/)
+ [Pemulihan Bencana Beban Kerja di AWS: Pemulihan di Cloud (Laporan Resmi AWS)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [AWS Elastic Disaster Recovery Mempersiapkan Failover](https://docs.aws.amazon.com/drs/latest/userguide/failback-preparing.html)
+ [Proyek komputasi Berkeley/Stanford berorientasi pemulihan](http://roc.cs.berkeley.edu/)
+ [Apa itu Simulator Injeksi Kesalahan AWS?](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html)
**Video terkait:**
+ [AWS re:Invent 2018: Pola Arsitektur untuk Aplikasi Aktif-Aktif Multi-Wilayah](https://youtu.be/2e29I3dA8o4)
+ [AWS re:Invent 2019: Pencadangan dan pemulihan serta solusi pemulihan bencana dengan AWS](https://youtu.be/7gNXfo5HZN8)
# REL13-BP04 Mengelola penyimpangan konfigurasi di lokasi atau Wilayah Pemulihan Bencana (DR)
Untuk melakukan prosedur pemulihan bencana (DR) yang berhasil, beban kerja Anda harus dapat kembali beroperasi normal dengan cepat tanpa kehilangan fungsionalitas atau data yang relevan setelah lingkungan DR aktif dan siap digunakan. Untuk mencapai tujuan ini, penting untuk menjaga konsistensi infrastruktur, data, dan konfigurasi antara lingkungan DR Anda dan lingkungan primer.
**Hasil yang diinginkan:** Konfigurasi dan data situs pemulihan bencana Anda setara dengan situs primer, sehingga memudahkan pemulihan yang cepat dan menyeluruh saat dibutuhkan.
**Anti-pola umum:**
+ Anda tidak memperbarui lokasi pemulihan ketika ada perubahan pada lokasi primer, sehingga menghasilkan konfigurasi usang yang dapat menghambat upaya pemulihan.
+ Anda tidak mempertimbangkan potensi keterbatasan seperti perbedaan layanan antara lokasi primer dan pemulihan, sehingga dapat menyebabkan kegagalan tak terduga selama failover.
+ Anda mengandalkan proses manual untuk memperbarui dan menyinkronkan lingkungan DR, sehingga meningkatkan risiko kesalahan manusia dan inkonsistensi.
+ Anda gagal mendeteksi penyimpangan konfigurasi, sehingga Anda keliru menganggap bahwa situs DR siap sebelum insiden.
**Manfaat menjalankan praktik terbaik ini:** Konsistensi antara lingkungan DR dan lingkungan primer secara signifikan meningkatkan kemungkinan keberhasilan pemulihan setelah insiden dan mengurangi risiko prosedur pemulihan yang gagal.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Tinggi
## Panduan implementasi
Pendekatan komprehensif untuk manajemen konfigurasi dan kesiapan failover dapat membantu Anda memverifikasi bahwa situs DR secara konsisten diperbarui dan siap untuk mengambil alih jika terjadi kegagalan situs primer.
Untuk mencapai konsistensi antara lingkungan primer dan pemulihan bencana (DR) Anda, validasikan bahwa pipeline pengiriman Anda mendistribusikan aplikasi ke situs primer dan juga situs DR Anda. Terapkan perubahan ke situs DR setelah periode evaluasi yang sesuai (juga dikenal sebagai *deployment bertahap*) untuk mendeteksi masalah di situs primer dan menghentikan deployment sebelum masalah tersebut menyebar. Terapkan pemantauan untuk mendeteksi peyimpangan konfigurasi, dan lacak perubahan serta kepatuhan di berbagai lingkungan Anda. Lakukan remediasi otomatis di situs DR agar tetap konsisten dan siap untuk mengambil alih jika terjadi insiden.
### Langkah-langkah implementasi
1. Validasi bahwa wilayah DR berisi fitur dan layanan AWS yang diperlukan untuk keberhasilan pelaksanaan rencana DR Anda.
1. Gunakan infrastruktur sebagai kode (IaC). Jaga agar templat infrastruktur produksi dan konfigurasi aplikasi Anda tetap akurat, dan terapkan secara teratur ke lingkungan pemulihan bencana Anda. [AWS CloudFormation](https://aws.amazon.com/cloudformation/) dapat mendeteksi penyimpangan antara konfigurasi yang ditentukan dalam templat CloudFormation Anda dan apa yang sebenarnya di-deploy.
1. Konfigurasikan pipeline CI/CD untuk melakukan deployment pembaruan aplikasi dan infrastruktur ke semua lingkungan, termasuk situs primer dan DR. Solusi CI/CD seperti [AWS CodePipeline](https://aws.amazon.com/codepipeline/) dapat mengotomatiskan proses deployment, sehingga mengurangi risiko penyimpangan konfigurasi.
1. Lakukan deployment bertahap antara lingkungan primer dan DR. Pendekatan ini memungkinkan pembaruan di-deploy dan diuji terlebih dahulu di lingkungan primer, sehingga masalah di situs primer dapat diisolasi sebelum menyebar ke situs DR. Pendekatan ini mencegah kecacatan didorong ke situs produksi dan DR pada saat yang bersamaan dan menjaga integritas lingkungan DR.
1. Terus pantau konfigurasi sumber daya di lingkungan primer dan DR. Solusi seperti [AWS Config](https://aws.amazon.com/config/) dapat membantu menegakkan kepatuhan konfigurasi dan mendeteksi penyimpangan konfigurasi, sehingga membantu menjaga konsistensi konfigurasi di seluruh lingkungan.
1. Implementasikan mekanisme peringatan untuk melacak dan memberitahukan setiap penyimpangan konfigurasi atau gangguan atau keterlambatan replikasi data.
1. Otomatiskan perbaikan penyimpangan konfigurasi yang terdeteksi.
1. Jadwalkan audit dan pemeriksaan kepatuhan rutin untuk memverifikasi keselarasan yang berkelanjutan antara konfigurasi primer dan DR. Peninjauan berkala membantu Anda menjaga kepatuhan terhadap aturan yang ditetapkan dan mengidentifikasi ketidaksesuaian apa pun yang perlu ditangani.
1. Periksa ketidakcocokan dalam kapasitas yang disediakan AWS, kuota layanan, batas throttle, serta perbedaan konfigurasi dan versi.
## Sumber daya
**Praktik-praktik terbaik terkait:**
+ [REL01-BP01 Mengetahui kuota dan keterbatasan layanan](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_manage_service_limits_aware_quotas_and_constraints.html)
+ [REL01-BP02 Mengelola kuota layanan di seluruh akun dan wilayah](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_manage_service_limits_limits_considered.html)
+ [REL01-BP04 Memantau dan mengelola kuota](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_manage_service_limits_monitor_manage_limits.html)
+ [REL13-BP03 Menguji implementasi pemulihan bencana untuk memvalidasi implementasi](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_dr_tested.html)
**Dokumen terkait:**
+ [Mengatasi Sumber Daya AWS yang Tidak Patuh oleh Aturan AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html)
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [AWS CloudFormation: Mendeteksi perubahan konfigurasi tidak terkelola ke tumpukan dan sumber daya](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-stack-drift.html)
+ [AWS CloudFormation: Mendeteksi Penyimpangan di Seluruh Tumpukan CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/detect-drift-stack.html)
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [Pemulihan Bencana Beban Kerja di AWS: Pemulihan di Cloud (Laporan Resmi AWS)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [Bagaimana cara mengimplementasikan solusi Manajemen Konfigurasi Infrastruktur di AWS?](https://aws.amazon.com/answers/configuration-management/aws-infrastructure-configuration-management/?ref=wellarchitected)
+ [Mengatasi Sumber Daya AWS yang Tidak Patuh oleh Aturan AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html)
**Video terkait:**
+ [AWS re:Invent 2018: Pola Arsitektur untuk Aplikasi Aktif-Aktif Multi-Wilayah (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
**Contoh terkait:**
+ [Registri CloudFormation](https://aws.amazon.com/blogs/devops/identify-regional-feature-parity-using-the-aws-cloudformation-registry/)
+ [Pemantau Kuota untuk AWS](https://aws.amazon.com/solutions/implementations/quota-monitor/)
+ [Mengimplementasikan perbaikan otomatis atas penyimpangan untuk AWS CloudFormation menggunakan Amazon CloudWatch dan AWS Lambda](https://aws.amazon.com/blogs/mt/implement-automatic-drift-remediation-for-aws-cloudformation-using-amazon-cloudwatch-and-aws-lambda/)
+ [AWS Blog Arsitektur : Seri Pemulihan Bencana](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [AWS Marketplace: produk yang dapat digunakan untuk pemulihan bencana](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
+ [Melakukan otomatisasi deployment secara aman dan otonom](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/)
# REL13-BP05 Mengotomatiskan pemulihan
Implementasikan mekanisme pemulihan teruji dan otomatis yang andal, dapat diamati, serta dapat direproduksi untuk mengurangi risiko dan dampak bisnis dari kegagalan.
**Hasil yang diinginkan:** Anda telah mengimplementasikan alur kerja otomatisasi untuk proses pemulihan yang terdokumentasi dengan baik, terstandardisasi, dan teruji secara menyeluruh. Otomatisasi pemulihan Anda secara otomatis memperbaiki masalah kecil yang menimbulkan risiko rendah kehilangan atau ketidaktersediaan data. Anda dapat dengan cepat menginvokasi proses pemulihan untuk insiden serius, mengamati perilaku perbaikan saat proses tersebut beroperasi, dan menghentikan proses jika Anda mengamati situasi berbahaya atau kegagalan.
**Anti-pola umum:**
+ Anda bergantung pada komponen atau mekanisme yang berada dalam keadaan gagal atau kinerjanya menurun sebagai bagian dari rencana pemulihan Anda.
+ Proses pemulihan Anda memerlukan intervensi manual, seperti akses konsol (juga dikenal sebagai *click ops*).
+ Anda secara otomatis memulai prosedur pemulihan dalam situasi yang menimbulkan risiko tinggi kehilangan atau ketidaktersediaan data.
+ Anda gagal menyertakan mekanisme untuk membatalkan prosedur pemulihan (seperti *kabel Andon* atau *tombol darurat besar warna merah*) yang tidak berfungsi atau yang menimbulkan risiko tambahan.
**Manfaat menjalankan praktik terbaik ini:**
+ Peningkatan keandalan, prediktabilitas, dan konsistensi operasi pemulihan.
+ Kemampuan untuk memenuhi sasaran pemulihan yang lebih ketat, termasuk Sasaran Waktu Pemulihan (RTO) dan Sasaran Titik Pemulihan (RPO).
+ Mengurangi kemungkinan pemulihan gagal selama suatu insiden.
+ Mengurangi risiko kegagalan yang terkait dengan proses pemulihan manual yang rentan terhadap kesalahan manusia.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Sedang
## Panduan implementasi
Untuk menerapkan pemulihan otomatis, Anda memerlukan pendekatan komprehensif yang menggunakan layanan AWS dan praktik terbaik. Untuk memulai, identifikasi komponen penting dan titik kegagalan potensial dalam beban kerja Anda. Kembangkan proses otomatis yang dapat memulihkan beban kerja dan data Anda dari kegagalan tanpa campur tangan manusia.
Kembangkan otomatisasi pemulihan Anda menggunakan prinsip infrastruktur sebagai kode (IaC). Hal ini membuat lingkungan pemulihan Anda konsisten dengan lingkungan sumber dan memungkinkan kontrol versi untuk proses pemulihan Anda. Untuk mengorkestrasi alur kerja pemulihan yang kompleks, pertimbangkan solusi seperti [Otomatisasi AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) atau [AWS Step Functions](https://aws.amazon.com/step-functions/).
Otomatisasi proses pemulihan memberikan manfaat yang signifikan dan dapat membantu Anda lebih mudah mencapai Sasaran Waktu Pemulihan (RTO) dan Sasaran Titik Pemulihan (RPO). Namun, otomatisasi tersebut dapat mengalami situasi tak terduga yang dapat membuatnya gagal atau menciptakan risiko baru seperti waktu henti tambahan dan kehilangan data. Untuk mengurangi risiko ini, berikan kemampuan yang dapat dengan cepat menghentikan otomatisasi pemulihan yang sedang berlangsung. Setelah dihentikan, Anda dapat menyelidiki dan mengambil langkah-langkah korektif.
Untuk beban kerja yang didukung, pertimbangkan solusi seperti AWS Elastic Disaster Recovery (AWS DRS) untuk menyediakan failover otomatis. AWS DRS secara terus-menerus mereplikasi mesin Anda (termasuk sistem operasi, konfigurasi status sistem, basis data, aplikasi, dan file) ke dalam area staging di akun Akun AWS target Anda dan Wilayah yang dipilih. Jika terjadi insiden, AWS DRS mengotomatiskan konversi server replika Anda menjadi beban kerja yang disediakan sepenuhnya di Wilayah pemulihan Anda di AWS.
Pemulihan otomatis adalah proses yang perlu dipelihara dan ditingkatkan secara berkelanjutan. Terus uji dan sempurnakan prosedur pemulihan Anda berdasarkan pelajaran yang dipetik, dan tetap ikuti informasi terbaru tentang fitur dan layanan AWS baru yang dapat meningkatkan kemampuan pemulihan Anda.
### Langkah-langkah implementasi
1. **Rencanakan pemulihan otomatis**
1. Lakukan tinjauan menyeluruh atas arsitektur beban kerja, komponen, dan dependensi Anda untuk mengidentifikasi dan merencanakan mekanisme pemulihan otomatis. Kategorikan dependensi beban kerja Anda ke dalam dependensi *mutlak* dan *relatif*. Dependensi mutlak adalah dependensi yang tanpanya beban kerja tidak dapat beroperasi dan tidak ada pengganti yang dapat disediakan. Dependensi relatif adalah dependensi yang biasanya digunakan oleh beban kerja tetapi dapat diganti dengan sistem atau proses pengganti sementara atau dapat ditangani dengan [penurunan terkendali](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_mitigate_interaction_failure_graceful_degradation).
1. Tetapkan proses untuk mengidentifikasi dan memulihkan data yang hilang atau rusak.
1. Tentukan langkah-langkah untuk mengonfirmasi kondisi stabil dan pulih setelah tindakan pemulihan selesai.
1. Pertimbangkan tindakan apa pun yang diperlukan untuk membuat sistem yang pulih siap untuk layanan penuh, seperti pra-pemanasan dan pengisian cache.
1. Pikirkan berbagai masalah yang dapat muncul selama proses pemulihan dan cara mendeteksi dan memperbaikinya.
1. Pertimbangkan skenario ketika situs primer dan bidang kontrolnya tidak dapat diakses. Verifikasi bahwa tindakan pemulihan dapat dilakukan secara independen tanpa bergantung pada situs primer. Pertimbangkan solusi seperti [Pengontrol Pemulihan Aplikasi (ARC) Amazon](https://aws.amazon.com/application-recovery-controller/) untuk mengalihkan lalu lintas tanpa perlu mengubah catatan DNS secara manual.
1. **Kembangkan proses pemulihan otomatis**
1. Terapkan deteksi kesalahan otomatis dan mekanisme failover untuk pemulihan tanpa intervensi manual. Buat dasbor misalnya dengan [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) untuk melaporkan progres dan kondisi prosedur pemulihan otomatis. Sertakan prosedur untuk memvalidasi pemulihan yang berhasil. Sediakan mekanisme untuk membatalkan pemulihan yang sedang berlangsung.
1. Buat [playbook](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_testing_resiliency_playbook_resiliency) sebagai proses alternatif untuk kesalahan yang tidak dapat dipulihkan secara otomatis, dan pastikan keselarasannya dengan [rencana pemulihan bencana](https://aws.amazon.com/disaster-recovery/faqs/#Core_concepts) Anda.
1. Uji proses pemulihan sebagaimana dibahas di [REL13-BP03](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_planning_for_recovery_dr_tested.html).
1. **Bersiap untuk pemulihan**
1. Evaluasi keadaan situs pemulihan Anda dan lakukan deployment komponen penting ke situs tersebut sebelumnya. Untuk detail lebih lanjut, lihat [REL13-BP04](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_config_drift.html).
1. Tentukan peran, tanggung jawab, dan proses pengambilan keputusan yang jelas untuk operasi pemulihan, yang melibatkan pemangku kepentingan dan tim yang relevan di keseluruhan organisasi.
1. Tentukan kondisi untuk memulai proses pemulihan Anda.
1. Buat rencana untuk mengembalikan proses pemulihan dan kembali ke situs primer Anda jika diperlukan atau setelah dianggap aman.
## Sumber daya
**Praktik-praktik terbaik terkait:**
+ [REL07-BP01 Menggunakan otomatisasi ketika mendapatkan atau menskalakan sumber daya](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_adapt_to_changes_autoscale_adapt.html)
+ [REL11-BP01 Memantau semua komponen beban kerja untuk mendeteksi kegagalan](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_withstand_component_failures_monitoring_health.html)
+ [REL13-BP02 Menggunakan strategi pemulihan untuk memenuhi sasaran pemulihan](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_disaster_recovery.html)
+ [REL13-BP03 Menguji implementasi pemulihan bencana untuk memvalidasi implementasi](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_planning_for_recovery_dr_tested.html)
+ [REL13-BP04 Mengelola penyimpangan konfigurasi di lokasi atau Wilayah Pemulihan Bencana (DR)](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_config_drift.html)
**Dokumen terkait:**
+ [Blog Arsitektur AWS: Seri Pemulihan Bencana](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [Pemulihan Bencana Beban Kerja di AWS: Pemulihan di Cloud (Laporan Resmi AWS)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [Mengorkestrasi Otomatisasi Pemulihan Bencana menggunakan ARC Amazon Route 53 dan AWS Step Functions](https://aws.amazon.com/blogs/networking-and-content-delivery/orchestrate-disaster-recovery-automation-using-amazon-route-53-arc-and-aws-step-functions/)
+ [Membuat runbook Otomatisasi AWS Systems Manager menggunakan AWS CDK](https://aws.amazon.com/blogs/mtbuild-aws-systems-manager-automation-runbooks-using-aws-cdk/)
+ [AWS Marketplace: Produk yang Dapat Digunakan untuk Pemulihan Bencana](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
+ [Otomatisasi AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [Pemulihan Bencana Elastis AWS](https://aws.amazon.com/disaster-recovery/)
+ [Menggunakan Pemulihan Bencana Elastis untuk Failover dan Failback](https://docs.aws.amazon.com/drs/latest/userguide/failback.html)
+ [Sumber Daya AWS Elastic Disaster Recovery](https://aws.amazon.com/disaster-recovery/resources/)
+ [Partner APN: Partner yang Dapat Membantu Anda Melakukan Pemulihan Bencana](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
**Video terkait:**
+ [AWS re:Invent 2018: Pola Arsitektur untuk Aplikasi Aktif-Aktif Multi-Wilayah (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [AWS re:Invent 2022: AWS On Air ft. AWS Failback untuk AWS Elastic Disaster Recovery](https://youtu.be/Ok-vpV8b1Hs)