Belajar Site Reliability Engineer - SRE Culture & Team

#Pendahuluan

Hingga episode 24, hampir semua yang kalian pelajari bersifat teknis: SLO, observability, chaos, DR, kode. Tapi ada satu fakta yang menyedihkan: budaya bisa mengalahkan semua itu. SLO yang indah tidak berfungsi jika tim menyembunyikan insiden karena takut disalahkan. Error budget yang ditetapkan tidak berarti jika manajemen mengabaikannya. Postmortem yang sempurna tidak mengubah apa pun jika tidak ada yang mau mengaku melakukan kesalahan.

SRE pada akhirnya adalah disiplin tentang manusia. Episode 25 membahas tiga hal yang paling menentukan keberhasilan adopsi SRE: hubungannya dengan DevOps, budaya blameless, dan kemampuan memengaruhi tanpa punya otoritas formal.

#SRE vs DevOps: Saudara dengan Penekanan Berbeda

Keduanya sering dianggap sama — dan memang berbagi fondasi (otomasi, budaya, pengukuran). Perbedaannya adalah penekanan dan pelatihan:

Cara paling berguna melihat keduanya: SRE adalah salah satu implementasi konkret dari DevOps — ia memberikan jawaban teknis dan terukur untuk pertanyaan budaya DevOps ("bagaimana caranya dev dan ops bekerja sama?"). Jawabannya: lewat SLO yang dimiliki bersama, error budget, dan postmortem blameless. Sebuah organisasi bisa "melakukan DevOps" tanpa SRE; tim SRE yang sehat selalu mempraktikkan nilai DevOps.

#Blameless Culture: Fondasi yang Paling Sering Disalahpahami

Postmortem (episode 7) hanya efektif jika aman untuk jujur. Blameless culture bukan "tidak ada yang bersalah" — itu salah paham yang berbahaya. Blameless culture berarti: kesalahan dipahami sebagai masalah sistem, bukan masalah karakter individu.

Perbedaan krusialnya:

• Menyalahkan: "Deploynya yang salah, siapa yang melakukannya?" → hasilnya orang menyembunyikan kesalahan.
• Blameless: "Mengapa sistem mengizinkan deploy berbahaya terjadi tanpa proteksi?" → hasilnya sistem diperbaiki, kesalahan berikutnya bisa dicegah.

Contoh sederhana: seorang engineer menjalankan DROP TABLE tanpa menyalakan BEGIN. Postmortem blameless tidak menanyakan "kenapa dia ceroboh?" — ia menanyakan "kenapa production mengizinkan perintah itu dijalankan dari laptop manusia tanpa konfirmasi? Kenapa tidak ada recovery cepat?" Dua pertanyaan itu menghasilkan perbaikan nyata; pertanyaan pertama hanya menghasilkan rasa bersalah.

Praktik yang konkret: bahas postmortem di depan umum, termasuk siapa yang "salah". Ketika tim melihat orang yang melakukan kesalahan besar justru ikut memimpin analisis dan perbaikannya tanpa dihukum, budaya berubah dari takut menjadi belajar. Sebaliknya, satu postmortem yang berujung hukuman cukup untuk menghancurkan kejujuran selama bertahun-tahun.

#Pengaruh Tanpa Otoritas

Tim SRE jarang punya kuasa untuk memaksa: developer tidak "dilaporkan" ke SRE, product owner tidak menunggu izin SRE, dan perintah "kalian harus menulis SLO" tidak akan dipatuhi. Yang dimiliki SRE adalah pengaruh — dan pengaruh dibangun, bukan ditunjuk.

Empat sumber pengaruh yang paling ampuh:

1. Kredibilitas teknis — SRE yang memahami kode developer dan data produksi mereka didengarkan; SRE yang hanya mengutip aturan diabaikan.
2. Data, bukan opini — "saya pikir fitur ini berbahaya" kalah oleh "error budget fitur ini sudah habis tiga bulan berturut-turut". SLO memberi kalian senjata data yang tidak bisa diserang dengan perasaan.
3. Menawarkan solusi, bukan larangan — "jangan deploy hari ini" kalah oleh "deploy hari ini, tapi ini plan mitigasi + rollback yang sudah siap".
4. Konsistensi — orang dipercaya berdasarkan pola perilaku jangka panjang, bukan heroisme sekali.

#Praktik: Roadmap Adopsi SRE

Susun roadmap realistis untuk tim kalian — jangan menunggu mandat organisasi:

1. Mulai dari satu service yang paling menyakitkan — bukan dari seluruh portofolio.
2. Tetapkan SLO dan error budget-nya (episode 3-4) bersama pemilik produk.
3. Lakukan postmortem blameless pertama — pilih insiden yang sudah selesai dan aman dibahas.
4. Otomasi toil paling menyakitkan (episode 9) dan catat waktu yang terselamatkan.
5. Tunjukkan bukti dalam bahasa bisnis: "insiden turun 40%, waktu deploy turun dari 2 jam ke 15 menit".
6. Naikkan cakupan ke service berikutnya — setelah pola terbukti, bukan sebelum.

Minggu 1-2 : pilih service, pasang observability yang memadai
Minggu 3-4 : SLO + error budget disepakati dengan produk
Minggu 5-6 : alerting sehat + on-call untuk service tsb
Minggu 7-9 : 2 postmortem blameless + otomasi toil pertama
Minggu 10-12: review hasil, presentasikan data ke organisasi

#Penutup

Pada episode 25 ini, kalian telah belajar bahwa SRE adalah soal manusia dan budaya, bukan hanya mesin.

Inti yang harus dibawa pulang:

• SRE adalah implementasi konkret DevOps — jawaban terukur untuk pertanyaan budaya.
• Blameless berarti memperbaiki sistem, bukan menghindari rasa bersalah — dan dimulai dari keputusan manajemen.
• Pengaruh tanpa otoritas dibangun dari kredibilitas, data, solusi, dan konsistensi.
• Adopsi SRE dimulai dari satu service dan masalah yang sudah terasa, lalu dibuktikan dengan data.
• Mulailah sekarang, dari skala terkecil — bukan menunggu mandat yang mungkin tidak datang.

Di episode 26 selanjutnya, kita akan memandang ke depan: ekosistem & tren modern 2026 — reliability engineering platforms, error budget yang di-enforce otomatis, dan AI-augmented observability. Sampai jumpa di episode 26!