Organisasi dengan ketahanan yang tinggi, kematangan digital, dan observabilitas yang tinggi melalui dasbor dan alat lainnya harus mengadopsi rekayasa kekacauan, karena mereka dapat mengambil tindakan segera pada masalah yang terjadi melalui eksperimen. Organisasi yang tidak memiliki observabilitas ini⁴ (tautan berada di luar ibm.com) bisa memakan waktu terlalu lama untuk menyelesaikan eksperimen yang mereka buat melalui rekayasa kekacauan.

Rekayasa kekacauan juga harus dimiliki oleh organisasi yang menggunakan cloud, khususnya cloud publik, dan aplikasicloud-native. Cloud publik memperkenalkan potensi masalah pemadaman yang memerlukan koordinasi dengan penyedia cloud, yang menciptakan pendekatan berbeda daripada menangani masalah di lokasi. 

Perusahaan yang menggunakan cloud masih sering mendekati insiden TI tanpa mempertimbangkan bagaimana cloud dan software-as-a-service (SaaS) memengaruhi insiden tersebut secara berbeda, menurut Constellation Research⁵. (tautan berada di luar ibm.com) 

Selain itu, maraknya penggunaan layanan mikro, yang meningkatkan jumlah host atau kontainer yang berjalan dalam sebuah sistem, menciptakan tantangan unik (tautan berada di luar ibm.com) yang dapat digali dan dipecahkan melalui eksperimen kekacauan. Ini menggeser kompleksitas dari desain kode ke dalam operasi sistem, yang tidak menghilangkan kompleksitas, tetapi memungkinkan otomatisasi yang lebih besar.

Rekayasa kekacauan juga dapat membantu organisasi meningkatkan kecepatan integrasi berkelanjutan dan jalur pengiriman berkelanjutan (CI/CD). Memasukkan rekayasa kekacauan ke dalam CI/CD seperti yang dilakukan Netflix⁶ (tautan berada di luar ibm.com), memungkinkan organisasi untuk mengotomatiskan eksperimen berkelanjutan sambil mengendalikan potensi dampaknya. 

Terakhir, fakta bahwa organisasi semakin terhubung dengan mitra melalui API berarti masalah dalam sistem mereka dapat berdampak pada organisasi lain.

Penerapan rekayasa kekacauan membantu organisasi memahami titik lemah dalam arsitektur mereka dan memperbaikinya, pada akhirnya menciptakan kemampuan untuk mengantisipasi kegagalan di masa depan. Rekayasa kekacauan yang sukses dapat membantu organisasi untuk meminimalkan kegagalan teknis dengan dampak pelanggan yang signifikan dan juga mendukung pembangunan arsitektur sistem kompleks yang lebih kuat dan lebih tangguh. Setelah organisasi memutuskan untuk mengejar rekayasa kekacauan, langkah selanjutnya adalah menentukan apakah akan mengeksekusinya di lingkungan pra-produksi atau produksi.

Tim DevOps memiliki beberapa opsi untuk menjalankan eksperimen rekayasa kekacauan untuk menguji berbagai proses sistem.

• Injeksi latensi: Tim DevOps dengan sengaja membuat skenario yang meniru koneksi jaringan yang lambat atau gagal. Hal ini termasuk adanya penundaan jaringan atau waktu respons yang lebih lambat.
• Injeksi kesalahan: Ini melibatkan penyisipan kesalahan secara sengaja ke dalam sistem untuk menentukan bagaimana pengaruhnya terhadap sistem lain yang bergantung dan apakah kesalahan tersebut mengganggu layanan. Contoh injeksi kesalahan termasuk menyebabkan kegagalan disk, menghentikan proses, mematikan host, atau menyebabkan peningkatan daya atau suhu. Injeksi kesalahan dapat membantu organisasi mengidentifikasi satu titik kegagalan, yang dapat menyebabkan seluruh sistem gagal jika terjadi sesuatu pada titik tersebut.
• Pembangkitan beban: Ini berkaitan dengan sengaja membebani sistem dengan mengirimkan tingkat lalu lintas yang signifikan jauh melampaui operasi normal. Ini membantu insinyur keandalan situs (SRE) untuk memahami setiap hambatan dalam sistem, yang pada gilirannya memungkinkan mereka untuk membangun sistem yang lebih skalabel. 
• Pengujian Canary: Ini melibatkan peluncuran produk atau fitur baru ke sekelompok kecil pengguna. Dengan begitu, gangguan atau bug apa pun hanya akan memengaruhi sebagian pengunjung, sehingga audiens lainnya dapat mengakses pengalaman situs web yang ada.

Menciptakan proses rekayasa kekacauan yang ideal membutuhkan beberapa prinsip untuk memastikan sebuah organisasi dapat memiliki sistem terdistribusi dalam skala besar. 

• Memahami sistem: Hal ini melibatkan pengetahuan yang komprehensif tentang sistem secara keseluruhan, sifat dan fungsi yang muncul serta topologi, arsitektur, ketergantungan, perilaku kondisi tunak, respons keluaran, dan karakteristik seperti ketersediaan, latensi, dan keluaran.
  
• Menerima kegagalan: Tampaknya paradoks pada awalnya bagi insinyur perangkat lunak untuk membiarkan insiden terjadi ketika mereka terhubung untuk mencegah kejadian seperti itu. Namun, gangguan akan selalu terjadi dalam layanan TI dan lebih baik mengalaminya di lingkungan yang terkendali untuk mengidentifikasi solusi secara preventif daripada setelah jam kerja ketika tim organisasi tidak bekerja atau belum pernah mengalami masalah spesifik itu sebelumnya.
• Menetapkan perilaku kondisi tunak: Pertama, tim teknisi harus menentukan bagaimana sistem harus berperilaku ketika berjalan dengan benar, sehingga dapat membandingkan bagaimana eksperimen berdampak pada kondisi mantap tersebut.
• Mengidentifikasi kejadian di dunia nyata: Eksperimen rekayasa kekacauan harus dibuat sedekat mungkin dengan apa yang bisa terjadi pada hari biasa, bukan menciptakan situasi yang tidak mungkin terjadi. Kegagalan jaringan dan infrastruktur, kode yang buruk, masalah daya, dan kelebihan lalu lintas berpotensi terjadi.
• Ciptakan hari permainan: Rekayasa kekacauan dapat mempelajari lingkungan pada hari permainan, ketika beberapa tes dilakukan selama hari tertentu untuk memaksimalkan sumber daya untuk mengidentifikasi dan menyelesaikan sebanyak mungkin masalah. 
• Gunakan otomatisasi: Organisasi dari semua ukuran dapat menggunakan rekayasa kekacauan dengan mengotomatisasi eksperimen, yang akan terlalu padat karya jika perusahaan melakukannya secara manual. Ini mengurangi beberapa beban pada tim TI selama proses rekayasa kekacauan. Desain eksperimen, injeksi kegagalan, dan penyediaan infrastruktur adalah semua aspek eksperimen yang dapat diotomatisasi oleh organisasi
• Perhatikan radius ledakan: Seorang insinyur kekacauan harus berusaha keras untuk meminimalkan radius ledakan sehingga bahaya yang sebenarnya bagi pelanggan sekecil mungkin. Beberapa cara untuk meminimalkan radius ledakan adalah:
  • Targetkan sebagian layanan: Rekayasa kekacauan, terutama dalam lingkungan produksi, seharusnya tidak mengganggu layanan organisasi secara mendasar. Menargetkan subset layanan tertentu dapat meminimalkan dampak insiden jika terjadi, memastikan bahwa insiden tersebut tidak melumpuhkan seluruh sistem.
  • Jalankan eksperimen untuk waktu yang terbatas: Eksperimen harus memiliki awal dan akhir. Inti dari eksperimen ini adalah untuk membuat insiden dan menyelesaikannya versus membiarkannya berjalan tidak terkendali untuk waktu yang lama.
  • Jalankan eksperimen jauh dari lalu lintas puncak: Organisasi sebaiknya menghindari menjalankan eksperimen selama waktu puncak kecuali jika mereka secara khusus mencoba mengukur seberapa besar pengaruh kapasitas tinggi terhadap sistem selama insiden. 
  • Jalankan eksperimen di lingkungan pengembangan: Cara termudah untuk memastikan tidak ada pelanggan yang mengalami gangguan layanan adalah dengan menjalankannya di lingkungan praproduksi. Namun, hal ini berarti kondisinya akan berbeda dengan lingkungan produksi, sehingga berpotensi memberikan gambaran yang salah tentang apa yang sedang terjadi. Untuk meminimalkan hal ini, pastikan lingkungan praproduksi dan produksi Anda sebisa mungkin mencerminkan satu sama lain. 
  • Bereksperimenlah pada setiap komponen: Eksperimen kekacauan tidak pernah berakhir karena sistem organisasi terus berubah. Tujuannya juga harus menguji "segala sesuatu"; memeriksa semua komponen, lapisan, layanan - dan dependensinya di seluruh proses.

Organisasi yang menggunakan rekayasa kekacauan harus memutuskan apakah akan menggunakan pengujian chaos di lingkungan produksi atau pra-produksi. Ada beberapa alasan mengapa rekayasa kekacauan paling bermanfaat dalam lingkungan produksi. Lingkungan langsung menyediakan lingkungan yang paling akurat untuk memahami bagaimana sebuah insiden berdampak pada pengalaman pelanggan. Alasan lainnya yaitu, lingkungan pra-produksi mungkin tidak memiliki pengaturan yang sama persis dengan lingkungan langsung, sehingga menghadirkan sejumlah variabilitas pada eksperimen.

Misalnya, insiden di lingkungan pra-produksi mungkin tidak menciptakan respons yang realistis karena tidak memiliki tingkat lalu lintas yang sama dengan lingkungan langsung. Ini juga mungkin tidak memiliki konfigurasi keamanan yang sama dengan lingkungan itu. 

Beberapa organisasi takut menyebabkan masalah dengan situs live mereka, jadi mereka menjalankan eksperimen mereka di situs pra-produksi atau situs pengembangan. Hal ini memastikan bahwa masalah apa pun yang terjadi tidak berdampak pada pengalaman pelanggan secara langsung. Untuk mengurangi hal ini, beberapa organisasi memulai di lingkungan pra-produksi untuk memahami prosesnya sebelum beralih ke lingkungan produksi langsung.

Organisasi akan memilih lingkungan mana yang akan digunakan berdasarkan toleransi risiko mereka. Pada akhirnya, rekayasa kekacauan bertujuan untuk menguji masalah skala besar yang sebenarnya, sehingga lingkungan produksi akan memberikan gambaran paling akurat tentang apa yang terjadi dan apa yang perlu diperbaiki.