Apa Itu Site Reliability Engineering? Panduan Praktis

Apa itu site reliability engineering? Ini adalah praktik menjalankan sistem produksi dengan rekayasa perangkat lunak, bukan operasi manual. Tim SRE menetapkan target keandalan yang bisa diukur, lalu mengotomatiskan pekerjaan berulang yang menjaga layanan tetap hidup. Jika pager Anda berbunyi jam 3 pagi karena alert disk yang sama setiap bulan, itulah masalah yang ingin dihilangkan SRE.

Google memperkenalkan istilah ini sekitar tahun 2003. Sekarang idenya dipakai jauh melampaui Google, dari startup berisi 20 orang sampai bank. Yang berbeda antara keduanya adalah skala, bukan mekanisme intinya.

Apa yang sebenarnya dikerjakan seorang site reliability engineer?

Ben Treynor Sloss, yang memimpin tim SRE pertama Google, merangkumnya dengan sederhana di bab pembuka buku SRE Google: SRE adalah hasil ketika Anda meminta seorang software engineer mendesain tim operasi. Pekerjaannya tetap operasi, tetapi dikerjakan dengan kode.

Dalam satu minggu biasa, ada empat hal yang dikerjakan. Anda mendefinisikan apa arti "berfungsi" untuk sebuah layanan. Anda membangun monitoring yang memberi tahu ketika layanan tidak berfungsi. Anda merespons saat sesuatu rusak. Lalu Anda menulis perbaikannya, supaya orang berikutnya tidak dibangunkan karena masalah yang sama.

Dua contoh membuatnya lebih konkret. Tim yang men-deploy secara manual setiap Kamis membangun pipeline dengan rollback otomatis. Tim yang me-restart layanan yang bocor setiap malam akhirnya mencari sumber kebocorannya. Keduanya mengubah pekerjaan rutin menjadi proyek sekali jalan, dan di situlah intinya.

Bagian keempat adalah bagian yang sering dilewatkan. SRE yang hanya merespons insiden tidak lebih dari engineer operasi dengan judul baru. Bagian rekayasa itulah yang membuat peran ini berbeda.

Bagaimana SRE berbeda dari DevOps?

DevOps adalah budaya: developer dan operator berbagi tanggung jawab atas apa yang dirilis dan bagaimana cara menjalankannya. Ia menyadarkan kita bahwa tembok antar tim adalah masalah. Tetapi ia tidak memberi tahu seberapa besar downtime yang bisa diterima, atau kapan harus berhenti merilis.

SRE menyediakan angkanya. Ia memberi service level objective, error budget, dan batas pada pekerjaan manual. Cara Google membingkainya: SRE adalah salah satu implementasi konkret dari ide-ide DevOps.

Tidak perlu memperdebatkan mana yang "lebih baik". Jika Anda memimpin tim berisi 8 orang, Anda pasti meminjam dari keduanya. Pertanyaan yang berguna adalah apakah tim Anda bisa menjawab dalam satu kalimat seberapa andal sebuah layanan harus berjalan.

Apa itu SLI, SLO, dan SLA, dan mengapa penting?

Tiga akronim ini memikul sebagian besar beban di SRE, dan orang sering mencampuradukkannya.

• SLI (service level indicator): sebuah pengukuran. Contohnya, porsi request HTTP yang mengembalikan respons non-5xx dalam waktu di bawah 300 ms.

• SLO (service level objective): target untuk pengukuran itu. Contohnya, 99.9% request dalam jendela bergulir 28 hari.

• SLA (service level agreement): kontrak dengan konsekuensi, biasanya pengembalian dana jika target meleset. SLA Anda sebaiknya lebih longgar daripada SLO.

Bayangkan dua tim yang sama-sama mengatakan layanan mereka "cukup andal". Yang satu menargetkan 99%, yang lain 99.99%. Keduanya benar menurut definisi mereka sendiri, dan keduanya akan berselisih begitu ada insiden. Angka yang eksplisit menghilangkan ambiguitas itu sebelum insiden terjadi.

Alasan untuk repot dengan ini sederhana. Kalimat "situsnya harus cepat dan andal" tidak bisa diuji. Target seperti "99.9% request checkout berhasil dalam waktu di bawah 500 ms" bisa diuji, dan itu mengakhiri perdebatan.

Mulailah dengan dua atau tiga SLI per layanan. Lebih dari itu, tidak ada yang mengingatnya.

Pilih SLI yang bisa dirasakan pengguna. Penggunaan CPU adalah penyebab, bukan gejala. Checkout yang gagal, halaman yang lambat, dan data yang sudah basi adalah hal-hal yang dirasakan pelanggan.

Bagaimana error budget bekerja?

Error budget adalah ketidakandalan yang diizinkan oleh SLO Anda. Rumusnya sederhana: 1 dikurangi SLO. Target ketersediaan 99.9% menyisakan 0.1%, kira-kira 43 menit downtime dalam bulan 30 hari.

Berikut versi kecilnya dalam kode, karena aritmetika itulah inti dari ide ini:

slo = 0.999
window_minutes = 30 * 24 * 60          # 43200
budget = (1 - slo) * window_minutes    # 43.2 menit
spent = 31                              # menit layanan buruk sejauh ini
print(f"{budget - spent:.1f} menit tersisa")  # 12.2 menit tersisa

Selama budget masih ada, tim bisa merilis dengan cepat. Ketika budget habis, rilis fitur dijeda dan pekerjaan beralih ke keandalan. Contoh kebijakan error budget di SRE Workbook menunjukkan bagaimana sebuah tim menuliskan aturan itu.

Tujuannya bukan menghukum. Aturan ini menggantikan pertengkaran lama, di mana developer ingin merilis dan operator ingin stabilitas, dengan satu angka bersama yang bisa dibaca kedua pihak. Cara ini hanya berhasil jika pimpinan sepakat di muka untuk menghormati jeda tersebut. Kebijakan yang dilanggar setiap kuartal hanyalah hiasan.

Mengapa ada aturan toil 50%?

Toil adalah pekerjaan manual dan berulang yang bertambah seiring membesarnya layanan, dan tidak meninggalkan apa pun. Me-restart worker yang macet secara manual adalah toil. Menulis health check yang me-restart-nya secara otomatis adalah rekayasa.

Organisasi SRE Google bertujuan menjaga toil di bawah 50% waktu setiap engineer, seperti dijelaskan dalam bab tentang menghilangkan toil. Sisa waktunya dipakai untuk proyek yang mengurangi toil di masa depan atau menambah fitur. Alasannya lugas: toil akan memenuhi 100% waktu semua orang jika tidak ada yang menghentikannya.

Contoh toil yang sering luput: memindahkan data secara manual antar-sistem setiap akhir bulan, atau menyetujui permintaan akses yang sebenarnya bisa diotomasi dengan aturan yang jelas. Pekerjaan semacam ini terasa kecil satu per satu, tetapi jumlahnya bertambah diam-diam.

Anggap 50% sebagai batas atas, bukan target. Tim yang sehat di layanan yang sudah matang berada jauh di bawahnya. Jika Anda melewatinya selama satu kuartal, Anda tidak sedang menjalankan SRE. Anda sedang menjalankan antrean operasi.

Cara sederhana untuk memulai: selama dua minggu, beri tag pada setiap tiket dan page sebagai toil atau proyek. Lalu urutkan toil berdasarkan jam kerja. Tiga item teratas adalah backlog otomasi Anda.

Apa yang berubah dengan blameless postmortem?

Ketika sesuatu rusak, postmortem menanyakan bagaimana sistem memungkinkan seseorang membuat kesalahan itu, bukan siapa yang membuatnya. Menyalahkan orang mengajarkan mereka untuk menyembunyikan informasi. Review tanpa menyalahkan mengajarkan mereka untuk menuliskannya.

Postmortem yang berguna itu singkat dan memiliki empat bagian: linimasa, penyebab yang berkontribusi, apa yang berjalan dengan baik, dan action item dengan pemilik serta tanggal. Action item tanpa pemilik hanyalah harapan.

Sebagian besar nilainya datang dari tindak lanjut. Tinjau action item yang masih terbuka setiap bulan. Jika penyebab yang sama muncul dua kali dalam enam bulan, postmortem pertama gagal, apa pun isi dokumennya.

Tools apa yang dibutuhkan tim SRE lebih dulu?

Tidak banyak. Mulailah dari sinyal, lalu tambahkan on-call dan otomasi.

1. Metrik dan dasbor. Cukup untuk menghitung SLI Anda. Grafana dan Prometheus adalah pasangan open source yang umum dipakai. Datadog dan New Relic adalah jalur hosted.

2. Alerting yang terhubung ke SLO. Beri alert saat budget terbakar dengan cepat, bukan saat satu host melonjak. Pager lebih sedikit, dan lebih bermakna.

3. Feature flag dan rollout bertahap. Kurang lebih, sebagian besar outage mengikuti sebuah perubahan, jadi kemenangan keandalan yang paling murah adalah membuat perubahan bisa dibatalkan. LaunchDarkly dan Statsig mencakup kebutuhan ini.

4. Runbook tertulis untuk setiap page. Jika sebuah alert tidak punya runbook, tulis runbook-nya atau hapus alert-nya.

Beli atau bangun, dan urutkan seperti itu. Tim yang mulai dengan membeli tool tanpa SLO berakhir dengan dasbor yang indah tetapi tidak jelas untuk apa.

Di mana membaca kode yang tidak familiar cocok dalam SRE?

Ini bagian yang tidak pernah dicantumkan dalam deskripsi pekerjaan. Saat insiden, SRE sering harus memahami layanan yang tidak ia tulis, di repositori yang sudah berbulan-bulan tidak dibuka. Pertanyaannya jarang abstrak. Biasanya bunyinya begini: "di mana retry loop ini berada, dan apa yang dilakukannya saat timeout?"

Anda sudah pernah melakukannya: grep, blame, lalu mengirim pesan ke orang yang terakhir menyentuh file itu. Di repo 80K baris, cara ini masih berhasil. Di dua belas layanan yang dimiliki enam tim, cara ini menghabiskan 20 menit pertama insiden, dan menit-menit itu dihitung terhadap error budget.

Di sinilah alat pencarian kode yang bisa menjawab pertanyaan tentang repo Anda sendiri menjadi berguna. Contohnya, menanyakan di mana sebuah layanan mengatur timeout-nya dan caller mana yang bergantung padanya. Alat seperti itu tidak akan memperbaiki outage. Ia memperpendek waktu membaca sebelum Anda bisa bertindak, dan waktu itu bisa diukur.

Apakah SRE berlebihan untuk tim Anda, dan bagaimana memulainya?

Lewati tim SRE khusus jika Anda hanya punya satu layanan, beberapa engineer, dan pengguna yang bisa menoleransi jam buruk sesekali. Anda tidak butuh tim. Anda butuh satu SLO, satu alert yang baik, dan seseorang yang memegang pager.

Pertimbangkan hal ini begitu salah satu kondisi berikut terjadi: outage menimbulkan kerugian pendapatan nyata, on-call membuat orang kelelahan, atau developer terhambat oleh permintaan operasi ad hoc. Banyak perusahaan memulai dengan menjadikan satu atau dua engineer sebagai SRE paruh waktu, lalu melihat hasilnya.

Kesalahan yang umum adalah mengganti nama tim operasi menjadi "SRE" tanpa mengubah cara kerjanya. Jika tim masih memiliki tiket, deploy manual, dan tidak ada error budget, judulnya yang berubah dan yang lainnya tidak.

Cara memulai minggu depan

Anda tidak perlu reorganisasi. Pilih satu layanan yang menghadap pengguna dan paling sering bermasalah, lalu kerjakan lima hal berikut.

1. Tulis satu SLI dan satu SLO untuk layanan itu. Buat tetap sederhana.

2. Hitung error budget dan tampilkan di dasbor yang bisa dilihat seluruh tim.

3. Lacak toil selama dua minggu dan pilih item teratas untuk diotomasi.

4. Adakan blameless postmortem untuk insiden berikutnya, dengan action item yang punya pemilik.

5. Sepakati secara tertulis apa yang terjadi ketika error budget mencapai nol.

Jika sebulan lagi tim lebih sedikit berdebat tentang apakah harus merilis dan lebih banyak membahas apa yang ditunjukkan angka-angkanya, berarti ini berhasil. Jika budget tidak pernah bergerak karena SLO-nya terlalu longgar, perketat SLO-nya.