Belajar Site Reliability Engineer - Peran, Sejarah & Filosofi

#Pendahuluan

Setelah di episode 0 kita menyiapkan environment — VM, Docker, dan stack Prometheus/Grafana yang berjalan — pada episode ini kita memahami mengapa SRE ada. Banyak yang menganggap SRE hanya "DevOps dengan gaji lebih tinggi", padahal peran ini lahir dari masalah nyata yang dihadapi Google di awal 2000-an: sistem tumbuh terlalu cepat untuk dioperasikan secara manual.

Mengapa harus memahami sejarah dan filosofinya? Karena keputusan desain SRE — dari SLO, error budget, sampai aturan 50% toil — bukanlah tebakan, melainkan jawaban atas masalah yang sudah diamati selama bertahun-tahun. Memahami "mengapa" membuat kalian mampu berpikir seperti SRE, bukan sekadar mengikuti checklist.

#Lahirnya SRE di Google

#2003: Definisi dari Ben Treynor Sloss

Istilah Site Reliability Engineer pertama kali dipakai di Google pada 2003 oleh Ben Treynor Sloss. Definisi aslinya sederhana namun revolusioner:

"SRE is what happens when a software engineer is tasked with operations."

Definisinya: "apa yang terjadi ketika seorang software engineer ditugaskan mengerjakan operasi." Sebelum ini, operasi (operations) dianggap pekerjaan yang berbeda dari pengembangan software — dijalankan oleh sysadmin yang mengikuti runbook manual. Google melihat masalah: menulis software untuk mengoperasikan software adalah masalah software engineering, bukan sekadar disiplin operasi.

#Mengapa Google Butuh Peran Ini

Masalah yang mendorong lahirnya SRE bisa diringkas dalam tiga titik:

1. Skala — sistem Google terlalu besar untuk dioperasikan manual; insiden adalah cara hidup.
2. Kualitas — operasi yang dijalankan dengan script ad-hoc rapuh; butuh pendekatan engineering.
3. Karir — engineer tidak mau terjebak sebagai operator yang mengerjakan pekerjaan berulang tanpa kendali.

SRE menjawab ketiganya sekaligus: memperlakukan operasi sebagai masalah engineering, mengotomasi yang berulang, dan memberikan kendali desain kepada tim operasi itu sendiri.

#Filosofi Inti SRE

Empat filosofi yang menopang seluruh praktik SRE:

#1. Mengotomasi Toil

Toil adalah pekerjaan operasional berulang, manual, dan tanpa nilai jangka panjang — misalnya merestart service yang crash karena alasan yang sama setiap hari. Prinsip SRE: toil harus dikurangi, diotomasi, atau dihilangkan. Google menetapkan patokan: maksimal 50% waktu SRE boleh habis untuk toil; sisanya untuk engineering (membangun tooling, observability, kapasitas).

#2. Reliability Harus Diukur

Pernyataan "sistem kita reliable" tanpa angka adalah opini, bukan fakta. SRE mengukur reliability dengan SLI (indikator), menargetkannya lewat SLO (target), dan mengelola risiko lewat error budget. Episodes 3 dan 4 akan membedah ketiganya secara mendalam.

#3. Keseimbangan Kecepatan vs Stabilitas

Ini yang membedakan SRE dari pendekatan operasi tradisional: SRE tidak anti-perubahan. Ia menggunakan error budget sebagai mata uang — jika tim pengembang masih punya budget error, mereka boleh merilis lebih cepat; jika sudah habis, rilis dihentikan. Stabilitas bukan tujuan mutlak, melainkan salah satu faktor yang diseimbangkan dengan kecepatan inovasi.

100%

#4. Blameless Postmortem

Ketika insiden terjadi, pertanyaan yang benar bukan "siapa yang salah?" melainkan "apa yang gagal dalam sistem dan proses?". Postmortem tanpa menyalahkan orang memastikan temuan jujur, sehingga perbaikan sistemik bisa dilakukan. Ini kita bahas penuh di episode 7.

#SRE vs DevOps: Bukan Hal yang Sama

Perbandingan umum yang sering membingungkan:

DevOps adalah set of principles; SRE adalah how to implement them di dunia nyata dengan metrik dan mekanisme yang konkret. Banyak tim modern justru menerapkan filosofi DevOps dan menjadikan SRE sebagai perwujudan teknisnya.

#SRE dalam Angka: Kenapa Praktik Ini Bertahan

SRE bukan sekadar tren. Riset DORA (DevOps Research & Assessment) berulang kali menunjukkan korelasi antara praktik pengukuran reliability (SLO, observability) dengan kecepatan dan stabilitas pengiriman software. Konsep seperti error budget memberi bahasa bersama antara tim produk dan tim operasi — menghilangkan konflik "mereka memperlambat kita" yang klasik.

Selain itu, SRE mengubah cara organisasi berpikir tentang investasi reliability: alih-alih menghabiskan uang untuk "uptime semaksimal mungkin" (yang tidak selalu bernilai), SRE menginvestasikan secara proporsional terhadap target yang disepakati dan kebutuhan bisnis.

#Penutup

Pada episode 1 ini, kalian telah menelusuri asal-usul dan filosofi yang menjadi fondasi seluruh praktik SRE.

Inti yang harus dibawa pulang:

• SRE lahir di Google 2003 dari Ben Treynor Sloss: software engineer yang ditugaskan mengerjakan operasi.
• Empat filosofi inti: otomasi toil, reliability terukur, balance velocity vs stability, dan blameless postmortem.
• Toil maksimal 50% waktu SRE; sisanya untuk engineering.
• SRE berbeda dari DevOps: SRE adalah perwujudan teknis yang konkret, DevOps adalah gerakan budaya.

Di episode 2 selanjutnya, kita akan membedah prinsip dan arsitektur SRE — service level engineering, capacity planning, toil, blameless postmortem, dan konsep reliability-as-code yang menghubungkan seluruh praktik ini menjadi satu kerangka kerja. Sampai jumpa di episode 2!