Konteks dan pertanyaan
Layanan ini memiliki SLO ketersediaan 99,99% dan error budget bulanan 0,01%. Kegagalan yang terlihat oleh pengguna telah melebihi anggaran, namun fitur yang memengaruhi perpanjangan kontrak utama sedang menunggu untuk dirilis. Jelaskan bagaimana Anda mendefinisikan indikator, memverifikasi bahwa anggaran benar-benar habis, memutuskan perubahan mana yang dijeda, dan memulihkan ritme rilis yang sehat.
Google SRE memperlakukan error budget sebagai ruang kegagalan yang diizinkan oleh SLO: selama anggaran masih ada, tim dapat melakukan rilis dalam batas wajar; setelah habis, perubahan biasanya dibekukan, kecuali perbaikan keamanan mendesak dan perbaikan untuk kegagalan saat ini. Ini adalah masukan untuk keputusan risiko, bukan larangan mutlak terhadap produk.
Apa yang diuji oleh pewawancara
Jawaban yang kuat dimulai dari SLI yang berpusat pada pengguna dan menghubungkan konsumsi anggaran dengan waktu rilis, rollback, dan pemulihan. Antisipasi pertanyaan tentang mengapa metrik server dapat salah menggambarkan ketersediaan pengguna, cara membedakan lonjakan singkat dari pembakaran berkelanjutan (sustained burn), bukti apa yang membenarkan pengecualian, dan siapa yang dapat mencabut pembekuan.
"Hentikan semua pengembangan" mengabaikan kewajiban keamanan, integritas data, dan kepatuhan. "Bisnis itu penting, jadi tetap rilis" mengabaikan bahasa risiko bersama.
Pertanyaan klarifikasi awal
Dampak pengguna dan batasan metrik
Pastikan bahwa SLI berasal dari alur perjalanan pengguna (user journeys) yang sebenarnya dan mencakup klien, dependensi, serta alur kerja penting. Pisahkan kegagalan permintaan, latensi, data yang salah, dan ketidaktersediaan; satu nilai rata-rata dapat menyembunyikan tail latency atau dampak parah pada satu kelompok pelanggan tertentu.
Jendela anggaran dan burn rate
Klarifikasi apakah anggaran bersifat bulanan, triwulanan, atau bergulir (rolling), ditambah burn rate saat ini dan tingkat ketidakpastiannya. Saldo harus menjawab "berapa lama kita dapat mempertahankan kondisi ini?" alih-alih hanya menampilkan persentase.
Nilai dan risiko rilis
Nilai pendapatan, kepatuhan, dan nilai keamanan. Bisakah fitur tersebut diuji coba melalui canary, di-rollback, atau dibatasi untuk tenant tertentu? Tanpa nilai yang dapat diverifikasi dan jalur pemulihan, tekanan pelanggan bukanlah bukti risiko.
Jawaban 30 detik
"Pertama-tama saya memvalidasi SLI di sisi pengguna, jendela SLO, dan burn rate, memeriksa apakah sinyal tersebut bersifat berkelanjutan atau merupakan kesalahan instrumentasi. Jika anggaran benar-benar habis, saya menjeda rilis non-esensial dan mengarahkan kapasitas serta upaya rekayasa untuk memulihkan SLO, memperbaiki penyebab utama, dan memvalidasi pemantauan. Perubahan keamanan, kepatuhan, atau mitigasi insiden dapat menjadi pengecualian jika cakupannya kecil, dapat dibatalkan (reversible), dan memiliki pemilik yang jelas. Untuk fitur pelanggan utama, saya akan mengupayakan isolasi tenant atau canary yang tertunda, lalu menggunakan tinjauan risiko untuk memutuskan apakah akan melanjutkan. Setelah batas anggaran yang disepakati kembali pulih, saya akan membuka kembali rilis secara bertahap dan meninjau apakah SLO benar-benar mewakili nilai bagi pengguna."
Solusi langkah demi langkah
Langkah 1: Tentukan SLI sebagai hasil pengguna
Definisikan tingkat keberhasilan, latensi end-to-end, dan kebenaran data untuk alur kerja kritis, menggunakan data klien atau edge jika memungkinkan. Nyatakan apa yang dihitung sebagai permintaan yang valid, jendela pemeliharaan, dan segmentasi tenant. Jika pengguna peduli dengan penyelesaian ekspor, buat SLI penyelesaian pekerjaan alih-alih hanya mengandalkan status HTTP 200 dari API.
Langkah 2: Hitung anggaran dan burn rate
Target ketersediaan 99,99% mengizinkan rasio kegagalan 0,01% dalam jendela yang dipilih; jumlah menit bergantung pada jendela waktu dan metode penghitungan. Gunakan satu kueri untuk menghitung sisa anggaran, burn rate, dan ketidakpastian, serta beri label penundaan data. Sebelum bertindak atas suatu anomali, periksa penghitungan ganda, telemetri yang hilang, dan atribusi dependensi.
Langkah 3: Tetapkan release gate
Saat anggaran sehat, rilis normal tetap memerlukan kemampuan rollback dan pemantauan. Saat mendekati habis, tingkatkan level peninjauan serta kurangi ukuran batch dan eksposur canary. Setelah habis, bekukan perubahan non-esensial; hanya izinkan perbaikan insiden, pekerjaan integritas data, keamanan tingkat tinggi, atau perubahan kepatuhan dengan bukti rollback. Terapkan gate ini dalam alat (tooling) dan matriks tanggung jawab alih-alih hanya mengandalkan kesepakatan lisan.
Langkah 4: Evaluasi pengecualian
Untuk setiap pengecualian, catat manfaat bagi pengguna, risiko, tenant yang terpapar, persentase, kondisi rollback, dan jendela observasi. Isolasi ke satu tenant, shadow traffic, atau pengguna internal merupakan bukti yang berguna. Produk, pemilik perubahan, dan SRE menyetujui bersama; janji tim penjualan saja tidak dapat dijadikan dasar keputusan.
Langkah 5: Pulihkan keandalan sebelum mengejar kesempurnaan
Selama pembekuan, perbaiki akar masalah, batas kapasitas, dan celah pemantauan, dengan target SLO pemulihan, margin anggaran, dan tenggat waktu. Jika target tersebut menuntut upaya heroik jangka panjang, sesuaikan target selama peninjauan, namun jangan mengubah jendela waktu atau mengecualikan kegagalan setelah kejadian hanya untuk meloloskan rilis.
Langkah 6: Berkomunikasi dengan pelanggan dan tim
Jelaskan alur kerja yang terpengaruh, rentang waktu, mitigasi, dan pembaruan berikutnya. Tawarkan alternatif yang dapat diverifikasi atau jadwal untuk fitur pelanggan; jangan menjanjikan waktu pemulihan yang belum terbukti. Gunakan satu dasbor anggaran, linimasa insiden, dan daftar pemilik secara internal untuk mengurangi negosiasi politis antara produk dan rekayasa.
Langkah 7: Kelola tata kelola pemulihan
Ketika anggaran mencapai ambang batas yang disepakati, buka kembali rilis secara bertahap, dimulai dengan batch kecil. Tinjau perubahan yang gagal, keterlambatan deteksi, durasi rollback, dan dampak pada pelanggan. Jika SLO tidak mewakili nilai bagi pengguna, usulkan perubahan yang didukung data. Simpan catatan pembekuan, pengecualian, persetujuan, dan hasil akhir untuk tinjauan risiko triwulanan.
Contoh jawaban berkualitas tinggi
Saya tidak akan membuat keputusan mutlak hanya berdasarkan "penjualan sedang mendesak" atau "anggaran nol". Saya akan memvalidasi SLI sisi pengguna, jendela statistik, integritas data, dan burn rate, guna menyingkirkan kesalahan instrumentasi dan penghitungan ganda. Jika anggaran benar-benar habis, saya akan membekukan rilis non-esensial dan berinvestasi pada pemulihan, perbaikan, serta pemantauan. Pengecualian dapat diajukan untuk perbaikan keamanan, kepatuhan, pemulihan data, dan mitigasi insiden.
Jika fitur pelanggan utama harus diluncurkan, saya akan mengisolasi tenant, menggunakan canary skala kecil, menambahkan rollback otomatis, dan menentukan jendela observasi. Produk, pemilik perubahan, dan SRE akan memberikan persetujuan bersama dengan mencatat manfaat, risiko, dan kondisi penghentian. Setelah anggaran pulih, saya akan mencabut pembekuan secara bertahap dan meninjau apakah SLO mengukur hasil nyata pengguna sebelum mengubah target atau proses.
Kesalahan umum
- Kesalahan: Membekukan setiap perubahan setelah anggaran habis. → Mengapa gagal: Keamanan, perbaikan data, dan mitigasi insiden dapat tertunda. → Solusi: Tentukan pengecualian yang terikat batasan, pihak yang menyetujui, dan bukti rollback.
- Kesalahan: Hanya menggunakan rata-rata latensi server. → Mengapa gagal: Ini mengabaikan kegagalan klien, tail latency, dan pengalaman tenant utama. → Solusi: Definisikan SLI end-to-end dari alur perjalanan pengguna.
- Kesalahan: Mengubah jendela SLO atau mengecualikan kegagalan demi meloloskan rilis. → Mengapa gagal: Anggaran kehilangan keterbandingan (comparability) dan menyembunyikan risiko. → Solusi: Pertahankan jendela saat ini dan gunakan tata kelola formal untuk perubahan berikutnya.
- Kesalahan: Menganggap satu pengujian canary yang sukses sebagai bukti untuk rilis penuh. → Mengapa gagal: Eksposur, dependensi, dan tail risk berbeda. → Solusi: Perluas secara bertahap dengan rollback otomatis.
Pertanyaan lanjutan dan jawabannya
Pertanyaan lanjutan 1: Berapa banyak anggaran yang diwakili oleh 99,99%?
Rasio kegagalan yang diizinkan dalam jendela yang dipilih adalah 0,01%. Mengonversinya menjadi menit memerlukan informasi mengenai jendela waktu, metode penghitungan, dan apakah metrik tersebut berbasis permintaan atau berbasis waktu. Kuncinya adalah menyatakan jendela waktu daripada menyajikan angka tanpa syarat.
Pertanyaan lanjutan 2: Apakah fitur yang dijanjikan tim penjualan merupakan pengecualian?
Nilai komersial saja tidak memberikan pengecualian. Tunjukkan dampak pada pengguna, pendapatan, atau kepatuhan; berikan bukti isolasi, canary, rollback, dan observasi; serta dapatkan persetujuan bersama. Jika eksposur tidak dapat dikurangi, tunda fitur tersebut dan tawarkan alternatif.
Pertanyaan lanjutan 3: Bagaimana jika perhitungan anggaran ternyata salah?
Bekukan rilis berisiko tinggi sambil secara paralel memeriksa cakupan telemetri, penghitungan ganda, jeda waktu, atribusi dependensi, dan sampel klien. Hitung ulang setelah koreksi dilakukan, tetapi jangan memperluas eksposur saat hasilnya masih belum pasti.
Pertanyaan lanjutan 4: Kapan SLO harus diubah?
Ubah SLO ketika operasi yang stabil dan data peninjauan menunjukkan bahwa target tidak sesuai dengan nilai pengguna, biaya, atau kapabilitas. Catat target lama, target baru, dampak, dan pemberi persetujuan terlebih dahulu. Pemadaman layanan (outage) atau tekanan rilis bukanlah alasan untuk menurunkan target secara ad-hoc.
Pertanyaan lanjutan 5: Bagaimana Anda tahu bahwa masa pembekuan telah selesai?
Tentukan kondisi pemulihan sebelumnya: SLI memenuhi target selama jendela observasi, anggaran telah pulih hingga ambang batas tertentu, perbaikan akar masalah telah diverifikasi, dan fungsi rollback berjalan. Kemudian mulailah dengan batch kecil dan lanjutkan pemantauan daripada langsung kembali ke kecepatan penuh.