Site Reliability Engineering: How Google Runs Production Systems

Ketika Anda membuka Google Search dan hasilnya muncul dalam sepersekian detik, jarang sekali Anda berpikir tentang ribuan server yang bekerja di baliknya, apalagi tentang tim yang bertanggung jawab menjaga semuanya tetap menyala hampir tanpa henti. Buku ini lahir dari tim itu sendiri, yaitu para insinyur di Google yang menciptakan disiplin baru bernama Site Reliability Engineering, atau biasa disingkat SRE, sebuah pendekatan yang kini menjadi rujukan hampir semua perusahaan teknologi skala besar di dunia.

Disunting oleh Betsy Beyer, Chris Jones, Jennifer Petoff, dan Niall Richard Murphy, buku ini mengumpulkan pengalaman puluhan insinyur Google dalam menjaga sistem raksasa tetap berjalan. Premis utamanya cukup radikal untuk masanya, yakni keandalan sistem sebaiknya diperlakukan sebagai fitur produk yang harus direkayasa dengan sengaja, bukan sekadar efek samping dari kerja keras tim operasional yang kelelahan menangani insiden satu demi satu.

Contoh Analogi

Konsep inti SRE bisa dipahami lewat analogi seorang pilot pesawat dibanding sopir taksi. Sopir taksi bereaksi terhadap kondisi jalan saat itu juga, berbelok menghindari lubang, mengerem mendadak saat ada halangan. Pilot pesawat sebaliknya, bekerja dengan checklist ketat, prosedur baku untuk setiap skenario darurat, dan margin keselamatan yang dihitung matang sebelum lepas landas. Google, lewat SRE, ingin tim mereka bekerja lebih seperti pilot, yaitu mengantisipasi kegagalan lewat prosedur dan perhitungan matang, bukan seperti sopir taksi yang terus menerus bereaksi terhadap kebakaran yang muncul satu per satu.

Bagian 1: Error Budget, Cara Baru Memandang Keandalan

Salah satu gagasan paling berpengaruh dari buku ini adalah konsep error budget. Alih-alih mengejar keandalan seratus persen, yang menurut para penulis justru mustahil dan mahal, SRE menetapkan target keandalan tertentu, misalnya 99,9 persen, dan sisa 0,1 persen itu menjadi "anggaran" yang boleh dipakai untuk bereksperimen, merilis fitur baru, atau mengambil risiko terukur.

Pendekatan ini menyelesaikan konflik klasik antara tim pengembang yang ingin merilis cepat dan tim operasional yang ingin sistem tetap stabil. Ketika anggaran error masih tersisa, tim pengembang bebas merilis dengan kecepatan tinggi. Namun begitu anggaran habis, prioritas otomatis bergeser ke stabilitas sampai anggaran pulih kembali.

“A hundred percent is probably the wrong reliability target for basically everything.”

Bagian 2: Toil, Musuh Tersembunyi Produktivitas

Buku ini memperkenalkan istilah "toil", yaitu pekerjaan operasional yang berulang, manual, tidak memberikan nilai jangka panjang, dan cenderung bertambah seiring pertumbuhan sistem. Para penulis menegaskan bahwa toil adalah musuh utama yang harus terus dikurangi lewat otomatisasi, karena jika dibiarkan, seluruh waktu tim SRE akan habis hanya untuk memadamkan api berulang tanpa sempat memperbaiki akar masalahnya.

Batas Waktu untuk Toil

Google bahkan menetapkan aturan eksplisit bahwa waktu tim SRE untuk toil sebaiknya tidak melebihi lima puluh persen dari total waktu kerja mereka, sisanya harus dialokasikan untuk proyek rekayasa yang benar-benar mengurangi beban operasional di masa depan. Aturan ini memastikan tim tidak terjebak selamanya dalam siklus reaktif, dan tetap punya ruang untuk berinvestasi pada solusi jangka panjang.

Filosofi ini menantang budaya kerja umum di banyak tim operasional yang justru menganggap kesibukan menangani insiden sebagai bukti produktivitas, padahal sering kali itu tanda sistem yang belum cukup diinvestasikan pada otomatisasi.

Bagian 3: Blameless Postmortem, Belajar Tanpa Menyalahkan

Bagian ini membahas bagaimana Google menangani insiden setelah terjadi, lewat praktik yang mereka sebut blameless postmortem. Alih-alih mencari siapa yang harus disalahkan atas sebuah kegagalan, proses ini fokus mencari faktor sistemik apa yang memungkinkan kegagalan itu terjadi, dan bagaimana mencegahnya terulang di masa depan.

Budaya Aman untuk Jujur

Para penulis menjelaskan bahwa budaya menyalahkan individu justru kontraproduktif, karena membuat orang cenderung menyembunyikan kesalahan atau insiden kecil demi menghindari konsekuensi personal, padahal informasi tersebut sangat berharga untuk mencegah insiden serupa yang lebih besar di kemudian hari. Dengan menghilangkan rasa takut disalahkan, tim menjadi lebih terbuka melaporkan masalah sekecil apa pun.

Praktik ini kini banyak diadopsi di luar Google sebagai standar industri untuk menangani insiden secara matang dan konstruktif.

Bagian 4: Monitoring yang Bermakna, Bukan Sekadar Alarm

Buku ini juga membahas panjang lebar bagaimana merancang sistem monitoring yang benar-benar berguna, bukan sekadar menghasilkan banyak alarm yang justru membuat tim kelelahan mengabaikannya, sebuah kondisi yang dikenal sebagai alert fatigue. Para penulis menekankan bahwa setiap alarm yang membangunkan seseorang tengah malam harus benar-benar memerlukan tindakan manusia segera, bukan sekadar informasi yang bisa ditunda sampai pagi.

Empat Sinyal Emas

Mereka memperkenalkan empat metrik utama yang layak dipantau ketat untuk sebagian besar sistem, yaitu latency, traffic, errors, dan saturation. Keempat sinyal ini memberikan gambaran cukup lengkap tentang kesehatan sebuah layanan tanpa harus tenggelam dalam ratusan metrik yang justru mengaburkan masalah sebenarnya.

Filosofi merancang monitoring yang tepat sasaran ini membantu tim fokus pada sinyal yang benar benar penting, alih-alih tenggelam dalam kebisingan data yang tidak relevan.

Bagian 5: Menyiapkan Manusia untuk Insiden Besar

Bagian menjelang akhir buku membahas bagaimana Google mempersiapkan timnya menghadapi insiden besar, mulai dari struktur komando yang jelas saat krisis terjadi, sampai latihan simulasi bencana yang rutin dijalankan meski tidak ada insiden nyata sedang terjadi.

Latihan Sebelum Krisis Sungguhan

Para penulis menceritakan bagaimana Google secara sengaja menjalankan latihan simulasi kegagalan besar, termasuk mematikan seluruh pusat data secara terkendali, untuk memastikan tim dan sistem benar-benar siap menghadapi skenario terburuk. Latihan semacam ini terasa mahal dan merepotkan di permukaan, namun jauh lebih murah dibanding menghadapi insiden nyata tanpa persiapan sama sekali.

Pendekatan proaktif ini mencerminkan filosofi inti SRE secara keseluruhan, yaitu lebih baik berinvestasi mencegah dan berlatih menghadapi kegagalan, daripada hanya bereaksi setelah kegagalan benar-benar terjadi.

Pelajaran untuk Hari Ini

1. Tetapkan Target Keandalan yang Realistis Daripada mengejar kesempurnaan yang mustahil, tentukan target keandalan yang jelas untuk sistem atau pekerjaan Anda, lalu gunakan sisa ruangnya untuk berinovasi dengan berani.

2. Kurangi Pekerjaan Berulang Secara Sengaja Identifikasi tugas rutin yang menghabiskan waktu Anda tanpa memberi nilai jangka panjang, dan alokasikan waktu khusus untuk mengotomatisasi atau menghilangkannya.

3. Bahas Kegagalan Tanpa Mencari Kambing Hitam Saat sesuatu berjalan salah, fokuslah mencari faktor sistemik yang memungkinkan kegagalan itu terjadi, bukan mencari siapa yang harus disalahkan.

4. Latih Diri Sebelum Krisis Datang Siapkan rencana dan latihan menghadapi skenario terburuk sebelum benar-benar terjadi, karena persiapan yang matang jauh lebih murah dibanding penanganan darurat tanpa arah.

Penutup

Site Reliability Engineering membuktikan bahwa keandalan sistem berskala besar bukan soal keberuntungan atau kerja lembur tanpa henti, melainkan hasil dari disiplin rekayasa yang matang dan budaya kerja yang sehat. Google menunjukkan bahwa dengan pendekatan yang tepat, kecepatan inovasi dan stabilitas sistem bisa berjalan beriringan, bukan saling mengorbankan satu sama lain.

Di era ketika sistem digital semakin kompleks dan bergantung pada infrastruktur cloud serta layanan pihak ketiga, prinsip prinsip dalam buku ini menjadi semakin relevan, terutama saat organisasi mulai memasukkan AI ke dalam sistem produksi mereka, yang menambah lapisan baru ketidakpastian yang perlu dikelola dengan disiplin serupa.

Pertanyaannya untuk Anda, apakah tim atau organisasi Anda saat ini lebih sering bertindak seperti pilot yang mengantisipasi kegagalan, atau seperti sopir taksi yang terus menerus bereaksi terhadap kebakaran yang sama berulang kali?

Tentang Buku Asli