Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Kegiatan pasca-penyebaran
Ketahanan adalah proses yang berkelanjutan dan evaluasi ketahanan aplikasi Anda harus dilanjutkan setelah aplikasi diterapkan. Hasil aktivitas pasca-penerapan Anda, seperti penilaian ketahanan yang sedang berlangsung, mungkin mengharuskan Anda mengevaluasi ulang dan memperbarui beberapa aktivitas ketahanan yang Anda lakukan sebelumnya dalam siklus hidup ketahanan.
Melakukan penilaian ketahanan
Menilai ketahanan tidak berhenti setelah Anda menerapkan aplikasi Anda ke dalam produksi. Bahkan jika Anda memiliki pipeline penyebaran yang terdefinisi dengan baik dan otomatis, perubahan terkadang dapat terjadi secara langsung di lingkungan produksi. Selain itu, mungkin ada faktor-faktor yang belum Anda pertimbangkan dalam verifikasi ketahanan pra-penerapan Anda. AWS Resilience Hubmenyediakan tempat sentral di mana Anda dapat menilai apakah arsitektur yang Anda gunakan memenuhi kebutuhan RPO dan RTO yang Anda tentukan. Anda dapat menggunakan layanan ini untuk menjalankan penilaian berdasarkan permintaan atas ketahanan aplikasi Anda, mengotomatiskan penilaian, dan bahkan mengintegrasikannya ke dalam alat CI/CD Anda, seperti yang dibahas dalam AWS posting blog Menilai ketahanan aplikasi secara terus-menerus dengan dan. AWS Resilience HubAWS CodePipeline
Pengujian DR
Pada Tahap 2: Merancang dan menerapkan, Anda mengembangkan strategi pemulihan bencana (DR) sebagai bagian dari sistem Anda. Selama Tahap 4, Anda harus menguji prosedur DR Anda untuk memastikan bahwa tim Anda sepenuhnya siap untuk suatu insiden dan prosedur Anda bekerja seperti yang diharapkan. Anda harus menguji semua prosedur DR Anda, termasuk failover dan failback, secara teratur dan meninjau hasil setiap latihan untuk menentukan apakah dan bagaimana prosedur sistem Anda harus diperbarui untuk hasil terbaik. Ketika Anda awalnya mengembangkan tes DR Anda, jadwalkan tes jauh sebelumnya dan pastikan bahwa seluruh tim memahami apa yang diharapkan, bagaimana hasil akan diukur, dan mekanisme umpan balik apa yang akan digunakan untuk memperbarui prosedur berdasarkan hasil. Setelah Anda menjadi mahir dalam menjalankan tes DR terjadwal, pertimbangkan untuk menjalankan tes DR yang tidak diumumkan. Bencana nyata tidak terjadi sesuai jadwal, jadi Anda harus siap untuk melaksanakan rencana Anda kapan saja. Namun, tanpa pemberitahuan tidak berarti tidak direncanakan. Pemangku kepentingan utama masih perlu merencanakan acara untuk memastikan bahwa pemantauan yang tepat telah dilakukan dan bahwa pelanggan dan aplikasi penting tidak terkena dampak buruk.
Deteksi drift
Perubahan konfigurasi yang tidak terduga dalam aplikasi produksi dapat terjadi bahkan ketika otomatisasi dan prosedur yang terdefinisi dengan baik sudah ada. Untuk mendeteksi perubahan pada konfigurasi aplikasi Anda, Anda harus memiliki mekanisme untuk mendeteksi drift, yang mengacu pada penyimpangan dari konfigurasi dasar. Untuk mempelajari cara mendeteksi drift di AWS CloudFormation tumpukan, lihat Mendeteksi perubahan konfigurasi yang tidak dikelola pada tumpukan dan sumber daya dalam dokumentasi. AWS CloudFormation Untuk mendeteksi drift di AWS lingkungan aplikasi Anda, lihat Mendeteksi dan menyelesaikan drift AWS Control Tower dalam dokumentasi. AWS Control Tower
Pengujian sintetis
Pengujian sintetis adalah proses pembuatan perangkat lunak yang dapat dikonfigurasi yang berjalan dalam produksi, secara terjadwal, untuk menguji API aplikasi Anda dengan cara yang mensimulasikan pengalaman pengguna akhir. Tes ini kadang-kadang disebut sebagai kenari, mengacu pada penggunaan asli istilah dalam penambangan batubara. Tes sintetis seringkali dapat memberikan peringatan dini ketika aplikasi mengalami gangguan, bahkan jika kerusakannya sebagian atau intermiten, seperti yang sering terjadi pada kegagalan abu-abu.
Rekayasa kekacauan
Rekayasa kekacauan adalah proses sistematis yang melibatkan sengaja menerapkan aplikasi pada peristiwa yang mengganggu dengan cara yang dikurangi risiko, memantau responsnya dengan cermat, dan menerapkan perbaikan yang diperlukan. Tujuannya adalah untuk memvalidasi atau menantang asumsi tentang kemampuan aplikasi untuk menangani gangguan tersebut. Alih-alih meninggalkan peristiwa ini secara kebetulan, rekayasa kekacauan memberdayakan para insinyur untuk mengatur eksperimen dalam lingkungan yang terkendali, biasanya selama periode lalu lintas rendah dan dengan dukungan teknik yang tersedia untuk mitigasi yang efektif.
Rekayasa kekacauan dimulai dengan memahami kondisi operasi normal, yang dikenal sebagai kondisi tunak, dari aplikasi yang sedang dipertimbangkan. Dari sana, Anda merumuskan hipotesis yang merinci perilaku sukses aplikasi di hadapan gangguan. Anda menjalankan eksperimen, yang melibatkan injeksi gangguan yang disengaja, termasuk, namun tidak terbatas pada, latensi jaringan, kegagalan server, kesalahan hard drive, dan gangguan dependensi eksternal. Anda kemudian menganalisis hasil percobaan dan meningkatkan ketahanan aplikasi berdasarkan pembelajaran Anda. Eksperimen ini berfungsi sebagai alat yang berharga untuk meningkatkan berbagai aspek aplikasi, termasuk kinerjanya, dan mengungkap masalah laten yang mungkin tetap tersembunyi. Selain itu, rekayasa kekacauan membantu mengungkapkan kekurangan dalam observabilitas dan alat yang mengkhawatirkan, dan membantu Anda memperbaikinya. Ini juga berkontribusi untuk mengurangi waktu pemulihan dan meningkatkan keterampilan operasional. Rekayasa kekacauan mempercepat penerapan praktik terbaik dan menumbuhkan pola pikir perbaikan berkelanjutan. Pada akhirnya, ini memungkinkan tim untuk membangun dan mengasah keterampilan operasional mereka melalui latihan reguler dan pengulangan.
AWS merekomendasikan agar Anda memulai upaya rekayasa kekacauan Anda di lingkungan non-produksi. Anda dapat menggunakan AWS Fault Injection Service (AWS FIS)
