Pertanyaan dan kapan ini berlaku
Pewawancara mungkin bertanya, “Dalam sebuah system design, bagaimana Anda akan menggunakan error budget untuk menyeimbangkan keandalan dan kecepatan rilis?” Anda harus menjelaskan bagaimana SLI, SLO, dan error budget memengaruhi rilis, rollback, kapasitas, dan koordinasi tim. Ini cocok untuk wawancara SRE, platform, backend, dan system design tingkat senior yang melibatkan ketersediaan tinggi, rilis berkala, atau dependensi antartim.
Apa yang dinilai oleh pewawancara
Ujiannya bukanlah apakah Anda dapat menghafal angka 99,99%. Ini tentang apakah Anda dapat mengubah tujuan pengalaman pengguna menjadi aturan keputusan operasional. Google SRE menggambarkan error budget sebagai ruang tersisa di bawah SLO, yang digunakan untuk mengoordinasikan pekerjaan keandalan dan inovasi; ketika anggaran habis, perubahan biasa dijeda sementara keandalan dipulihkan. Pewawancara juga mencari jendela pengukuran, kualitas data, progressive delivery, dan pengecualian yang dapat diaudit.
Pertanyaan klarifikasi untuk ditanyakan pada diri sendiri
Perjelas siapa penggunanya, perjalanan (journey) mana yang penting, di mana batas layanan berada, dan apakah tujuannya adalah ketersediaan, latensi, kesegaran (freshness), atau kebenaran data. Konfirmasikan jendela SLO, wilayah, kepemilikan dependensi, dan kemampuan rollback. Jika angka tidak tersedia, nyatakan asumsi seperti jendela empat minggu, ketersediaan 99,9%, dan pengukuran berdasarkan permintaan pengguna yang valid.
Kerangka jawaban 30 detik
Gunakan lima langkah:
- Tentukan SLI dan SLO yang terlihat oleh pengguna.
- Hitung error budget untuk jendela tersebut dan jelaskan apa yang mengonsumsinya.
- Hubungkan anggaran dengan progressive delivery, rollback otomatis, dan change gate.
- Ketika anggaran habis, bekukan perubahan biasa dan prioritaskan pekerjaan keandalan, dengan pengecualian eksplisit untuk keamanan dan perbaikan mendesak.
- Gunakan postmortem, atribusi dependensi, dan tren anggaran untuk menyesuaikan siklus perencanaan berikutnya.
Jawaban mendalam langkah demi langkah
1. Tentukan SLI dari hasil pengguna
Jangan menggunakan CPU server atau latensi rata-rata sebagai target keandalan secara default. Untuk layanan berbasis permintaan, pilih proporsi permintaan yang berhasil dan permintaan di bawah ambang batas latensi; untuk asynchronous job, gunakan penyelesaian tepat waktu atau kesegaran hasil. Pisahkan kegagalan yang berdampak pada pengguna dari retry internal dan lalu lintas tidak valid agar kebisingan (noise) tidak menghabiskan anggaran.
2. Pilih SLO dan jendela yang dapat dijelaskan
Misalnya, 99,9% permintaan valid yang berhasil selama empat minggu memungkinkan sekitar 0,1% mengalami kegagalan. Jendela tersebut mengontrol sensitivitas terhadap insiden singkat dan tren jangka panjang. Dengan beberapa SLO, nyatakan aturan kombinasinya: critical user journey dapat memblokir rilis, sementara metrik sekunder menginformasikan peringatan dan perencanaan. Jangan merata-ratakan persentase tanpa menjelaskan populasi dan bobotnya.
3. Atribusikan konsumsi anggaran ke perubahan
Catat total anggaran, burn rate, dan penyebabnya. Beri tag secara terpisah untuk rilis, konfigurasi, kegagalan dependensi, kekurangan kapasitas, dan false positive. Hanya atribusi tepercaya yang memberi tahu tim apakah harus memperbaiki kode, menambah kapasitas, mengubah kontrak dependensi, atau memperbaiki pemantauan. Contoh kebijakan Google juga membedakan kegagalan dalam layanan, kegagalan yang dimiliki oleh tim lain, dan lalu lintas di luar cakupan SLO.
4. Rancang release gate dan rollback progresif
Kirim perubahan biasa ke sebagian kecil lalu lintas atau satu wilayah, amati tingkat kesalahan, latensi, dan burn rate, lalu perluas. Gate harus memeriksa sisa anggaran dan burn rate jendela pendek; rata-rata bulanan yang aman dapat menyembunyikan insiden yang memburuk dengan cepat. Ketika perilaku tidak terduga, lakukan rollback sebelum mendiagnosis untuk mengurangi waktu pemulihan. Rollback juga membutuhkan idempoten dan kompatibilitas data.
5. Tentukan apa yang terjadi setelah anggaran habis
Menghabiskan anggaran bukan berarti pengembangan berhenti selamanya. Bekukan fitur biasa dan perubahan data yang tidak penting, lalu prioritaskan kapasitas, pengujian, isolasi dependensi, degradasi bertahap (graceful degradation), dan perbaikan akar masalah. Perbaikan keamanan dan cacat mendesak yang mengatasi kegagalan SLO dapat menjadi pengecualian, tetapi catat alasan, pemberi persetujuan, dan tinjauan tindak lanjut agar status "mendesak" tidak menjadi jalan pintas permanen.
6. Tangani dependensi dan kepemilikan lintas tim
Jangan menyembunyikan setiap kegagalan eksternal di dalam SLO layanan. Lacak kesalahan dependensi, klien, dan layanan secara terpisah, serta buat kepemilikan perbaikan dan komunikasi menjadi eksplisit. Ketika tim tidak setuju tentang aturan anggaran, selaraskan pada perjalanan pengguna dan pengukuran bersama, lalu eskalasikan melalui pemilik layanan. Mengalihkan kesalahan bukanlah strategi keandalan.
Contoh jawaban berkualitas tinggi
Jawaban fiktif ini harus diganti dengan angka dan batasan Anda sendiri:
Saya akan menentukan SLI tingkat keberhasilan dan latensi untuk permintaan pengguna yang paling penting. Misalkan SLO keberhasilan permintaan yang valid adalah 99,9% selama empat minggu, sehingga error budget adalah 0,1% dari permintaan yang valid. Pemantauan menunjukkan sisa anggaran, burn rate satu jam, dan atribusi kegagalan, tidak termasuk lalu lintas di luar batas layanan. Rilis dimulai di satu wilayah pada sebagian kecil lalu lintas dan diperluas secara bertahap; melewati ambang batas burn rate akan menghentikan peluncuran dan memicu rollback. Selama anggaran sehat, produk dan SRE dapat melakukan rilis dalam batas risiko yang dapat diterima. Setelah habis, perubahan biasa dibekukan dan tim memprioritaskan kapasitas, pengujian, isolasi dependensi, dan perbaikan akar masalah, dengan pengecualian yang dicatat untuk pekerjaan keamanan. Setiap insiden mendapatkan tinjauan tanpa saling menyalahkan (blameless review) dan perbaikan dimasukkan ke dalam siklus perencanaan berikutnya. Oleh karena itu, kecepatan rilis diatur oleh sisa anggaran dan risiko yang diamati, bukan oleh preferensi subjektif.
Kesalahan umum
Memperlakukan error budget sebagai izin untuk menyebabkan kegagalan
Anggaran mewakili ruang kegagalan yang ditoleransi pengguna, bukan kuota untuk membuat insiden. Jelaskan dampak pengguna, jendela, burn rate, dan kepemilikan perbaikan.
Hanya memberikan angka ketersediaan
Tanpa SLI, populasi, dan jendela, 99,99% tidak dapat memandu keputusan. Tambahkan permintaan yang valid, latensi atau kesegaran data, dan aturan untuk mengecualikan lalu lintas yang tidak relevan.
Membekukan rilis selamanya setelah anggaran terlampaui
Itu mengabaikan perbaikan keamanan, migrasi, dan pekerjaan pemulihan. Tentukan pengecualian, persetujuan, rollback, dan tinjauan agar pengecualian tidak menjadi jalur default.
Mengabaikan progressive delivery dan kompatibilitas rollback
"Pantau dan rilis" saja tidak cukup. Jelaskan tahapan lalu lintas, kondisi penghentian otomatis, urutan rollback, dan kompatibilitas antara operasi baca dan tulis lama serta baru.
Pertanyaan lanjutan dan latihan tingkat lanjut
SLO sehat, tetapi burn rate satu jam tinggi. Apakah Anda akan merilis?
Bandingkan saldo jendela panjang dengan tren jendela pendek. Jika konsumsi berkelanjutan, hentikan perluasan lalu lintas, verifikasi apakah itu dampak pengguna nyata, lonjakan lalu lintas, atau cacat pemantauan, lalu putuskan apakah akan melakukan rollback.
Dependensi eksternal menghabiskan anggaran. Haruskah tim Anda ikut membekukan rilis?
Periksa apakah komitmen layanan mencakup kegagalan dependensi tersebut, lalu putuskan berdasarkan perjalanan pengguna. Lindungi pengguna dan aktifkan degradasi bahkan ketika kepemilikan berada di pihak eksternal; aturan pembekuan harus disepakati sebelumnya dengan pembagian bukti dan eskalasi.
Beberapa SLO gagal sekaligus. Bagaimana Anda memprioritaskannya?
Urutkan berdasarkan critical user journey, blast radius, burn rate, dan reversibilitas. Atasi indikator yang dapat memperluas insiden atau menghalangi pemulihan terlebih dahulu, kemudian masalah kinerja lokal, dan nyatakan trade-off-nya.
Seorang product manager meminta Anda untuk merilis setelah anggaran habis. Bagaimana Anda meresponsnya?
Ubah perdebatan menjadi data: tunjukkan sisa anggaran, dampak pengguna, biaya rollback, dan waktu perbaikan. Tawarkan eksperimen kecil atau penundaan. Jika keadaan darurat bisnis yang tulus tetap ada, gunakan pengecualian yang tercatat sepenuhnya dan jadwalkan pekerjaan keandalan serta tinjauan.