Site Reliability Engineering: Cara Tim Engineering Indonesia Menjaga Uptime Tanpa Membakar Tim

TL;DR: Site Reliability Engineering (SRE) adalah pendekatan engineering yang memperlakukan operasional produk sebagai masalah software. Tim Indonesia yang mengadopsinya menetapkan SLO terukur, memakai error budget untuk menyeimbangkan rilis dan stabilitas, lalu mengotomasi toil operasional supaya engineer tidak terjebak rutinitas manual.

Saat membantu beberapa tim engineering klien menyiapkan kerangka kerja reliability, ada satu pola yang berulang. Tim mengejar 100% uptime, tidak punya angka SLO yang jelas, lalu kelelahan mengejar setiap peringatan tengah malam. SRE menawarkan disiplin yang sebaliknya: terima bahwa downtime kecil adalah anggaran yang bisa dipakai untuk inovasi.

Untuk tim Indonesia yang sedang berkembang dari startup ke skala menengah, mengadopsi SRE bukan soal merekrut "tim SRE" terpisah. Lebih sering ini soal mengubah cara engineering memandang reliability sebagai produk dengan metrik dan budget.

Tiga Pilar SRE

Konsep SRE yang dipopulerkan Google bertumpu pada tiga elemen yang saling menopang. Tanpa salah satunya, sistem cenderung kembali ke pola lama: panik saat insiden, lalu lupa saat tenang.

SLO, SLI, dan SLA adalah fondasi pengukuran. Tanpa angka spesifik, percakapan reliability menjadi anekdot.

Error Budget Mengubah Cara Diskusi Rilis

Error budget adalah angka yang muncul dari SLO. Kalau SLO Anda 99,9% per kuartal, error budget Anda adalah 0,1% downtime, sekitar 2 jam 10 menit. Selama anggaran ini belum habis, tim engineering boleh agresif merilis fitur. Begitu habis, fokus bergeser ke stabilisasi.

Pola ini ditulis lebih dalam di artikel error budget. Yang sering tim lupa: error budget adalah alat negosiasi antara product manager dan engineer. Tanpa angka ini, perdebatan rilis cepat vs stabil menjadi politis.

Toil: Pekerjaan yang Mestinya Dihilangkan

SRE mendefinisikan toil sebagai pekerjaan operasional yang manual, repetitif, tanpa nilai jangka panjang, dan scaling linear dengan ukuran sistem. Contohnya: restart manual layanan tiap minggu, deploy lewat klik UI, atau forward log secara manual ke tim lain.

Disiplin SRE menargetkan toil di bawah 50% waktu engineer. Saat menangani tim klien yang menjalankan platform untuk Atmo (LMS) dan Vetmo (pet care), pendekatan yang berhasil adalah satu engineer per minggu fokus pada otomasi toil terbesar yang teridentifikasi minggu sebelumnya. Setelah 8-12 minggu, jumlah pager call malam turun drastis.

Praktik yang Bisa Dimulai Minggu Ini

Adopsi SRE penuh memang bertahun-tahun, tetapi ada langkah yang bisa diambil tim engineering Indonesia minggu ini tanpa biaya tools mahal:

• Tetapkan satu SLO untuk endpoint paling kritis. Misal: 99,9% request berhasil dalam 500ms.
• Lacak observability dasar: logs, metrics, traces.
• Ukur Core Web Vitals dan latency p95 sebagai SLI.
• Buat runbook untuk 3 alert paling sering muncul.
• Lakukan blameless post-mortem setelah insiden, fokus ke sistem bukan orang.

Untuk referensi kerangka berpikir SRE, Google SRE Book gratis dibaca dan tetap menjadi rujukan paling lengkap.

Studi Kasus: Tim Kecil dengan Disiplin SRE Lebih Tahan

Saat bekerja dengan tim engineering yang menjalankan platform Atmo, kami menerapkan SLO 99,5% di tahap awal, bukan 99,99%. Alasannya sederhana: angka 99,99% berarti hanya 4 menit downtime per bulan, dan tim 4 orang tidak realistis mengejarnya tanpa burnout. Setelah 6 bulan disiplin di SLO 99,5%, tim baru menaikkan target ke 99,9% setelah otomasi mature.

Pelajaran utamanya: SLO yang terlalu agresif di awal bukan bukti kompetensi, justru bisa menjadi sumber kelelahan kronis. Naikkan bertahap mengikuti maturitas operasional.

Pertanyaan Umum

Apakah SRE hanya untuk tim besar?

Tidak. Prinsipnya berlaku di tim 3 orang. Yang berbeda hanya skala otomasi. Tim kecil cukup memulai dengan SLO sederhana dan satu runbook.

Bedanya DevOps dan SRE apa?

DevOps adalah filosofi kolaborasi dev dan ops. SRE adalah implementasi spesifik dari prinsip itu, dengan fokus terukur pada SLO, error budget, dan toil reduction.

Berapa lama sampai dampak terasa?

Per pengalaman, 3-6 bulan untuk melihat penurunan insiden, 12-18 bulan untuk transformasi budaya tim engineering.

Apakah perlu hire SRE engineer khusus?

Tidak wajib. Tim engineering existing bisa adopsi prinsipnya secara bertahap. Hire dedicated SRE biasanya relevan saat tim sudah di atas 20 engineer atau menjalankan multi-region.

Penutup: Reliability adalah Fitur Produk

Reliability bukan urusan ops tersembunyi, melainkan fitur yang dirasakan pelanggan setiap kali mereka memakai produk. Tim Indonesia yang memperlakukan reliability dengan disiplin SRE biasanya merilis lebih cepat justru karena punya angka untuk berdebat. Mulai dari satu SLO. Naikkan bertahap. Otomasi toil terbesar lebih dulu.