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

Siklus hidup eksperimen rekayasa kekacauan berkelanjutan

Seperti yang dibahas di bagian sebelumnya, Anda dapat menerapkan eksperimen rekayasa kekacauan dengan berbagai cara. Dalam semua kasus, kunci untuk membangun eksperimen chaos yang berarti adalah memahami aplikasi, insiden historis, dan remediasi yang diterapkan, dan untuk memahami dengan jelas area yang akan diselidiki, seperti ketahanan atau keamanan. Pengetahuan Anda tentang aplikasi membantu Anda merumuskan hipotesis tentang potensi kelemahan aplikasi dan memahami bagaimana aplikasi akan mendeteksi, memperbaiki, dan memulihkan ketika kesalahan disuntikkan.

Siklus hidup eksperimen chaos mencakup langkah-langkah berikut:

Langkah-langkah ini diilustrasikan dalam diagram dan dibahas di bagian berikut.

Tentukan tujuan dan tetapkan harapan

Sebelum setiap percobaan, pastikan bahwa tujuan dan harapan Anda spesifik, terukur, dapat dicapai, relevan, dan terikat waktu. Tentukan dengan jelas hal-hal berikut:

Pilih aplikasi target

Rekayasa kekacauan adalah teknik yang ampuh tetapi membutuhkan prioritas yang bijaksana untuk memaksimalkan nilai. Saat memutuskan di mana harus memfokuskan upaya rekayasa kekacauan, mulailah dengan mempertimbangkan layanan penting bisnis Anda. Minta tim Anda untuk mengulangi tahapan siklus hidup pengembangan perangkat lunak, dan mulailah menyuntikkan kesalahan di lingkungan pengujian terlebih dahulu. Aplikasi penting bisnis terkait langsung dengan pendapatan, pengalaman pelanggan, dan operasi inti. Eksperimen kekacauan pada layanan ini dapat mengungkap kerentanan yang dapat sangat berdampak pada organisasi - dan berpotensi seluruh pasar - jika tidak ditangani. Misalnya, fokus pada layanan yang dihadapi pelanggan seperti sistem perdagangan atau sistem pesanan terlebih dahulu. Memprioritaskan layanan pusat ini memberikan perlindungan paling besar per investasi waktu.

Setelah layanan kritis, lihat komponen dasar seperti database, antrian pesan, jaringan, dan layanan bersama. APIs Ini dapat digunakan sebagai komponen atau layanan bersama di seluruh organisasi Anda, sehingga kegagalan mereka akan menyebabkan masalah yang meluas. Mengonfirmasi ketahanan layanan infrastruktur memberikan keyakinan bahwa mereka tidak akan melumpuhkan aplikasi dependen di atasnya. Misalnya, eksperimen rekayasa kekacauan yang menjatuhkan cluster Kafka mengungkapkan banyak hal tentang toleransi kesalahan aplikasi hilir. Meskipun infrastruktur sistem tidak secara langsung menghadapi pelanggan, ini adalah target rekayasa kekacauan utama.

Jangan lupa untuk memetakan kesenjangan mental orang, proses, informasi fasilitas, dan ketergantungan pihak ketiga, karena ini dapat menyebabkan gangguan besar jika tidak selaras dengan tujuan toleransi dampak organisasi Anda. Untuk informasi lebih lanjut tentang mengukur ROI rekayasa kekacauan, baca Mengukur ROI rekayasa kekacauan dalam dokumen strategi Berinvestasi dalam rekayasa kekacauan sebagai kebutuhan strategis.

Diagram berikut menunjukkan laba atas investasi untuk menjalankan eksperimen chaos pada berbagai tingkatan layanan.

Sejajarkan peta mental (penemuan aplikasi)

Saat Anda menjalankan eksperimen ad-hoc atau hari permainan, Anda akan memulai proses penemuan aplikasi dengan mengadakan sesi papan tulis yang berfokus pada pemetaan detail aplikasi Anda. (Jika Anda menjalankan eksperimen di pipeline chaos, Anda akan sudah menyelaraskan peta mental itu, dengan mendefinisikan aplikasi target.) Pendekatan yang baik untuk memahami kesenjangan mental adalah meminta anggota tim paling junior menggambar diagram aplikasi terlebih dahulu, dan kemudian meminta lebih banyak anggota staf senior untuk menambahkan diagram secara progresif. Ini akan mengungkap kesenjangan dalam pemahaman di seluruh tingkat pengalaman.

Diagram harus menggambarkan dependensi hulu dan hilir langsung dari aplikasi, serta integrasi pihak ketiga yang penting. Pastikan bahwa ada keselarasan pada aliran permintaan yang diharapkan melalui aplikasi. Memetakan alur kerja utama dan perjalanan pengguna untuk mendapatkan kejelasan tentang bagaimana pelanggan menggunakan aplikasi. Pertimbangkan untuk menggunakan diagram urutan untuk menangkap informasi ini.

Setelah sesi kolaboratif ini, tim harus memiliki model mental bersama dari aplikasi, dependensi kritisnya, dan kemampuan pemantauannya, dan pemahaman tentang risiko untuk membuat keputusan berdasarkan informasi untuk melanjutkan, atau membatalkan, eksperimen kekacauan potensial.

Mengatasi masalah yang diketahui dengan aplikasi Anda

Eksperimen rekayasa kekacauan dirancang untuk secara proaktif memunculkan cacat dalam suatu aplikasi. Dengan menyuntikkan kegagalan seperti peningkatan latensi, reboot server, atau gangguan daya Availability Zone, Anda dapat memverifikasi kemampuan aplikasi Anda untuk mentolerir gangguan yang realistis. Namun, proses ini mengasumsikan tingkat stabilitas dan kesehatan yang mendasari dalam aplikasi target. Menjalankan eksperimen chaos pada aplikasi yang sudah bermasalah berisiko menutupi masalah yang lebih dalam.

Sebelum melakukan rekayasa kekacauan, tim harus menyelesaikan cacat, bug, dan masalah kinerja yang diketahui dalam aplikasi mereka.

Tentukan hipotesis dan eksperimen

Insiden masa lalu yang telah menyebabkan gangguan pada aplikasi Anda atau aplikasi lain dalam organisasi Anda dapat berfungsi sebagai sumber yang sangat baik untuk ide eksperimen kekacauan. Misalnya, apakah pemadaman sebelumnya dipicu oleh kesalahan konfigurasi atau pola ketahanan yang hilang? Meninjau sejarah insiden dan memutar ulang akar penyebab kegagalan dunia nyata melalui eksperimen kekacauan adalah cara yang efektif untuk mengembangkan ketahanan terhadap masalah serupa di masa depan.

Sumber konsep eksperimen lain yang berharga dapat datang langsung dari para insinyur, arsitek, dan operator yang paling akrab dengan aplikasi. Memungkinkan anggota tim untuk mengirimkan skenario kegagalan hipotetis yang mereka yakini dapat mengganggu aplikasi secara signifikan memungkinkan Anda mengumpulkan ide berdasarkan pengetahuan orang dalam. Tim aplikasi kemudian dapat mengevaluasi skenario mana yang diusulkan ini yang mungkin memiliki dampak potensial terbesar atau mengekspos risiko terbesar yang tidak diketahui. Menargetkan eksperimen chaos untuk skenario berisiko tinggi dan kurang dipahami dapat menghasilkan pembelajaran penting dan mencegah masalah di masa depan.

Sumber ide ketiga berasal dari melakukan pemodelan ketahanan untuk mengantisipasi kondisi yang akan menyebabkan kerugian bisnis yang teridentifikasi. Beberapa latihan pemodelan ketahanan memiliki pendekatan berbasis komponen untuk membangun model ketahanan sedangkan yang lain memiliki pendekatan berbasis sistem. Pendekatan berbasis komponen mengajukan pertanyaan, “Apa yang terjadi ketika komponen x berada di bawah beban ekstrim atau gagal?” Tim yang mengembangkan model ketahanan kemudian berspekulasi efek skenario seperti itu pada aplikasi yang lebih luas, dan mengidentifikasi pemantauan dan kontrol pencegahan yang saat ini ada untuk mendeteksi dan mengurangi efek skenario. Atau, pendekatan berbasis sistem mengikuti proses top-down untuk menyoroti keadaan aplikasi yang tidak diinginkan — seperti, “Etalase web menunjukkan tingkat inventaris basi” — dan mengundang tim aplikasi untuk mengantisipasi kondisi atau kondisi mana yang akan menyebabkan aplikasi berperilaku seperti ini.

Memastikan kesiapan operasional untuk percobaan

Anda memerlukan indikator yang dapat diukur untuk mengukur dampak kondisi buruk pada aplikasi dan perilakunya, seperti yang dijelaskan sebelumnya di bagian observabilitas. Mampu mengukur perilaku aplikasi memungkinkan Anda untuk menentukan apakah kondisi buruk memengaruhi aplikasi dan berapa besarnya.

Cara terbaik untuk memahami apakah ada dampak pada aplikasi Anda adalah dengan mengukur kondisi tunaknya. Steady state mengukur seperti apa operasi normal dan biasanya selaras dengan indikator pengalaman bisnis dan klien untuk aplikasi tertentu. Sebelum Anda melanjutkan ke langkah berikutnya, pastikan Anda memiliki observabilitas untuk memahami dampak, dan mekanisme rollback siap jika eksperimen tidak berjalan seperti yang diharapkan.

Jalankan eksperimen dan skenario terkontrol

Di AWS, kami tidak menyarankan melakukan eksperimen kekacauan awal pada aplikasi yang sedang diproduksi. Tujuan dari eksperimen chaos adalah untuk mempelajari sesuatu yang baru tentang bagaimana aplikasi berperilaku dalam kondisi stres. Perilaku aplikasi mungkin tidak dapat diprediksi selama percobaan, jadi melakukan eksperimen untuk pertama kalinya dalam produksi dapat memiliki konsekuensi yang berdampak pada pelanggan. Oleh karena itu, Anda harus selalu menjalankan eksperimen chaos awal di lingkungan tingkat rendah yang memiliki potensi minimal untuk memengaruhi pengguna dunia nyata, dan kemudian mengulangi lingkungan Anda setelah Anda memverifikasi dan yakin bahwa aplikasi Anda dapat menyerap, beradaptasi, dan memulihkan dari tindakan yang disuntikkan..

Rencanakan setiap percobaan secara menyeluruh dengan menggunakan dokumen yang menangkap detail kunci, mirip dengan dokumen perencanaan eksperimen yang disediakan dalam lampiran. Beberapa bidang penting untuk dimasukkan adalah definisi keadaan tunak, hipotesis, dan metode injeksi kegagalan. Perencanaan, pelaksanaan, dan analisis eksperimen chaos dapat dicakup dalam satu artefak.

Setelah Anda menyelesaikan rencana tertulis untuk percobaan, siapkan kode yang diperlukan untuk menyuntikkan gangguan yang direncanakan yang diuraikan dalam dokumen.

Untuk menangkap dampak potensial selama percobaan, pastikan bahwa mekanisme observabilitas sudah ada. Jika Anda belum memiliki cara otomatis untuk menangkap hasil eksperimen, seperti laporan AWS FIS eksperimen, identifikasi anggota tim yang akan membuat catatan selama eksekusi, menangkap tangkapan layar dasbor, dan memimpin tim melalui eksperimen.

Belajar dan menyempurnakan

Setelah setiap percobaan, berkumpul sebagai tim untuk meninjau dan merenungkan eksperimen kekacauan. Lakukan upaya sadar untuk mempertahankan pola pikir yang tidak bersalah. Tujuan Anda harus memiliki dialog terbuka dan konstruktif yang berfokus sepenuhnya pada memperoleh pembelajaran maksimal, bukan menyalahkan.

Mulailah dengan meninjau definisi kondisi tunak dan hipotesis untuk percobaan. Apakah aplikasi berperilaku seperti yang diharapkan? Apakah ada kejutan yang membatalkan asumsi? Diskusikan pengamatan tentang bagaimana aplikasi bereaksi selama percobaan, baik dan buruk. Data yang dikumpulkan―metrik, log, tangkapan layar, dan sebagainya—harus menceritakan kisah persis apa yang terjadi.

Dekati tinjauan data ini dengan rasa ingin tahu alih-alih penilaian, dan identifikasi area di mana perbaikan dapat dilakukan pada desain aplikasi, dokumentasi, pemantauan, atau kemampuan lain berdasarkan pembelajaran. Item tindakan ini ditangkap sebagai proyek tindak lanjut untuk membuat aplikasi lebih tangguh.

Melalui pendekatan tanpa cela ini, Anda dapat melakukan percakapan jujur tentang apa yang salah dan bagaimana Anda dapat memperbaikinya. Asumsikan niat positif dari semua orang yang terlibat, dan percayalah bahwa mereka bekerja menuju hasil yang baik. Tujuan bersama Anda adalah pertumbuhan dan kemajuan organisasi melalui pembelajaran dan adaptasi berkelanjutan. Ulasan eksperimen Chaos yang dilakukan secara konstruktif dan tidak bercela memberikan ruang yang aman bagi tim Anda untuk mendapatkan wawasan berharga yang membuat aplikasi dan organisasi Anda lebih andal dan tangguh dalam jangka panjang. Fokusnya tetap pada pembelajaran, bukan pada orang-orang. Untuk menyebarkan pembelajaran di seluruh tim Anda, publikasikan laporan hasil eksperimen di tempat sentral dan iklankan temuan sehingga orang lain dapat belajar darinya.