Belajar DevOps Engineer - Performance & Reliability

#Pendahuluan

Sistem yang bisa berjalan bukan berarti sistem yang andal. Berapa banyak pengguna yang bisa ditangani? Apa yang terjadi saat traffic melonjak lima kali lipat? Kapan sebuah deployment perlu dibatalkan? Jawaban pertanyaan ini tidak bisa ditebak dari dashboard — ia ditemukan dengan pengujian dan target yang terukur.

Episode 25 menggabungkan tiga disiplin yang menjadi jantung praktik SRE: load testing untuk membuktikan kapasitas, SLO dan error budget untuk mendefinisikan keandalan secara matematis, dan chaos engineering untuk menemukan kegagalan sebelum pengguna yang menemukannya. Di akhir episode, kalian menguji sistem nyata dan memperbaikinya berdasarkan data.

#Load Testing dengan k6

k6 adalah tool load testing modern berbasis JavaScript — ringan, bisa dijadikan kode, dan terintegrasi dengan CI. Skrip test meniru perilaku pengguna nyata:

import http from "k6/http"
import { check, sleep } from "k6"
 
export const options = {
  stages: [
    { duration: "2m", target: 20 },   // naik ke 20 pengguna
    { duration: "5m", target: 50 },   // tahan di 50 pengguna
    { duration: "2m", target: 0 },    // turun pelan-pelan
  ],
  thresholds: {
    http_req_duration: ["p(95) < 500"],   // 95% request di bawah 500ms
    http_req_failed: ["rate < 0.01"],     // error maksimal 1%
  },
}
 
export default function () {
  const res = http.get("https://app.example.com/api/users")
  check(res, { "status 200": (r) => r.status === 200 })
  sleep(1)
}

k6 run load-test.js
k6 run --out=cloud load-test.js

Perhatikan bagian thresholds: load test bukan sekadar "menembak sebanyak mungkin", tetapi menguji terhadap target. Jika p(95) melebihi 500ms, test gagal — dan kegagalan itu adalah data untuk perbaikan.

#SLO dan Error Budget

SLO (Service Level Objective) adalah target keandalan yang disepakati, dinyatakan secara matematis. Bentuk paling umum: persentase ketersediaan dalam periode tertentu.

Error budget adalah toleransi kegagalan yang disepakati — kebalikan dari SLO:

SLO 99.9% / bulan   → error budget = 0.1% waktu = ±43 menit downtime/bulan
SLO 99.95% / bulan  → error budget = 0.05% waktu = ±22 menit downtime/bulan

Logika error budget mengubah cara tim mengambil keputusan:

• Budget masih tersisa → rilis boleh berjalan, eksperimen boleh dijalankan.
• Budget hampir habis → rilis berisiko dihentikan; fokus kembali ke keandalan.

Ini menghapus perdebatan subjektif "berapa lama downtime masih oke?" — jawabannya ada di angka, disepakati bersama bisnis:

apiVersion: monitoring.googleapis.com/v1
kind: Slo
metadata:
  name: app-availability
spec:
  service: myapp
  goal: 99.9
  serviceLevelIndicator:
    ratio:
      good_total_ratio:
        good_service_filter: 'status_code: 200'
        total_service_filter: 'service: myapp'

SLO diukur terus-menerus; jika meleset, inilah alarm yang paling layak dibunyikan — lebih penting dari alert per-instan.

#Chaos Engineering Dasar

Chaos engineering adalah disiplin menguji sistem dengan membuat kegagalan yang disengaja, secara terkendali, untuk menemukan kelemahan. Prinsip Netflix yang asli: "jangan menunggu pengguna menemukan kegagalan kalian".

Dasar-dasar yang aman untuk pemula:

1. Mulai dari lingkungan staging — cluster non-produksi yang meniru produksi.
2. Pilih satu hipotesis — "jika satu node mati, aplikasi tetap tersedia tanpa intervensi manual".
3. Buat gangguan terkecil — matikan satu Pod, satu node, atau perkenalkan latensi, bukan menghancurkan semuanya.
4. Amati dan ukur — apakah SLO tetap terjaga? Bagaimana waktu pemulihan?
5. Perbaiki dan lakukan lagi — setiap temuan menjadi backlog perbaikan.

# Hipotesis: hapus satu replica, app tetap melayani request
kubectl scale deploy/myapp --replicas=2
kubectl delete pod myapp-<id> --wait=false
# Ukur: apakah SLO 99.9% terjaga selama 10 menit?
# Temuan umum: client tanpa retry gagal saat node mati

Tools: LitmusChaos dan Chaos Mesh menyediakan eksperimen terkelola (pod kill, network delay, stress CPU) langsung di Kubernetes. Mulai dari gangguan terkecil dan otomasikan secara bertahap.

#Praktik: Load Test + Improve

Alur lengkap yang bisa kalian jalankan hari ini:

1. Definisikan target — tulis SLO (99.9%) dan target latensi (p(95) < 500ms).
2. Load test di staging — jalankan skenario normal; catat hasil.
3. Identifikasi bottleneck — dari output k6: di mana latensi menumpuk? (bisa DB, bisa kode, bisa konfigurasi).
4. Perbaiki satu hal — misal: tambah replica, aktifkan caching, optimasi query.
5. Uji ulang — bandingkan sebelum/sesudah; hanya perbaikan yang terbukti dipertahankan.
6. Pasang SLO monitoring — kelola error budget sebagai rutinitas (episode 11 untuk dashboards).

# Sebelum: p(95)=820ms, error rate 2.3%
# Sesudah (add 2 replica + cache header): p(95)=340ms, error rate 0.2%

#Pitfall Umum

• Load test tanpa target — menembak tanpa SLO tidak menghasilkan keputusan, hanya angka.
• Hasil staging yang tidak mewakili produksi — test di environment yang lebih kecil dengan DB yang sama; kalau tidak, hasilnya menyesatkan.
• SLO yang tidak dipakai untuk keputusan — error budget yang tidak menghentikan rilis hanyalah poster.
• Chaos di produksi tanpa persiapan — mulai di staging; chaos production hanya untuk tim yang sudah matang.
• Mengukur keandalan dari uptime saja — SLO juga mengukur latensi dan error; uptime tanpa kualitas menipu.

#Penutup

Inti yang harus dibawa pulang:

• k6 menguji kapasitas terhadap target yang jelas (latensi, error rate).
• SLO + error budget mengubah keandalan dari opini menjadi angka yang menggerakkan keputusan.
• Chaos engineering menemukan kelemahan secara sengaja dan terkendali — mulai dari yang terkecil.
• Pola kerjanya: definisikan target → uji → perbaiki → ukur lagi.

Di episode 26 selanjutnya kita membahas Ekosistem & Tren Modern 2026 — platform engineering sebagai default, GitOps yang umum, AI-assisted ops, DevSecOps embedded, dan multi-cloud/K8s di mana-mana, semua diukur dengan DORA metrics. Semua yang kalian pelajari dari episode 0 sampai 25 akhirnya membentuk gambaran besar.