Belajar System Engineer - SRE & Reliability Practices

#Pendahuluan

Episode 21-22 membangun ketersediaan dan kapasitas secara teknis. Episode 24 ini membawa keandalan ke level yang lebih tinggi — dan lebih terukur — melalui lensa SRE (Site Reliability Engineering): disiplin yang lahir di Google untuk menjaga layanan besar tetap andal. SRE bukan "jabatan" semata — ia adalah cara berpikir yang bisa diterapkan setiap System Engineer.

Mengapa episode ini penting? Karena "jaga server tetap up" adalah kalimat yang terlalu kabur untuk dijalankan. SRE menjawabnya dengan angka: berapa persen ketersediaan yang dijanjikan, bagaimana mengukurnya, dan apa konsekuensinya. Episode ini membahas tiga pilar: SLI/SLO (definisi & pengukuran), error budgets (keseimbangan keandalan vs kecepatan), dan incident response (penanganan kegagalan yang profesional).

#SLI, SLO, Error Budget

#Definisi Singkat

Istilah	Arti	Contoh
SLI (Service Level Indicator)	Metrik yang mengukur keandalan	Persentase request berhasil dalam 5 detik
SLO (Service Level Objective)	Target yang dijanjikan	99,9% request sukses per bulan
SLA (Service Level Agreement)	Kontrak hukum dengan pelanggan	< SLA biasanya ada kompensasi
Error budget	"Jatah" kegagalan yang tersisa	100% - SLO = 0,1% (≈43 menit/bulan)

Aturan penting: SLA harus lebih longgar dari SLO. Kalian menetapkan SLO internal yang lebih ketat (99,95%) agar punya buffer sebelum melanggar SLA komersial (99,9%).

#Memilih SLI yang Tepat

SLI harus merepresentasikan pengalaman pengguna, bukan sekadar kesehatan server:

100%

SLI yang umum:

Availability: request sukses / total request (error rate < 0,1%).
Latency: persentase request di bawah ambang (p99 < 300 ms).
Throughput: request per detik (untuk kapasitas).
Durability: data tidak hilang (penting untuk storage/DB).

SLI bisa dihitung langsung dari metrik Prometheus (episode 10):

PromQL: error rate sebagai SLI

sum(rate(http_requests_total{status=~"5..|429"}[5m]))
/ sum(rate(http_requests_total[5m]))

#Error Budget: Uang untuk Inovasi

#Konsep

Error budget adalah jumlah kegagalan yang diperbolehkan sebelum melanggar SLO. Jika SLO 99,9% per bulan, error budget-nya 0,1% — sekitar 43 menit downtime/bulan. Filosofi penting SRE:

100% reliability adalah target yang salah — mengejarnya mengorbankan kecepatan pengembangan.
Error budget adalah anggaran yang boleh dihabiskan — untuk rilis baru, eksperimen, bahkan pemeliharaan.
Saat budget habis: perlambat rilis, fokus perbaikan keandalan dulu.

Ini mengubah keputusan operasional menjadi keputusan berbasis angka, bukan emosi atau hirarki:

Contoh keputusan berbasis error budget

Error budget bulan ini tersisa: 20% dari 43 menit
Proposal: rilis besar minggu ini.
Keputusan: DITOLAK sampai budget pulih, atau rilis di-batch kecil.

#Memantau Budget

PromQL: konsumsi error budget

1 - (sum(rate(http_requests_total{status=~"5..|429"}[30d]))
    / sum(rate(http_requests_total[30d])))
# Hasil di bawah 0.999 = budget terlampaui

Note

Error budget bukan alasan untuk abai — melainkan alat keputusan. Ketika budget hampir habis, prioritas berubah: fokus stabilisasi (rollback, reduksi fitur, penambahan kapasitas), bukan fitur baru. Inilah cara SRE menjaga keandalan berkelanjutan, bukan reaktif.

#Incident Response

#Siklus Insiden

Insiden besar tidak diatasi dengan panik, tapi dengan proses:

100%

Deteksi: dari monitoring/alert (episode 10) atau laporan pengguna.
Respon: lakukan severity triage (SEV1 = layanan down total, SEV2 = degradasi, SEV3 = lokal), buka channel komunikasi, tunjuk incident commander.
Mitigasi: langkah cepat mengembalikan layanan — rollback/revert dulu, analisis belakangan.
Recovery: verifikasi layanan pulih, komunikasikan ke stakeholder.
Postmortem: analisis root cause dan tindak lanjut — tanpa menyalahkan.

#Blameless Postmortem

Budaya terpenting SRE: postmortem blameless. Tujuannya bukan mencari siapa yang salah, tapi mencegah terulang:

Template postmortem

# Postmortem: [Judul Insiden]
Tanggal / Durasi / Severity: ...
 
## Ringkasan
Apa yang terjadi, dampak ke pengguna, berapa lama.
 
## Timeline
Waktu kejadian, deteksi, mitigasi, recovery (dengan timezone).
 
## Root Cause
Akar masalah teknis (bukan orang).
 
## Aksi Tindak Lanjut
- [ ] Otomasi deteksi (mengapa tidak terdeteksi lebih cepat?)
- [ ] Perbaikan proses (deploy, config)
- [ ] Refleksi: apa yang membuat insiden bertahan lama?

#Checklist Runbook

Saat insiden berlangsung, tim tidak boleh mengarang langkah — runbook (episode 2) yang sudah disiapkan dijalankan:

Runbook: SEV1 - layanan web down

1. Konfirmasi dari monitoring: node down? app 500? DB?
2. Buka channel insiden & umumkan severity
3. Cek dashboard sintetis: LB, app, DB
4. Langkah cepat: restart service / rollback release terakhir
5. Jika pulih: verifikasi + pantau 30 menit
6. Jika tidak: eskalasi + panggil on-call senior
7. Catat timeline untuk postmortem

#Praktik: Reliability Practices

Bangun fondasi SRE di lab kalian:

Skenario praktik SRE

# 1. Definisikan SLI/SLO di dokumen (contoh di atas)
# 2. Buat alert error rate berbasis SLI
#    (Prometheus rule: sum 5xx / sum total > 0.001 selama 10m)
 
# 3. Simulasikan insiden: stop service, ukur error rate
sudo systemctl stop nginx
# (lihat dashboard: error rate naik, alert terpicu)
 
# 4. Pulihkan & catat postmortem mini
sudo systemctl start nginx
# 5. Review: apakah deteksi cukup cepat? perbaiki alert bila perlu

#Kesalahan Umum

SLI yang tidak mewakili pengguna — mengukur kesehatan server, padahal pengguna mengalami error.
SLO tanpa error budget yang dijalankan — angka hiasan yang tidak memengaruhi keputusan.
Insiden ditangani tanpa proses — semua orang panik, tidak ada yang memimpin.
Postmortem yang menyalahkan orang — orang takut melapor, akar masalah tersembunyi.
Tidak belajar dari insiden — insiden yang sama berulang setiap kuartal.

#Penutup

Inti yang harus dibawa pulang:

SLI mengukur, SLO menargetkan, error budget memberi jatah kegagalan yang bisa dipakai.
Error budget mengubah keputusan keandalan menjadi keputusan berbasis angka.
Incident response: deteksi → triase → mitigasi (rollback dulu) → recovery → postmortem blameless.
Praktik SRE membuat keandalan terukur dan berkelanjutan, bukan sekadar harapan.

Di episode 25 selanjutnya kita menyatukan semuanya dalam kode: IaC & modern system ops — Terraform + Ansible, GitOps, dan SDLC untuk operasi. Sampai jumpa di episode 25!