Apa yang dimaksud dengan rekayasa kekacauan?

Setiap hari menciptakan peluang baru bagi aplikasi atau infrastruktur penting organisasi untuk gagal, yang berpotensi mengancam kemampuannya untuk memberikan layanan kepada pelanggan. Penyebab kegagalan dapat bervariasi di antara beberapa masalah, termasuk pelanggaran keamanan, kesalahan konfigurasi, atau gangguan layanan. Kemungkinan terjadinya kesalahan atau gangguan dapat meningkat dengan semakin banyaknya aplikasi dan data yang di-host di cloud, yang dapat meningkatkan masalah keamanan.

Salah satu cara untuk mengatasi gangguan adalah rekayasa kekacauan. Ini bukan proses acak ketika insinyur menghentikan instance atau layanan atau menyebabkan sistem gagal tanpa tujuan apa pun. Proses ini mengidentifikasi potensi masalah pada masa depan, memungkinkan tim teknik untuk menyelesaikan secara proaktif dan menghindarinya di lingkungan nyata di kemudian hari.

Rekayasa kekacauan ini penting karena kesalahan atau gangguan dapat memperlambat momentum organisasi, menghabiskan waktu yang berharga untuk mencari solusi dengan cepat saat waktu henti meningkat. Netflix mempelajari konsep ini secara langsung ketika beralih dari on-premise ke cloud¹ -mereka mengalami pemadaman yang menyebabkan gangguan tiga hari pada pengiriman layanan pada tahun 2008.

Pemutusan ini terjadi sebelum Netflix bertransformasi menjadi layanan streaming video, yang akan membuat pemutusan tersebut menjadi jauh lebih mahal. Sebagai hasilnya, Netflix memutuskan bahwa mereka akan melakukan segala cara untuk meminimalkan gangguan dan mulai memperkenalkan rekayasa kekacauan ke dalam alur kerjanya. Proses ini memungkinkan mereka untuk mengidentifikasi masalah sebelum terjadi dan meminimalkan kerusakan jika dan ketika terjadi kegagalan yang tidak dapat dihindari.

Netflix menciptakan chaos monkey², sebuah alat sumber terbuka yang menciptakan insiden acak dalam layanan dan infrastruktur TI yang dimaksudkan untuk mengidentifikasi kelemahan yang bisa diperbaiki atau diatasi melalui prosedur pemulihan otomatis. Solusi ini menerapkan chaos monkey saat pindah dari pusat data pribadi ke Amazon Web Services (AWS) sebagai tanggapan atas ketidakandalan dari cloud. Banyak organisasi sekarang menggunakan chaos monkey untuk menjalankan eksperimen rekayasa kekacauan mereka.

Rekayasa kekacauan merupakan pertahanan penting terhadap kegagalan infrastruktur, pemadaman listrik, atau komponen yang hilang dalam lingkungan produksi organisasi. Hal ini membantu teknisi keandalan lokasi (SRE) dan anggota tim DevOps lainnya untuk menyediakan layanan yang berkelanjutan dengan menghindari gangguan yang signifikan terhadap layanan mereka. Rekayasa kekacauan membantu mereka memahami kerentanan mereka dengan lebih baik, dan mengetahui cara meminimalkan dampak jika terjadi gangguan.

Bahkan masalah kecil dalam kode dapat berdampak besar pada lingkungan produksi secara keseluruhan karena ketergantungan program yang berbeda. Misalnya, kesalahan dalam sistem perangkat lunak transaksi untuk perusahaan jasa keuangan dapat mengakibatkan kerugian jutaan dolar.³ .

Organisasi mungkin tidak dapat menghindari semua insiden TI, namun mereka dapat meminimalkan kerusakan dengan menggunakan manajemen kekacauan untuk memahami skenario yang mungkin terjadi dan solusi terbaiknya.

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 aplikasi cloud-native. Cloud publik memperkenalkan potensi masalah pemutusan yang memerlukan koordinasi dengan penyedia cloud, yang menciptakan pendekatan berbeda daripada menangani masalah lokal.

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^5.

Selain itu, maraknya penggunaan layanan mikro, yang meningkatkan jumlah host atau kontainer yang berjalan dalam sebuah sistem, menciptakan tantangan unik 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 untuk meningkatkan kecepatan jalur integrasi berkelanjutan dan pengiriman berkelanjutan (CI/CD) mereka. Menggabungkan rekayasa kekacauan ke dalam CI/CD seperti yang dilakukan Netflix⁶ memungkinkan organisasi untuk mengotomatiskan eksperimen berkelanjutan sambil mengendalikan dampak potensialnya.

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.
• Pembuatan 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 dapat diskalakan.
• Pengujian Canary: Ini melibatkan peluncuran produk atau fitur baru ke sekelompok kecil pengguna. Dengan begitu, gangguan atau bug apa pun hanya akan mempengaruhi persentase pengunjung, meninggalkan audiens lainnya untuk 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 se dekat mungkin dengan apa yang mungkin 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 diotomatiskan 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. Solusi 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.

Rekayasa kekacauan memberikan beberapa manfaat utama bagi organisasi.

Pelanggan memiliki ekspektasi yang tinggi terhadap ketersediaan layanan yang mereka beli dari perusahaan. Setiap waktu henti atau ketidakmampuan untuk mengakses apa yang telah mereka bayar dapat berdampak serius pada kepuasan pelanggan, yang menyebabkan hilangnya pendapatan dan kerusakan reputasi. Menguji sistem dan mengidentifikasi solusi berarti mengurangi risiko bahwa sistem akan mati dalam jangka waktu yang lama.

Gangguan dapat berasal dari kode yang buruk, masalah server, atau ancaman eksternal. Yang terakhir ini dapat menyerang bahkan dengan praktik keamanan yang sangat baik. Rekayasa kekacauan membantu mengidentifikasi masalah yang dapat dieksploitasi, sehingga organisasi dapat memperkenalkan tambalan dan perbaikan bug untuk menjaga keamanan layanan mereka.

Rekayasa kekacauan memungkinkan organisasi untuk membuat cetak biru yang lebih tepat tentang bagaimana mereka mengatasi masalah yang akan terjadi di masa depan. Organisasi yang menganut rekayasa kekacauan akan memiliki rencana permainan khusus untuk banyak insiden, memungkinkan perbaikan lebih cepat dan lebih sedikit waktu henti. Rekayasa kekacauan dapat mengurangi waktu henti⁷ sebanyak 20%.

Eksperimen rekayasa kekacauan mengidentifikasi bagaimana suatu sistem mengalokasikan sumber daya. Memperkenalkan eksperimen akan menunjukkan bagaimana sistem menangani beban, menunjukkan di mana kemacetan atau kemungkinan akan terjadi.

Rekayasa kekacauan membantu tim membangun ketahanan dan fleksibilitas sistem yang lebih besar ke dalam perangkat lunak mereka. Oleh karena itu, organisasi dapat melakukan pendekatan pengkodean perangkat lunak dan solusi baru dengan lebih cerdas karena mereka tahu bagaimana sistem saat ini menangani masalah.