Site Reliability Engineering (SRE) adalah cara menjaga aplikasi tetap andal dengan pendekatan software engineering: keandalan diukur dengan angka, diberi target, dan sisa "jatah gagal"-nya dipakai untuk memutuskan kapan boleh merilis fitur dan kapan harus berhenti dan memperbaiki. Disiplin ini lahir di Google. Bayangin PO bus antarkota yang berjanji "99% keberangkatan tepat waktu". Mereka menghitung keberangkatan yang tepat waktu dibagi semua keberangkatan. Dari 3.000 keberangkatan sebulan, 1% atau 30 keberangkatan boleh telat. Kalau jatah 30 itu sudah habis tanggal 20, rute baru ditunda dan semua mekanik fokus memperbaiki bus. Di tiket ada janji lain lagi: telat lebih dari satu jam, uang kembali.
🧪 Tebakan cepat: dalam 30 hari terakhir, catatan-api melayani 2.506.020 request, dan 3.973 di antaranya gagal (error 5xx). Itu 99,84% berhasil. SLO-nya 99,9%. Lolos atau gak? Tebak dulu, jawabannya ada di bagian "Menghitung dari data sebulan".
SLI, SLO, SLA
Tiga istilah ini sering tertukar, padahal pertanyaannya beda:
| Istilah | Artinya | Contoh catatan-api | Bus |
|---|---|---|---|
| SLI (Service Level Indicator) | metrik yang diukur | request yang gak 5xx ÷ semua request | keberangkatan tepat waktu ÷ semua |
| SLO (Service Level Objective) | target internal untuk SLI | 99,9% per 30 hari | 99% per bulan |
| SLA (Service Level Agreement) | kontrak dengan pelanggan, ada konsekuensinya | 99,5% per bulan, kalau gagal kompensasi 10% | uang kembali kalau telat sejam |
- SLI selalu berupa perbandingan "yang baik ÷ semua". Selain availability, SLI yang umum adalah latency: persentase request yang selesai di bawah 300 ms.
- SLA dibuat lebih longgar dari SLO. Kalau SLO 99,9% mulai terancam, tim sudah bertindak jauh sebelum kontrak 99,5% dilanggar.
- Target 100% itu salah. Koneksi internet pengguna sendiri gak 100%, dan mengejarnya membuat tim gak pernah boleh mengubah apa pun.
Menghitung dari data sebulan
Ini data catatan-api untuk 30 hari terakhir (window SLO-nya), sama dengan di Lab. Beberapa hari penting:
| Hari | Request | Gagal | Gagal kumulatif | Catatan |
|---|---|---|---|---|
| 1 | 89.770 | 20 | 20 | hari biasa |
| 8 | 92.180 | 20 | 197 | hari biasa |
| 9 | 88.980 | 975 | 1.172 | deploy salah ketik nama tabel, 21 menit error |
| 18 | 61.400 | 25 | 1.421 | hari Minggu |
| 19 | 92.100 | 2.271 | 3.692 | disk Postgres penuh, 35 menit down |
| 30 | 94.100 | 28 | 3.973 | akhir window |
SLI-nya: (1 − 3.973 ÷ 2.506.020) × 100 = 99,84%. Kedengarannya tinggi, tapi di bawah 99,9%. Jadi gak lolos. Itu jawaban tebakannya. Angka 99,84% dan 99,9% kelihatan dekat, tapi yang dibandingkan adalah sisanya: 0,16% gagal berarti 1,6 kali jatah 0,1%.
Error budget
Error budget adalah jumlah kegagalan yang masih boleh terjadi sesuai SLO: 100% − SLO.
- Dalam request: 0,1% × 2.506.020 = 2.506 request gagal sebulan.
- Dalam waktu: 0,1% × 30 hari × 24 jam × 60 menit = 43,2 menit down sebulan.
Budget yang terpakai sepanjang bulan: hari ke-8 baru 8%, setelah insiden hari ke-9 jadi 47%, hari ke-18 57%, dan insiden hari ke-19 membuatnya 147%: habis. Makin ketat SLO, makin kecil budget-nya:
| SLO | Error budget 30 hari | Dalam request bulan ini | Habis di hari ke- |
|---|---|---|---|
| 99% | 7 jam 12 menit | 25.060 | gak habis (16%) |
| 99,5% | 3 jam 36 menit | 12.530 | gak habis (32%) |
| 99,9% | 43 menit | 2.506 | 19 |
| 99,99% | 4 menit | 250 | 9 |
Kalau budget habis
Tim menulis error budget policy sebelum ada insiden, supaya keputusannya gak diperdebatkan saat panik. Contoh policy dari buku SRE Google, diterapkan ke catatan-api:
- Selama SLI 30 hari terakhir di bawah SLO, rilis fitur dibekukan. Yang boleh deploy cuma perbaikan reliability dan keamanan.
- Insiden yang menghabiskan lebih dari 20% budget wajib ditulis postmortem: kronologi, akar masalah, dan tindakan supaya gak terulang (pelajaran Incident Response & Postmortems).
- Rilis fitur jalan lagi setelah hari-hari buruk keluar dari window 30 hari dan SLI kembali di atas SLO.
Sebaliknya, budget yang masih banyak boleh dipakai untuk mengambil risiko: rilis lebih sering, atau coba fitur baru lewat feature flag. Error budget membuat tim produk dan tim operasional berbagi satu angka, bukan saling tarik.
Toil
Toil adalah pekerjaan operasional yang manual, berulang, bisa diotomasi, gak menambah nilai jangka panjang, dan bertambah seiring aplikasi tumbuh. Google membatasi toil maksimal 50% waktu seorang SRE; sisanya untuk engineering yang menghapus toil itu. Sepanjang track ini kita sudah menghapus beberapa:
| Toil | Diganti dengan |
|---|---|
| SSH ke web-1 untuk deploy dengan tangan | pipeline CI/CD |
| Menyalakan ulang app yang crash tengah malam | systemd Restart= atau restart: unless-stopped |
| Memperpanjang sertifikat TLS tiap 90 hari | certbot dengan timer otomatis |
Menjalankan pg_dump sendiri |
cron 0 2 * * * dan restore drill |
Latihan: calculateErrorBudget
calculateErrorBudget(sloPercent, periodDays) mengembalikan { slo, errorBudgetPercent, downtimeMinutes, downtimeFormatted }. Satu jebakan JavaScript: 100 - 99.9 menghasilkan 0.09999999999999432, bukan 0.1, karena desimal disimpan sebagai biner. Bulatkan ke 2 angka di belakang koma dengan Number((100 - sloPercent).toFixed(2)). Lalu:
downtimeMinutes=Math.round(errorBudgetPercent / 100 × periodDays × 24 × 60): untuk 99,9% dan 30 hari, 43,2 jadi43.downtimeFormatted= jam (Math.floor(menit / 60)) +"h "+ sisa menit +"m":"0h 43m".
⚠️ Jebakan yang sering ketemu
- Membaca 99,84% sebagai "hampir 99,9%". Bandingkan kegagalannya, bukan keberhasilannya: 0,16% gagal adalah 160% dari budget 0,1%.
- SLA sama dengan SLO, atau lebih ketat. Tim baru tahu ada masalah saat sudah membayar kompensasi. SLA selalu lebih longgar.
- Target 99,99% untuk app kecil. Budget 4 menit sebulan habis oleh hari-hari biasa, jadi tim gak pernah boleh rilis.
- Floating point di perhitungan budget.
100 - 99.9bukan0.1di JavaScript; bulatkan dulu.
TL;DR: SRE (Site Reliability Engineering) mengukur keandalan dengan angka. SLI adalah metrik terukur (request yang gak 5xx ÷ semua request), SLO adalah target internal (99,9% per 30 hari), SLA adalah kontrak dengan pelanggan yang lebih longgar dan punya konsekuensi. Error budget = 100% − SLO: untuk catatan-api 2.506 request atau 43 menit sebulan. Bulan ini 3.973 request gagal, SLI 99,84%, budget habis di hari ke-19. Saat budget habis, error budget policy membekukan rilis fitur sampai SLI pulih; budget yang tersisa boleh dipakai untuk mengambil risiko. Toil (pekerjaan manual berulang) diganti otomasi, maksimal 50% waktu. Di JavaScript, bulatkan 100 - SLO dengan toFixed(2).
