Pelajari anggaran kesalahan untuk tim kecil: tetapkan SLO realistis untuk produk awal, tentukan insiden mana yang penting, dan jalankan ritual keandalan mingguan sederhana.
Tim kecil mengirim fitur cepat karena harus. Risikonya biasanya bukan satu outage besar. Melainkan kegagalan kecil yang berulang: signup yang mudah error, checkout yang kadang gagal, deploy yang sesekali merusak satu layar. Setiap kejadian mencuri jam kerja, mengikis kepercayaan, dan membuat rilis terasa seperti lempar koin.
Anggaran kesalahan memberi tim kecil cara sederhana untuk bergerak cepat tanpa berpura-pura bahwa keandalan "akan terjadi dengan sendirinya."
SLO (service level objective) adalah janji yang jelas tentang pengalaman pengguna, dinyatakan sebagai angka dalam jendela waktu. Contoh: “Checkout berhasil minimal 99.5% selama 7 hari terakhir.” Anggaran kesalahan adalah jumlah "buruk" yang diperbolehkan dalam janji itu. Jika SLO Anda 99.5%, anggaran mingguan Anda adalah 0.5% checkout gagal.
Ini bukan soal kesempurnaan atau tontonan uptime. Bukan proses berat, rapat tanpa akhir, atau spreadsheet yang tak pernah diperbarui. Ini cara untuk menyepakati apa arti “cukup baik”, menyadari saat Anda melenceng, dan membuat keputusan tenang tentang apa yang harus dilakukan selanjutnya.
Mulailah kecil: pilih 1 sampai 3 SLO yang terlihat pengguna dan terkait perjalanan paling penting, ukur menggunakan sinyal yang sudah Anda punya (error, latensi, pembayaran gagal), dan lakukan tinjauan singkat mingguan di mana Anda melihat pembakaran anggaran dan memilih satu tindakan lanjutan. Kebiasaan lebih penting daripada tooling.
Anggap keandalan seperti rencana diet. Anda tidak butuh hari yang sempurna. Anda butuh target, cara mengukurnya, dan toleransi untuk kehidupan nyata.
SLI (service level indicator) adalah angka yang Anda pantau, seperti “% permintaan yang berhasil” atau “p95 waktu muat halaman di bawah 2 detik.” SLO adalah target untuk angka itu, mis. “99.9% permintaan berhasil.” Anggaran kesalahan adalah seberapa banyak Anda boleh melewatkan SLO dan tetap berada di jalur.
Contoh: jika SLO Anda 99.9% ketersediaan, anggarannya 0.1% downtime. Dalam seminggu (10.080 menit), 0.1% kira-kira 10 menit. Itu bukan berarti Anda harus mencoba “menghabiskan” 10 menit. Artinya saat Anda menggunakannya, Anda secara sadar menukar keandalan dengan kecepatan, eksperimen, atau kerja fitur.
Nilainya: mengubah keandalan menjadi alat pengambil keputusan, bukan latihan pelaporan. Jika Anda sudah menghabiskan sebagian besar anggaran pada hari Rabu, Anda jeda perubahan berisiko dan memperbaiki yang rusak. Jika Anda hampir tak menghabiskan apa-apa, Anda bisa rilis lebih percaya diri.
Tidak semua hal perlu SLO yang sama. Aplikasi publik yang menghadap pelanggan mungkin butuh 99.9%. Alat admin internal seringkali boleh lebih longgar karena lebih sedikit orang yang menyadari dan dampaknya lebih kecil.
Jangan mulai dengan mengukur semuanya. Mulai dengan melindungi momen di mana pengguna memutuskan apakah produk Anda bekerja atau tidak.
Pilih 1 sampai 3 perjalanan pengguna yang membawa paling banyak kepercayaan. Jika itu solid, sebagian besar masalah lain terasa lebih kecil. Kandidat bagus adalah sentuhan pertama (signup atau login), momen uang (checkout atau upgrade), dan aksi inti (publish, create, send, upload, atau panggilan API kritis).
Tulis apa arti “sukses” dalam kata-kata biasa. Hindari istilah teknis seperti “200 OK” kecuali pengguna Anda adalah pengembang.
Beberapa contoh yang bisa Anda adaptasi:
Pilih jendela pengukuran yang cocok dengan seberapa cepat Anda melakukan perubahan. Jendela 7 hari cocok saat Anda rilis tiap hari dan ingin umpan balik cepat. Jendela 28 hari lebih tenang jika rilis kurang sering atau data Anda berisik.
Produk awal punya keterbatasan: trafik bisa rendah (satu deploy buruk menggeser angka), alur cepat berubah, dan telemetri sering tipis. Tidak apa-apa. Mulai dengan hitungan sederhana (percobaan vs keberhasilan). Perketat definisi setelah perjalanan itu sendiri berhenti berubah.
Mulai dari apa yang Anda kirim hari ini, bukan dari harapan ideal. Selama seminggu atau dua, tangkap baseline untuk tiap perjalanan kunci: seberapa sering berhasil dan seberapa sering gagal. Gunakan trafik nyata jika ada. Jika tidak, gunakan pengujian sendiri plus tiket dukungan dan log. Anda sedang membangun gambaran kasar tentang “normal.”
SLO pertama Anda harus sesuatu yang bisa Anda capai kebanyakan minggu sambil tetap mengirim. Jika baseline Anda 98.5%, jangan tetapkan 99.9% dan berharap. Tetapkan 98% atau 98.5%, lalu perketat nanti.
Latensi menggoda, tetapi bisa mengalihkan di awal. Banyak tim mendapat nilai lebih dari SLO tingkat keberhasilan terlebih dulu (permintaan selesai tanpa error). Tambahkan latensi ketika pengguna benar-benar merasakannya dan data Anda stabil cukup untuk membuat angka bermakna.
Format yang membantu adalah satu baris per perjalanan: siapa, apa, target, dan jendela waktu.
Jaga jendela lebih panjang untuk momen uang dan kepercayaan (tagihan, auth). Jaga lebih pendek untuk alur sehari-hari. Saat Anda mudah memenuhi SLO, naikkan sedikit dan lanjutkan.
Tim kecil kehilangan banyak waktu keandalan ketika setiap gangguan kecil menjadi panik. Tujuannya sederhana: rasa sakit yang terlihat pengguna menghabiskan anggaran; hal lain ditangani sebagai pekerjaan normal.
Satu set kecil tipe insiden cukup: outage penuh, outage parsial (satu alur kunci rusak), kinerja menurun (berfungsi tapi terasa lambat), deploy buruk (rilis menyebabkan kegagalan), dan masalah data (salah, hilang, duplikat).
Jaga skalanya kecil dan gunakan setiap kali.
Putuskan apa yang dihitung melawan anggaran. Perlakukan kegagalan yang terlihat pengguna sebagai pengeluaran: signup atau checkout rusak, timeout yang dirasakan pengguna, lonjakan 5xx yang menghentikan perjalanan. Pemeliharaan terencana tidak boleh dihitung jika Anda sudah mengomunikasikannya dan aplikasi berperilaku seperti yang diharapkan selama jendela itu.
Satu aturan menyelesaikan banyak perdebatan: jika pengguna eksternal nyata akan menyadari dan tidak bisa menyelesaikan perjalanan yang dilindungi, itu dihitung. Jika tidak, tidak.
Aturan itu juga mencakup area abu-abu umum: outage pihak ketiga hanya dihitung jika memecah perjalanan pengguna, jam dengan trafik rendah tetap dihitung jika pengguna terdampak, dan penguji internal tidak dihitung kecuali dogfooding adalah penggunaan utama Anda.
Tujuannya bukan pengukuran sempurna. Ini sinyal bersama yang bisa diulang yang memberi tahu Anda kapan keandalan mulai mahal.
Untuk tiap SLO, pilih satu sumber kebenaran dan konsisten: dashboard monitoring, log aplikasi, cek sintetis yang memanggil satu endpoint, atau satu metrik seperti checkout berhasil per menit. Jika nanti Anda mengubah metode pengukuran, catat tanggalnya dan anggap itu reset supaya Anda tidak membandingkan apel dengan jeruk.
Alert harus mencerminkan pembakaran anggaran, bukan setiap gangguan. Lonjakan singkat mungkin menyebalkan, tetapi tidak harus membangunkan siapa pun jika hanya sedikit menyentuh anggaran bulanan. Satu pola sederhana bekerja baik: alert pada “fast burn” (Anda diproyeksikan menghabiskan anggaran sebulan dalam sehari) dan alert lebih lembut pada “slow burn” (diproyeksikan habis dalam seminggu).
Simpan log keandalan kecil supaya Anda tidak bergantung pada ingatan. Satu baris per insiden cukup: tanggal dan durasi, dampak pengguna, penyebab kemungkinan, apa yang Anda ubah, dan pemilik tindak lanjut dengan tenggat.
Contoh: tim dua orang merilis API baru untuk aplikasi mobile. SLO mereka adalah “99.5% permintaan berhasil,” diukur dari satu counter. Deploy buruk menurunkan keberhasilan ke 97% selama 20 menit. Alert fast-burn memicu, mereka rollback, dan tindak lanjutnya “tambah cek canary sebelum deploy.”
Anda tidak butuh proses besar. Anda butuh kebiasaan kecil yang membuat keandalan terlihat tanpa mengorbankan banyak waktu membangun. Cek-in 20 menit seminggu bekerja karena mengubah semuanya menjadi satu pertanyaan: apakah kita menghabiskan keandalan lebih cepat dari rencana?
Gunakan slot kalender yang sama setiap minggu. Simpan satu catatan bersama yang Anda tambahkan (jangan menimpanya). Konsistensi mengalahkan detail.
Agenda sederhana yang muat:
Antara tindak lanjut dan komitmen, putuskan aturan rilis Anda untuk minggu itu dan jaga agar tetap membosankan:
Jika alur signup Anda mengalami dua outage singkat dan menghabiskan sebagian besar anggarannya, Anda mungkin hanya membekukan perubahan terkait signup sementara tetap mengirim pekerjaan lain.
Anggaran kesalahan hanya penting jika mengubah apa yang Anda lakukan minggu depan. Tujuannya bukan uptime sempurna. Ini cara jelas untuk memutuskan: apakah kita kirim fitur, atau membayar hutang keandalan?
Kebijakan yang bisa Anda ucapkan dengan jelas:
Itu bukan hukuman. Ini trade publik supaya pengguna tidak harus membayar nanti.
Saat Anda melambat, hindari tugas samar seperti “tingkatkan stabilitas.” Pilih perubahan yang mengubah hasil berikutnya: tambah guardrail (timeouts, validasi input, rate limit), perbaiki test yang seharusnya menangkap bug, buat rollback mudah, perbaiki sumber error terbanyak, atau tambahkan satu alert yang terkait perjalanan pengguna.
Jaga pelaporan terpisah dari menyalahkan. Hargai laporan insiden cepat, meski detailnya berantakan. Satu-satunya laporan insiden yang benar-benar buruk adalah yang datang terlambat, ketika tak ada yang ingat apa yang berubah.
Perangkap umum adalah menetapkan SLO berlapis emas di hari pertama (99.99% terdengar hebat) lalu diam-diam mengabaikannya saat realita datang. SLO awal Anda harus bisa dicapai dengan orang dan alat yang Anda punya sekarang, atau itu menjadi kebisingan latar.
Kesalahan lain adalah mengukur hal yang salah. Tim memantau lima service dan grafik database, tapi melewatkan perjalanan yang sebenarnya dirasakan pengguna: signup, checkout, atau “simpan perubahan.” Jika Anda tidak bisa menjelaskan SLO dalam satu kalimat dari sudut pandang pengguna, kemungkinan terlalu internal.
Kelelahan alert menguras satu-satunya orang yang bisa memperbaiki produksi. Jika setiap lonjakan kecil menimbulkan paging, paging menjadi “biasa” dan kebakaran nyata terlewatkan. Paginglah berdasarkan dampak pengguna. Rute lainnya ke pemeriksaan harian.
Pembunuh yang lebih halus adalah penghitungan yang tidak konsisten. Minggu ini Anda menghitung slowdown 2 menit sebagai insiden, minggu depan tidak. Lalu anggaran jadi bahan perdebatan, bukan sinyal. Tuliskan aturan sekali dan terapkan konsisten.
Guardrail yang membantu:
Jika deploy merusak login selama 3 menit, hitung itu setiap kali, meski cepat diperbaiki. Konsistensi membuat anggaran berguna.
Setel timer 10 menit, buka dokumen bersama, dan jawab lima pertanyaan ini:
Jika Anda belum bisa mengukur sesuatu, mulai dengan proksi yang bisa terlihat cepat: pembayaran gagal, error 500, atau tiket dukungan yang diberi tag “checkout.” Ganti proksi nanti saat pelacakan membaik.
Contoh: tim dua orang melihat tiga pesan “tidak bisa reset password” minggu ini. Jika reset password adalah perjalanan yang dilindungi, itu insiden. Mereka menulis satu catatan singkat (apa yang terjadi, berapa pengguna, apa yang mereka lakukan) dan memilih satu tindak lanjut: tambahkan alert pada kegagalan reset atau tambahkan retry.
Maya dan Jon menjalankan startup dua orang dan rilis tiap Jumat. Mereka bergerak cepat, tetapi pengguna pertama yang membayar peduli tentang satu hal: bisakah mereka membuat proyek dan mengundang rekan tanpa rusak?
Minggu lalu mereka mengalami satu outage nyata: “Buat proyek” gagal selama 22 menit setelah migrasi yang buruk. Mereka juga mengalami tiga periode “lambat tapi tidak mati” di mana layar berputar 8–12 detik. Pengguna mengeluh, tapi tim berdebat apakah lambat dihitung sebagai “down.”
Mereka memilih satu perjalanan dan membuatnya terukur:
Senin mereka menjalankan ritual 20 menit. Waktu sama, dokumen sama. Mereka menjawab empat pertanyaan: apa yang terjadi, berapa banyak anggaran terbakar, apa yang berulang, dan satu perubahan tunggal yang mencegah pengulangan.
Trade-off menjadi jelas: outage ditambah periode lambat menghabiskan sebagian besar anggaran mingguan. Jadi fitur besar minggu depan berubah menjadi “tambah index DB, buat migrasi lebih aman, dan alert pada kegagalan create-project.”
Hasilnya bukan keandalan sempurna. Melainkan lebih sedikit masalah berulang, keputusan ya/tidak yang jelas, dan lebih sedikit panik tengah malam karena mereka sudah sepakat sebelumnya apa yang “cukup buruk.”
Pilih satu perjalanan pengguna dan buat janji keandalan sederhana padanya. Anggaran kesalahan bekerja terbaik ketika membosankan dan dapat diulang, bukan sempurna.
Mulai dengan satu SLO dan satu ritual mingguan. Jika setelah sebulan masih terasa mudah, tambahkan SLO kedua. Jika terasa berat, kecilkan.
Jaga matematikanya sederhana (mingguan atau bulanan). Tetapkan target realistis berdasarkan posisi Anda sekarang. Tulis catatan keandalan satu halaman yang menjawab: SLO dan bagaimana mengukurnya, apa yang dihitung sebagai insiden, siapa yang bertanggung jawab minggu ini, kapan check-in berlangsung, dan apa yang dilakukan secara default saat anggaran terbakar terlalu cepat.
Jika Anda membangun di platform seperti Koder.ai (koder.ai), itu bisa membantu memadukan iterasi cepat dengan kebiasaan keselamatan, terutama snapshot dan rollback, sehingga “kembali ke keadaan baik terakhir” tetap menjadi langkah normal dan terlatih.
Jaga loop tetap rapat: satu SLO, satu catatan, satu check-in singkat mingguan. Tujuannya bukan menghilangkan insiden. Melainkan menyadari lebih awal, memutuskan dengan tenang, dan melindungi beberapa hal yang benar-benar dirasakan pengguna.
Sebuah SLO adalah janji tentang keandalan pengalaman pengguna, diukur dalam jendela waktu (mis. 7 atau 30 hari).
Contoh: “99.5% checkout berhasil selama 7 hari terakhir.”
Anggaran kesalahan adalah jumlah “buruk” yang diperbolehkan dalam SLO Anda.
Jika SLO Anda 99.5% sukses, maka anggarannya 0.5% kegagalan dalam jendela itu. Ketika anggaran habis terlalu cepat, Anda perlambat perubahan berisiko dan memperbaiki penyebabnya.
Mulailah dengan 1–3 perjalanan yang langsung dirasakan pengguna:
Jika hal-hal ini andal, kebanyakan masalah lain terasa lebih kecil dan lebih mudah diurutkan prioritasnya nantinya.
Pilih baseline yang realistis dan bisa Anda capai kebanyakan minggu.
Jika Anda saat ini 98.5%, memulai di 98–98.5% lebih berguna daripada menetapkan 99.9% lalu mengabaikannya.
Gunakan penghitungan sederhana: percobaan vs keberhasilan.
Sumber data pemula yang baik:
Jangan tunggu observabilitas sempurna; mulai dengan proksi yang Anda percayai dan jaga konsistensinya.
Hitung sebagai insiden jika pengguna eksternal akan menyadari dan gagal menyelesaikan perjalanan yang dilindungi.
Contoh yang biasanya “mengurangi anggaran”:
Jangan hitung gangguan internal saja kecuali penggunaan internal adalah penggunaan utama produk Anda.
Aturan sederhana: paging berdasarkan pembakaran anggaran, bukan setiap gangguan kecil.
Dua tipe alert berguna:
Ini mengurangi kelelahan alert dan memfokuskan perhatian pada isu yang benar-benar akan mengubah apa yang Anda kirimkan selanjutnya.
Jaga 20 menit per minggu, waktu yang sama, dokumen yang sama:
Akhiri dengan mode rilis minggu itu: Normal, , atau .
Gunakan kebijakan default yang mudah diucapkan:
Tujuannya adalah trade-off yang tenang, bukan saling menyalahkan.
Beberapa penjaga praktis membantu:
Jika Anda membangun di platform seperti Koder.ai, jadikan “kembali ke keadaan baik terakhir” sebagai langkah rutin, dan anggap rollback berulang sebagai sinyal untuk investasi pada test atau pemeriksaan deploy yang lebih aman.
