Belajar Site Reliability Engineer - Prinsip & Arsitektur SRE

#Pendahuluan

Setelah di episode 1 kita memahami asal-usul dan filosofi SRE, sekarang saatnya merangkainya menjadi arsitektur — bagaimana prinsip-prinsip itu saling terhubung dan diterapkan dalam satu sistem yang utuh. Episode 1 memberi kalian "mengapa", episode 2 memberi "bagaimana semuanya nyambung".

SRE sering disalahpahami sebagai kumpulan tips terpisah: "pasang Prometheus", "buat dashboard", "adakan game day". Padahal kekuatan SRE justru terletak pada keterhubungannya: setiap praktik adalah mekanisme yang memberi makan praktik lain. SLO menentukan alert; alert memicu incident; postmortem menghasilkan perbaikan; perbaikan mengurangi toil; toil yang berkurang memberi ruang engineering; dan engineering membangun reliability-as-code yang membuat seluruh siklus otomatis.

#Prinsip SRE sebagai Sistem

#SLI, SLO, Error Budget: Mata Uang Reliability

Ketiganya bukan tiga hal terpisah, melainkan satu hierarki:

• SLI (Service Level Indicator) — metrik terukur yang merepresentasikan pengalaman pengguna, misalnya availability, latency, atau error rate.
• SLO (Service Level Objective) — target yang disepakati, misalnya "latency p95 di bawah 250 ms selama 30 hari".
• Error budget — jumlah kegagalan yang "diizinkan" sebelum SLO dilanggar, yaitu 100% - SLO. Dengan SLO 99,9%, error budget adalah 0,1% dari periode tersebut.

Inilah yang membuat SRE berbeda dari pendekatan "uptime 99,999% demi gengsi": SLO adalah keputusan bisnis yang disepakati, dan error budget adalah ruang aman untuk bergerak.

#Toil Budget: Kapasitas Engineering

Toil adalah pekerjaan manual, berulang, dan tanpa nilai jangka panjang. Aturan emasnya: maksimal 50% waktu SRE boleh untuk toil. Jika toil melebihi itu, kualitas operasi menurun — tidak ada waktu untuk membangun tooling, dan toil semakin menumpuk (lingkaran setan). Prinsip ini dipakai juga untuk mengukur kesehatan tim: toil budget adalah alarm pertama bahwa tim SRE sedang tenggelam dalam pekerjaan manual.

#Blameless Postmortem: Siklus Perbaikan

Postmortem adalah penutup siklus: setiap insiden menghasilkan daftar aksi, setiap aksi dicek keterlaksanaannya, dan hasilnya masuk kembali ke SLO. Tanpa postmortem yang jujur, insiden terulang; tanpa penutup siklus, perbaikan menguap begitu panas mereda.

#Arsitektur SRE: Service Level Engineering

#Hirarki Layanan dan Ownership

Arsitektur SRE dimulai dari memetakan layanan dan ownership: siapa yang bertanggung jawab atas service apa, apa dependensinya, dan di mana batas tanggung jawabnya. Di sinilah konsep service level menjadi kerangka: setiap service kritis harus punya owner yang jelas dan SLO yang terdefinisi.

#Capacity Planning: Menghubungkan Observability ke Skala

Capacity planning membaca data dari sistem pengukuran (metrics) untuk menjawab pertanyaan: kapan kita kehabisan resource? Ini bukan menebak, melainkan ekstrapolasi dari tren penggunaan terhadap waktu. Arsitekturnya:

1. Ukur — resource utilization dan permintaan aktual (dari metrics).
2. Proyeksikan — tren pertumbuhan dan beban musiman.
3. Rencanakan — tambah kapasitas (vertical/horizontal) atau kurangi permintaan.
4. Otomatiskan — auto-scaling sebagai pengaman, bukan pengganti perencanaan.

top -bn1 | head -12
df -h /
free -h

Perintah ini hanya contoh: di episode 8 kita akan melakukannya secara proper dengan metrik Prometheus dan forecasting.

#Reliability-as-Code: Mengubah Prinsip Jadi Artefak

Prinsip SRE baru bernilai saat menjadi artefak yang bisa direview, di-version, dan diotomasi. Reliability-as-code berarti SLO, alert, dashboard, dan runbook disimpan dalam git sebagai kode, bukan sebagai dokumen lepas atau konfigurasi di UI. Contoh bentuknya:

#Siklus SRE Lengkap

Bila dirangkai, arsitektur SRE adalah loop yang terus berputar:

1. Definisikan SLO dari kebutuhan bisnis.
2. Ukur SLI lewat observability (episode 5).
3. Alert saat error budget terancam (episode 6).
4. Respon lewat incident management (episode 7).
5. Belajar lewat blameless postmortem.
6. Perbaiki dengan mengotomasi dan merencanakan kapasitas (episode 8-9).
7. Kendalikan risiko lewat rilis aman dan chaos engineering (episode 11, 13).

#Penutup

Pada episode 2 ini, kalian telah melihat bagaimana prinsip SRE terangkai menjadi arsitektur yang utuh.

Inti yang harus dibawa pulang:

• SLI/SLO/error budget adalah satu hierarki, bukan tiga konsep terpisah.
• Toil budget (50%) melindungi ruang engineering tim.
• Blameless postmortem menutup siklus perbaikan agar insiden tidak berulang.
• Service level engineering, capacity planning, dan reliability-as-code adalah tulang punggung operasional.
• Seluruh praktik adalah satu loop yang terus berputar.

Di episode 3 selanjutnya, kita mulai masuk ke praktik paling dasar sekaligus paling penting: SLO, SLI & SLA — mendefinisikan SLI (availability, latency, error rate), menentukan target SLO yang rasional, membedakan SLO dari SLA, dan mempraktikkan SLO untuk satu service. Sampai jumpa di episode 3!