Apa Itu Site Reliability Engineering? Panduan untuk Dev

Apa itu site reliability engineering? Ini cara memperlakukan operasional sebagai masalah software: kamu menetapkan target keandalan yang bisa diukur, mencatat seberapa sering target itu meleset, dan membiarkan angka tersebut memutuskan apakah kamu merilis fitur atau memperbaiki masalah. Google yang mempopulerkan istilahnya, tapi idenya berlaku di skala apa pun. Untuk developer solo dengan satu aplikasi dan beberapa pengguna, artinya kamu memutuskan dari awal berapa lama downtime yang masih bisa kamu terima.

Masalah yang sering muncul di lapangan: kebanyakan side project tidak punya angka seperti itu. Aplikasinya dianggap "hidup" sampai ada yang mengirim email mengeluh. Artikel ini menjelaskan SRE dengan bahasa biasa, lalu memangkasnya jadi sesuatu yang bisa dijalankan satu orang dalam satu akhir pekan.

Jadi, sebenarnya apa SRE itu?

Versi singkatnya datang dari buku SRE Google: SRE adalah hasil ketika kamu meminta software engineer mendesain tim operasional. Alih-alih orang me-restart server secara manual, kamu menulis kode yang melakukannya, lalu mengukur hasilnya.

Ada tiga ide yang menanggung sebagian besar bobotnya. Keandalan adalah fitur dengan target, bukan perasaan. Pekerjaan manual yang berulang (buku itu menyebutnya toil) adalah bug yang harus diotomasi. Dan kegagalan dianggap pasti terjadi, jadi kamu merencanakan cara belajar darinya, bukan cara menghindari kesalahan siapa pun.

DevOps dan SRE banyak beririsan. Bedanya secara praktis: DevOps adalah budaya membangun dan menjalankan kode bersama, sedangkan SRE memberimu alat konkret untuk berdebat soal itu dengan angka. Kamu tidak perlu memilih kubu untuk memakai angka-angkanya.

SLI, SLO, SLA: tiga singkatan, satu ide masing-masing

SLI (service level indicator) adalah sesuatu yang kamu ukur. Untuk aplikasi web, biasanya persentase request yang berhasil, atau persentase request yang dijawab di bawah 300 ms. Pilih satu atau dua. Jangan dua belas.

SLO (service level objective) adalah target yang kamu pasang pada ukuran itu, misalnya "99,9% request berhasil selama 30 hari". Ini internal. Ini janji kepada dirimu sendiri.

SLA (service level agreement) adalah kontrak dengan pelanggan, biasanya dengan refund jika meleset. Kalau belum ada yang membayarmu untuk uptime, kamu belum punya SLA, dan jangan sampai tanpa sengaja menuliskannya di halaman harga.

Error budget: bagian yang mengubah cara kerjamu

Error budget sederhananya adalah 100% dikurangi SLO. Target 99,9% selama 30 hari menyisakan sekitar 43 menit kegagalan yang boleh terjadi. Itu anggaran yang bisa kamu belanjakan untuk deploy berisiko, migrasi, dan eksperimen.

Bagian yang berguna ada pada aturan yang menempel padanya. Selama budget masih tersisa, kamu merilis. Kalau sudah habis, kamu berhenti merilis fitur dan memperbaiki keandalan sampai budget pulih. Bab tentang risiko di buku SRE membingkainya sebagai cara menyelesaikan perdebatan antara "bergerak cepat" dan "jangan merusak" dengan satu angka bersama, bukan negosiasi tanpa ujung.

Ada juga poin tajam yang layak diulang: 100% hampir tidak pernah menjadi target yang tepat. Pengguna dengan jaringan seluler yang putus-putus tidak bisa membedakan 99,99% dari 99,9%, dan setiap sembilan tambahan biayanya jauh lebih besar daripada sembilan sebelumnya. Ini bukan target yang sempurna. Tapi ini target yang bisa dijalankan.

Kalau kamu ingin workflow konkret untuk memilih indikator dan menulis objektif pertama, workbook SRE tentang implementasi SLO adalah bab yang paling praktis dan relatif singkat.

Apa yang sebenarnya dikerjakan SRE setiap hari?

Di perusahaan besar, SRE membagi waktunya antara on-call, respons insiden, perencanaan kapasitas, dan pekerjaan otomasi. Buku Google menyarankan untuk membatasi beban operasional sekitar separuh waktu seorang engineer, supaya sisanya bisa dipakai untuk engineering. Batas itu adalah batasan desain, bukan sekadar pilihan bagus.

Pekerjaan rutinnya kira-kira seperti ini:

• Menetapkan SLO bersama tim produk, lalu memberi alert pada laju pemakaian budget, bukan pada setiap gangguan kecil

• Menjalankan rotasi on-call dan menulis runbook supaya alert jam 3 pagi punya daftar periksa

• Memimpin respons insiden, lalu menulis postmortem yang tidak menyalahkan siapa pun

• Mengotomasi apa pun yang dikerjakan secara manual lebih dari beberapa kali

• Meninjau rilis untuk risiko keandalan sebelum masuk ke produksi

Feature flag adalah contoh bagus untuk pola pikir ini. Flag memungkinkanmu mematikan rilis yang buruk dalam hitungan detik tanpa deploy ulang, dan itu melindungi budget. Apakah kamu perlu tool hosted untuk itu bergantung pada jumlah flag-mu: untuk tiga flag pertama, environment variable sudah cukup.

Perlukah SRE kalau kamu membangun sendirian?

Ada tiga alasan untuk melakukannya, dan satu alasan untuk tidak.

Alasan untuk melakukannya: cepat atau lambat side project-mu akan membangunkanmu sendiri; target tertulis mencegahmu over-engineering; dan kalimat "saya menjalankan produksi dengan SLO" terdengar bagus ketika seseorang sedang memutuskan apakah akan mempekerjakan atau mempercayaimu. Alasan untuk tidak: kalau proyekmu belum punya pengguna, kamu sedang berlatih untuk masalah yang belum kamu miliki. Bangun dulu, ukur ketika ada yang bergantung padanya.

Jadi lewati perangkat lengkapnya. Jangan sewa layanan pager untuk aplikasi hobi, jangan jalankan Kubernetes supaya terlihat serius, dan jangan tulis template insiden sepuluh halaman. Yang layak dilakukan begitu kamu punya minimal sepuluh pengguna sungguhan: satu health check, satu SLO, dan satu tempat untuk melihat ketika ada yang rusak.

Setup SRE satu malam untuk side project

Ini minimum yang cenderung bertahan ketika pengguna sudah mencapai 10.000 orang, dan butuh satu malam untuk membuatnya. Sudah diuji. Belum optimal. Alasan kami tetap melakukannya: membosankan, dan yang membosankan biasanya bertahan.

Pertama, pilih satu SLI: persentase request HTTP yang tidak mengembalikan 5xx. Kedua, pasang SLO di 99,5% selama 30 hari, yang kira-kira setara dengan 3,6 jam budget. Mulai longgar, perketat nanti. Ketiga, tambahkan uptime check eksternal yang menembak health endpoint sungguhan.

Health endpoint yang layak punya memeriksa hal-hal yang benar-benar bisa rusak, bukan sekadar memastikan prosesnya masih hidup:

// GET /healthz
app.get("/healthz", async (req, res) => {
  try {
    await db.query("select 1");          // database bisa dijangkau
    await cache.ping();                  // cache bisa dijangkau
    res.status(200).json({ ok: true });
  } catch (err) {
    res.status(503).json({ ok: false });
  }
});

Keempat, kirim alert ke tempat yang pasti kamu lihat, yaitu notifikasi push di ponsel, bukan inbox. Kelima, simpan file teks biasa bernama postmortems.md dan tambahkan empat baris setelah setiap outage: apa yang terjadi, mengapa, berapa lama, dan apa yang berubah. File itu adalah alat keandalan yang paling diremehkan yang akan kamu miliki.

Di mana AI membantu, dan di mana tidak

Asisten AI cukup bagus di sisi pekerjaan manual: menulis health check, Terraform untuk uptime monitor, draf pertama runbook, atau script yang mem-parsing log untuk menghitung rasio 5xx. Mereka buruk dalam menentukan SLO-mu, karena itu adalah keputusan produk tentang apa yang bisa ditoleransi penggunamu.

Saat insiden, hati-hati. Asisten bisa menyarankan perbaikan yang masuk akal, lalu kamu terapkan ke produksi jam 2 pagi tanpa membacanya dengan benar. Gunakan untuk menjelaskan stack trace atau menulis draf postmortem setelahnya, dan biarkan keputusan rollback di tangan manusia yang sedang terjaga.

Quality gate di CI juga masuk dalam gambar ini. Banyak outage berasal dari perubahan yang tampak tidak berbahaya saat review. Static analysis di CI tidak akan memberimu keandalan, tapi ia menghapus satu kelas kesalahan konyol sebelum sempat menghabiskan budget.

Bagaimana menulis postmortem yang benar-benar dibaca orang?

Buat singkat dan tanpa menyalahkan. Tanpa menyalahkan bukan berarti tidak ada yang bertanggung jawab. Artinya kamu bertanya apa di dalam sistem yang memungkinkan kesalahan terjadi, bukan siapa yang melakukannya. Kalau kamu satu-satunya orang di tim, ini lebih penting daripada kedengarannya, karena godaannya adalah merasa tidak enak lalu melewatkan penulisannya.

Empat judul sudah cukup: apa yang terjadi, mengapa terjadi, berapa lama pengguna terdampak, dan apa yang berubah. Bagian terakhir harus menyebut tindakan yang benar-benar akan kamu lakukan, dengan tanggal. "Lebih hati-hati" bukan tindakan. "Tambahkan pengecekan migrasi di staging sebelum rilis berikutnya" adalah tindakan.

Setelah setahun, file itu berubah menjadi peta titik lemahmu. Aturannya: kalau penyebab yang sama muncul dua kali, otomasikan. Pernah ada tiga outage yang disebabkan sertifikat kedaluwarsa yang sama. Menambahkan monitoring perpanjangan sertifikat hanya butuh satu malam, dan sejak itu tidak pernah terulang.

Alert berdasarkan burn rate, bukan setiap gangguan kecil

Kesalahan pemula yang umum adalah membangunkan diri sendiri setiap kali satu request gagal. Dalam seminggu kamu akan membisukan channel-nya. Sinyal yang lebih baik adalah burn rate: seberapa cepat kamu menghabiskan error budget dibandingkan laju yang akan menghabiskannya tepat di akhir periode.

Untuk side project, buat sederhana. Kirim notifikasi push jika error rate dalam 10 menit terakhir di atas 5%, dan kirim ringkasan email jika rate mingguan mengarah ke meleset dari SLO. Itu dua level: bangun sekarang, atau cek hari Senin. Yang lebih rumit bisa menunggu sampai pengguna mengeluh tentang level pertama.

Contoh konkretnya: kalau SLO-mu 99,5% selama 30 hari, budget-mu sekitar 3,6 jam. Jika dalam dua hari pertama satu jam sudah hilang karena deploy yang rusak, laju pemakaianmu jauh di atas normal dan itu layak membangunkanmu malam itu juga. Jika yang hilang cuma dua menit karena satu request timeout acak, tidak ada yang perlu dikejar. Angka yang sama, keputusan yang berbeda, dan itulah gunanya burn rate.

Apakah SRE jalur karier yang bagus untuk dev yang suka membangun?

Tergantung apa yang kamu nikmati. Peran SRE cocok untuk orang yang lebih suka sistem, mode kegagalan, dan otomasi daripada mengirim UI. Kalau kamu puas membuat pager lebih sepi, kamu akan menyukainya. Kalau kamu ingin melihat pengguna mengklik fitur barumu, kemungkinan besar tidak.

Jalur masuknya biasanya lewat pekerjaan backend atau infrastruktur: kamu mulai memiliki deploy dan alert sebuah layanan, lalu mengambil lebih banyak tanggung jawab atas keandalannya. Skill yang ikut terbawa: dasar Linux, networking, satu cloud provider, stack monitoring, dan kebiasaan menulis hal-hal ke catatan. Side project adalah tempat yang wajar untuk membangun semuanya, karena kamu adalah seluruh timnya.

Apa yang dibangun berikutnya?

Pilih satu hal yang sudah kamu jalankan, bahkan aplikasi tier gratis. Tulis SLI-nya, SLO-nya, dan tindakan persis yang akan kamu ambil ketika budget habis. Kalau kamu tidak bisa menyebutkan apa yang akan kamu hentikan, angkanya cuma hiasan. Proyekmu yang mana yang akan kamu sadari sedang down sebelum ada pengguna yang memberitahumu?