Sistem yang tampak sehat saat semua komponen bekerja normal belum tentu mampu bertahan ketika jaringan melambat, layanan pihak ketiga gagal, atau satu node berhenti mendadak. Chaos engineering adalah pendekatan terstruktur untuk menguji asumsi tentang ketahanan sistem dengan memperkenalkan gangguan yang terkendali, lalu mengamati dampaknya. Tujuannya bukan membuat kekacauan demi sensasi, melainkan menemukan kelemahan sebelum insiden nyata mengungkapkannya kepada pengguna.
Prinsip utamanya adalah merumuskan hipotesis yang bisa diukur, membatasi risiko eksperimen, dan memakai hasilnya untuk memperbaiki sistem. Panduan Principles of Chaos Engineering menekankan pengamatan perilaku sistem dalam kondisi realistis, bukan sekadar memeriksa apakah sebuah proses masih berjalan.
Kapan chaos engineering berguna?
Pendekatan ini paling berguna pada sistem yang memiliki beberapa layanan, ketergantungan jaringan, antrean, replika data, atau mekanisme failover. Misalnya, aplikasi mungkin memiliki dua instance layanan, tetapi keduanya ternyata bergantung pada satu basis data tanpa kapasitas cadangan. Pengujian normal tidak selalu memperlihatkan titik kegagalan tunggal tersebut.
Chaos engineering juga membantu memvalidasi timeout, retry, circuit breaker, autoscaling, backup, dan prosedur pemulihan. Namun, teknik ini bukan pengganti pengujian unit, pengujian integrasi, pemindaian keamanan, atau uji beban. Ia menjawab pertanyaan berbeda: apakah sistem tetap memenuhi perilaku penting ketika komponen atau kondisi yang diandalkan mengalami gangguan?
Mulai dari hipotesis dan steady state
Sebelum menjalankan eksperimen, tentukan kondisi normal yang ingin dipertahankan atau steady state. Gunakan keluaran yang dirasakan pengguna, bukan hanya indikator internal. Contohnya, 99% permintaan harus selesai dalam waktu kurang dari 500 milidetik, tingkat error tetap di bawah 1%, dan transaksi yang sudah dikonfirmasi tidak boleh hilang.
Setelah itu, tulis hipotesis secara spesifik. Contoh: “Jika satu instance layanan katalog dihentikan, permintaan pengguna akan dialihkan ke instance lain dan tingkat error tidak melampaui ambang selama lima menit.” Hipotesis seperti ini bisa diuji dan dibuktikan salah. Pernyataan kabur seperti “sistem harus tetap andal” tidak memberi kriteria lulus atau gagal yang jelas.
Pilih eksperimen kecil terlebih dahulu
Gangguan tidak harus langsung dilakukan pada seluruh produksi. Mulailah di lingkungan staging yang menyerupai konfigurasi nyata, lalu naikkan cakupan hanya setelah kontrol keselamatan terbukti bekerja. Eksperimen awal dapat berupa menghentikan satu proses uji, menambah latensi pada koneksi nonkritis, menolak sebagian kecil permintaan, atau membuat dependensi tiruan mengembalikan error terencana.
Hindari menggabungkan banyak gangguan dalam satu percobaan awal. Jika jaringan, basis data, dan cache dibuat gagal sekaligus, penyebab hasil yang buruk akan sulit dipisahkan. Satu variabel utama per eksperimen membuat temuan lebih mudah direproduksi dan perbaikannya lebih terarah.
Batasi blast radius dan siapkan penghentian darurat
Blast radius adalah luas dampak jika eksperimen berjalan tidak sesuai rencana. Batasi dampak dengan memilih satu layanan, satu zona, satu kelompok pengguna internal, atau sebagian kecil trafik. Gunakan identitas eksperimen yang jelas, izin akses minimum, serta jendela pelaksanaan yang disepakati tim operasi.
Sebelum mulai, tetapkan kondisi penghentian otomatis maupun manual. Contohnya, hentikan eksperimen bila tingkat error melewati ambang, latensi meningkat tajam, antrean terus bertambah, atau metrik bisnis turun. Pastikan petugas dapat membatalkan perubahan dengan cepat dan jalur pemulihan telah diuji. Jangan melakukan eksperimen destruktif pada data produksi, sistem pembayaran, atau layanan kritis tanpa kontrol, persetujuan, dan rencana pemulihan yang memadai.
Amati metrik, log, dan trace
Eksperimen hanya berguna jika tim dapat melihat dampaknya. Pantau latensi persentil tinggi, tingkat error, throughput, saturasi CPU dan memori, panjang antrean, serta indikator bisnis yang relevan. Log membantu menjelaskan kejadian, sedangkan trace memperlihatkan bagaimana permintaan bergerak melewati beberapa layanan.
Jika instrumentasi belum memadai, perbaiki observabilitas sebelum memperluas eksperimen. Artikel OpenTelemetry: memahami logs, metrics, dan traces menjelaskan bagaimana sinyal tersebut membantu menemukan akar masalah. Untuk gangguan antarlayanan, periksa juga perilaku fallback dan circuit breaker, bukan hanya apakah proses masih aktif.
Alur eksperimen yang dapat diulang
- Tentukan tujuan: pilih satu risiko nyata dan tulis hipotesis serta metrik keberhasilan.
- Periksa kesiapan: pastikan dashboard, alert, akses pembatalan, dan prosedur pemulihan berfungsi.
- Mulai dengan cakupan kecil: gunakan staging atau sebagian kecil sistem yang disetujui.
- Perkenalkan satu gangguan: catat waktu, perubahan, dan durasi agar hasil dapat direproduksi.
- Bandingkan hasil: periksa metrik terhadap steady state dan catat perilaku yang menyimpang.
- Pulihkan dan tindak lanjuti: pastikan sistem kembali normal, buat tugas perbaikan, lalu ulangi eksperimen.
Simpan catatan tentang hipotesis, konfigurasi, waktu, hasil, dan keputusan tim. Temuan yang tidak menghasilkan tindak lanjut akan mudah terlupakan. Prioritaskan perbaikan berdasarkan risiko pengguna dan kemungkinan kejadian, bukan berdasarkan seberapa menarik eksperimennya.
Kesalahan yang perlu dihindari
Kesalahan umum adalah menganggap chaos engineering sebagai acara sekali jalan, menjalankan eksperimen tanpa pemilik yang bertanggung jawab, atau menilai keberhasilan hanya dari tidak adanya alarm. Tidak munculnya alarm dapat berarti sistem tangguh, tetapi bisa juga berarti pemantauan tidak lengkap. Uji pula apakah alarm yang relevan benar-benar terpicu dan diterima petugas yang tepat.
Jangan menyalin eksperimen perusahaan lain tanpa menyesuaikannya dengan arsitektur sendiri. Gangguan yang aman pada satu sistem dapat berbahaya pada sistem lain. Mulailah dari risiko yang dipahami, dokumentasikan batas keselamatan, dan libatkan tim yang menguasai layanan serta proses pemulihannya.
Kesimpulan
Chaos engineering membantu tim menguji ketahanan melalui eksperimen yang terukur, bukan dengan menunggu insiden terjadi. Mulailah dari hipotesis yang jelas, tentukan steady state, batasi blast radius, siapkan penghentian darurat, dan amati metrik yang mencerminkan pengalaman pengguna. Setiap eksperimen harus menghasilkan pembelajaran serta tindakan perbaikan. Dengan pendekatan bertahap dan disiplin, tim dapat menemukan kelemahan lebih awal tanpa mempertaruhkan stabilitas layanan secara tidak perlu.