Apa yang Diselesaikan SRE
Selamat Datang di Site Reliability Engineering
Site Reliability Engineering (SRE) dimulai di Google pada tahun 2003. Ben Treynor Sloss mengambil alih tim operasional kecil dan membangunnya kembali seolah-olah insinyur, bukan pager manusia, yang menjalankan produksi. Hasilnya menjadi model standar untuk menjalankan layanan internet berskala besar.
Tim operasional tradisional menjaga layanan tetap berjalan melalui pekerjaan manual: restart server ini, hubungi insinyur itu, tulis runbook, dan berharap semuanya berjalan. Model tersebut tidak lagi berlaku saat skala membesar. Tim yang terdiri dari lima puluh operator tidak dapat me-restart lima ribu server secara manual. Melebihi ukuran tertentu, operasional manual menjadi beban yang menghabiskan setiap jam produktif.
SRE membalikkan model. Alih-alih merekrut lebih banyak operator saat sistem berkembang, SRE merekrut insinyur perangkat lunak dan memberi tahu mereka: tulis kode yang melakukan pekerjaan operasional untuk Anda. Pekerjaan Anda memenuhi syarat sebagai rekayasa perangkat lunak yang diterapkan pada masalah operasional. Output Anda: otomatisasi, pemantauan, dan keandalan yang direkayasa, bukan intervensi manual.
Tiga gagasan dasar yang mendorong praktik SRE:
- Service Level Objectives (SLOs): target keandalan numerik yang disepakati sebelumnya
- Error budgets: kebalikan dari SLO, digunakan untuk mengambil risiko
- Toil elimination: setiap pekerjaan operasional yang skalanya linier dengan ukuran sistem harus dihilangkan
Ketiga gagasan ini mengalir ke setiap praktik SRE: postmortems, rotasi on-call, perencanaan kapasitas, monitoring, dan release engineering.
Operasional Tradisional versus SRE
Mengapa Operasional Tradisional Gagal pada Skala Besar
Tim ops yang khas tumbuh secara linear bersama sistem yang dikelolanya. Gandakan server, gandakan operator. Ini masuk akal secara finansial untuk deployment kecil, tetapi berbahaya di skala besar: Anda tidak bisa merekrut untuk keluar dari masalah kuadratik.
SRE membatasi pekerjaan operasional hingga lima puluh persen waktu seorang engineer. Setengah sisanya harus digunakan untuk engineering: membangun tools, mengotomasi proses, menghilangkan toil yang membuat mereka mencapai lima puluh persen. Jika toil melebihi lima puluh persen terlalu lama, tim harus mengembalikan pekerjaan ke tim development atau merekrut lebih banyak SRE. Aturan lima puluh persen mencegah tim SRE berubah menjadi tim ops tradisional di bawah tekanan berkelanjutan.
Bandingkan mode kegagalan:
- Ops tradisional: lebih banyak insiden menyebabkan lebih banyak respons manual, yang menyisakan lebih sedikit waktu untuk pencegahan, yang menciptakan lebih banyak insiden. Sebuah lingkaran kehancuran.
- SRE: lebih banyak insiden memicu postmortems, yang mengungkap peluang otomasi, yang mengurangi waktu respons insiden berikutnya. Sebuah lingkaran kebajikan, ketika berhasil.
SLI, SLO, SLA
Tiga Huruf yang Menggerakkan Produksi
Reliabilitas tanpa pengukuran hanyalah sandiwara. SRE menjadikan reliabilitas sebagai angka yang disepakati di awal, yang dapat diverifikasi oleh semua orang.
Indikator Tingkat Layanan (SLI): pengukuran perilaku layanan. Contoh: latensi permintaan, tingkat kesalahan, throughput, kedalaman antrian. SLI adalah sesuatu yang dapat Anda grafik.
Tujuan Tingkat Layanan (SLO): nilai target atau rentang untuk SLI. Contoh: '99,9% permintaan HTTP berhasil dalam jendela bergulir 28 hari.' SLO adalah janji yang Anda buat kepada diri sendiri dan pengguna tentang kualitas layanan yang dapat diterima.
Perjanjian Tingkat Layanan (SLA): komitmen kontraktual, biasanya dengan penalti finansial jika dilanggar. Contoh: 'Kami mengembalikan 10% jika ketersediaan bulanan turun di bawah 99,9%.' SLA adalah janji yang ditegakkan oleh pengacara.
Perbedaan penting: SLA Anda harus selalu lebih longgar daripada SLO Anda. Jika Anda menargetkan 99,9% secara internal dan mengontrak 99,9% secara eksternal, Anda tidak memiliki margin sama sekali. SRE biasanya menjalankan SLO satu sembilan lebih ketat daripada SLA: target 99,95%, kontrak 99,9%. Celah ini menyerap minggu buruk yang tak terhindarkan.
Error Budgets: The Inverse SLO
Dari Target Keandalan ke Keputusan Engineering
SLO menetapkan target keandalan. Error budget adalah sisanya: jumlah kegagalan yang masih bisa Anda gunakan sebelum melewatkan target.
Jika SLO Anda menjanjikan 99.9% keberhasilan selama 28 hari, error budget Anda adalah 0.1% dari permintaan, atau sekitar 40 menit downtime total per bulan. Anggaran ini bebas Anda gunakan sesuai keinginan: untuk rilis terencana, fitur eksperimental, chaos engineering, atau menoleransi dependensi yang bermasalah.
Error budgets mengubah konflik dev versus ops. Tanpa anggaran, setiap gangguan memicu perdebatan tentang siapa yang merilis perubahan buruk dan bagaimana mencegah yang berikutnya. Dengan anggaran:
- Anggaran masih tersedia: kirim lebih cepat, ambil lebih banyak risiko, jalankan eksperimen. Anggaran membayarnya.
- Anggaran habis: hentikan peluncuran fitur baru, bekukan perubahan berisiko, fokus pada pekerjaan keandalan hingga anggaran terisi kembali.
Ini mengubah keandalan dari perdebatan emosional menjadi sumber daya yang terukur. Engineer dapat menggunakan anggaran secara sengaja, seperti input produksi lainnya.
Mendefinisikan Toil
Apa yang Termasuk Toil
Tidak semua tugas operasional memenuhi syarat sebagai toil. SRE mendefinisikan toil secara tepat: pekerjaan yang manual, repetitif, dapat diotomatisasi, taktis, tidak memiliki nilai jangka panjang, & skalanya linier seiring pertumbuhan layanan.
Semua enam sifat tersebut harus terpenuhi. Migrasi data satu kali bersifat manual tetapi tidak repetitif: itu tidak memenuhi syarat sebagai toil. Seorang insinyur senior yang merancang arsitektur layanan baru menangani keputusan taktis tetapi menambahkan nilai jangka panjang: itu tidak memenuhi syarat sebagai toil.
Contoh yang memenuhi syarat sebagai toil:
- Memulai ulang layanan secara manual setelah crash akibat kebocoran memori
- Menempelkan potongan log ke saluran obrolan saat triage insiden
- Mengisi formulir tiket untuk menyediakan basis data baru
- Menjalankan laporan kapasitas triwulanan secara manual
- Menyetujui permintaan deployment rutin satu per satu
Aturan lima puluh persen membatasi toil maksimal setengah dari waktu SRE. Di atas 50%, tim harus mengembalikan tanggung jawab ke tim produk atau merekrut lebih banyak engineer, tetapi tujuannya tetap jelas: mendorong toil menuju nol dengan menggantinya menggunakan sistem yang direkayasa untuk melakukan pekerjaan yang sama tanpa intervensi manusia.
Otomasi tidak hanya menghemat waktu. Ia menghilangkan seluruh kelas kesalahan manusia. Skrip yang menyediakan database tidak akan melewatkan langkah-langkah setelah shift panjang.
Penalaran Audit Toil
Tim Anda melacak bagaimana waktu mereka dihabiskan. Triwulan lalu rinciannya adalah: 30% deploy, 25% respons insiden, 20% pekerjaan kapasitas, 15% rekayasa fitur, 10% permintaan satu kali dari tim produk.
On-Call Hygiene
Engineers, Not Pagers
On-call membawa biaya nyata. Tidur terganggu, akhir pekan terpotong, dan stres akibat masalah yang tidak diketahui semakin menumpuk. SRE memperlakukan on-call sebagai sumber daya terbatas yang harus tetap berkelanjutan, bukan beban heroik yang ditanggung oleh siapa pun yang paling peduli.
Rotasi on-call yang sehat mengikuti beberapa prinsip:
- Waktu yang dikompensasi: jam on-call dipetakan ke waktu pengganti, bayaran tambahan, atau manfaat setara lainnya. On-call tanpa kompensasi akan membakar habis tim.
- Kedalaman rotasi yang wajar: tim beranggotakan enam orang yang menjalankan primary plus secondary berarti setiap insinyur mengambil satu shift setiap tiga minggu. Rotasi dua orang menghancurkan karier.
- Anggaran volume halaman: buku SRE Google menyarankan maksimum dua peristiwa paging per shift dua belas jam. Di atas itu, tim harus menginvestasikan waktu rekayasa untuk mengurangi volume alert, bukan sekadar menahannya.
- Hanya alert yang dapat ditindaklanjuti: setiap halaman harus memerlukan tindakan manusia. Jika sebuah halaman akan diabaikan, diotomatisasi, atau berbunyi berulang kali selama operasi normal, maka halaman tersebut seharusnya tidak ada. Alert fatigue adalah cacat keandalan.
- Serah terima follow-the-sun: tim yang tersebar secara global menyerahkan shift pada batas zona waktu sehingga tidak ada yang dipanggil pukul 3 pagi kecuali sistem benar-benar tidak dapat menunggu hingga pagi.
Blameless Postmortems [BLOCK_TYPE CONTENT oncall/blameless_postmortem]
Bagaimana Insiden Menjadi Perbaikan
[BLOCK_TYPE CONTENT oncall/blameless_postmortem]Setiap insiden signifikan akan mendapatkan postmortem: analisis tertulis tentang apa yang terjadi, mengapa, apa yang memperbaikinya, dan perubahan apa yang mencegah kejadian berulang. Postmortem adalah padanan SRE dari bunga majemuk: setiap postmortem menambahkan keandalan permanen pada sistem. [BLOCK_TYPE CONTENT oncall/blameless_postmortem]
Blameless berarti dokumen mengaitkan kegagalan pada sistem dan proses, bukan pada individu. Jika seorang engineer menjalankan perintah yang salah, postmortem bertanya: mengapa sistem mengizinkan perintah tersebut? Mengapa tidak ada pengaman yang menangkapnya? Perubahan apa pada sistem, dokumentasi, atau alat yang akan mencegah engineer berikutnya melakukan kesalahan yang sama? [BLOCK_TYPE CONTENT oncall/blameless_postmortem]
Blamelessness ada untuk satu alasan: orang menyembunyikan kesalahan ketika mereka takut dihukum. Kesalahan yang tersembunyi menjadi insiden berikutnya. Biaya budaya blameless tergolong murah dibandingkan dengan biaya akumulasi cacat yang tidak diungkapkan. [BLOCK_TYPE CONTENT oncall/blameless_postmortem]
Postmortem biasanya mencakup: [BLOCK_TYPE CONTENT oncall/blameless_postmortem]
- Ringkasan: deskripsi satu paragraf tentang insiden & dampaknya [BLOCK_TYPE CONTENT oncall/blameless_postmortem]
- Timeline: rekonstruksi menit demi menit dengan stempel waktu
- Analisis akar masalah: faktor teknis dan proses yang memungkinkan kegagalan terjadi
- Deteksi: bagaimana tim mengetahui insiden tersebut, dan berapa lama waktu yang dibutuhkan
- Resolusi: tindakan yang diambil untuk memulihkan layanan
- Pembelajaran: apa yang berhasil, apa yang tidak berhasil
- Item tindakan: tugas rekayasa yang konkret, bertanggung jawab, dan terikat waktu
Item tindakan berada di dalam pelacak. Mereka diprioritaskan seperti pekerjaan rekayasa lainnya. Postmortem tanpa item tindakan hanya menjadi cerita. Pekerjaan tersebut tidak mengubah apa pun.
Empat Sinyal Emas
Apa yang Harus Diukur Setiap Layanan
Buku SRE Google mengusulkan empat sinyal yang harus diekspos oleh setiap layanan yang berhadapan dengan pengguna: latency, traffic, errors, dan saturation. Bersama-sama mereka menggambarkan kesehatan layanan dari perspektif pengguna. Memantau dengan sinyal yang lebih sedikit meninggalkan titik buta; memantau dengan ratusan metrik justru membanjiri tim dengan alert fatigue.
Latency: berapa lama waktu yang dibutuhkan permintaan. Lacak distribusi, bukan rata-rata. p50 (median) menggambarkan pengalaman tipikal. p99 menggambarkan 1% pengguna terburuk. Rata-rata saja menyembunyikan long tail: layanan dengan median 50 ms dan p99 5.000 ms terlihat baik-baik saja pada rata-rata, tetapi merusak satu dari seratus pengguna.
Traffic: beban permintaan pada layanan. Untuk layanan web, ini berarti permintaan per detik. Untuk layanan streaming, koneksi simultan. Untuk pekerjaan batch, item yang diproses per menit. Traffic berkorelasi dengan keputusan kapasitas dan mengungkap anomali beban kerja.
Errors: tingkat permintaan yang gagal. Kegagalan eksplisit (HTTP 500), kegagalan implisit (HTTP 200 dengan data rusak), dan kegagalan kebijakan (respons terlalu lambat untuk memenuhi SLO) semuanya dihitung. Membedakan di antara mereka penting: respons 200 dengan payload buruk seringkali lebih merugikan pengguna daripada 500 yang jujur.
Saturasi: seberapa penuh sistem berjalan. Utilisasi CPU, kedalaman antrean, tekanan memori, okupansi kolam koneksi. Saturasi memprediksi latensi di masa depan: sistem pada 95% CPU memiliki sangat sedikit ruang sebelum latensi yang dirasakan pengguna melonjak.
Sebagian besar peringatan SRE berasal dari keempat sinyal ini. Peringatan berbasis gejala (peringatan saat pengguna akan menyadarinya) lebih unggul daripada peringatan berbasis penyebab (peringatan saat CPU melebihi 80%). Keempat sinyal emas menggambarkan gejala.
Jalur Karir SRE
Di Mana Keterampilan SRE Bernilai
Karir SRE terbagi berdasarkan bagian mana dari disiplin yang paling disukai seorang insinyur:
Infrastructure SRE: membangun platform yang digunakan tim lain untuk menjalankan layanan mereka. Kubernetes, service mesh, cloud internal. Banyak pekerjaan rekayasa sistem, teori sistem terdistribusi, dan desain platform. Gaji sangat tinggi di perusahaan besar karena skalabilitas pekerjaannya: satu infrastructure SRE mendukung ratusan product engineer.
Embedded SRE: berpasangan dengan tim product engineering untuk meningkatkan keandalan layanan tertentu. Setengah engineer, setengah coach. Keterampilan komunikasi dan code review sama pentingnya dengan kedalaman teknis. Sering menjadi jalur terbaik bagi engineer yang menyukai mengajar.
Reliability tooling: membangun observability stack: monitoring, alerting, dashboard, postmortem tools, platform manajemen insiden. Banyak pekerjaan frontend dan data engineering. Output digunakan oleh setiap tim lain.
Production engineering: istilah Facebook/Meta untuk SRE yang berfokus pada kapasitas, deployment, dan manajemen traffic. Banyak pekerjaan jaringan dan sistem.
Sertifikasi teknis yang layak dimiliki: Google Cloud Professional Cloud Architect, AWS Solutions Architect Professional, dan sertifikasi CNCF (Kubernetes Administrator, Kubernetes Application Developer) menandakan kefasihan cloud-native. Sertifikasi Linux Foundation menandakan kedalaman sistem. Tidak ada yang menggantikan pekerjaan portofolio, tetapi mereka membantu menyaring penyaringan rekruter.
Menyimpulkan
Apa yang Anda Ketahui Sekarang
Site reliability engineering dimulai sebagai solusi Google terhadap masalah skalabilitas dan berkembang menjadi disiplin yang kini diterapkan di seluruh industri. Anda telah mempelajari:
- Pergeseran dari operasi manual ke keandalan yang direkayasa
- SLI, SLO, SLA, dan konsep error budget sebagai kebalikan dari SLO
- Definisi toil, aturan 50%, dan pengurangan berbasis rekayasa
- Rotasi on-call yang berkelanjutan dan praktik postmortem tanpa menyalahkan
- Empat sinyal emas sebagai titik awal untuk pemantauan layanan
- Jalur karir SRE dan sertifikasi yang membuka peluang
Dua ide yang paling penting. Reliabilitas adalah sebuah angka, yang disepakati di awal. Dan toil adalah cacat, bukan deskripsi pekerjaan. Bawa kedua hal ini ke depan dan seluruh SRE akan mengikuti secara alami.
Bacaan yang direkomendasikan: Buku SRE Google (gratis online: sre.google/books/), SRE Workbook untuk latihan praktis, dan tulisan Charity Majors tentang observabilitas. Pelajaran geometri-of companion membahas lebih dalam tentang struktur visual di balik praktik SRE: distribusi latensi, kerucut anggaran kesalahan, grafik ketergantungan, dan tata letak dasbor.