Gambaran umum

Membandingkan pengujian ketahanan dengan rekayasa kekacauan

Pengujian ketahanan bersifat deterministik. Artinya, ini memvalidasi karakteristik yang diketahui tentang mekanisme ketahanan, seperti pemutus sirkuit, percobaan ulang, kegagalan atau fallback, yang telah diterapkan dalam aplikasi Anda. Ini menegaskan bagaimana komponen aplikasi ini menyerap gangguan terkontrol dengan dampak minimal atau tanpa pengguna. Oleh karena itu, pengujian ketahanan berfokus pada validasi mode kegagalan yang diketahui yang disuntikkan ke dalam komponen aplikasi dengan tujuan menghasilkan hasil. pass/fail Anda harus menjalankan pengujian ketahanan terus menerus sebagai langkah dalam jalur Anda untuk memastikan bahwa Anda tidak memperkenalkan regresi pada postur ketahanan Anda. Dalam pengujian ketahanan, Anda sering tidak menjalankan pengujian terhadap komponen nyata, tetapi tiruan APIs yang mensimulasikan komponen tertentu. Pendekatan ini memungkinkan pengujian skenario kegagalan yang konsisten dan dapat direproduksi dalam lingkungan yang terkendali, sehingga cocok untuk integrasi pipa otomatis dan pengujian regresi.

Sebaliknya, rekayasa kekacauan bersifat non-deterministik. Artinya, ini berbasis hipotesis dan memverifikasi model mental Anda tentang bagaimana aplikasi dan ketergantungannya (orang, proses, dan teknologi) menyerap, beradaptasi, dan akhirnya pulih dari mode kegagalan yang tidak terduga. Oleh karena itu, rekayasa kekacauan berfokus pada end-to-end verifikasi mode kegagalan yang tidak diketahui, dengan tujuan menangkap cacat lebih awal, dan memperbaikinya sebelum berubah menjadi peristiwa skala besar. Rekayasa kekacauan mendorong pembelajaran berkelanjutan dan harus dipraktikkan melalui pipeline chaos terpisah atau eksperimen ad-hoc yang memungkinkan Anda menjalankan beberapa eksperimen kapan saja tanpa menghalangi produktivitas pengembang Anda dalam menerapkan kode.

Proses rekayasa kekacauan sering dimulai dengan hari permainan chaos, yang merupakan acara khusus di mana tim sengaja menyuntikkan kesalahan atau kegagalan yang dikendalikan ke dalam aplikasi mereka. Hari permainan progresif: Dimulai di lingkungan tingkat yang lebih rendah (seperti pengembangan atau pengujian) dan secara bertahap maju ke lingkungan tingkat yang lebih tinggi (seperti pementasan dan pra-produksi) saat kepercayaan meningkat. Dengan bergerak secara sistematis melalui lingkungan ini, tim dapat memverifikasi bahwa sistem mereka mentolerir kesalahan yang disuntikkan dengan benar sebelum mereka mencapai produksi. Perkembangan metodis ini memastikan bahwa pada saat eksperimen chaos dilakukan di lingkungan produksi, tim telah membangun kepercayaan besar pada kemampuan ketahanan sistem mereka. Proses hari permainan adalah pendekatan proaktif untuk mengidentifikasi kelemahan dan kerentanan dalam arsitektur aplikasi dan praktik operasional, sambil menghilangkan stres belajar selama pemadaman produksi yang tidak terduga.

Nilai rekayasa kekacauan

Sistem yang kompleks ada di mana-mana di dunia saat ini. Mereka memainkan peran penting dalam banyak aspek kehidupan kita, dari pasar keuangan hingga perawatan kesehatan. Kami berharap sistem ini selalu beroperasi. Namun, sistem yang kompleks seringkali rentan terhadap peristiwa dan perilaku tak terduga yang dapat memiliki konsekuensi signifikan. Organizations perlu merencanakan gangguan daripada bertanya-tanya apakah itu akan terjadi. Mereka dapat melakukannya dengan menerapkan pengujian skenario di seluruh layanan bisnis kritis atau mission-critical mereka. Di sinilah chaos engineering ikut bermain.

Chaos engineering menawarkan pendekatan untuk mengelola sistem kompleks yang dapat membantu mengurangi risiko dan meningkatkan ketahanan. Proses mempersiapkan eksperimen chaos membutuhkan tim untuk mengembangkan hipotesis tentang perilaku sistem mereka, yang memperdalam pemahaman mereka tentang bagaimana sistem dibangun dan bagaimana mereka beroperasi. Persiapan ini sering mengungkapkan kesenjangan mental, wawasan arsitektur, dan pengetahuan operasional yang mungkin tetap belum ditemukan. Dengan memajukan pemahaman tentang bagaimana sistem yang kompleks bereaksi terhadap kegagalan, chaos engineering mempromosikan transparansi dan akuntabilitas yang lebih besar dalam desain dan manajemen sistem. Semakin sering organisasi Anda mempraktikkan rekayasa kekacauan, semakin siap mereka secara operasional. Chaos engineering membantu Anda menetapkan praktik terbaik untuk merancang aplikasi tangguh yang dapat bertahan dari kegagalan komponen dengan dampak minimal atau tanpa pengguna. Ini memastikan bahwa aplikasi penting beroperasi dalam tingkat layanan yang diharapkan dan toleransi dampak, sambil terus meningkatkan pengetahuan tim tentang sistem mereka sendiri.

Mempersiapkan kondisi buruk

Saat membangun AWS, Anda menggunakan berbagai jenis layanan, termasuk layanan zona seperti Amazon Elastic Compute Cloud (Amazon EC2), layanan Regional seperti Amazon Simple Storage Service (Amazon S3), layanan global seperti (IAM), layanan perangkat lunak AWS Identity and Access Management pihak ketiga sebagai layanan (SaaS), dan layanan lokal. Setiap jenis layanan memperlihatkan domain kegagalan berbeda yang perlu Anda perhitungkan. Bagaimana Anda mempersiapkan diri untuk peristiwa yang ditimbulkan sendiri, atau peristiwa yang disebabkan oleh pihak ketiga yang tidak dapat dikendalikan oleh organisasi Anda?

Untuk membantu memahami bagaimana aplikasi Anda dapat merespons kondisi buruk, Anda dapat menggunakan AWS Fault Injection Service (AWS FIS). AWS FIS adalah layanan yang dikelola sepenuhnya untuk menjalankan eksperimen injeksi kesalahan dengan cara yang terkontrol. Anda dapat menggunakan layanan ini untuk AWS menyuntikkan skenario yang disediakan seperti gangguan daya Availability Zone dan masalah konektivitas lintas wilayah, atau membuat eksperimen Anda sendiri dengan menyatukan berbagai macam tindakan kesalahan yang disediakan oleh layanan. AWS FIS memungkinkan tim Anda untuk terus berlatih dan mempelajari bagaimana aplikasi mereka akan bereaksi terhadap kesalahan umum dan memperbaiki cacat saat mereka mendeteksi mereka.

Mempraktikkan rekayasa kekacauan terkontrol

Prinsip-prinsip kunci dari eksperimen chaos terkontrol adalah:

Agar berhasil menskalakan rekayasa kekacauan, Anda harus menerapkan eksperimen chaos dengan cara yang terkendali. Saat Anda menggunakan AWS FIS, Anda dapat membuat kondisi berhenti dengan menggunakan CloudWatchalarm Amazon. Anda dapat memasukkan kondisi ini ke dalam templat eksperimen untuk memastikan bahwa eksperimen dihentikan jika di luar batas dan diputar kembali ke keadaan terakhir yang diketahui. AWS FIS juga menyediakan tuas pengaman. Saat Anda menggunakan tuas ini, AWS FIS hentikan dan putar kembali semua eksperimen yang sedang berjalan di akun di Wilayah AWS, termasuk eksperimen multi-akun, dan mencegah eksperimen baru dimulai. Ini mencegah injeksi kesalahan selama periode waktu tertentu, seperti jam perdagangan, acara penjualan, atau peluncuran produk, atau sebagai respons terhadap alarm kesehatan aplikasi. Tuas pengaman tetap aktif sampai dilepaskan secara manual.

Saat Anda melakukan eksperimen chaos, Anda harus menentukan pengamanan untuk mencegah efek samping yang tidak diinginkan di lingkungan, terutama jika ada kemungkinan eksperimen tersebut akan memengaruhi aplikasi yang sedang diproduksi. Saat Anda merencanakan eksperimen, antisipasi efek samping apa pun yang mungkin ditimbulkannya pada aplikasi lain di lingkungan. Misalnya, aplikasi lain dapat menerima pesan yang salah dari aplikasi yang merupakan bagian dari eksperimen, mengalami volume permintaan yang tinggi, atau menghadapi pertentangan sumber daya jika mereka berbagi infrastruktur. Dokumentasikan risiko ini dan atasi masalah yang diketahui atau tidak dapat diterima sebelum Anda menjalankan eksperimen.