Belajar Site Reliability Engineer - Chaos Engineering

#Pendahuluan

Ada kalanya insiden terjadi karena kegagalan yang tidak pernah dibayangkan: node mati berbarengan dengan DNS bermasalah, atau satu query berat menguras seluruh koneksi database. Sistem jarang gagal seperti yang kita antisipasi — ia gagal dengan cara yang tidak kita pikirkan sama sekali. Chaos engineering lahir untuk mengubah ketakutan itu menjadi pengetahuan: sengaja membuat sistem gagal, di lingkungan terkendali, sebelum ia gagal sendiri di lingkungan tak terkendali.

Ini bukan "sabotase iseng" atau "membiarkan semuanya meledak". Chaos engineering adalah eksperimen berdisiplin yang menguji hipotesis — "sistem kita masih melayani pengguna walau satu AZ mati" — dengan cara mengukurnya, bukan dengan percaya diri.

#Prinsip Chaos Engineering

Empat prinsip dari Principles of Chaos Engineering (principlesofchaos.org):

#1. Definisikan "Steady State"

Sebelum memecahkan sesuatu, tentukan dulu tanda sehatnya: metrik apa yang menunjukkan sistem berfungsi normal (latency, error rate, throughput). Ini adalah hipotesis yang akan diuji.

#2. Hipotesis: Steady State Bertahan

Rumuskan dugaan yang bisa diuji: "Saat 30% pod payment mati, error rate tetap di bawah 1% dan p95 tetap di bawah 300 ms." Bukan "mudah-mudahan tidak apa-apa" — tapi klaim spesifik yang bisa terbukti salah.

#3. Variasi Nyata

Eksperimen harus memakai kejadian nyata di sistem nyata: matikan process, tunda paket, habiskan disk, matikan zona. Skala dan cakupan diatur bertahap — bukan simulasi di kepala.

#4. Minimalkan Blast Radius

Mulai dari yang terkecil dan aman: satu pod, lalu beberapa, lalu layanan edge. Sistem produksi diuji dengan gradual roll-out — persis seperti canary, tetapi untuk kegagalan.

#Chaos vs Sabotase: Garis yang Tidak Boleh Dilanggar

Aturan non-negoisabel: setiap eksperimen punya tombol stop, dan dipantau oleh manusia yang berwenang menghentikannya. Jika steady state melanggar, eksperimen dihentikan dan perbaikan dimulai — bukan dilanjutkan "untuk melihat sejauh mana".

#Game Days: Chaos yang Terjadwal

Game day adalah versi terjadwal dan lintas-tim dari chaos experiment — gabungan incident drill (episode 7) dan chaos engineering:

1. Skenario ditentukan dan disetujui tim (misal: "kafka cluster loss dua broker").
2. Game master menjalankan eksperimen; participants merespons seperti insiden sungguhan.
3. Observer mencatat: apa yang diperkirakan akan terjadi vs kenyataan.
4. Debrief — ini bukan "siapa yang salah", tapi "di mana sistem gagal seperti yang diduga, dan di mana tidak".

Hasil game day yang baik berupa dua daftar: hal yang ternyata bertahan (pengetahuan berharga — jangan diotomasi ulang) dan celah yang baru terungkap (prioritas perbaikan).

#Tools: Chaos Mesh & Litmus

#Chaos Mesh

Chaos Mesh adalah proyek CNCF (incubating) yang berjalan di dalam Kubernetes. Ia menyuntik kegagalan pada pod, network, filesystem, dan time lewat CRD — tanpa mengubah kode aplikasi. Contoh yang sering dipakai:

Chaos Mesh: kill pod acak

apiVersion: chaos-mesh.org/v1alpha1
kind: PodChaos
metadata:
  name: pod-kill-demo
spec:
  action: pod-kill
  mode: one
  duration: "60s"
  selector:
    namespaces: ["default"]
    labelSelectors:
      app: demo

#Litmus

Litmus (CNCF graduated) mengambil pendekatan berbasis scenario: kalian mendefinisikan eksperimen sebagai workflow yang mencakup inject, observability, dan verification otomatis. Cocok untuk tim yang ingin integration dengan CI: eksperimen dijalankan sebagai bagian dari pipeline rilis.

Litmus: core experiment

apiVersion: litmuschaos.io/v1alpha1
kind: ChaosEngine
metadata:
  name: engine-demo
spec:
  appinfo:
    appns: default
    applabel: "app=demo"
  experiments:
    - name: pod-network-latency
      spec:
        components:
          env:
            - name: LATENCY
              value: "1000"
            - name: JITTER
              value: "200"

#Pilihan Praktis

• Chaos Mesh — untuk eksperimen ad-hoc dan exploration di cluster kalian sendiri.
• Litmus — untuk eksperimen sebagai gate pipeline yang berjalan otomatis di CI.
• Keduanya bisa: exploration bebas + gate otomatis untuk jalur kritis.

#Praktik: Simulasi Kegagalan Service

Untuk lab lokal tanpa Kubernetes, kita bisa mulai sederhana dengan Chaos Toolkit (sudah diinstall di episode 0). Eksperimen: matikan service demo dan amati apakah stack memulihkan diri.

{
  "title": "Demo service hilang, recovery sehat",
  "steady-state-hypothesis": {
    "title": "Service kembali sehat dalam 120 detik",
    "probes": [
      {
        "type": "probe",
        "tolerance": 1,
        "provider": {
          "type": "http",
          "url": "http://localhost:8080/health",
          "timeout": 120
        }
      }
    ]
  },
  "method": [
    {
      "name": "matikan container demo",
      "type": "action",
      "provider": {
        "type": "process",
        "path": "docker",
        "arguments": ["stop", "sre-lab-demo-1"]
      }
    }
  ]
}

Jalankan eksperimen dan lihat hasilnya:

chaos run experiment.json

[Steady State Hypothesis] PASSED: service sehat kembali < 120s
[method] container demo di-stop, healthcheck auto-restart memulihkan

#Penutup

Pada episode 13 ini, kalian telah belajar mendisiplinkan kekacauan.

Inti yang harus dibawa pulang:

• Chaos engineering = eksperimen berhipotesis, bukan sabotase: steady state → hipotesis → variasi nyata → blast radius terkendali.
• Selalu punya tombol stop dan observability yang memadai.
• Game day adalah cara menjadwalkan chaos secara lintas-tim dan belajar dari perbandingan ekspektasi vs kenyataan.
• Chaos Mesh untuk eksplorasi, Litmus untuk gate CI; Chaos Toolkit untuk lab sederhana.
• Mulai dari kegagalan kecil yang aman, lalu naikkan gradasi.

Di episode 14 selanjutnya, kita akan merangkai seluruh konfigurasi menjadi kode: reliability-as-code — SLO-as-code, alert-as-code, dan IaC untuk recovery, lengkap dengan praktik menyimpan SLO dan alert di git. Sampai jumpa di episode 14!