SLO untuk alat internal: target keandalan sederhana yang efektif

Mengapa alat internal membutuhkan SLO (bahkan jika hanya 20 orang menggunakannya)

Alat internal terasa kecil karena audiensnya sedikit. Dampaknya seringkali tidak kecil: jika dashboard operasional Anda mati, pesanan berhenti; jika konsol dukungan lambat, pelanggan menunggu; jika panel admin rusak, perbaikan menumpuk.

Tanpa target keandalan yang jelas, setiap gangguan jadi bahan debat. Satu orang menganggap gangguan 10 menit sepele, yang lain menganggapnya krisis. Anda kehilangan waktu karena chat berisik, prioritas yang tidak jelas, dan pekerjaan mendadak pada saat terburuk.

SLO memperbaiki itu dengan menetapkan ekspektasi sederhana yang bisa diukur. Mereka menjawab dua pertanyaan praktis: apa yang harus bekerja, dan seberapa baik harus bekerja agar orang bisa melakukan tugas mereka.

Biaya tersembunyi dari “kita akan jaga cukup stabil” cepat terlihat. Pekerjaan berhenti sementara tim menunggu alat pulih. Ping dukungan bertambah karena tidak ada yang tahu apa yang normal. Insinyur ditarik ke perbaikan mendesak daripada peningkatan terencana. Product owner berhenti percaya pada sistem dan mulai meminta cadangan manual. Masalah kecil bertahan karena belum pernah melewati garis yang jelas.

Anda tidak perlu program keandalan penuh. Tim kecil bisa memulai dengan beberapa tujuan berfokus pengguna seperti “login bekerja” atau “hasil pencarian cepat dimuat,” plus sejumlah kecil alert yang terkait tindakan nyata.

Ini berlaku terlepas bagaimana alat dibangun. Jika Anda menggunakan AppMaster (appmaster.io) untuk membuat aplikasi internal, pilih aksi yang diandalkan orang, ukur uptime dan waktu respon, dan alert hanya saat itu memengaruhi pekerjaan.

SLO, SLI, dan SLA dengan kata sederhana

Ketiga istilah ini terdengar mirip, tapi mereka jenis bahasa keandalan yang berbeda. Mencampurnya adalah sumber kebingungan yang umum.

Sebuah SLI (Service Level Indicator) adalah pengukuran. Itu sesuatu yang bisa Anda hitung, seperti “persentase permintaan yang berhasil” atau “berapa lama halaman dimuat.” Jika Anda tidak bisa mengukurnya secara andal, itu bukan SLI yang baik.

Sebuah SLO (Service Level Objective) adalah target untuk pengukuran itu. Ia menjawab: tingkat apa yang cukup baik bagi pengguna sebagian besar waktu? SLO membantu Anda memutuskan apa yang harus diperbaiki dulu dan apa yang bisa ditunda.

Sebuah SLA (Service Level Agreement) adalah janji, biasanya tertulis, sering dengan konsekuensi. Banyak alat internal tidak perlu SLA sama sekali. Mereka butuh tujuan yang jelas, bukan komitmen gaya hukum.

Contoh singkat:

• SLI (uptime): Persentase menit tool dapat dijangkau.
• SLO (tujuan uptime): 99.9% uptime bulanan.
• SLI (latensi): p95 waktu muat halaman untuk dashboard.
• SLO (tujuan latensi): p95 di bawah 2 detik selama jam kerja.

Perhatikan yang hilang: “tidak pernah down” atau “selalu cepat.” SLO bukan tentang kesempurnaan. Mereka membuat trade-off terlihat sehingga tim kecil dapat memilih antara fitur, pekerjaan keandalan, dan menghindari kerja yang tidak perlu.

Aturan praktis: jika memenuhi target memerlukan aksi heroik, itu bukan SLO, itu angan-angan. Mulailah dengan sesuatu yang tim Anda bisa pertahankan dengan tenang, lalu perketat nanti jika pengguna masih merasakan sakit.

Pilih beberapa aksi pengguna yang benar-benar penting

Alat internal gagal dengan cara spesifik: panel admin terbuka tapi menyimpan record berputar selamanya; dashboard ops terbuka tapi grafik tidak pernah refresh; portal staf bekerja kecuali login rusak setelah pembaruan. Anda mendapatkan nilai paling besar dengan fokus pada aksi yang diandalkan orang setiap hari, bukan setiap halaman dan tombol.

Mulailah dengan menamai tipe alat, karena itu memberi petunjuk jalur kritis. Panel admin tentang “mengubah sesuatu dengan aman.” Dashboard ops tentang “melihat apa yang terjadi sekarang.” Portal tentang “masuk, menemukan info, dan mengirim permintaan.”

Lalu tuliskan perjalanan pengguna teratas dalam bahasa sederhana. Satu set awal yang baik:

• Login dan sampai ke layar utama
• Cari atau filter dan dapatkan hasil
• Kirim form (buat/perbarui) dan lihat pesan sukses
• Muat tampilan dashboard utama dengan data segar
• Ekspor atau unduh laporan yang dipakai dalam pekerjaan harian

Untuk setiap perjalanan, definisikan apa yang dianggap kegagalan. Bersikap ketat dan terukur: error 500 adalah kegagalan, begitu juga timeout, halaman yang tak pernah selesai memuat, atau form yang memberi status sukses sementara datanya hilang.

Jaga ruang lingkup kecil pada awalnya. Pilih 1 sampai 3 perjalanan yang cocok dengan rasa sakit nyata dan risiko nyata. Jika halaman on-call biasanya “tak seorang pun bisa login” dan “tombol simpan macet,” mulai dengan Login dan Kirim form. Tambahkan Pencarian nanti setelah Anda percaya pada pengukuran dan alert.

Pilih SLI yang benar-benar bisa Anda ukur

SLI yang baik itu membosankan. Mereka berasal dari data yang sudah Anda miliki, dan mereka cocok dengan apa yang pengguna rasakan saat alat bekerja atau gagal. Jika Anda perlu seluruh setup monitoring baru cuma untuk mengukurnya, pilih SLI yang lebih sederhana.

Mulailah dengan availability dalam istilah yang orang pahami: dapatkah saya membuka alat dan menyelesaikan tugas? Untuk banyak alat internal, dua SLI menutupi sebagian besar rasa sakit:

• Uptime untuk alat (dapat dijangkau dan merespon)
• Tingkat keberhasilan untuk 1 sampai 3 aksi kunci (login, pencarian, simpan, approve)

Lalu tambahkan latensi, tapi tetap sempit. Pilih satu atau dua layar atau endpoint yang mewakili keluhan tunggu pengguna, seperti memuat dashboard atau mengirim form. Mengukur segalanya biasanya menimbulkan kebisingan dan perdebatan.

Tentukan jendela pengukuran di muka. Periode 30 hari bergulir umum untuk alat yang stabil; mingguan bisa bekerja saat Anda sering merilis dan ingin umpan balik cepat. Apa pun yang Anda pilih, pertahankan agar tren berarti.

Akhirnya, pilih satu sumber kebenaran per SLI dan tuliskan:

• Cek sintetis (bot memanggil health check atau menjalankan flow sederhana)
• Metrik server (jumlah permintaan, error, latensi dari backend Anda)
• Log (hitung event “sukses” vs “gagal” untuk aksi tertentu)

Contoh: jika aplikasi internal Anda dibangun di AppMaster, Anda bisa mengukur uptime dengan ping sintetis ke backend, tingkat keberhasilan dari respons API, dan latensi dari waktu request backend. Kuncinya konsistensi, bukan kesempurnaan.

Tetapkan SLO uptime dan latensi yang realistis

Mulailah dengan memilih angka uptime yang bisa Anda pertahankan di minggu yang buruk. Untuk banyak alat internal, 99.5% adalah SLO awal yang baik. Kedengarannya tinggi, tapi memberi ruang untuk pekerjaan perubahan normal. Langsung ke 99.9% sering berarti paging di luar jam dan rilis lebih lambat.

Untuk membuat uptime terasa nyata, ubah ke waktu. Bulan 30 hari punya sekitar 43.200 menit:

• 99.5% uptime mengizinkan sekitar 216 menit downtime per bulan
• 99.9% uptime mengizinkan sekitar 43 menit downtime per bulan

Downtime yang diizinkan itu adalah error budget Anda. Jika Anda menghabiskannya lebih awal, hentikan perubahan berisiko dan fokus pada keandalan sampai kembali ke jalur.

Untuk latensi, hindari rata-rata. Ia menyembunyikan momen lambat yang diingat pengguna. Gunakan persentil (biasanya p95) dan tetapkan ambang jelas yang terkait aksi nyata. Contoh: “p95 muat dashboard di bawah 2 detik” atau “p95 Simpan selesai di bawah 800 ms.”

Cara sederhana men-setting angka pertama adalah memantau satu minggu trafik nyata, lalu pilih target sedikit lebih baik dari kondisi hari ini tapi bukan fantasi. Jika p95 saat ini 1.9 detik, SLO 2.0 detik aman dan berguna. SLO 500 ms hanya akan menimbulkan kebisingan.

Cocokkan SLO dengan kapasitas dukungan Anda. Tim kecil harus memilih beberapa target yang dapat dicapai daripada banyak target ketat. Jika tidak ada yang bisa merespon dalam satu jam, jangan tetapkan tujuan yang mengasumsikan mereka bisa.

Buat trade-off terlihat: biaya, risiko, dan error budget

SLO yang lebih ketat terdengar menenangkan, tapi ada harganya. Jika Anda menggeser alat dari 99.5% ke 99.9% uptime, Anda juga mengatakan “kita menerima jauh lebih sedikit menit buruk,” yang biasanya berarti lebih banyak paging dan lebih banyak waktu dihabiskan untuk keandalan alih-alih fitur baru.

Cara paling sederhana membuat ini nyata adalah berbicara dalam error budget. Dengan target 99.5% bulanan, Anda bisa “menghabiskan” sekitar 3.6 jam downtime dalam 30 hari. Dengan 99.9%, Anda hanya mendapat sekitar 43 menit. Perbedaan itu mengubah seberapa sering Anda akan menghentikan pekerjaan fitur untuk memperbaiki keandalan.

Juga bantu mencocokkan ekspektasi ke kapan orang benar-benar menggunakan alat. Target 24/7 mahal jika alat hanya kritikal 9am–6pm. Anda bisa menetapkan satu SLO untuk jam kerja (lebih ketat) dan yang longgar di luar jam (lebih sedikit paging) agar tim bisa tidur.

Maintenance terjadwal seharusnya tidak dihitung sebagai kegagalan selama dikomunikasikan dan dibatasi. Perlakukan itu sebagai pengecualian eksplisit (jendela maintenance) daripada mengabaikan alert setelahnya.

Tulis hal-hal dasar agar semua orang melihat trade-off:

• Angka SLO dan apa yang hilang pengguna saat terlewat
• Error budget per bulan (dalam menit atau jam)
• Aturan paging (siapa, kapan, dan untuk apa)
• Ekspektasi jam kerja vs 24/7, jika berbeda
• Apa yang dihitung sebagai maintenance terjadwal

Setelah 4–6 minggu data nyata, tinjau target. Jika Anda tak pernah menghabiskan error budget, SLO mungkin terlalu longgar. Jika cepat habis dan fitur terhenti, kemungkinan terlalu ketat.

Peta SLO ke alert yang bisa tim Anda pertahankan

Alert bukanlah SLO Anda. Alert adalah sinyal “ada yang salah sekarang” yang melindungi SLO. Aturan sederhana: untuk setiap SLO, buat satu alert yang penting, dan tahan diri untuk menambahkan lebih banyak kecuali Anda bisa membuktikan mereka mengurangi downtime.

Pendekatan praktis adalah paging pada burn error budget yang cepat (seberapa cepat Anda memakai error budget) atau pada satu ambang jelas yang sesuai rasa sakit pengguna. Jika SLO latensi Anda “p95 di bawah 800 ms,” jangan page pada setiap spike lambat. Page hanya saat berlanjut.

Pemisahan sederhana yang menjaga kebisingan:

• Page mendesak: alat pada dasarnya rusak, dan seseorang harus bertindak sekarang.
• Tiket non-darurat: sesuatu menurun, tapi bisa menunggu sampai jam kerja.

Ambang konkret (sesuaikan dengan trafik Anda): jika SLO uptime 99.5% bulanan, page saat availability turun di bawah 99% selama 10 menit (outage jelas). Buat tiket saat turun di bawah 99.4% selama 6 jam (slow burn). Untuk latensi, page saat p95 di atas 1.5 s selama 15 menit; tiket saat p95 di atas 1.0 s selama 2 jam.

Jelaskan kepemilikan. Putuskan siapa yang on call (meskipun “satu orang minggu ini”), apa arti acknowledge (mis. dalam 10 menit), dan langkah pertama yang harus dilakukan. Untuk tim kecil yang menjalankan aplikasi internal di AppMaster, tindakan pertama bisa: cek deploy terbaru, lihat error API, lalu rollback atau redeploy jika perlu.

Setelah setiap alert nyata, lakukan satu tindak lanjut kecil: perbaiki penyebabnya atau tune alert agar mem-page lebih jarang tapi tetap menangkap dampak pengguna nyata.

Kesalahan umum yang menciptakan alert fatigue

Alert fatigue biasanya dimulai dari niat baik. Tim kecil menambahkan “beberapa” alert, lalu menambah satu lagi setiap minggu. Segera, orang berhenti mempercayai notifikasi, dan outage nyata terlewat.

Satu jebakan besar adalah alert pada setiap spike. Alat internal sering punya trafik bursty (proses payroll, laporan akhir bulan). Jika alert menyala pada blip 2 menit, tim belajar mengabaikannya. Kaitkan alert ke sinyal dampak pengguna, bukan kebisingan metrik mentah.

Jebakan lain adalah berpikir “lebih banyak metrik = lebih aman.” Seringkali berarti lebih banyak page. Tetap pada sedikit sinyal yang benar-benar dirasakan pengguna: login gagal, halaman terlalu lambat, job kunci tidak selesai.

Kesalahan yang paling banyak menimbulkan kebisingan:

• Paging pada gejala (CPU, memori) daripada dampak pengguna (error, latensi)
• Tidak ada pemilik untuk alert, sehingga tak pernah ditune atau dihapus
• Tidak ada runbook, sehingga setiap alert jadi permainan tebak-tebakan
• Mengandalkan dashboard sebagai pengganti alert (dashboard untuk melihat, alert untuk bertindak)
• Menetapkan ambang karena sistem kurang terinstrumentasi

Dashboard tetap penting, tapi mereka membantu diagnosis setelah alert, bukan menggantikan alert.

Jika Anda belum punya pengukuran yang bersih, jangan pura-pura punya. Tambahkan instrumentasi dasar dulu (tingkat keberhasilan, p95 latency, dan cek “apakah pengguna bisa menyelesaikan tugas”), lalu tetapkan ambang berdasarkan satu atau dua minggu data nyata.

Pemeriksaan cepat sebelum mengaktifkan alert

Sebelum Anda mengaktifkan alert, lakukan pra-penerbangan singkat. Sebagian besar alert fatigue muncul dari melewati salah satu dasar ini, lalu mencoba memperbaikinya di bawah tekanan.

Checklist praktis untuk tim kecil:

• Konfirmasi 1 sampai 3 aksi pengguna kunci (mis.: buka dashboard, simpan pembaruan tiket, ekspor laporan).
• Batasi pada 2 sampai 4 SLI yang bisa Anda ukur hari ini (availability/tingkat keberhasilan, p95 latency, tingkat error untuk endpoint kritis).
• Batasi diri pada 2 sampai 4 alert total untuk alat.
• Sepakati jendela pengukuran, termasuk apa arti “buruk” (5 menit terakhir untuk deteksi cepat, atau 30–60 menit terakhir untuk mengurangi kebisingan).
• Tetapkan pemilik (satu orang, bukan “tim”).

Selanjutnya, pastikan alert benar-benar bisa ditindaklanjuti. Alert yang menyala saat tak ada yang tersedia melatih orang untuk mengabaikannya.

Putuskan detail operasi sebelum page pertama:

• Jam paging: hanya jam kerja, atau 24/7 sejati
• Jalur eskalasi: siapa selanjutnya jika orang pertama tak merespon
• Apa yang dilakukan pertama: satu atau dua langkah untuk konfirmasi dampak dan rollback atau mitigasi
• Kebiasaan tinjauan bulanan sederhana: 15 menit untuk melihat alert yang pernah menyala, insiden yang terlewat, dan apakah SLO masih sesuai penggunaan alat

Jika Anda membangun atau mengubah alat (termasuk di AppMaster), jalankan checklist lagi. Kode yang digenerasi ulang dan alur baru dapat menggeser latensi dan pola error, dan alert Anda harus ikut berubah.

Contoh: dashboard ops kecil dengan dua SLO dan tiga alert

Tim ops 18 orang menggunakan dashboard internal sepanjang hari untuk memeriksa status pesanan, mengirim ulang notifikasi yang gagal, dan menyetujui pengembalian dana. Jika down atau lambat, pekerjaan cepat terhenti.

Mereka memilih dua SLO:

• Uptime SLO: 99.9% muat halaman sukses selama 30 hari (sekitar 43 menit “waktu buruk” per bulan)
• SLO Latensi: p95 waktu muat halaman di bawah 1.5 detik selama jam kerja

Sekarang mereka menambahkan tiga alert yang bisa ditangani tim kecil:

• Hard down alert (muat halaman gagal): memicu jika tingkat keberhasilan turun di bawah 98% selama 5 menit. Tindakan pertama: cek deploy terbaru, restart web app, konfirmasi kesehatan database.
• Slow dashboard alert: memicu jika p95 latency di atas 2.5 detik selama 10 menit. Tindakan pertama: cari query tunggal yang lambat atau job background macet, lalu jedakan laporan berat sementara.
• Error budget burn alert: memicu jika mereka berpotensi memakai 50% error budget bulanan dalam 7 hari ke depan. Tindakan pertama: hentikan perubahan non-esensial sampai stabil.

Yang penting adalah apa yang terjadi minggu depan. Jika alert error budget menyala dua kali, tim membuat keputusan jelas: tunda fitur baru dan habiskan dua hari memperbaiki penyebab latensi terbesar (mis. scan tabel tanpa indeks). Jika mereka membangun alat di AppMaster, mereka bisa menyesuaikan model data, regenerasi, dan redeploy kode bersih daripada menumpuk perbaikan cepat.

Cara menjaga SLO tetap hidup tanpa menjadikannya proyek

SLO hanya membantu jika tetap terhubung ke pekerjaan nyata. Triknya memperlakukannya seperti kebiasaan kecil, bukan program baru.

Gunakan cadence yang cocok untuk tim kecil dan kaitkan ke pertemuan yang sudah ada. Sekilas mingguan cepat menangkap drift, dan penyesuaian bulanan cukup setelah Anda punya data nyata.

Proses ringan yang tahan lama:

• Mingguan (10 menit): cek grafik SLO dan beberapa alert terakhir, lalu konfirmasi tidak ada yang semakin buruk diam-diam.
• Setelah insiden apa pun (15 menit): beri tag penyebab dan catat aksi pengguna mana yang terpengaruh (login, pencarian, simpan, ekspor).
• Bulanan (30 menit): tinjau pola insiden berulang teratas dan pilih satu perbaikan untuk bulan berikutnya.
• Bulanan (10 menit): hapus atau tune satu alert yang berisik.

Jaga perbaikan kecil dan terlihat. Jika “muat halaman lambat setiap Senin pagi” muncul tiga kali, lakukan satu perubahan konkret (cache satu laporan, tambah indeks, jadwalkan job berat) lalu amati SLI minggu berikutnya.

Gunakan SLO untuk mengatakan tidak dengan sopan dan jelas. Saat ada permintaan fitur bernilai rendah, tunjukkan error budget saat ini dan tanyakan: “Apakah perubahan ini berisiko pada simpan atau alur persetujuan kita?” Jika Anda sudah memakai budget, keandalan menang. Itu bukan memblokir, itu memprioritaskan.

Simpan dokumentasi minimal: satu halaman per alat. Cantumkan aksi pengguna kunci, angka SLO, beberapa alert yang terkait, dan pemilik. Jika alat dibangun di AppMaster, tambahkan di mana melihat log/metrik dan siapa yang dapat melakukan deploy, lalu selesai.

Langkah berikutnya: mulai kecil, lalu perbaiki satu alat pada satu waktu

Cara termudah membuat keandalan nyata adalah menjaga setup pertama sangat kecil. Pilih satu alat internal yang menimbulkan rasa sakit nyata saat rusak (handoff on-call, persetujuan pesanan, pengembalian dana, edit inventaris), dan tetapkan target di sekitar beberapa aksi yang orang lakukan setiap hari.

Setup terkecil yang bekerja dan bisa ditiru:

• Pilih 1 alat dan 2 aksi pengguna kunci (mis.: Buka dashboard dan Submit persetujuan).
• Definisikan 2 SLI yang bisa Anda ukur sekarang: uptime untuk endpoint/halaman, dan p95 latency untuk aksi.
• Tetapkan 2 SLO sederhana (contoh: 99.5% uptime bulanan, p95 di bawah 800 ms selama jam kerja).
• Buat 2 sampai 3 alert total: satu untuk hard down, satu untuk latensi berkepanjangan, dan satu untuk burn cepat error budget.
• Tinjau sekali seminggu selama 10 menit: apakah alert membantu, atau hanya membuat kebisingan?

Setelah itu stabil, perluas perlahan: tambahkan satu aksi lagi, atau satu alat lagi per bulan. Jika Anda tidak bisa menyebutkan siapa yang akan memiliki alert, jangan buat dulu.

Jika Anda sedang membangun atau membangun ulang alat internal, AppMaster dapat membuat sisi pemeliharaan lebih mudah dipertahankan. Anda bisa memperbarui model data dan logika bisnis secara visual dan menghasilkan kode bersih saat kebutuhan berubah, yang membantu menjaga SLO selaras dengan apa yang alat lakukan hari ini.

Cobalah membangun satu alat internal dan tambahkan SLO dasar sejak hari pertama. Anda akan mendapatkan ekspektasi lebih jelas, lebih sedikit kejutan, dan alert yang bisa diikuti tim kecil Anda.