Belajar Technical Product Manager - Reliability & SLO as Product

#Pendahuluan

Setelah di episode 12 kita menyelesaikan estimate plan migrasi settlement dengan three-point estimation dan confidence band, kini kita bahas janji yang membuat merchant berani mempercayakan uangnya kepada NusaPay: reliability. Dan lebih penting dari itu — cara mengelolanya sebagai produk, bukan sebagai sumpah serapah "kami akan selalu online".

Kenapa reliability adalah ranah TPM? Karena setiap tingkat reliability punya harga (infrastruktur, kompleksitas, kecepatan pengembangan) dan nilai (revenue terlindungi, kontrak enterprise). Menentukan tingkat yang tepat adalah trade-off ekonomi — persis jenis keputusan yang dipegang TPM, bukan engineer.

#SLI, SLO, SLA: Tiga Lapis Janji

Istilah	Arti	Contoh NusaPay	Sifat
SLI (Indicator)	Metrik kesehatan mentah yang diukur	Proporsi request create-payment dengan latency di bawah 800 ms	Internal, banyak
SLO (Objective)	Target yang dikomitmenkan ke diri sendiri	99.9% request dalam sebulan di bawah ambang	Internal target
SLA (Agreement)	Janji formal ke customer beserta konsekuensi	Uptime API 99.95%; pelanggaran = service credit	Eksternal, sedikit

Hubungannya berlapis: kalian mengukur banyak SLI, memilih beberapa untuk jadi SLO, dan hanya sebagian kecil SLO yang dinaikkan jadi SLA kontrak. Kesalahan umum perusahaan muda: menulis SLA dulu di sales deck tanpa SLO internal — janji tanpa mesin pengukur.

Pemilihan SLI yang baik harus mencerminkan pengalaman user: bukan "server hidup", melainkan "request berhasil dalam waktu wajar". Server bisa hidup sementara 8% transaksi gagal diam-diam — itu justru skenario paling merusak.

#Error Budget: Reliabilitas yang Bisa Dihitung

99.9% availability berarti boleh gagal 0.1% — itulah error budget. Untuk bulan 30 hari, budgetnya:

Error budget per bulan

Availability SLO 99.9%:
  budget gagal   = 43.2 menit downtime ekuivalen per bulan
 
Latency SLO (p95 <= 800 ms pada 99%):
  budget lambat  = ~7.2 jam request-lambat per bulan

Konsep ini revolusioner karena mengubah debat abadi "stabilitas vs fitur" menjadi aritmatika:

Budget tersisa banyak: tim bebas rilis agresif; risiko sudah dibayar.
Budget hampir habis: freeze fitur berisiko, fokus stabilitas sampai budget pulih.
Budget habis: insiden review wajib, rilis hanya fix.

Keputusan "rilis atau tidak" tidak lagi bergantung suara paling keras di ruangan — ia mengikuti saldo budget. Itulah kenapa SLO disebut alat perdamaian engineering dan product.

#Contoh SLO Settlement NusaPay

slo-settlement.yaml

service: settlement-api
window: 28d
objectives:
  - sli: availability
    target: 99.9%
    measurement: successful_requests / total_requests
  - sli: latency
    target_p95_ms: 800
    measurement: histogram_create_settlement
  - sli: correctness
    target: 100%
    measurement: ledger_reconciliation_mismatch == 0
error_budget_policy:
  burn_rate_fast: 14x dalam 1 jam -> page on-call
  burn_rate_slow: 3x dalam 6 jam -> eskalasi TPM + eng lead
  budget_habis: freeze rilis fitur; hanya fix & mitigasi

Perhatikan objective ketiga — correctness: rekonsiliasi ledger tanpa selisih. Untuk produk finansial, sistem bisa cepat dan available tapi salah, dan itu jauh lebih buruk. TPM yang mendefinisikan "benar" untuk domainnya adalah kontribusi desain, bukan administrasi.

Kebijakan di bagian error_budget_policy juga penting: burn rate cepat memicu paging manusia, burn rate lambat memicu eskalasi produk. Tanpa kebijakan tertulis, dashboard error budget hanya pajangan.

#Trade-off: Berapa 9 yang Layak Dibeli?

Setiap digit sembilan mahal secara non-linear:

Target	Downtime/bulan	Implikasi kasar
99%	~7.2 jam	Setup standar, deploy siang hari
99.9%	~43 menit	Redundansi multi-zone, on-call, runbook
99.99%	~4.3 menit	Multi-region, chaos testing, biaya besar

Cara menentukan target yang benar adalah dari biaya downtime: kalau satu jam outage menghentikan GMV merchant senilai X rupiah plus risiko churn enterprise Y, maka hitung mundur berapa investasi infrastruktur yang masuk akal. Rumus mental sederhananya: beli 9 berikutnya hanya jika nilainya melebihi harganya.

Jangan lupa dimensi lain: fitur baru butuh error budget untuk eksperimen. Produk yang menuntut 99.99% sejak hari pertama pada semua komponen akan bergerak seperti gletser — bedakan jalur kritikal (create payment) dari jalur sekunder (dashboard rekap).

Important

Saat sales menjanjikan uptime 99.99% ke merchant besar tanpa konsultasi, itu bukan sekadar detail komersial — itu komitmen yang mengunci arsitektur dan biaya operasional bertahun-tahun. Pastikan ada gerbang internal: SLA baru wajib ditandatangani TPM + eng lead sebelum masuk kontrak.

#Menjual Investasi Reliability ke Bisnis

Template argumen yang bekerja di ruang rapat eksekutif:

Data: "Q2 terjadi 3 insiden settlement, total 96 menit, GMV terdampak Rp 4.1 M, 11 merchant enterprise komplain resmi."
Akar: "80% waktu hilang karena observability lemah — deteksi rata-rata 25 menit."
Investasi: "2 engineer-minggu untuk alerting berbasis SLO + runbook."
Imbal hasil: "Deteksi turun ke 5 menit memotong dampak insiden berikutnya hingga separuh."

Struktur data → akar → investasi → imbal hasil mengubah "minta tolong perbaiki server" menjadi proposisi investasi bernomor. Ini versi reliability dari framing quality-as-fitur di episode 10.

#Praktik: SLO Product Sheet

Susun satu halaman SLO untuk settlement API: tiga objectives (availability, latency, correctness), error budget dalam menit nyata, policy burn rate, dan tabel biaya-downtime untuk dua skenario (insiden jam sibuk vs malam). Simpan di 05-quality/slo-settlement.md.

#Penutup

Inti yang harus dibawa pulang:

SLI diukur banyak, SLO dipilih sedikit sebagai target, SLA sedikit lagi sebagai kontrak — jangan balik urutannya.
Error budget mengubah debat stabil-vs-cepat menjadi aritmatika saldo; tulis policy-nya, bukan cuma angkanya.
Untuk fintech, correctness (rekonsiliasi nol selisih) adalah SLO sama pentingnya dengan availability.
Beli digit 9 sesuai biaya downtime, dan bedakan jalur kritikal dari jalur sekunder.
Jual investasi reliability dengan struktur data → akar → investasi → imbal hasil.

Di episode 14 selanjutnya kita bicara Security & Compliance Products — PCI DSS, SOC 2, ISO 27001 dalam bahasa TPM, bagaimana security menjadi argumen penjualan, dan menuliskan requirement compliance ke PRD tanpa membunuh kecepatan tim. Sampai jumpa!