Belajar Site Reliability Engineer - Error Budget & Trade-offs

#Pendahuluan

Setelah di episode 3 kita mendefinisikan SLI, SLO, dan SLA, kini saatnya memakai hasilnya untuk hal yang benar-benar mengubah cara kerja tim: error budget. Jika SLO adalah "berapa banyak kegagalan yang kita izinkan", maka error budget adalah cara menghabiskan izin itu secara sadar — dan menjadikannya dasar keputusan, bukan sekadar metrik di dashboard.

Inilah bagian SRE yang paling sering disalahpahami. Banyak tim membuat SLO lalu mengabaikannya sampai melanggar, dan merespons setiap pelanggaran dengan panik. Error budget yang sehat bekerja sebaliknya: ia adalah alat negosiasi dan kecepatan. Ketika budget tersisa, tim boleh bergerak cepat; ketika habis, semua sepakat berhenti dan fokus pada reliability.

#Menghitung Error Budget

Error budget didefinisikan sebagai 100% - SLO dalam periode pengukuran. Contoh perhitungan untuk berbagai SLO dalam 30 hari:

SLO	Error budget per bulan	Downtime yang "diizinkan"
99,0%	1,0%	± 7 jam 18 menit
99,9%	0,1%	± 43 menit
99,95%	0,05%	± 21 menit
99,99%	0,01%	± 4 menit

Perhatikan pola yang sering mengejutkan: naik dari 99,9% ke 99,99% bukan "10x lebih sulit" secara persepsi, melainkan error budget mengecil 10x — downtime izin turun dari 43 menit menjadi 4 menit per bulan. Trade-off ini harus menjadi diskusi bisnis, bukan keputusan teknik sepihak.

#Melacak Konsumsi Error Budget

Kita lanjutkan dari recording rule episode 3. Untuk mengubah konsumsi budget menjadi rasio tahunan (annualized burn) — cara yang direkomendasikan Google — gunakan query berikut:

Error budget yang terpakai (30d)

(1 - sum(rate(http_requests_total{code=~"2..|3.."}[30d]))
  / sum(rate(http_requests_total[30d])))
/ (1 - 0.999) * 100

Bila hasilnya mendekati atau melebihi 100%, budget habis dan SLO terancam. Pola praktiknya:

Multi-window burn rate: pakai dua jendela (misal 1 jam dan 6 jam) untuk membedakan "sedikit error lama" vs "ledakan error baru" — dasar desain alert SLO yang baik.
Review bulanan: grafik sisa budget di-review dalam meeting SRE; keputusan rilis dikaitkan langsung dengan angka ini.

#Error Budget sebagai Policy Rilis

Inilah bagian yang membedakan SRE dari monitoring biasa: error budget menghubungkan reliability dengan pengembangan. Ketika budget tersisa, tidak ada alasan teknis untuk menahan rilis. Ketika budget habis, rilis yang menambah risiko harus dihentikan sampai budget pulih — bukan karena "takut", melainkan karena kontrak yang disepakati.

100%

Gate rilis ini bisa diotomasi. Contoh: pipeline CI membaca error budget service target dan membatalkan deploy jika burn rate sedang tinggi:

Gate error budget dalam CI

BURN=$(curl -s "http://prometheus:9090/api/v1/query" \
  --data-urlencode 'query=burn_rate_slo_30d > 1.2' | jq '.data.result | length')
if [ "$BURN" -gt 0 ]; then
  echo "Error budget habis, deploy dibatalkan"
  exit 1
fi
echo "Budget aman, lanjut deploy"

Note

Gate rilis adalah mekanisme pengaman, bukan pengganti komunikasi. Tim yang matang juga membaca konteks: apakah error yang membakar budget berasal dari release terakhir (maka rollback lebih tepat daripada freeze) atau dari serangan luar (maka freeze rilis tidak menyelesaikan apa pun). Episode 11 akan membahas release reliability secara menyeluruh.

#Trade-off Velocity vs Reliability

Konflik klasik "tim produk mau rilis cepat, tim operasi mau stabil" adalah masalah desain, bukan masalah orang. Error budget menyelesaikannya dengan mengubah konflik menjadi matematika:

Velocity tinggi → risiko insiden naik → burn rate tinggi → budget cepat habis → rilis terhenti.
Reliability tinggi → burn rate rendah → budget mengalir → ruang rilis terus tersedia.

Tim yang sehat mengelola ini seperti anggaran pribadi: menabung (budget besar, rilis jarang berisiko) memberi ruang untuk pengeluaran (rilis berani). Memaksa keduanya sekaligus hanya membuat sistem tidak jujur — SLO diturunkan diam-diam, atau alert dimatikan.

#Keputusan Berbasis Budget yang Nyata

Skenario	Keputusan berbasis budget
Budget 40% tersisa, fitur baru punya risiko sedang	Rilis normal, pantau burn rate
Budget 5% tersisa, tapi fitur kecil dan mudah di-rollback	Rilis aman, siapkan rollback otomatis
Budget habis karena error massal pagi ini	Freeze rilis hari ini, lakukan postmortem dulu
Budget sering habis di hari yang sama tiap minggu	Bukan soal disiplin rilis — tanya dulu apakah SLO realistis

#Praktik: Kelola Error Budget Deployment

Langkah praktis untuk episode ini, memakai stack Prometheus yang sudah berjalan:

Buat recording rule multi-window burn rate (episode 3) untuk SLO service demo.
Dashboard Grafana: panel "Error Budget" dengan unit persen, threshold merah di 100%.
Script gate CI seperti contoh di atas — jalankan sebelum deploy, bukan setelah.
Definisikan policy (dalam repo, bukan di kepala): "Bila burn rate 30d ≥ 1, deploy feature baru ditunda sampai budget pulih ke 80%."

Warning

Jangan sekali-kali menghapus atau menurunkan SLO hanya karena pelanggaran berulang — tanpa menulis penjelasan dan persetujuan pemilik bisnis. Error budget yang "diakali" adalah kebohongan yang menyebar: alert mati, insiden membesar, dan kepercayaan tim runtuh. Kalau SLO memang salah, ubahlah secara transparan.

#Penutup

Pada episode 4 ini, kalian telah mengubah error budget dari konsep menjadi alat manajemen.

Inti yang harus dibawa pulang:

Error budget = 100% - SLO; kelola secara eksplisit seperti anggaran.
Pantau dengan burn rate multi-window (1 jam + 6 jam), bukan satu error.
Error budget adalah dasar policy rilis: habis berarti freeze, tersisa berarti ruang bergerak.
Trade-off velocity vs reliability diselesaikan dengan mekanisme, bukan perdebatan personal.
SLO tidak boleh diturunkan diam-diam — perubahan harus transparan.

Di episode 5 selanjutnya, kita masuk ke tulang punggung pengukuran: observability — tiga pilar metrics/logs/traces, peran OpenTelemetry, dan cara mengkorelasikan ketiganya untuk menjawab pertanyaan "apa yang terjadi?", "kenapa?", dan "di mana?". Sampai jumpa di episode 5!