Error Budget: Cara Tim Engineering Indonesia Menyeimbangkan Kecepatan Rilis dan Stabilitas Produksi

TL;DR: Error budget adalah selisih antara target SLO dan 100%, yang berfungsi sebagai kuota toleransi kegagalan untuk dipakai merilis fitur baru. Konsep ini mengubah debat antara tim produk yang ingin cepat rilis dan tim engineering yang ingin stabil jadi diskusi berbasis angka. Tim Indonesia bisa mulai dengan SLO 99,5% dan error budget bulanan sekitar 3,6 jam downtime.

Banyak tim teknologi Indonesia yang saya temui di proyek client masih terjebak dalam pola lama: tim produk menekan rilis cepat, tim engineering membela stabilitas, dan keputusan akhir ditentukan siapa yang lebih keras suaranya di rapat. Dalam beberapa kasus, hasilnya adalah rilis fitur yang ditunda berbulan-bulan atau, sebaliknya, downtime yang merusak reputasi.

Error budget menawarkan jalan tengah yang lebih dewasa. Bukan dengan memaksakan kompromi, melainkan dengan menerjemahkan reliability jadi kuota yang bisa dihitung, dipakai, dan dievaluasi setiap kuartal.

Kenapa Debat Cepat vs Stabil Tidak Pernah Selesai

Tanpa angka yang disepakati, kecepatan rilis dan stabilitas terlihat seperti dua kutub yang saling meniadakan. Tim produk merasa tim engineering paranoid, tim engineering merasa tim produk ceroboh. Faktanya, reliability 100% bukan hanya mahal, tapi juga tidak diperlukan oleh kebanyakan produk konsumen di Indonesia. Pengguna cenderung memaafkan downtime kecil yang jarang, tapi tidak memaafkan produk yang stagnan tanpa fitur baru selama enam bulan.

Konsep error budget dipopulerkan oleh tim Site Reliability Engineering Google dan didokumentasikan di SRE Workbook. Idenya sederhana: kalau Anda berkomitmen 99,9% uptime, berarti 0,1% atau sekitar 43 menit per bulan adalah kuota downtime yang boleh dipakai untuk eksperimen, migrasi, atau rilis berisiko.

Cara Menghitung Error Budget yang Realistis

Saat membangun Vetmo, kami menetapkan SLO 99,5% di tahun pertama. Angka itu memberi ruang untuk migrasi database besar, eksperimen feature flag, dan jadwal rilis dua kali seminggu. Setelah produk stabil, baru naik ke 99,9% di tahun kedua.

Yang penting bukan angka abstrak, melainkan kesepakatan tim. Pilih angka yang masuk akal untuk industri dan tahap produk Anda, lalu ukur konsisten via observability yang sudah terpasang.

Kebijakan Error Budget yang Berfungsi di Tim Indonesia

Error budget hanya bermanfaat kalau ada konsekuensi yang disepakati saat kuota habis. Tanpa konsekuensi, angka tinggal angka. Berikut tiga lapis kebijakan yang biasa saya rekomendasikan ke tim client:

Pertama, kalau error budget di atas 50% sisa di tengah bulan, tim boleh merilis fitur dengan tingkat risiko normal dan boleh memakai canary release bertahap. Kedua, kalau tinggal 10-50%, rilis baru harus melewati review tambahan dan eksperimen riskan ditunda. Ketiga, kalau habis, tim wajib fokus ke perbaikan reliability sampai bulan berikutnya, semua fitur non-kritis ditahan.

Salah satu klien saya di sektor edukasi awalnya keberatan dengan kebijakan lapis ketiga ini, takut tim produk merasa "dikekang". Tapi setelah dua kuartal, mereka melaporkan kebalikannya: tim produk justru jadi lebih disiplin di awal, karena tahu kalau error budget habis di minggu pertama, sisa bulan akan terkunci.

Studi Kasus: Atmo LMS dan Migrasi Database Besar

Saat melakukan migrasi database besar di proyek Atmo (LMS), kami secara sadar memakai sebagian error budget untuk eksperimen dark launch. Selama dua minggu, sebagian trafik dialihkan ke infrastruktur baru tanpa pengguna tahu, dan kami memantau metrik latensi via dashboard internal.

Hasilnya, ada satu jam degradasi yang terbakar dari kuota bulanan, tapi migrasi selesai tanpa rollback darurat. Tanpa konsep error budget, tim mungkin akan menunda migrasi berbulan-bulan karena takut "memecahkan apa yang berjalan".

Pertanyaan Umum

Apakah error budget hanya untuk perusahaan teknologi besar?

Tidak. Justru tim kecil yang paling diuntungkan karena sumber daya terbatas. Error budget memaksa prioritas yang jelas tanpa drama.

Bagaimana mengukur error budget tanpa tools enterprise?

Banyak tools open-source seperti Prometheus + Grafana sudah cukup untuk SLO sederhana. Untuk tim yang lebih kecil, bahkan uptime monitor seperti UptimeRobot bisa jadi titik awal.

Apa beda error budget dengan SLA penalty?

Error budget adalah kebijakan internal yang mengatur prioritas tim. SLA penalty adalah konsekuensi finansial ke pelanggan eksternal kalau janji formal dilanggar. Keduanya komplementer, bukan substitusi.

Apa yang terjadi kalau error budget terus habis tiap bulan?

Itu sinyal SLO terlalu agresif untuk infrastruktur saat ini, atau ada utang teknikal mendasar yang harus dibereskan sebelum rilis fitur baru.

Penutup: Error Budget sebagai Bahasa Bersama

Yang paling sering saya lihat di tim Indonesia bukan kekurangan teknologi, melainkan kekurangan bahasa bersama antara tim produk dan engineering. Error budget memberi bahasa itu. Diskusi yang dulunya emosional jadi diskusi tentang angka, dan keputusan yang dulunya diambil siapa yang dominan jadi diputuskan bersama berdasarkan kuota yang tersisa.

Mulai bulan ini, coba sepakati satu SLO sederhana di tim Anda, lalu ukur. Tiga bulan ke depan, Anda akan punya basis empiris untuk pertama kalinya.