SLO dan Error Budget untuk Tim 3 Orang: Setup Pragmatis 2026

SLO dan error budget terdengar seperti sesuatu yang hanya masuk akal di Google atau Netflix dengan tim SRE puluhan orang. Di klien Jakarta yang tim backendnya cuma tiga orang, saya sempat berpikir demikian juga — sampai kami mengalami incident yang ketiga kalinya dalam sebulan dan masih berdebat apakah “ini serius atau tidak”. Saat itulah saya menyadari masalahnya bukan kurangnya monitoring, melainkan tidak adanya angka referensi yang disepakati bersama.

Kenapa Tim Kecil Justru Butuh SLO

Tanpa SLO, setiap keputusan reliability menjadi debat subjektif. “Kita harusnya deploy fitur baru ini hari Jumat tidak?” — tidak ada yang tahu jawabannya karena tidak ada baseline objektif tentang kondisi sistem saat ini. Error budget mengubah debat itu menjadi pertanyaan yang bisa dijawab dengan data: “Kita sudah pakai berapa persen budget bulan ini?”

Yang membuat SLO berguna untuk tim kecil bukan sofistikasi toolingnya, melainkan efek kulturalnya: tim punya bahasa yang sama untuk reliability. Satu angka — sisa error budget — menggantikan diskusi panjang tentang “apakah sistem sudah cukup stabil”.

Pilih SLI yang Tepat Dulu

Sebelum bicara tooling, putuskan apa yang Anda ukur. Terlalu banyak tim langsung loncat ke dashboard tanpa menyepakati SLI yang bermakna.

Untuk backend service yang melayani user request, ada tiga SLI yang hampir selalu relevan:

Availability — persentase request HTTP yang direspons dengan status non-5xx:

availability = (total_request - request_5xx) / total_request

Latency — persentase request yang selesai dalam batas waktu tertentu (misalnya 95% request selesai dalam 500ms):

latency_slo = request_selesai_dibawah_500ms / total_request

Error rate — lebih granular dari availability, bisa dipecah per endpoint atau per operasi bisnis kritis.

Untuk MVP dengan tiga engineer, saya sarankan mulai dari dua SLO saja: availability dan latency pada endpoint bisnis paling kritis (biasanya checkout, login, atau fungsi pembayaran). Jangan ukur semuanya sekaligus — noise-nya mengalahkan sinyal.

Setup Prometheus + Grafana untuk SLO

Asumsi: Anda sudah punya Prometheus dan Grafana. Kalau belum, setup paling cepat adalah stack Docker Compose berikut (dari artikel OpenTelemetry + Grafana di monolith):

# docker-compose.yml (hanya bagian relevan)
services:
  prometheus:
    image: prom/prometheus:v2.51.0
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
      - ./rules:/etc/prometheus/rules
    ports:
      - "9090:9090"

  grafana:
    image: grafana/grafana:10.4.0
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=admin
    ports:
      - "3001:3000"
    depends_on:
      - prometheus

Recording Rules untuk SLI

Jangan hitung SLI di dalam query Grafana secara langsung — lambat dan tidak konsisten. Pakai recording rules Prometheus agar kalkulasinya pre-computed dan bisa dipakai di mana-mana.

Buat file rules/slo_rules.yml:

groups:
  - name: slo_availability
    interval: 30s
    rules:
      # Total request per service (hanya endpoint bisnis kritis)
      - record: slo:http_requests:rate5m
        expr: |
          sum by (service, route) (
            rate(http_requests_total{route=~"/api/checkout|/api/auth/login|/api/payment"}[5m])
          )

      # Request error (5xx)
      - record: slo:http_errors:rate5m
        expr: |
          sum by (service, route) (
            rate(http_requests_total{status=~"5..", route=~"/api/checkout|/api/auth/login|/api/payment"}[5m])
          )

      # Availability per service per route (rolling 1 jam)
      - record: slo:availability:ratio_rate1h
        expr: |
          1 - (
            sum by (service, route) (rate(http_requests_total{status=~"5.."}[1h]))
            /
            sum by (service, route) (rate(http_requests_total{}[1h]))
          )

      # Latency SLI: persentase request < 500ms (rolling 1 jam)
      - record: slo:latency_fast:ratio_rate1h
        expr: |
          sum by (service, route) (
            rate(http_request_duration_seconds_bucket{le="0.5", route=~"/api/checkout|/api/auth/login|/api/payment"}[1h])
          )
          /
          sum by (service, route) (
            rate(http_request_duration_seconds_count{route=~"/api/checkout|/api/auth/login|/api/payment"}[1h])
          )

Pastikan prometheus.yml Anda me-load file rules ini:

rule_files:
  - "rules/slo_rules.yml"

Error Budget di Grafana

Di Grafana, buat panel dengan query berikut untuk menampilkan sisa error budget (dalam persentase dari budget 30 hari):

# Sisa error budget availability (SLO target: 99.5%)
(
  (1 - (
    sum(increase(http_requests_total{status=~"5..", service="payment-service"}[30d]))
    /
    sum(increase(http_requests_total{service="payment-service"}[30d]))
  )) - 0.995
) / (1 - 0.995) * 100

Nilai 100% berarti budget penuh (tidak ada error sama sekali). Nilai 0% berarti budget habis. Negatif berarti SLO dilanggar.

Burn Rate Alerting: Yang Lebih Penting dari Dashboard

Dashboard bagus untuk review mingguan, tapi untuk mendeteksi masalah real-time, Anda butuh alerting berbasis burn rate — bukan threshold error rate biasa.

Konsepnya: daripada alert “error rate > 5%”, alert saat “Anda akan menghabiskan seluruh error budget dalam X jam jika kondisi ini berlanjut”.

Tambahkan ke rules/slo_rules.yml:

  - name: slo_alerts
    rules:
      # Burn rate tinggi dalam 1 jam terakhir (menghabiskan budget 14x lebih cepat)
      # Artinya: budget 30 hari akan habis dalam ~2 hari
      - alert: SLOHighBurnRate
        expr: |
          (
            sum by (service) (rate(http_requests_total{status=~"5.."}[1h]))
            /
            sum by (service) (rate(http_requests_total{}[1h]))
          ) > (14 * (1 - 0.995))
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "SLO burn rate sangat tinggi di {{ $labels.service }}"
          description: "Error budget akan habis dalam ~2 hari jika tidak ada tindakan."

      # Burn rate medium (menghabiskan budget 6x lebih cepat)
      # Budget 30 hari habis dalam ~5 hari
      - alert: SLOMediumBurnRate
        expr: |
          (
            sum by (service) (rate(http_requests_total{status=~"5.."}[6h]))
            /
            sum by (service) (rate(http_requests_total{}[6h]))
          ) > (6 * (1 - 0.995))
        for: 30m
        labels:
          severity: warning
        annotations:
          summary: "SLO burn rate tinggi di {{ $labels.service }}"
          description: "Error budget akan habis dalam ~5 hari jika tidak ada tindakan."

Angka 14x dan 6x dari contoh Google SRE Workbook — cukup bagus sebagai titik awal.

Kebijakan Error Budget: Satu Halaman, Tiga Aturan

Tooling tanpa kebijakan tidak berguna. Satu halaman di Notion atau Confluence tim Anda cukup berisi tiga aturan:

1. Budget > 50%: Bisnis seperti biasa. Deployment baru boleh, eksperimen boleh, refactoring boleh.

2. Budget 10–50%: Hati-hati. Deployment fitur baru harus lewat review singkat. Fokus pada reliability fixes. Tidak ada eksperimen berisiko.

3. Budget < 10% (atau negatif): Freeze fitur. Hanya hotfix dan perbaikan reliability yang boleh masuk production. Semua sprint berikutnya diprioritaskan untuk membayar utang reliability.

Di klien Jakarta tadi, aturan ini mengubah culture debat menjadi proses mekanis. Kalau budget masih 60%, tidak ada yang perlu dipertanyakan soal deploy. Kalau budget 8%, tidak ada yang perlu berdebat soal harus freeze atau tidak.

Trade-off Jujur

Setup ini bukan tanpa ongkos. Tiga hal yang perlu Anda sadari:

Metrik harus sudah ada. Recording rules di atas tidak akan berguna kalau service Anda belum menginstrumentasi http_requests_total dengan label status dan route, dan http_request_duration_seconds sebagai histogram. Kalau belum, instrumentasi dulu — ini PR tersendiri.

SLO target awal seringkali salah. 99,5% terdengar masuk akal, tapi kalau ternyata sistem Anda memang sering 99,2%, error budget akan selalu negatif dan aturannya menjadi tidak bermakna (semua orang akan mengabaikannya). Pantau dua minggu pertama sebagai “observasi”, baru tetapkan target yang realistis berdasarkan data historis.

Window 30 hari lambat mendeteksi perbaikan. Kalau terjadi incident parah di awal bulan lalu sistem pulih sempurna, dashboard SLO masih akan merah untuk sisa bulan itu. Untuk feedback lebih cepat, tambahkan panel dengan window 7 hari di samping window 30 hari.

Kapan Tidak Perlu SLO

Kalau Anda sedang di tahap benar-benar awal — produk belum punya user aktif yang membayar, traffic masih di bawah ratusan request per hari — overhead menyepakati dan menjaga SLO lebih besar dari nilainya. Cukup punya Prometheus + alert sederhana untuk error rate dan uptime.

SLO mulai bermakna saat ada konsekuensi nyata dari downtime: pengguna yang membayar, kontrak yang bergantung pada availability, atau tim yang cukup besar sehingga koordinasi butuh mekanisme objektif.

Penutup

SLO dan error budget untuk tim kecil bukan tentang meniru Google. Ini tentang mengganti debat subjektif “sistem kita sudah cukup stabil belum?” dengan satu angka yang disepakati bersama. Setup Prometheus recording rules + dua alert burn rate + satu halaman kebijakan sudah cukup untuk tim tiga orang mendapatkan 80% manfaatnya.

Mulai dari dua SLO saja untuk endpoint paling kritis. Jalankan dua minggu pertama sebagai observasi murni — jangan langsung enforce kebijakannya. Setelah Anda punya data historis yang cukup untuk menetapkan target yang realistis, barulah kebijakan error budget mulai diaktifkan. Yang Anda dapatkan bukan sekadar dashboard yang bagus, tapi mekanisme keputusan yang mengurangi overhead koordinasi paling mahal di tim kecil: perdebatan tentang kapan boleh deploy.