Belajar Multigress - SLOs, Runbooks & Operational Readiness

#Pendahuluan

Gateway yang bekerja tanpa target yang jelas sulit dievaluasi. Episode 21 membahas SLOs, runbooks, dan operational readiness: mendefinisikan SLI untuk ingress dan routing, membuat runbook untuk menangani kegagalan serta perubahan route, dan membangun pola on-call yang sehat.

Semua metrik dari episode 7 dan 20 sekarang dirangkai menjadi janji layanan yang terukur dan dipahami seluruh tim.

#Mendefinisikan SLI untuk Ingress dan Routing

#Memilih SLI Availability dan Latency

SLI dimulai dari pertanyaan sederhana: bagaimana tim tahu layanan sedang baik atau buruk? Untuk gateway, jawabannya biasanya dua angka: availability dan latensi.

sum(rate(multigress_http_requests_total{status!~"5.."}[28d]))
/ sum(rate(multigress_http_requests_total[28d]))

Query di atas menghitung proporsi request yang tidak mengembalikan status 5xx selama 28 hari. status!~"5.." mengecualikan semua error server dari pembilang.

#Error Budget dan Target SLO

SLO menetapkan angka target untuk SLI, dan error budget adalah sisa yang bisa dikorbankan. Untuk SLO availability 99.9 persen per bulan, budget error hanya sekitar 43 menit. Pantau burn rate dengan alert sehingga tim tahu saat budget terkikis cepat.

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: multigress-slo
  namespace: monitoring
spec:
  groups:
    - name: gateway-slo
      rules:
        - alert: ErrorBudgetBurn
          expr: |
            (1 - (sum(rate(multigress_http_requests_total{status=~"5.."}[1h]))
              / sum(rate(multigress_http_requests_total[1h]))))
            < 0.99
          for: 15m
          labels:
            severity: page

Alert ErrorBudgetBurn menyala saat availability satu jam turun di bawah 99 persen selama 15 menit. Burn rate yang tinggi berarti budget bulanan terkikis cepat dan harus segera ditangani.

#Runbook untuk Kegagalan dan Perubahan Route

#Struktur Runbook

Runbook menghapus tebakan saat insiden. Struktur yang konsisten memudahkan siapa pun memakainya, bahkan di tengah malam:

• Ringkasan kondisi dan gejala yang terlihat.
• Langkah diagnosis untuk mengonfirmasi penyebab.
• Langkah mitigasi untuk memulihkan layanan.
• Prosedur rollback untuk mengembalikan konfigurasi.
• Postmortem untuk mencatat akar masalah.

#Contoh Runbook: Rate Limit Mendadak

Salah satu insiden umum adalah status 429 melonjak tiba-tiba. Runbook untuk kasus ini berisi dua langkah diagnosis singkat.

kubectl get backendtrafficpolicy -A
kubectl logs -n multigress-system -l app=multigress-gateway --tail=200

Perintah kubectl get backendtrafficpolicy -A memeriksa policy yang aktif, lalu log terakhir memberi petunjuk apakah 429 berasal dari rate limit atau dari aplikasi. Runbook menutup dengan langkah mitigasi: menaikkan rps sementara atau menambah replica.

#On-Call Pattern untuk Operasional Gateway

#Rotasi, Handover, dan Escalation

On-call yang sehat punya rotasi jelas dan handover tertulis. Sebelum shift berakhir, operator mencatat apa yang sedang berjalan, apa yang mencurigakan, dan apa yang harus dicek shift berikutnya.

#Alert Routing Berdasarkan Severity

Tidak semua alert perlu membangunkan orang. Pisahkan critical yang memanggil on-call dari warning yang cukup masuk channel chat.

routes:
  - matchers: ["severity=critical"]
    receiver: pagerduty-oncall
  - matchers: ["severity=warning"]
    receiver: slack-gateway

Matcher severity=critical mengarah ke PagerDuty, sedangkan severity=warning cukup ke Slack. Routing yang disiplin menjaga on-call tidak kelelahan oleh noise.

#Penutup

Episode 21 menjadikan operasional gateway bisa diukur dan dipelajari: SLI mendefinisikan kesehatan, SLO menetapkan target dengan error budget, runbook menyiapkan langkah insiden, dan on-call menjaga respons yang sehat.

Inti yang harus dibawa pulang:

• SLI adalah metrik; SLO adalah target yang disepakati.
• Error budget menetapkan batas waktu layanan boleh meleset.
• Alert burn rate memperingatkan budget yang terkikis cepat.
• Runbook mengubah insiden dari tebakan menjadi prosedur.
• On-call sehat butuh rotasi, handover, dan escalation yang jelas.
• Routing alert memisahkan yang memanggil orang dari yang sekadar mencatat.

Di episode 22 selanjutnya sebagai episode terakhir kita akan membahas production hardening & best practices — security hardening, traffic governance dan configuration hygiene, serta upgrade path dan compatibility check. Seluruh pelajaran series akan dirangkum menjadi checklist produksi.