Chaos Engineering: Cara Tim Engineering Indonesia Uji Ketahanan Sistem Sebelum Insiden

TL;DR: Chaos engineering adalah disiplin menyuntikkan kegagalan terkontrol ke sistem produksi untuk memverifikasi ketahanan. Mulai dari hipotesis steady state, jalankan eksperimen dengan blast radius kecil, ukur hasil lewat observability yang sudah matang. Tim Indonesia bisa adopsi tanpa Netflix-scale dengan tooling sederhana di staging dulu, baru naik ke produksi.

Tahun lalu, sebuah klien e-commerce mengalami downtime 47 menit di tengah flash sale. Penyebabnya bukan trafik, tapi satu replika Redis yang gagal failover karena timeout konfigurasi salah. Yang menyakitkan, kondisi ini sebetulnya bisa ditemukan jauh sebelumnya, kalau tim sengaja menguji skenario "Redis primary mati" di lingkungan produksi yang aman.

Itulah inti chaos engineering. Bukan merusak sistem secara acak, tapi cara terstruktur menemukan kelemahan sebelum kegagalan nyata datang.

Kenapa Pengujian Tradisional Tidak Cukup

Unit test memverifikasi fungsi. Integration test memverifikasi alur. Load test memverifikasi kapasitas. Tapi tak satu pun dari pengujian ini menangkap mode kegagalan yang lahir dari interaksi antar microservices saat kondisi tidak ideal: dependency lambat, antrean penuh, partial network failure, atau cascading timeout. Sistem modern Indonesia, dari fintech sampai e-commerce, melayani trafik tinggi pada jam sibuk yang predictable. Yang tidak predictable adalah perilaku sistem saat satu komponen pelan-pelan rusak. Praktik observability tanpa eksperimen aktif hanya memberi visibility setelah masalah terjadi.

Berdasarkan praktik tim engineering yang menerapkan SRE di berbagai client, sekitar 60-70% insiden produksi datang dari mode kegagalan yang tidak pernah diuji. Chaos engineering menutup celah ini.

Empat Prinsip yang Harus Dipegang

Mulai dari Mana untuk Tim Indonesia

Sebagian besar tim engineering Indonesia tidak punya skala Netflix dan tidak butuh skala itu. Adopsi praktis bisa dilakukan bertahap.

Tahap 1: Staging-only experiments. Pakai tool sederhana untuk simulasi gangguan di staging. Kill container, tambah delay artifisial 200 ms, putus koneksi ke satu service. Ukur dampak ke metrik bisnis yang dipantau lewat Lighthouse CI atau dashboard internal. Tahap ini tidak butuh izin khusus dan melatih tim merumuskan hipotesis.

Tahap 2: GameDay terjadwal. Sebulan sekali, tim sengaja menjadwalkan latihan respons insiden. Salah satu engineer "menyebabkan" kegagalan terdokumentasi (misal mematikan satu pod), sisa tim merespons sesuai runbook. Tujuan: mengukur waktu deteksi dan waktu recovery, bukan menyalahkan.

Tahap 3: Production experiments dengan blast radius kecil. Eksperimen di produksi terjadwal, di luar jam sibuk, dengan rollback otomatis. Pakai feature flags untuk membatasi siapa yang terkena. Kombinasikan dengan circuit breaker supaya cascading failure tertahan.

Studi Kasus: Validasi Failover Redis di Atmo

Saat membangun infrastruktur Atmo (LMS klien), tim menjalankan eksperimen sederhana: matikan Redis primary di jam non-puncak, ukur berapa lama failover ke replica dan berapa banyak request gagal. Hipotesis awal: failover di bawah 30 detik, error rate di bawah 1%. Hasil aktual: failover 2 menit 18 detik, error rate spike ke 14%. Penyebab: timeout client ternyata lebih pendek dari interval health check sentinel. Perbaikan dilakukan sebelum sistem masuk fase trafik tinggi. Eksperimen seperti ini biaya kecil, manfaat besar.

Tools yang Sering Dipakai

Tim Indonesia tidak harus pakai Chaos Monkey ala Netflix. Beberapa pilihan praktis:

• Toxiproxy. Proxy ringan untuk inject latency, slow connection, dan partition.
• Litmus atau Chaos Mesh. Untuk Kubernetes, eksperimen pod kill, network delay, IO chaos.
• Manual scripting. Bash + kubectl + curl. Cukup untuk tim awal yang masih membangun disiplin.

Pilihan tool kurang penting dibanding disiplin merumuskan hipotesis dan mengukur hasil. Dokumentasi resmi Google SRE Workbook dan Principles of Chaos Engineering jadi rujukan utama.

Pertanyaan Umum

Apakah chaos engineering aman untuk tim kecil?

Aman jika dimulai dari staging dan eksperimen kecil. Yang berbahaya bukan praktik itu sendiri, tapi mengabaikan ketahanan sampai insiden besar terjadi.

Berapa lama sampai melihat hasil?

Manfaat awal terlihat dalam 1-2 bulan: tim mulai menemukan dan memperbaiki konfigurasi salah, monitoring yang silent, dan runbook usang. Manfaat jangka panjang: penurunan MTTR insiden produksi 30-50% dalam 6-12 bulan, berdasarkan pengalaman tim engineering yang konsisten menjalankan disiplin ini.

Apakah harus pakai tool mahal?

Tidak. Eksperimen pertama bisa dijalankan dengan script bash 50 baris. Investasi tool baru worth it setelah disiplin praktik tertanam, biasanya setelah 6 bulan rutin GameDay.

Bagaimana mengukur keberhasilan eksperimen?

Pakai metrik bisnis steady state, bukan metrik infra. Misal: latensi p95 checkout tetap di bawah 1 detik selama eksperimen, error rate di bawah 0,5%, conversion tidak turun lebih dari 2%.

Penutup

Chaos engineering bukan tentang membuat sistem gagal. Justru sebaliknya, ini cara paling jujur mengukur seberapa siap sistem Anda menghadapi kegagalan yang pasti datang. Mulai dari hipotesis kecil di staging, naikkan blast radius perlahan, dan biarkan data eksperimen memandu perbaikan arsitektur. Trafik puncak akan menemukan setiap kelemahan tersembunyi pada waktunya, lebih baik Anda yang menemukannya lebih dulu.