# Apa Itu SLO? Panduan Praktis untuk Developer Solo Hari Ini URL: https://whatshouldibuildnext.com/id/journal/apa-itu-slo Type: blog Locale: id Published: 2026-10-17 Updated: 2026-10-17 --- > Jawaban sederhana untuk apa itu SLO, cara kerja error budget, dan cara developer solo menetapkan target keandalan yang realistis dalam satu sore. Apa itu SLO? SLO (service level objective) adalah angka yang kamu janjikan pada diri sendiri tentang seberapa sering layananmu harus berfungsi, diukur dalam jangka waktu tetap. "99.9% request berhasil selama 30 hari" adalah contoh SLO. Angka ini mengubah "situsnya kelihatan oke kok" menjadi sesuatu yang bisa kamu cek, dan memberi tahu kapan sebaiknya berhenti merilis fitur dan memperbaiki yang rusak. Kamu tidak butuh tim platform untuk ini. Developer solo dengan satu API dan database Postgres bisa menulis SLO yang layak dipakai dalam satu sore. Berikut arti istilahnya, cara memilih angkanya, dan di mana biasanya salah. ## Jam 2 pagi, dan tidak ada yang tahu apakah aplikasinya rusak Bayangkan sebuah side project dengan 400 pengguna mingguan. Suatu malam, endpoint checkout mulai mengembalikan 500 selama sekitar 20 menit. Tidak ada yang nge-tweet, tidak ada yang mengirim email. Kamu baru tahu tiga hari kemudian dari satu pesan dukungan pelanggan. Seberapa parah kejadian itu? Tanpa target, kamu tidak bisa menjawabnya. Dengan target, kamu bisa: kalau SLO-mu mengizinkan sekitar 43 menit kegagalan per bulan dan kamu baru saja memakai 20 menit, berarti satu malam buruk sudah menghabiskan hampir separuh jatahmu. Di situlah inti SLO. Ia mengganti perasaan dengan anggaran. ## SLI, SLO, dan SLA dalam bahasa sehari-hari Orang sering tertukar antara SLI, SLO, dan SLA, jadi ini versi singkatnya. **SLI** (service level indicator) adalah pengukuran. "Persentase request HTTP yang mengembalikan status selain 5xx dalam 30 hari terakhir" adalah SLI. Ini rasio antara event yang baik dan total event. **SLO** (service level objective) adalah target untuk pengukuran itu. "Rasio tersebut harus tetap di atas atau sama dengan 99.9%" adalah SLO. SLO bersifat internal. Kamu yang menetapkannya, kamu boleh mengubahnya, dan tidak ada yang akan menggugatmu karenanya. **SLA** (service level agreement) adalah kontrak dengan konsekuensi, biasanya refund atau kredit. Kebanyakan side project tidak punya SLA, dan itu tidak masalah. Kamu tetap bisa menjalankan SLO tanpa SLA. [Bab SRE workbook tentang implementasi SLO](https://sre.google/workbook/implementing-slos/) adalah referensi standar kalau kamu ingin versi panjangnya. Urutannya penting: pilih SLI dulu, lalu SLO, dan pikirkan SLA hanya jika pelanggan berbayar memintanya secara tertulis. ![Stopwatch dan sketsa buku catatan yang menggambarkan bilah error budget yang terisi sebagian](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/whatshouldibuildnext/2026-10/70d162-i1.webp) ## Error budget: bagian yang mengubah cara kerjamu SLO 99.9% juga berarti 0.1% event boleh gagal. Jatah kegagalan itu adalah error budget-mu, dan itulah separuh yang paling berguna dari ide ini. Dalam satu bulan 30 hari, ketersediaan 99.9% menyisakan sekitar 43 menit downtime yang diizinkan. Hitungannya: 30 hari × 24 jam × 60 menit, lalu dikali 0.001. Target 99% memberi sekitar 7.2 jam. Target 99.99% memberi sekitar 4.3 menit. Angka-angka terakhir itulah alasan kebanyakan proyek kecil sebaiknya tidak membidik terlalu tinggi. Empat menit per bulan berarti satu deploy buruk dan rollback sudah membuat target jebol. Yang sering luput dari perhatian: makin tinggi targetmu, makin banyak waktumu habis untuk mempertahankan angka itu, bukan untuk membangun produk. Budget juga memberi aturan untuk memutuskan apa yang dibangun berikutnya. Budget masih utuh: rilis fitur yang berisiko. Budget sudah habis: perbaiki dulu bagian yang rapuh. Tidak perlu rapat, cukup satu angka di dashboard. Di proyek solo, aturan ini terasa lebih konkret daripada kedengarannya. Kamu tidak perlu menunggu persetujuan siapa pun untuk menunda fitur baru. Kamu cukup membuka dashboard, melihat sisa budget, lalu memutuskan sendiri. Aturan ini juga mencegah keputusan yang lahir dari perasaan, misalnya "sepertinya server akhir-akhir ini sering error" tanpa bukti apa pun. ## Cara memilih SLI dan menentukan angkanya Mulailah dari apa yang akan disebut "rusak" oleh pengguna. Untuk aplikasi web, biasanya itu berkisar pada dua pertanyaan: apakah request-nya berhasil, dan apakah cukup cepat? Untuk sebagian besar side project, dua SLI sudah menutup 90% nilainya: - **Availability**: request yang baik dibagi total request, dengan "baik" berarti respons selain 5xx. - **Latency**: persentase request yang dijawab di bawah ambang, misalnya 95% request di bawah 500 ms. Perhatikan bahwa latency ditulis sebagai persentase request di bawah ambang, bukan sebagai rata-rata. Rata-rata menyembunyikan ekor yang lambat, dan di ekor lambat itulah pengguna menyerah. Rata-rata 300 ms bisa saja berada di atas p99 sebesar 4 detik. Ukur di tepi sistemmu, sedekat mungkin dengan pengguna. Health check yang melakukan ping ke `/healthz` dari dalam VPC yang sama hanya memberi tahu bahwa prosesnya hidup, bukan bahwa pengguna bisa login. Kalau kamu hanya sanggup satu pengukuran, uji jalur pengguna yang nyata, misalnya login atau checkout, dari luar. Untuk proyek baru, jawaban jujurnya adalah 99% atau 99.5%. Lihat data 30 hari terakhirmu, hitung apa yang benar-benar kamu berikan, tetapkan SLO sedikit di bawah angka itu, dan perketat nanti kalau pengguna mengeluh. Panduan kasarnya untuk proyek solo: - **Tool hobi tanpa pendapatan**: 99% sudah cukup. Sekitar 7 jam kegagalan per bulan tidak terlihat oleh sebagian besar pengguna. - **SaaS berbayar dengan beberapa lusin pelanggan**: 99.5% sampai 99.9%, tergantung seberapa sensitif produkmu terhadap waktu. - **Apa pun yang dibutuhkan pelanggan pada jam kerja**: 99.9%, dan uji jalur rollback-mu sebelum menjanjikannya. Belum optimal, tapi tetap layak dilakukan: SLO yang selalu kamu penuhi 100% adalah angka yang terlalu rendah, dan SLO yang meleset setiap bulan adalah angka yang tidak dipercaya siapa pun. Targetkan untuk meleset sesekali, karena di situlah budget bekerja. ![Laptop di kafe Bangkok yang menampilkan grafik latency datar dan stabil saat senja](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/whatshouldibuildnext/2026-10/d85f1c-i2.webp) ## Alerting berdasarkan burn rate, bukan setiap lonjakan Kesalahan yang hampir semua orang buat: memasang alert setiap kali error rate melewati ambang. Kamu dibangunkan jam 3 pagi kUntuk satu orang, dua alert sudah masuk akal. Yang cepat, misalnya burn rate di atas 10 selama satu jam, yang membangunkanmu. Yang lambat, misalnya burn rate sekitar 2 selama satu hari, yang menjadi tiket untuk pagi hari. [Bab SRE book tentang service level objectives](https://sre.google/sre-book/service-level-objectives/) membahas alasannya, dan versi multi-window ada di workbook yang sudah disebut di atas. Alert yang baik harus bisa ditindaklanjuti. Kalau kamu menerima notifikasi tengah malam tetapi tidak tahu apakah harus bangun atau cukup membuka laptop besok, alert itu sebenarnya belum selesai. Tulis di samping setiap alert apa langkah pertama yang akan kamu ambil, misalnya memeriksa log deploy terakhir atau melakukan rollback. Dengan begitu, alert tidak berhenti sebagai bunyi, tetapi berubah menjadi keputusan.ng cepat, misalnya burn rate di atas 10 selama satu jam, yang membangunkanmu. Yang lambat, misalnya burn rate sekitar 2 selama satu hari, yang menjadi tiket untuk pagi hari. [Bab SRE book tentang service level objectives](https://sre.google/sre-book/service-level-objectives/) membahas alasannya, dan versi multi-window ada di workbook yang sudah disebut di atas. ![Ponsel di meja samping tempat tidur yang menyala karena alert malam hari](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/whatshouldibuildnext/2026-10/838592-i3.webp) ## Tulis SLO kecilmu hari ini, dan bedakan dengan monitoring uptime Kamu tidak perlu vendor untuk memulai. Tulis ini di repo-mu, dalam file bernama `SLO.md`: `service: checkout-api window: 30d slis: availability: good: http_status < 500 total: semua request kecuali /healthz latency: good: response_time < 500ms total: semua request kecuali /healthz objectives: availability: 99.5% latency: 95% if_budget_burned: - tunda fitur yang tidak mendesak - perbaiki sumber error terbesar lebih dulu`Kalau stack-mu sudah mengekspor jumlah request, SLI ketersediaan dalam sintaks gaya Prometheus cukup satu baris: `sum(rate(http_requests_total{status!~"5.."}[30d])) / sum(rate(http_requests_total[30d]))`Rasio itu, dibandingkan dengan targetmu, adalah seluruh dashboard SLO-mu. Sisanya hanya polesan. Tiga panel sudah cukup: SLI saat ini, sisa budget, dan garis burn rate. Apakah SLO hanya monitoring uptime dengan langkah tambahan? Tidak sepenuhnya, meski keduanya saling tumpang tindih. Ping monitor memberi tahu bahwa situs menjawab pada menit tertentu. SLO memberi tahu berapa persen request pengguna nyata yang berhasil selama sebulan, dan apa artinya untuk keputusanmu berikutnya. Bayangkan dua minggu ketika ping monitor menunjukkan hijau setiap menit, padahal satu query database yang lambat membuat halaman dashboard timeout untuk 3% pengguna yang sudah login. Monitor bilang semuanya baik-baik saja. SLI-mu bilang kamu meleset dari target latency. Hanya salah satunya yang akan mengubah apa yang kamu kerjakan hari Senin. Tetap pertahankan ping monitor. Ia murah dan cepat menangkap outage total. Anggap saja sebagai salah satu input, bukan definisi dari "berfungsi". ## Alat mana yang dipakai saat kamu satu-satunya tim ops Kamu bisa menjalankan SLO dari spreadsheet dan cron job selama sebulan sambil belajar apa yang benar-benar kamu pedulikan. Begitu angkanya berarti, sebuah tool baru layak dipakai. Ada tiga yang layak dilihat, dengan catatan bahwa stack-mu lebih menentukan daripada daftar fitur. Grafana adalah pilihan default untuk orang yang sudah mengekspor metrik Prometheus. Tier gratisnya cukup longgar untuk side project, dan fitur SLO-nya berdiri di atas data yang mungkin sudah kamu punya. Lewati kalau kamu belum punya pipeline metrik dan belum berminat membangunnya. New Relic punya tier gratis dengan ingest data 100 GB per bulan dan tooling SLO yang sudah terpasang di platform. Cocok kalau kamu ingin setup berbasis agent dengan konfigurasi minimal. Konsekuensinya, biaya jadi kurang bisa diprediksi begitu kamu melewati batas gratis. Datadog adalah opsi yang paling lengkap sekaligus paling mahal, dengan infrastruktur, APM, dan log yang ditagih terpisah. Layak kalau tim di sekitarmu sedang berkembang. Lewati untuk proyek solo kecuali ada orang lain yang membayarnya. Apa pun pilihanmu, tahan dorongan untuk mendefinisikan lima belas SLO di hari pertama. Satu SLO ketersediaan dan satu SLO latency per layanan yang dilihat pengguna sudah cukup untuk belajar darinya. ## Satu bulan dengan hitungan nyata, dan tiga kesalahan yang harus dihindari Misalnya SLO-mu adalah ketersediaan 99.5% selama 30 hari, dan kamu melayani sekitar 600 ribu request per bulan. Target itu mengizinkan kegagalan 0.5%, jadi ada 3000 request gagal sebelum budget habis. Pada hari ke-9, migrasi yang buruk mengembalikan 500 selama 25 menit dan menghabiskan 1100 request gagal. Kamu sudah memakai sekitar 37% budget dalam satu malam. Pada hari ke-17, API pihak ketiga timeout dan menghabiskan 900 lagi. Sekarang kamu berada di sekitar 67% terpakai dengan 13 hari tersisa. Di titik inilah budget membuktikan gunanya. Kamu tidak perlu panik, tetapi kamu juga sebaiknya tidak merilis refactor berisiko yang kamu rencanakan untuk hari ke-20. Tambahkan timeout dan fallback untuk panggilan pihak ketiga itu, tulis pengecekan migrasi yang tadi kamu lewati, dan pindahkan refactor ke bulan depan. Intinya bukan bahwa kegagalan itu buruk. Kegagalan memang diharapkan dan sudah diperhitungkan. Yang diberikan angka ini adalah jawaban yang tenang dan bersama atas pertanyaan "mampukah kita menanggung risiko ini sekarang?", bahkan ketika satu-satunya orang di ruangan itu adalah kamu. Tinjau setiap SLO sekali per kuartal, atau setelah bulan ketika kamu meleset parah atau sama sekali tidak menyentuh budget. Meleset dua bulan berturut-turut berarti sistemmu butuh pekerjaan nyata, atau targetnya terlalu ambisius untuk tahap yang sedang kamu jalani. Dua-duanya fakta yang berguna. Kalau kamu mendapat pelanggan berbayar, tanyakan kepada mereka apa arti "rusak" bagi mereka. Pelanggan yang menjalankan laporan mingguan peduli pada Senin pagi, bukan pada lonjakan kecil hari Sabtu malam, dan SLO-mu bisa mencerminkannya dengan target yang lebih ketat pada jam kerja mereka. **Mengukur apa yang mudah, bukan apa yang dirasakan pengguna.** Penggunaan CPU bukan SLI. Pengguna tidak peduli CPU-mu di 40%. Mereka peduli bahwa halaman terbuka. **Menetapkan target dari ambisi.** "Kita mau lima sembilan" terdengar serius dan tidak berarti apa-apa kalau database-mu satu instance di VM kecil. Tetapkan SLO dari kenyataan yang teramati, perbaiki sistemnya, lalu perketat angkanya. **Tidak pernah memakai budget.** Kalau kamu selalu menutup bulan dengan 98% budget tersisa, kamu terlalu lambat merilis atau targetnya terlalu longgar. Budget yang tidak terpakai adalah kapasitas untuk mengambil risiko yang terbuang. Apa yang akan kamu taruh di bawah SLO pertama? Pilih satu endpoint yang akan disadari pengguna kalau rusak. Tulis SLI-nya dengan bahasa biasa, tetapkan target 0.5 poin di bawah yang kamu capai bulan lalu, dan cek lagi 30 hari kemudian. Kalau kamu ingin side project yang memaksamu berlatih, dashboard uptime dan latency kecil untuk aplikasimu sendiri adalah proyek akhir pekan yang layak. Layanan mana yang paling tidak kamu percaya saat ini? ## FAQ ### Apa itu SLO dengan kata sederhana? SLO adalah target untuk seberapa andal layananmu, diukur dalam jangka waktu tertentu. Misalnya, 99.9% request harus berhasil selama 30 hari. Ini tujuan internal, bukan kontrak. ### Apa perbedaan SLI, SLO, dan SLA? SLI adalah pengukurannya, misalnya persentase respons selain 5xx. SLO adalah target untuk pengukuran itu. SLA adalah kontrak dengan penalti, misalnya kredit, jika kamu gagal memenuhi level yang dijanjikan. ### Berapa downtime yang diizinkan 99.9% per bulan? Sekitar 43 menit dalam bulan 30 hari. Target 99% mengizinkan sekitar 7.2 jam, dan 99.99% mengizinkan sekitar 4.3 menit. ### Apa itu error budget? Itu adalah porsi event yang boleh gagal berdasarkan SLO-mu. Pada 99.9%, 0.1% request boleh gagal. Saat budget hampir habis, kamu menunda rilis yang berisiko dan memperbaiki keandalan dulu. ### SLO apa yang sebaiknya dipakai proyek side project? Mulai dari 99% sampai 99.5%, sedikit di bawah yang kamu capai selama 30 hari terakhir. Perketat hanya ketika pengguna atau pendapatan membenarkan usaha tambahannya. ### Apakah saya perlu tool berbayar untuk melacak SLO? Tidak. Sebuah file di repo, jumlah request dari aplikasimu, dan satu query sederhana sudah cukup untuk memulai. Tool seperti Grafana atau New Relic membantu saat kamu ingin alert burn rate dan dashboard. ### Apa itu burn rate? Burn rate adalah seberapa cepat kamu menghabiskan error budget dibanding laju yang akan menghabiskannya tepat di akhir jendela waktu. Burn rate 10 berarti budget habis dalam sekitar tiga hari pada jendela 30 hari.