Digital Transformation
SLO Error Budget
Error budget adalah selisih antara target SLO dan reliabilitas 100% yang menjadi kuota kegagalan tim untuk dipakai pada eksperimen, deployment, dan rilis fitur baru.
TL;DR: Error budget adalah angka konkret yang muncul dari SLO: kalau target uptime 99,9% per bulan, tim punya 43,2 menit kegagalan untuk dibelanjakan. Saat budget habis, tim wajib rem rilis dan fokus stabilitas. Saat masih sehat, tim bebas eksperimen lebih agresif.
Apa itu Error Budget?
Error budget mengubah reliabilitas dari janji absolut menjadi kuota yang bisa dianggarkan. Konsep ini diperkenalkan tim SRE Google supaya developer dan ops tidak saling tarik menarik antara "rilis cepat" dan "jangan rusak". Dengan budget yang sama-sama dilihat, kedua kubu bicara dengan satuan yang sama: persen kegagalan yang masih boleh terjadi sebelum kontrak dengan pengguna dilanggar.
Cara Menghitung
| Target SLO | Budget per 30 hari | Implikasi praktis |
|---|---|---|
| 99,0% | 7 jam 12 menit | Cocok untuk produk internal, tier B |
| 99,9% | 43,2 menit | Standar SaaS umum |
| 99,95% | 21,6 menit | Mulai mahal, perlu HA arsitektur |
| 99,99% | 4,3 menit | Hanya untuk core financial atau critical |
Rumusnya sederhana: budget = (1 - SLO) x periode. Hitung tail latency dan error rate via observability stack agar burndown error budget bisa dipantau real-time.
Kenapa Penting?
Untuk tim engineering Indonesia yang menjalankan banyak rilis per minggu, error budget memberi sinyal jelas kapan harus stop merge. Tanpa angka ini, tim sering trade-off rilis vs stabilitas berdasarkan emosi atau tekanan stakeholder. Tim yang dewasa pakai burn rate alert: kalau budget habis 25% dalam 1 jam, otomatis trigger investigasi sebelum DORA metrics ikut anjlok.
Pertanyaan Umum
Apa beda SLO dan error budget?
SLO adalah target reliabilitas (mis. 99,9%). Error budget adalah sisa anggaran kegagalan yang berasal dari SLO tersebut. SLO menjawab "seberapa baik", budget menjawab "berapa banyak boleh gagal lagi bulan ini".
Apa yang terjadi kalau error budget habis?
Praktik standar: rilis fitur dibekukan, tim fokus perbaikan reliabilitas sampai budget kembali sehat di periode berikutnya. Boleh ada exception untuk patch keamanan kritis.