Error Budget: Panduan Lengkap SRE untuk Menghentikan Perang Fitur v...

Pendahuluan

Anda menetapkan target SLO 99,9 persen. Tim Anda on-call, ditelepon untuk setiap error 500, dan deployment dihentikan karena error rate sedikit meningkat. Sementara itu, kecepatan pengembangan fitur merosot drastis.

Ini kebalikan dari apa yang seharusnya dicapai oleh SRE.

Error budget hadir untuk memutus siklus ini. Ia memberikan kerangka kerja berbasis data yang jelas untuk memutuskan kapan harus memprioritaskan keandalan dan kapan harus memprioritaskan pengembangan fitur. Panduan ini membahas apa itu error budget, cara menghitungnya, cara mengimplementasikannya dengan Prometheus, dan cara membangun kebijakan error budget yang benar-benar akan digunakan oleh tim Anda.

Apa Itu Error Budget?

Error budget adalah jumlah maksimum waktu atau jumlah kegagalan yang dapat dialami oleh layanan Anda dalam periode tertentu sebelum melanggar SLO-nya.

Rumusnya sederhana:

Error Budget = (1 - SLO) × Total Permintaan dalam Periode Waktu

Untuk SLO 99,9% pada layanan yang menangani 1 juta permintaan per bulan:

Error Budget = (1 - 0,999) × 1.000.000
Error Budget = 0,001 × 1.000.000
Error Budget = 1.000 permintaan gagal yang diizinkan

Dengan kata lain: layanan Anda boleh gagal sebanyak 1.000 permintaan per bulan sebelum Anda dianggap melanggar SLO. Selama jumlah kegagalan di bawah 1.000, Anda tetap "dalam budget" — dan tim bisa fokus mengembangkan fitur.

Mengapa Error Budget Penting

Tanpa error budget, setiap insiden terasa mendesak. Tim produk ingin fitur baru, tim SRE ingin stabilitas — dan tidak ada yang punya data untuk menyelesaikan perdebatan.

Dengan error budget:

Di atas 50% budget tersisa: Fitur dikirim dengan kecepatan penuh. Keandalan sesuai target.
25-50% budget tersisa: Semua pekerjaan fitur dibekukan. 100% waktu engineering dialihkan ke perbaikan keandalan.
Di bawah 25% budget tersisa: Mode darurat. Semua perubahan dihentikan, escalation ke leadership. Incident commander mengambil alih.

Ini bukan saran — ini adalah kebijakan yang sudah disepakati sebelumnya. Tidak ada meeting, tidak ada debat. Dashboard menunjukkan merah, tim tahu apa yang harus dilakukan.

Cara Menghitung Error Budget dengan Prometheus

Implementasi error budget di Prometheus dimulai dengan mendefinisikan SLI (Service Level Indicator) Anda. Berikut adalah aturan recording Prometheus untuk menghitung error budget yang tersisa:

groups:
  - name: error_budget.rules
    interval: 30s
    rules:
      # SLI: error rate 5 menit
      - record: job:error_rate:ratio5m
        expr: |
          sum(rate(http_requests_total{status=~"5.."}[5m])) by (job)
          /
          sum(rate(http_requests_total[5m])) by (job)

      # SLO target sebagai konstanta (99.9% = 0.999)
      - record: job:slo_target
        expr: 0.999

      # Error budget yang tersisa (rasio)
      - record: job:error_budget_remaining:ratio
        expr: |
          1 - (
            (1 - job:slo_target)
            /
            (
              sum(rate(http_requests_total{status=~"5.."}[30d])) by (job)
              /
              sum(rate(http_requests_total[30d])) by (job)
            )
          )

      # Error budget tersisa dalam permintaan absolut
      - record: job:error_budget_remaining:absolute
        expr: |
          (job:error_budget_remaining:ratio * (1 - job:slo_target))
          *
          sum(rate(http_requests_total[30d])) by (job) * 30 * 86400

Metrik job:error_budget_remaining:ratio adalah indikator utama Anda. Ketika nilainya di atas 1 — budget Anda aman. Ketika turun di bawah 0 — budget habis, SLO Anda dilanggar.

Visualisasi Error Budget di Grafana

Buat dashboard Grafana dengan tiga panel kunci:

Panel 1: Gauge Error Budget Tersisa. Gunakan PromQL:

100 * job:error_budget_remaining:ratio{job="payment-service"}

Atur threshold hijau di atas 50%, kuning 25-50%, merah di bawah 25%.

Panel 2: Burn Rate 1 Jam vs 6 Jam. Gunakan PromQL:

# 1-hour burn rate
(job:error_rate:ratio5m / (1 - 0.999)) * (30*86400 / 3600)

# 6-hour burn rate  
(job:error_rate:ratio5m / (1 - 0.999)) * (30*86400 / 21600)

Burn rate 1 berarti mengonsumsi budget persis sesuai jadwal. Burn rate 14,4 berarti mengonsumsi 14,4 kali lebih cepat — budget 30 hari akan habis dalam waktu kurang dari 24 jam.

Panel 3: Timeline Error Budget. Gunakan predict_linear untuk memproyeksikan kapan budget akan habis:

predict_linear(job:error_budget_remaining:ratio[7d], 30 * 86400)

Multi-Window Alerting: Hanya Terbangun Saat Perlu

Kesalahan terbesar dalam SRE alerting adalah memberi peringatan pada setiap error. Hasilnya: alert fatigue, on-call burnout, dan tim yang mulai mengabaikan semua notifikasi.

Multi-window burn rate alert hanya memberi peringatan ketika budget benar-benar terancam:

groups:
  - name: error_budget_alerts
    rules:
      - alert: ErrorBudgetCriticalBurn
        expr: |
          (
            sum(rate(http_requests_total{status=~"5.."}[1h])) by (job)
            /
            sum(rate(http_requests_total[1h])) by (job)
          ) &gt; 14.4 * (1 - 0.999)
          and
          (
            sum(rate(http_requests_total{status=~"5.."}[6h])) by (job)
            /
            sum(rate(http_requests_total[6h])) by (job)
          ) &gt; 6.0 * (1 - 0.999)
        for: 5m
        labels:
          severity: page
        annotations:
          summary: "Error budget {{ $labels.job }} terbakar kritis"

Mengapa dua jendela? Lonjakan error 2 menit karena restart deployment tidak akan memicu alert — karena jendela 6 jam akan meratakannya. Hanya pembakaran budget yang berkelanjutan yang menghasilkan halaman.

Kebijakan Error Budget dalam Praktik

Kebijakan error budget harus berupa dokumen resmi yang disetujui oleh engineering manager, product manager, dan SRE lead. Simpan di git — di samping definisi SLO Anda:

# error-budget-policy.yaml
service: payment-api
slo_target: 0.999
measurement_window: 30d
policies:
  - trigger: error_budget_remaining &gt; 0.50
    action: "Fitur normal — kirim sesuai sprint plan"
    
  - trigger: error_budget_remaining &lt;= 0.50
    action: "Feature freeze — semua engineer fokus pada reliability"
    approver: engineering_manager
    
  - trigger: error_budget_remaining &lt;= 0.10
    action: "Emergency mode — rollback semua deployment minggu ini, incident commander on-call 24/7"
    approver: vp_engineering

Poin kuncinya: kebijakan ini dinegosiasikan saat semuanya tenang — bukan saat production down di jam 3 pagi. Ketika dashboard menunjukkan merah, tidak ada yang berdebat. Tim buka dokumen kebijakan dan eksekusi.

Kesalahan Umum Error Budget

Kesalahan 1: SLO yang tidak realistis. "99,99%!" kedengarannya bagus di slide presentasi. Tetapi 99,99% berarti hanya 52 menit downtime per tahun. Jika Anda belum pernah mencapai ini, Anda akan kehabisan budget di minggu pertama setiap bulan. Mulailah dengan 99,9% (8,7 jam downtime/tahun) dan tingkatkan secara bertahap.

Kesalahan 2: Tidak menghormati kebijakan. Kebijakan error budget hanya berfungsi jika leadership menghormatinya. Jika VP engineering memaksa deployment fitur saat budget merah, kebijakan Anda hanya dekorasi.

Kesalahan 3: Satu SLO untuk semua. Layanan pembayaran mungkin perlu 99,99%. Layanan rekomendasi produk mungkin cukup dengan 99%. Dashboard internal? Mungkin 95% sudah acceptable. Setiap layanan punya SLO-nya sendiri.

Kesalahan 4: Tidak menghitung error budget untuk dependensi. Jika layanan Anda bergantung pada database eksternal dengan SLO 99,5%, SLO Anda sendiri secara matematis tidak mungkin 99,9%. SLO berantai — hitung end-to-end.

Error Budget dan SLO: Hubungan yang Tidak Terpisahkan

Error budget tidak bisa berdiri sendiri — ia adalah konsekuensi langsung dari SLO Anda. Untuk panduan komprehensif tentang SLO, SLI, dan SLA, baca artikel kami tentang perbedaan SLI vs SLO vs SLA.

Implementasi Error Budget: Checklist

Definisikan SLI yang benar-benar mencerminkan pengalaman pengguna — bukan sekadar metrik yang mudah diukur
Tentukan SLO yang realistis, mulai dari 99,9% untuk layanan produksi
Implementasikan Prometheus recording rules untuk menghitung error budget secara otomatis
Bangun dashboard Grafana yang menampilkan status budget dalam sekali lihat
Konfigurasikan multi-window burn rate alert dengan severity page (kritis) dan ticket (warning)
Tulis kebijakan error budget yang disetujui oleh engineering manager dan product manager
Review SLO setiap kuartal — apakah 99,9% masih masuk akal? Apakah perlu ditingkatkan menjadi 99,95%?

Error budget adalah alat paling powerful yang dimiliki SRE untuk mengubah perdebatan subjektif ("lebih penting fitur atau stabilitas?") menjadi keputusan berbasis data. Dashboard yang menunjukkan 87% budget tersisa berarti: kirim fitur, kami aman. Dashboard yang menunjukkan 12% berarti: hentikan segalanya, perbaiki keandalan.

Inilah janji SRE yang sesungguhnya: bukan zero downtime, tapi keputusan yang tepat tentang kapan harus berinvestasi dalam keandalan.

Ingin belajar lebih lanjut tentang SRE? Subscribe newsletter DevToCash untuk panduan SRE mingguan dalam Bahasa Indonesia. Atau baca artikel terkait: Panduan Manajemen Insiden SRE dan AI Agents untuk SRE: Respons Insiden Otomatis.

Error Budget: Panduan Lengkap SRE untuk Menghentikan Perang Fitur vs Keandalan