Belajar Staff Engineer - Reliability & SLO Programs

#Pendahuluan

Setelah di episode 13 kita belajar mendanai dan mengeksekusi program debt & platform, pada episode ini kita fokus pada dimensi yang paling cepat menghancurkan kepercayaan pelanggan jika diabaikan: reliability. Di level staff, kalian tidak lagi hanya memperbaiki service sendiri — kalian membangun program: cara organisasi mendefinisikan, mengukur, dan menjaga reliabilitas lintas puluhan layanan.

Alat utamanya adalah SLO (Service Level Objective) dengan error budget — bukan sebagai dashboard hiasan, melainkan mesin pengambil keputusan: kapan boleh rilis, kapan harus stabilisasi, dan berapa investasi reliability yang pantas.

#Dari Uptime Mentah ke SLO yang Bermakna

Metrik uptime klasik ("99.9%!") punya cacat mendasar: ia mengukur server, bukan pengalaman. Server bisa 100% uptime sementara checkout gagal untuk 5% pengguna karena timeout di dependency. Program modern bekerja bertingkat:

Prinsip pemilihan SLI yang baik: ukur dari sisi pengguna, bukan sisi proses. "CPU di bawah 80%" adalah metrik internal; "95% pencarian selesai dalam 300 ms" adalah pengalaman.

#Menetapkan SLO yang Jujur

Dua kesalahan umum saat menetapkan SLO:

1. SLO ambisius tanpa dasar — memilih 99.99% karena terdengar profesional lalu melanggarnya tiap bulan; angka yang selalu dilanggar kehilangan seluruh nilai sinyalnya.
2. SLO seragam untuk semua layanan — layanan internal admin dan checkout pelanggan punya kebutuhan beda; satu angka untuk semua berarti tak ada yang dipikirkan.

Cara yang benar: mulai dari data nyata (p90/p95/p99 historis), tanya apa yang benar-benar dirasakan pengguna, lalu set target sedikit di atas performa saat ini dengan biaya peningkatan yang diketahui.

#Error Budget Policy: Mesin Keputusannya

Nilai sesungguhnya error budget ada pada policy: aturan otomatis tentang apa yang terjadi saat budget habis atau tersisa banyak.

Budget > 50%  : normal - rilis bebas sesuai standar.
Budget 25-50% : perhatian - rilis fitur non-kritis ditinjau lead.
Budget 10-25% : pembatasan - hanya bugfix + reliability work.
Budget < 10%  : freeze rilis fitur; sprint reliability wajib;
                review arsitektur penyebab dominan.

Kekuatan policy ini: ia mengubah debat emosional ("kita harus rilis!" vs "tunggu dulu!") menjadi keputusan mekanis yang sudah disepakati semua pihak saat kepala dingin. Manajemen produk dan engineering sama-sama meratifikasi policy sekali, lalu tidak perlu berdebat tiap pekan.

#Postmortem Blameless yang Benar-benar Belajar

Program reliability hidup dari insiden yang dipelajari. Budaya postmortem yang gagal biasanya bukan soal format, tapi soal dua hal: menyalahkan orang dan temuan yang tidak dieksekusi.

Struktur postmortem efektif:

1. Timeline fakta — deteksi, mitigasi, resolusi, dengan timestamp; pisahkan fakta dari interpretasi.
2. Dampak — durasi, cakupan pengguna, dampak bisnis dalam angka.
3. Penyebab sistemik — bukan "engineer salah ketik", melainkan "proses deploy memungkinkan perubahan produksi tanpa gate". Pertanyaan pembeda: orang lain akan melakukan hal sama dalam kondisi serupa? Jika ya, itu kegagalan sistem.
4. Aksi dengan pemilik dan tenggat — maksimal 3-5 aksi; lebih dari itu berarti belum difilter prioritas.
5. Review bulanan aksi tertunda — tanpa ini, postmortem menjadi teater dokumentasi.

Aturan blameless perlu dijaga aktif oleh senior di ruangan — termasuk kalian. Satu lelucon menyalahkan cukup membuat orang berikutnya menyembunyikan kesalahan.

#Praktik: Rencana Program Reliability 90 Hari

Program lintas tim butuh rencana bertahap. Susun ~/staff-lab/initiatives/reliability-program.md:

# Program Reliability 90 Hari
 
Fase 1 (pekan 1-4): Fondasi
- Pilih 3 layanan user-facing terpenting (checkout, auth, search).
- Definisikan SLI + SLO draft bersama tim masing-masing.
- Pasang dashboard error budget otomatis (alerting burn-rate).
 
Fase 2 (pekan 5-8): Policy & ritual
- Ratifikasi error budget policy bersama PM + VP Eng.
- Format postmortem standar + review aksi bulanan dimulai.
- Dry-run: simulasi budget habis -> latih jalur eskalasi.
 
Fase 3 (pekan 9-12): Skala
- Perluas ke 8 layanan berikutnya via template + workshop.
- Review kuartalan: SLO mana yang terlalu longgar/ketat.
- Publikasikan scorecard reliability antar tim (transparansi).
 
Ukuran sukses hari ke-90:
- 11 layanan punya SLO + dashboard burn-rate aktif.
- 2 insiden ditutup dengan postmortem beraksi tereksekusi.
- Keputusan rilis pertama dibuat via budget policy (bukan drama).

Catatan penting baris scorecard antar tim: transparansi menciptakan tekanan sosial yang bekerja lebih baik daripada mandat — asalkan scorecard dipakai untuk belajar, bukan ranking yang dihukum.

#Pitfall Umum Program Reliability

• SLO tanpa konsekuensi — dashboard indah yang tidak pernah mengubah keputusan apa pun; pasang policy atau jangan bangun sama sekali.
• Alert fatigue — alerting per-SLI mentah menghasilkan kebisingan; gunakan multi-window burn-rate alerts agar alarm berarti "budget terbakar abnormal", bukan "ada spike sesaat".
• Postmortem jadi novel — dokumen 12 halaman yang tak dibaca; satu-dua halaman dengan aksi konkret mengalahkan analisis filosofis.
• Reliability = tugas SRE saja — program mati jika developer tidak ikut; SLO milik tim pemilik layanan, kalian fasilitator dan penjaga standar.
• Melompat ke tooling mahal — platform observability canggih tanpa definisi SLI hanyalah biaya baru; urutan yang benar: definisi → policy → tooling.

#Penutup

Inti yang harus dibawa pulang:

• Ukur dari sisi pengguna: SLI → SLO → error budget; hindari SLO ambisius tanpa dasar dan target seragam semua layanan.
• Error budget policy mengubah debat rilis menjadi keputusan mekanis yang telah diratifikasi.
• Postmortem blameless hidup dari penyebab sistemik dan aksi tereksekusi, bukan format dokumen.
• Program 90 hari: fondasi 3 layanan → policy & ritual → skala via template dan transparansi.

Di episode 15 selanjutnya kita akan membahas data & metrics for decisions — kerangka metrik teknis dan bisnis untuk mengambil keputusan, jebakan vanity metrics dan Goodhart's law, serta cara menyusun metrics framework yang membuat argumen kalian tak terbantahkan. Sampai jumpa di episode 15!