Belajar Principal Engineer - Reliability at Scale

#Pendahuluan

Setelah di episode 13 kalian belajar mendiagnosis dan menaikkan velocity organisasi — pada episode ini kita bicarakan sisi lain dari kecepatan: reliability. Org yang cepat tapi sering jatuh sedang meminjam kepercayaan pelanggan dengan bunga mahal; org yang andal tapi lambat kalah kompetisi. Principal adalah penjaga keseimbangan ini.

Mengapa level org? Karena reliability gagal secara sistemik, bukan per tim: satu service lambat bisa menjatuhkan checkout, satu tim tanpa SLO bisa menghabiskan error budget global. Program reliability organisasi — SLO, error budget, incident excellence — adalah infrastruktur sosial-teknis yang hanya bisa dibangun dari posisi seperti kalian.

#Dari Uptime ke SLO

Uptime "99.9%" global hampir tidak berarti apa-apa: ia tidak menyebut siapa penggunanya, operasi apa, atau seberapa buruk saat melanggar. SLO yang benar menjawab tiga hal:

SLI: indikator persentase permintaan sukses (bukan rata-rata latensi!).
Target: misal 99.9% permintaan read sukses dalam 300 ms per rolling 28 hari.
Error budget: sisa toleransi kegagalan = 100% − target.

Contoh definisi lintas layanan:

Layanan	SLI	Target	Error Budget/28 hari
Checkout API	% request sukses < 500 ms	99.95%	~21 menit
Search API	% request sukses < 300 ms	99.9%	~43 menit
Dashboard internal	% render sukses	99.5%	~3,5 jam

Perhatikan targetnya berbeda-beda sesuai nilai bisnis — itu poin utamanya. SLO adalah keputusan produk tentang risiko yang mau ditanggung, bukan prestasi teknis untuk menyamakan semua angka jadi lima sembilan.

#Error Budget sebagai Kontrak Perilaku

Kekuatan sesungguhnya ada di error budget, karena ia mengubah debat abadi "fitur vs stabil" menjadi aturan mekanis:

Kebijakan error budget

Budget tersisa > 25%   -> bebas rilis fitur normal
Budget tersisa 0-25%   -> rilis butuh review tambahan,
                          prioritas refactor reliability
Budget habis           -> freeze fitur non-kritis sampai
                          budget pulih, postmortem wajib

Aturan ini hanya bekerja jika dua syarat terpenuhi: (1) eksekutif setuju sejak awal — karena freeze fitur adalah keputusan bisnis; (2) data SLO dipercaya semua pihak — satu dashboard, definisi sama, tidak bisa direkayasa per tim.

Important

Jangan mulai dengan 50 SLO. Program pertama yang berhasil biasanya mencakup 5-8 layanan kritikal bisnis saja. Adopsi lewat bukti ("tim checkout berhenti berdebat soal rilis sejak pakai budget") lebih berharga daripada cakupan luas yang setengah hati.

#Incident Excellence

Insiden akan tetap terjadi — reliability bukan nol insiden, melainkan respons dan pembelajaran yang konsisten. Tiga komponen programnya:

#1. Severity Matrix yang Disepakati

Level	Definisi	Respons
SEV-1	Pelanggan utama tak bisa bertransaksi	All-hands, comms tiap 30 menit
SEV-2	Degradasi signifikan, workaround ada	Tim on-call + IC ditunjuk
SEV-3	Gangguan lokal/minor	Jam kerja normal

Tanpa matriks ini, setiap insiden dibuka dengan debat tingkat keparahan — waktu emas hilang untuk ego.

#2. Peran Jelas Saat Insiden

Dua peran yang paling sering hilang dan paling menentukan: Incident Commander (koordinasi, bukan debugging) dan Communicator (update stakeholder/pelanggan). Engineer terbaik jarang harus jadi IC; jadikan IC orang paling tenang, bukan paling pintar.

#3. Postmortem Blameless

Blameless bukan artinya tanpa akuntabilitas — artinya fokus analisis pada sistem yang memungkinkan manusia salah, bukan manusianya:

postmortem/template.md

# Postmortem: [Judul] - [Tanggal] - [SEV]
 
## Ringkasan 3 Kalimat
Apa terjadi, dampak, durasi, status sekarang.
 
## Timeline Faktual
Waktu deteksi -> mitigasi -> resolusi. Tanpa opini.
 
## Akar Masalah (kenapa-berlapis)
Teknis + proses + faktor organisasi yang memungkinkannya.
 
## Apa yang Berjalan Baik
Deteksi cepat? Mitigasi tepat? Catat agar tetap.
 
## Action Items
Tiap item: pemilik, tenggat, tiket terhubung.
Prioritaskan item yang menghapus kelas kesalahan,
bukan sekadar insiden spesifik ini.

Kalimat terakhir templat itulah pembeda program matang: perbaikan yang mencegah kelas kegagalan berikutnya, bukan sekadar patch satu lubang.

#Rollout Program Reliability

Program org-wide dijalankan seperti inisiatif besar episode 6:

Gelombang 1: pilih 3-5 layanan kritikal, definisikan SLO bersama timnya, jalankan kebijakan budget selama satu kuartal dalam mode shadow (tanpa freeze sungguhan).
Evaluasi & playbook: apakah budget cukup realistis? Sesuaikan target, dokumentasikan cara menghitung SLI.
Gelombang 2: perluasan ke domain lain + incident roles dilatih via tabletop exercise (simulasi SEV-1).
Gelombang 3: SLO masuk review arsitektur standar; dashboard publik internal; laporan bulanan reliability ke eksekutif.

Warning

Kegagalan klasik program SLO: target ditetapkan dari atas tanpa data baseline. Hasilnya angka yang tidak dipercaya dan kebijakan yang diabaikan diam-diam. Selalu mulai dengan mengukur perilaku nyata 4-8 minggu sebelum menetapkan target apa pun.

#Praktik

Di workspace kalian:

Pilih tiga layanan kritikal; tulis draft SLO + error budget dengan tabel di atas.
Draft severity matrix org kalian; bandingkan dengan praktik insiden terakhir yang kalian kenal.
Adaptasi templat postmortem; audit satu postmortem lama — apakah action items-nya mencegah kelas kegagalan?
Rancang gelombang rollout satu halaman untuk org kalian.

#Penutup

Inti yang harus dibawa pulang:

SLO menjawab siapa/operasi apa/seberapa toleran — target berbeda per nilai bisnis, bukan seragam.
Error budget adalah kontrak perilaku fitur-vs-stabil; butuh persetujuan eksekutif dan data yang dipercaya.
Incident excellence = severity matrix + peran IC/Communicator + postmortem yang mencegah kelas kegagalan.
Rollout bertahap: shadow dulu, playbook, baru standar org-wide.

Di episode 15 selanjutnya kita membahas data-driven org decisions — membangun hierarki metrik organisasi dari north star sampai input metrics, budaya eksperimen dengan guardrail metrics, dan cara menghindari Goodhart's law yang merusak program metrik kalian. Sampai jumpa di episode 15!