Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Memulai dengan rekayasa kekacauan
Sebelum Anda melakukan percobaan, kami sarankan Anda meletakkan beberapa hal penting untuk memaksimalkan praktik rekayasa kekacauan Anda. Hal-hal penting ini meliputi:
-
Observabilitas (metrik, logging, penelusuran permintaan)
-
Daftar peristiwa atau kesalahan dunia nyata yang ingin Anda jelajahi
-
Sponsor ketahanan organisasi melalui dukungan kepemimpinan
-
Prioritisasi temuan kritis, berdasarkan potensi dampak bisnis, di atas fitur baru yang ditemukan saat menjalankan eksperimen chaos
Observabilitas untuk eksperimen kekacauan
Observabilitas, yang terdiri dari metrik, logging, dan penelusuran permintaan, memainkan peran kunci dalam rekayasa kekacauan. Anda akan ingin memahami metrik bisnis, metrik sisi server, metrik pengalaman klien, dan metrik operasi saat menjalankan eksperimen. Tanpa observabilitas, Anda tidak akan dapat mendefinisikan perilaku kondisi tunak atau membuat eksperimen yang bermakna untuk memverifikasi apakah hipotesis Anda tentang aplikasi Anda benar.
Metrik-metrik
Diagram berikut menunjukkan jenis metrik yang dapat Anda lacak untuk eksperimen chaos untuk berbagai jenis aplikasi.
-
Metrik bisnis — Steady state menunjukkan operasi normal sistem Anda dan ditentukan oleh metrik bisnis Anda. Ini dapat diwakili oleh transaksi per detik (TPS), aliran klik per detik, pesanan per detik, atau pengukuran serupa. Aplikasi Anda menunjukkan kondisi mapan saat beroperasi seperti yang diharapkan. Oleh karena itu, verifikasi bahwa aplikasi Anda sehat sebelum Anda menjalankan eksperimen. Steady state tidak selalu berarti bahwa tidak akan ada dampak pada aplikasi ketika kesalahan terjadi, karena persentase kesalahan dapat berada dalam batas yang dapat diterima. Kondisi mapan adalah baseline Anda. Misalnya, kondisi tunak sistem pembayaran dapat didefinisikan sebagai pemrosesan 300 TPS dengan tingkat keberhasilan 99 persen dan waktu pulang-pergi 500 ms. Secara visual, pikirkan kondisi tunak sebagai elektrokardiogram (EKG). Jika kondisi stabil sistem Anda tiba-tiba berfluktuasi, Anda tahu bahwa ada masalah dengan layanan Anda.
-
Metrik sisi server — Untuk memahami kinerja sumber daya selama percobaan, Anda memerlukan wawasan tentang kinerjanya sebelum, selama, dan setelah percobaan. Untuk mengukur dampak sumber daya Anda AWS, Anda dapat menggunakan Amazon CloudWatch. CloudWatch adalah layanan yang memantau aplikasi, merespons perubahan kinerja, mengoptimalkan penggunaan sumber daya, dan memberikan wawasan tentang kesehatan operasional. Selama eksperimen, Anda akan ingin menangkap metrik sisi server seperti saturasi, volume permintaan, tingkat kesalahan, dan latensi.
-
Metrik pengalaman pelanggan — Aktif AWS, Anda dapat menangkap metrik pengguna nyata dengan menggunakan CloudWatchRUM untuk mensimulasikan permintaan pengguna melalui alat seperti Locust, Grafana k6, Selenium, atau Dalang. Metrik pengguna nyata sangat penting bagi organisasi yang melakukan eksperimen rekayasa kekacauan. Dengan memantau bagaimana pengguna nyata terkena dampak selama percobaan, tim dapat memperoleh gambaran yang akurat tentang bagaimana kesalahan dan gangguan akan mempengaruhi pelanggan dalam produksi. Metrik pengalaman klien utama adalah Time to First Byte (TTFB), Largest Contentful Paint (LCP), Interaction to Next Paint (INP), dan Total Blocking Time (TBT).
-
Metrik operasi — Intervensi mengukur seberapa berhasil Anda mengurangi kesalahan secara otomatis―misalnya, latensi permintaan klien yang berhasil selama reboot pod, tugas, atau instans EC2 dengan mekanisme seperti pengontrol replikasi atau penskalaan otomatis. Mampu melakukan intervensi secara otomatis selama kesalahan secara langsung berkorelasi dengan pengalaman pengguna yang baik. Memahami jika ada penyimpangan dalam mekanisme mitigasi ini dari waktu ke waktu sangat penting. Dengan mendefinisikan metrik untuk mitigasi otomatis yang berhasil dan gagal, Anda membuat pos panduan yang membantu mengidentifikasi potensi regresi di seluruh sistem Anda.
Pencatatan log
Pencatatan terpusat adalah kunci untuk memahami status komponen aplikasi Anda sebelum, selama, dan setelah eksperimen chaos. Kami menyarankan Anda mengumpulkan log dari semua komponen aplikasi Anda untuk membangun tampilan konsolidasi tentang apa yang dilakukan setiap komponen pada saat eksperimen disuntikkan. Ini memberikan gambaran yang jelas tentang aliran end-to-end eksperimen.
Pelacakan permintaan
Penelusuran permintaan memungkinkan Anda mengamati aliran permintaan tunggal apa pun di seluruh komponen dalam aplikasi Anda untuk mendapatkan pemahaman yang komprehensif tentang dampak kegagalan yang disuntikkan terhadap sistem dan dependensinya. Dengan menelusuri permintaan, Anda dapat melihat bagaimana kegagalan menyebar melalui berbagai layanan dan komponen, sehingga Anda dapat menilai cakupan gangguan dengan lebih baik. Untuk melacak permintaan Anda AWS, Anda dapat menggunakan AWS X-Ray.
Skenario kegagalan untuk menyuntikkan dalam eksperimen kekacauan
Tujuan dari menyuntikkan kesalahan umum ke dalam aplikasi Anda adalah untuk memahami bagaimana aplikasi bereaksi terhadap kejadian tak terduga ini, sehingga Anda dapat membuat mekanisme mitigasi dan membuat sistem Anda tahan terhadap kesalahan tersebut. Selain itu, Anda harus menggunakan rekayasa kekacauan untuk memutar ulang skenario kegagalan historis untuk memverifikasi bahwa mekanisme mitigasi Anda masih berfungsi seperti yang diharapkan dan tidak melayang seiring waktu.
Pertimbangkan peristiwa-peristiwa berikut ketika Anda merencanakan eksperimen rekayasa kekacauan Anda.
| Mode kegagalan | Deskripsi |
|---|---|
Kerusakan server |
Reboot instans EC2, hapus pod Kubernetes atau tugas Amazon Elastic Container Service (Amazon ECS) untuk memahami bagaimana aplikasi Anda bereaksi terhadap crash tersebut. |
Kesalahan API |
Suntikkan kesalahan ke dalam AWS dan layanan Anda sendiri APIs untuk memahami perilaku aplikasi. |
Masalah jaringan |
Memperkenalkan latensi atau kemacetan, atau memblokir koneksi untuk meniru masalah jaringan dunia nyata. |
AWS Gangguan Availability Zone |
Putar ulang kerusakan dari seluruh Availability Zone untuk memverifikasi pemulihan di seluruh zona. |
Wilayah AWS gangguan konektivitas |
Putar ulang gangguan jaringan Wilayah AWS untuk memverifikasi bagaimana sumber daya di Wilayah sekunder bereaksi terhadap peristiwa semacam itu. |
Kegagalan basis data |
Gagal atas replika database atau data yang rusak, atau membuat instance database tidak dapat dijangkau, untuk memahami dampak pada aplikasi dan strategi pemulihan Anda. |
Jeda dalam database dan replikasi Amazon S3 |
Jeda replikasi database atau Amazon Simple Storage Service (Amazon S3) di seluruh Availability Zone atau Wilayah AWS untuk memahami dampak aplikasi hilir. |
Degradasi penyimpanan |
Jeda I/O, hapus volume Amazon Elastic Block Store (Amazon EBS), atau hapus file untuk memverifikasi daya tahan dan pemulihan data. |
Gangguan ketergantungan |
Hapus atau turunkan kinerja layanan hilir atau hulu yang Anda andalkan, termasuk layanan pihak ketiga, untuk memahami end-to-end aliran dan dampaknya terhadap pelanggan Anda. |
Lonjakan lalu lintas |
Hasilkan lonjakan lalu lintas pengguna untuk menguji kemampuan penskalaan otomatis, dan lihat bagaimana waktu boot dingin dapat memengaruhi keseluruhan status aplikasi Anda. |
Kelelahan sumber daya |
Maksimalkan CPU, memori, dan ruang disk untuk memverifikasi degradasi aplikasi Anda yang anggun. |
Kegagalan Cascading |
Memulai kegagalan utama yang mengalir ke aplikasi dan komponen hilir. |
Penerapan yang buruk |
Luncurkan perubahan atau konfigurasi yang bermasalah untuk memverifikasi mekanisme rollback. |
Sponsor ketahanan organisasi
Rekayasa kekacauan memberikan nilai paling besar ketika diterapkan di seluruh organisasi Anda. Kami menyarankan Anda bekerja dengan sponsor eksekutif yang dapat membantu menetapkan tujuan ketahanan di seluruh organisasi Anda, menghilangkan rasa takut, ketidakpastian, dan keraguan tentang domain, dan memulai proses transformasi untuk membuat ketahanan menjadi tanggung jawab semua orang.
Untuk mendukung kasus bisnis membangun praktik rekayasa kekacauan, lampirkan upaya rekayasa kekacauan ke proyek bisnis penting Anda. Menjadikan ketahanan sebagai aset dan pendorong akselerasi akan membantu Anda melacak kesuksesan dari waktu ke waktu. Mulailah dengan hitungan insiden kritis per bulan atau per kuartal, waktu rata-rata untuk pulih, dan dampak yang ditimbulkan insiden ini terhadap pelanggan dan organisasi Anda. Tetapkan tujuan bersama tim Anda untuk mengurangi jumlah insiden selama periode 6 hingga 12 bulan karena perbaikan dilakukan di seluruh tumpukan aplikasi Anda sebagai respons terhadap eksperimen rekayasa kekacauan.
Ukur apakah insiden sangat berulang. Misalnya, katakanlah sertifikat TLS yang kedaluwarsa menyebabkan downtime karena klien tidak dapat membuat koneksi tepercaya. Jika beberapa insiden terjadi dalam setahun karena kedaluwarsa beberapa sertifikat TLS, Anda dapat menjalankan eksperimen kedaluwarsa sertifikat TLS dan memverifikasi bahwa tim Anda mendapatkan peringatan atau dapat secara otomatis mengurangi masalah tersebut. Ini akan membantu memastikan bahwa Anda menjadi tangguh terhadap kesalahan tersebut.
Untuk melacak kemajuan dalam rekayasa kekacauan dari waktu ke waktu, tangkap metrik berikut untuk membantu menyoroti nilai rekayasa kekacauan di seluruh siklus hidup aplikasi:
-
Tingkat insiden berkurang — Lacak jumlah insiden produksi dari waktu ke waktu dan korelasikan angka ini dengan adopsi rekayasa kekacauan. Harapannya adalah bahwa tingkat insiden parah akan menurun.
-
Peningkatan waktu rata-rata untuk resolusi (MTTR) - Hitung waktu rata-rata yang diperlukan untuk menyelesaikan insiden dan melacak data ini untuk melihat apakah itu membaik dengan rekayasa kekacauan dari waktu ke waktu.
-
Peningkatan ketersediaan aplikasi — Gunakan metrik tingkat layanan untuk menunjukkan peningkatan ketersediaan saat ketahanan aplikasi meningkat melalui eksperimen chaos.
-
Waktu yang lebih cepat ke pasar - Rekayasa kekacauan dapat memberikan kepercayaan diri untuk meluncurkan penawaran inovatif lebih cepat, karena Anda tahu bahwa aplikasi Anda tangguh. Lacak peningkatan kecepatan pelepasan produk.
-
Pengurangan biaya operasional — Mengukur apakah indikator seperti kebisingan peringatan, beban operasional, dan upaya manual untuk mengelola aplikasi berkurang dengan praktik kekacauan yang berlaku.
-
Meningkatkan kepercayaan diri — Pengembang survei, insinyur keandalan situs (SREs), dan staf teknis lainnya untuk mengukur apakah rekayasa kekacauan meningkatkan kepercayaan mereka dalam ketahanan aplikasi. Persepsi penting.
-
Pengalaman pelanggan yang lebih baik - Hubungkan rekayasa kekacauan ke hasil positif bagi pelanggan, seperti lebih sedikit gangguan layanan, kemunduran, dan pemadaman.
Memprioritaskan remediasi
Saat Anda melakukan eksperimen chaos, Anda cenderung mengidentifikasi area untuk perbaikan di mana aplikasi tidak berfungsi sebagaimana dimaksud. Remediasi barang-barang tersebut akan menjadi pekerjaan di backlog Anda yang harus diprioritaskan bersama dengan pekerjaan lain seperti pengembangan fitur. Kami menyarankan Anda meluangkan waktu untuk penyempurnaan ini untuk menghindari kegagalan di masa depan. Pertimbangkan untuk memprioritaskan pembelajaran dan tugas-tugas remediasi ini berdasarkan tingkat dampak yang mungkin ditimbulkannya. Temuan yang secara langsung berdampak pada ketahanan atau keamanan aplikasi Anda harus memiliki prioritas di atas fitur baru, untuk menghindari dampak pelanggan. Jika tim berjuang untuk memprioritaskan pekerjaan remediasi daripada pengembangan fitur, pertimbangkan untuk menghubungi sponsor eksekutif Anda untuk memastikan bahwa prioritas ditetapkan berdasarkan toleransi risiko bisnis.
