

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

# Lampiran A - Jenis tujuan untuk rekayasa kekacauan
<a name="appendix-a"></a>

Deskripsi jenis tujuan berikut mencakup contoh dunia nyata tentang bagaimana Amazon dan organisasi lain telah merancang tujuan untuk rekayasa kekacauan.

## Tujuan arsitektur tangguh
<a name="resilient-architecture"></a>

Salah satu pendorong awal untuk mengadopsi chaos engineering adalah mengidentifikasi dan mengurangi titik kegagalan tunggal (SPOF) di seluruh sistem dan infrastruktur. Tujuan ditetapkan untuk memvalidasi ketahanan sistem dan arsitektur kritis, terutama untuk layanan atau aplikasi baru.

Tujuan arsitektur tangguh melibatkan menjalankan eksperimen chaos yang mensimulasikan kegagalan dalam dependensi layanan. Eksperimen mengkonfirmasi apakah batas waktu, percobaan ulang, perilaku caching, dan konfigurasi pemutus sirkuit berfungsi dengan benar. Eksperimen ini membantu mengungkap masalah untuk remediasi, mencegah insiden yang berdampak pada pelanggan. Sebagai contoh, lihat [Membangun layanan tangguh di Prime Video dengan rekayasa kekacauan](https://aws.amazon.com/blogs/opensource/building-resilient-services-at-prime-video-with-chaos-engineering/).

## Tujuan pemulihan layanan
<a name="service-recovery"></a>

Tujuan pemulihan layanan berfokus pada peningkatan kemampuan untuk pulih dari gangguan operasional atau kegagalan infrastruktur. Misalnya, organisasi Anda mungkin bertujuan untuk mencapai tujuan waktu pemulihan tertentu (RTO) untuk layanan inti Anda jika terjadi pemadaman. Tim dapat merancang eksperimen chaos untuk memvalidasi dan mengoptimalkan strategi evakuasi, mekanisme failover, dan proses pemulihan otomatis. Pengoptimalan pada akhirnya mengurangi waktu yang diperlukan untuk restorasi layanan. Sebagai contoh, lihat [AWS Lambda: Ketahanan under-the-hood](https://aws.amazon.com/blogs/compute/aws-lambda-resilience-under-the-hood/).

## Tujuan pengalaman pengguna
<a name="ux"></a>

Mempertahankan pengalaman pengguna yang konsisten dan andal adalah yang terpenting, terutama selama periode lalu lintas tinggi atau peristiwa kritis. Dalam kasus seperti itu, tetapkan tujuan yang berpusat di sekitar memenuhi tujuan tingkat layanan tertentu (). SLOs Pendekatan yang berpusat pada pelanggan ini memastikan bahwa upaya ketahanan secara langsung selaras dengan memberikan pengalaman pengguna yang unggul, bahkan dalam menghadapi kegagalan atau kondisi yang terdegradasi. Sebagai contoh, lihat [Ketahanan Rekayasa: Pelajaran dari Perjalanan Rekayasa Kekacauan Amazon Search](https://community.aws/posts/amazon-search-chaos-engineering-journey).

## Tujuan berbasis metrik
<a name="metrics"></a>

Anda dapat menetapkan sasaran berdasarkan metrik kuantitatif, seperti skor ketahanan yang dihitung dengan memberikan poin ke layanan yang mengadopsi praktik terbaik ketahanan yang terbukti. Anda kemudian dapat menggunakan eksperimen kekacauan tertentu untuk menentukan skor ketahanan. Skor ini dapat berfungsi sebagai ukuran bagi tim untuk melacak kemajuan mereka dalam mengurangi risiko ketersediaan yang diketahui dan menerapkan langkah-langkah ketahanan yang direkomendasikan. Namun, sangat penting untuk menafsirkan skor tersebut dengan hati-hati dan menghindari terlalu menekankan satu metrik dengan mengorbankan tujuan ketahanan yang lebih luas. Sebagai contoh, lihat [Memahami skor ketahanan](https://docs.aws.amazon.com/resilience-hub/latest/userguide/resil-score.html).

## Tujuan kepatuhan regulasi
<a name="compliance"></a>

Industri jasa keuangan telah muncul sebagai pelari terdepan dalam merangkul rekayasa kekacauan, terutama didorong oleh persyaratan peraturan yang ketat yang mengamanatkan kemampuan ketahanan yang kuat. Peraturan akan menuntut agar lembaga keuangan secara proaktif mengidentifikasi, menguji, dan memulihkan kerentanan dalam sistem dan proses kritis mereka. Peraturan ini meliputi:
+ Makalah Antar Lembaga tentang Praktik Suara untuk Memperkuat Ketahanan Operasional yang dikeluarkan oleh lembaga federal AS
+ Pedoman Bank Sentral Eropa tentang ketahanan operasional
+ Proposal Komisi Eropa untuk Undang-Undang Ketahanan Operasional Digital (DORA)

Jika organisasi Anda adalah lembaga keuangan, patuhi peraturan ini dengan menetapkan tujuan eksplisit untuk menunjukkan ketahanan operasional melalui strategi pengujian dan validasi yang komprehensif. Sebagai contoh, lihat [London Stock Exchange Group menggunakan chaos engineering AWS untuk meningkatkan ketahanan](https://aws.amazon.com/blogs/architecture/london-stock-exchange-group-uses-chaos-engineering-on-aws-to-improve-resilience/).