Chaos Engineering | Faisal Affan

Versi Bahasa Indonesia. Baca dalam Bahasa Inggris

Chaos engineering adalah praktik dengan sengaja memperkenalkan gangguan atau kegagalan terkendali ke dalam sistem untuk menguji ketahanan dan keandalannya. Tujuannya adalah mengidentifikasi kerentanan, memahami perilaku sistem dalam tekanan, dan membangun kepercayaan pada kemampuan sistem untuk bertahan dalam kondisi tak terduga.

Prinsip Utama

Bangun Hipotesis Seputar Steady State: Tentukan bagaimana perilaku "normal" sistem Anda, seperti response time, throughput, atau error rate.
Perkenalkan Kejadian Dunia Nyata: Simulasikan kegagalan seperti network latency, server crash, atau data center outage untuk meniru skenario dunia nyata.
Jalankan Eksperimen di Production atau Mendekati Production: Lakukan pengujian di lingkungan yang sangat mirip dengan production untuk memastikan temuan bersifat realistis.
Minimalkan Blast Radius: Mulai dari skala kecil dan batasi dampak eksperimen untuk menghindari gangguan yang meluas.
Ukur dan Pelajari: Analisis hasil eksperimen untuk mengidentifikasi kelemahan dan meningkatkan desain serta proses sistem.

Manfaat

Peningkatan keandalan dan fault tolerance sistem.
Pemahaman yang lebih baik tentang perilaku sistem.
Identifikasi dan resolusi kerentanan secara proaktif.

Tools untuk Chaos Engineering

Chaos Monkey: Dikembangkan oleh Netflix, secara acak menonaktifkan instance produksi untuk memastikan ketahanan sistem.
Gremlin: Tool komersial untuk menjalankan eksperimen chaos yang terkendali.
LitmusChaos: Tool open-source untuk chaos engineering di lingkungan Kubernetes.

Contoh Use Case

Industri Fintech

Di industri fintech, di mana keandalan, keamanan, dan pemrosesan real-time sangat penting, chaos engineering dapat membantu memastikan sistem tangguh terhadap kegagalan yang dapat mengganggu layanan, menyebabkan kerugian finansial, atau melanggar kepercayaan pelanggan. Berikut adalah contoh eksperimen chaos engineering yang relevan untuk fintech:

Kegagalan Payment Gateway

Skenario: Simulasikan ketidaktersediaan payment gateway pihak ketiga selama jam transaksi puncak.
Tujuan: Pastikan sistem dapat merutekan transaksi ke gateway alternatif dan memberikan penanganan error serta komunikasi yang tepat kepada pengguna.
Hasil: Identifikasi hambatan dalam mekanisme fallback dan uji sistem notifikasi pelanggan.

Contoh menggunakan gremlin:

# Menjatuhkan semua lalu lintas jaringan yang cocok.
gremlin attack new \
--type "blackhole" \
--target "host" \
--host "payment-gateway-url" \
--tags "env=production"

Latensi Database

Skenario: Perkenalkan latensi buatan pada query database, terutama selama pengecekan saldo atau pemrosesan transaksi.
Tujuan: Nilai kemampuan sistem untuk mempertahankan kinerja dalam kondisi terdegradasi dan mencegah kegagalan berantai.
Hasil: Optimalkan performa query, strategi caching, dan mekanisme retry.

API Rate-Limiting

Skenario: Simulasikan rate-limiting atau throttling pada API mitra, seperti untuk layanan credit scoring atau deteksi penipuan.
Tujuan: Uji seberapa baik sistem menangani batas rate API dan apakah sistem memprioritaskan transaksi kritis.
Hasil: Kembangkan strategi untuk sumber data cadangan atau caching preventif.
Tools: gremlin

Duplikasi Transaksi

Skenario: Suntikkan kegagalan yang menyebabkan transaksi diproses beberapa kali (misalnya, menagih pelanggan dua kali).
Tujuan: Uji mekanisme deteksi untuk transaksi duplikat dan pastikan rollback atau pengembalian dana tepat waktu.
Hasil: Tingkatkan proses rekonsiliasi dan protokol koreksi error.

Partisi Jaringan

Skenario: Simulasikan partisi jaringan antara microservices yang menangani manajemen akun pelanggan dan pemrosesan transaksi.
Tujuan: Verifikasi kemampuan sistem untuk beroperasi dalam keadaan terdegradasi tanpa kehilangan atau merusak data.
Hasil: Perkuat mekanisme konsistensi data dan proses pemulihan.

Kegagalan Dependency Layanan

Skenario: Nonaktifkan layanan kunci, seperti deteksi penipuan, konversi mata uang, atau verifikasi KYC.
Tujuan: Pastikan sistem dapat melanjutkan operasi parsial, seperti memproses transaksi yang tidak memerlukan layanan yang dinonaktifkan.
Hasil: Bangun strategi isolasi layanan dan failover yang kuat.

Simulasi Lalu Lintas Volume Tinggi

Skenario: Perkenalkan lonjakan aktivitas pengguna secara tiba-tiba, meniru Black Friday atau peluncuran produk finansial populer.
Tujuan: Uji skalabilitas, load balancer, dan fitur auto-scaling.
Hasil: Optimalkan arsitektur sistem untuk ketersediaan tinggi dan kinerja di bawah beban.

Contoh menggunakan k6 load testing:

import http from 'k6/http';
import { sleep } from 'k6';

export const options = {
  stages: [
    { duration: '1m', target: 1000 },
    { duration: '3m', target: 2000 },
    { duration: '1m', target: 0 },
  ],
};

export default function () {
  http.get('https://your-host/transactions');
  sleep(1);
}

Keterlambatan Penerbitan Kartu

Skenario: Suntikkan penundaan atau error pada sistem penerbitan kartu (misalnya, untuk kartu debit virtual).
Tujuan: Validasi komunikasi ke pengguna dan manajemen antrian untuk keterlambatan penerbitan kartu.
Hasil: Tingkatkan pengalaman pengguna selama penundaan operasional.

Contoh menggunakan gremlin:

# menambah latensi ke target container
gremlin attack new \
--type "latency" \
--target "container" \
--container-names "card-issuance-service" \
--delay 5000 \
--jitter 1000

Lonjakan Transaksi Penipuan

Skenario: Simulasikan lonjakan transaksi yang ditandai sebagai mencurigakan oleh sistem deteksi penipuan.
Tujuan: Uji kemampuan sistem untuk memproses transaksi asli sambil mengisolasi transaksi penipuan secara efisien.
Hasil: Identifikasi hambatan dalam pipeline deteksi penipuan dan tingkatkan mekanisme respons real-time.
Tools: k6

Pemadaman Sistem Audit Kepatuhan

Skenario: Simulasikan downtime pada sistem audit kepatuhan selama periode pelaporan.
Tujuan: Pastikan kemampuan untuk mengantrekan log audit dan menyinkronkan data setelah sistem pulih.
Hasil: Pertahankan standar kepatuhan bahkan selama pemadaman.