Petunjuk dan konteks
Desain sebuah layanan yang menghitung SLO, error budget, dan burn rate untuk banyak layanan serta memicu reliability gate dan peringatan. Bagaimana Anda menangani data yang terlambat, jendela waktu, pembungkaman (silence), backfill, dan pengecualian?
Ini cocok untuk peran SRE, platform, backend, dan system design. Buku kerja Google SRE menjelaskan error budget sebagai cara untuk menyeimbangkan keandalan dengan kecepatan pengiriman, sementara peringatan burn-rate berfokus pada seberapa cepat anggaran tersebut habis terkonsumsi. Desain harus menghubungkan definisi, komputasi, peringatan, keputusan, dan auditabilitas.
Apa yang sedang diuji oleh pewawancara
- Membedakan peristiwa SLI, target SLO, periode kepatuhan, error budget, dan burn rate.
- Menjelaskan mengapa jendela cepat dan lambat saling melengkapi dan bagaimana kebisingan (noise) dikendalikan.
- Mendesain deduplikasi, data terlambat, sampel duplikat, backfill, dan komputasi ulang berversi (versioned recomputation).
- Memisahkan peringatan dari deployment gate, respons on-call, pembungkaman (silence), dan pengecualian manusia.
- Menetapkan batas untuk isolasi penyewa (tenant), biaya kueri, ketertelusuran historis, dan izin.
- Memvalidasi kebijakan dengan metrik kualitas data dan pemutaran ulang (replay) alih-alih hanya menggambar dasbor.
Kerangka jawaban 30 detik
"Saya akan membagi layanan ini menjadi spesifikasi SLO, penyerapan peristiwa (event ingestion), agregasi jendela, kalkulasi anggaran, evaluasi kebijakan, dan audit notifikasi. Setiap SLO menetapkan peristiwa sukses dan total, target, periode kepatuhan, serta versi; burn rate adalah tingkat kesalahan yang diamati dibagi dengan tingkat kesalahan yang diizinkan. Jendela cepat menangkap lonjakan dan jendela lambat mengonfirmasi persistensi, dengan pemeriksaan kesegaran data dan ukuran sampel. Data yang terlambat atau di-backfill menghasilkan komputasi ulang berversi alih-alih secara diam-diam menulis ulang keputusan yang telah diaudit."
Pembahasan mendalam langkah demi langkah
Langkah 1: Tentukan SLI dan kontrak peristiwa
Spesifikasi SLO menyebutkan nama layanan, jenis metrik, peristiwa sukses, total peristiwa, target, periode kepatuhan, dimensi agregasi, dan zona waktu. Penghitung (counter) membutuhkan kunci deduplikasi yang stabil dan waktu peristiwa. Pembatalan klien, kegagalan dependensi, dan kerusakan platform tidak boleh dicampur tanpa kebijakan yang eksplisit. Setelah dipublikasikan, spesifikasi diberi versi sehingga kalkulasi historis menggunakan versi yang aktif pada saat itu.
Langkah 2: Hitung anggaran dan burn rate
Untuk target 99,9%, rasio kesalahan yang diizinkan selama periode kepatuhan adalah 0,1%. Bagi tingkat kesalahan jendela saat ini dengan tingkat yang diizinkan tersebut untuk mendapatkan burn rate: nilai 1 menghabiskan anggaran pada kecepatan yang direncanakan, sedangkan nilai di atas 1 menghabiskannya lebih cepat. Simpan hitungan mentah dan agregat beserta pembilang, penyebut, dan batas waktu sehingga hasilnya dapat dihitung ulang alih-alih hanya mempertahankan persentase.
Langkah 3: Gabungkan jendela cepat dan lambat
Jendela cepat mendeteksi lonjakan rilis dengan cepat; jendela lambat mengonfirmasi bahwa dampaknya tetap berlanjut. Suatu kebijakan mencatat kedua panjang jendela, ambang batas burn-rate, volume peristiwa minimum, dan evaluasi yang diperlukan. Picu hanya jika kesegaran data dan ukuran penyebut mencukupi. Layanan dapat menggunakan kebijakan yang berbeda, tetapi templat harus menyatakan tujuannya alih-alih memaksakan setiap peringatan ke dalam satu ambang batas.
Langkah 4: Tangani data yang terlambat, duplikat, dan di-backfill
Jadikan penyerapan (ingestion) idempoten berdasarkan ID peristiwa atau keranjang waktu (time bucket), serta pertahankan watermark agregasi dan versi koreksi. Peristiwa terlambat di dalam batas penundaan yang diizinkan akan memicu komputasi ulang; peristiwa di luar batas tersebut menandai data sebagai tidak lengkap. Backfill tidak boleh secara diam-diam mengubah notifikasi atau gate lama. Catat nilai lama, nilai baru, operator, alasan, dan ID keputusan yang terpengaruh.
Langkah 5: Hubungkan peringatan, gate, dan pengecualian
Layanan peringatan memberi tahu dan melakukan eskalasi, pengontrol deployment menjeda atau meminta persetujuan, dan layanan kebijakan mengeluarkan status yang didukung bukti. Pengecualian memiliki cakupan, masa kedaluwarsa, pemberi persetujuan, dan alasan. Pembungkaman (silence) hanya menekan notifikasi; ini tidak menghentikan kalkulasi anggaran. Setiap gate mencakup SLO, jendela, hitungan, kesegaran, dan versi aturan sehingga keputusannya dapat diaudit.
Langkah 6: Skalakan dan amati layanan
Shard agregasi berdasarkan layanan, wilayah, dan penyewa (tenant), batasi dimensi dengan kardinalitas tinggi, dan lakukan cache untuk kueri berulang. Pantau lag penyerapan, kehilangan, duplikasi, penundaan agregasi, waktu evaluasi, keberhasilan notifikasi, dan kesalahan kebijakan. Putar ulang (replay) insiden historis untuk memvalidasi jendela dan lakukan injeksi kegagalan untuk mengukur latensi menyeluruh dari peristiwa ke peringatan dan dari peristiwa ke gate. Data yang tidak lengkap harus ditampilkan sebagai tidak diketahui dan dieskalasi, bukan dilaporkan sebagai sehat.
Pertukaran (trade-offs), batasan, dan perolehan informasi
Layanan error-budget mengubah target keandalan menjadi keputusan rekayasa yang dapat diaudit. Ambang batas burn-rate yang lebih sensitif meningkatkan kebisingan dan beban peringatan; jendela yang lebih panjang merespons lebih lambat. Pisahkan fakta yang dihitung, tindakan notifikasi, dan keputusan deployment. Izinkan komputasi ulang yang dikoreksi sambil tetap mempertahankan versi historis. Layanan ini menyediakan bukti bersama; layanan tidak memilih prioritas tim.
Model jawaban berkualitas tinggi
"Saya akan mulai dengan spesifikasi SLO berversi yang mencakup peristiwa sukses dan total, target, periode kepatuhan, dimensi, dan deduplikasi. Penyerapan idempoten menyimpan pembilang, penyebut, batas waktu, dan watermark berdasarkan layanan dan jendela. Agregasi menghitung tingkat kesalahan, tingkat kesalahan yang diizinkan, dan burn rate. Evaluasi kebijakan menggunakan jendela cepat untuk lonjakan dan jendela lambat untuk persistensi, memeriksa volume minimum dan kesegaran data.
Notifikasi, deployment gate, dan pengecualian manusia adalah konsumen yang terpisah. Silence menekan notifikasi tetapi membiarkan komputasi tetap berjalan; sebuah gate memancarkan bukti dengan SLO, jendela, hitungan, aturan, dan versi data; pengecualian harus disetujui, terikat waktu, dan dapat diaudit. Data yang terlambat menghasilkan komputasi ulang berversi daripada diam-diam mengubah keputusan sebelumnya.
Pada skala besar, saya melakukan sharding berdasarkan layanan, wilayah, dan penyewa, membatasi label berkardinalitas tinggi, dan memantau lag penyerapan, duplikat, kehilangan, penundaan agregasi, dan keberhasilan notifikasi. Replay dan injeksi kesalahan memvalidasi kebijakan. Data yang tidak lengkap ditandai tidak diketahui dan dieskalasi alih-alih dihitung sebagai nol kesalahan."
Kesalahan umum
- Hanya menyimpan persentase SLO → ukuran sampel dan batasan hilang → pertahankan pembilang, penyebut, jendela, dan watermark.
- Satu ambang batas untuk setiap layanan → risiko dan lalu lintas berbeda → buat versi kebijakan berdasarkan target, volume, dan jendela.
- Memperlakukan silence sebagai penghentian komputasi → fakta anggaran hilang → hanya tekan notifikasi dan tetap lakukan audit.
- Menimpa riwayat dengan data yang terlambat → keputusan rilis tidak dapat direkonstruksi → buat versi komputasi ulang dan pertahankan nilai lama serta baru.
- Memperlakukan data yang hilang sebagai sehat → kegagalan pengumpulan data tersembunyi → tampilkan tidak diketahui dan berikan peringatan tentang kualitas data.
- Membuat gate bergantung pada status notifikasi → percobaan ulang notifikasi mengubah hasil rilis → gate harus membaca bukti evaluasi yang tidak dapat diubah (immutable).
Pertanyaan lanjutan dan jawaban
Mengapa menggunakan jendela cepat dan lambat sekaligus?
Jendela cepat mengurangi waktu deteksi lonjakan; jendela lambat memfilter kebisingan sementara dan mengonfirmasi konsumsi anggaran yang berkelanjutan. Keduanya secara bersama-sama menyeimbangkan kecepatan respons dan positif palsu, tetapi ambang batas harus divalidasi terhadap volume peristiwa.
Apa yang terjadi pada peringatan lama setelah backfill mengubah burn rate?
Pertahankan catatan evaluasi dan notifikasi lama, buat komputasi ulang yang ditandai dengan versi data baru, dan nyatakan apakah gate saat ini berubah. Jangan menghapus riwayat; penanggap (responder) membutuhkan fakta yang tersedia pada saat itu.
Bagaimana Anda mencegah dimensi dengan kardinalitas tinggi membebani sistem?
Batasi label yang diizinkan, ambil sampel irisan penyewa atau rute berdasarkan tingkat (tier), materialisasi hanya tampilan yang berharga, dan terapkan anggaran kueri serta batas waktu (timeout). SLO tingkat layanan seharusnya tidak memerlukan dimensi yang tidak terbatas.
Bagaimana pengecualian mencegah bypass gate secara permanen?
Ikatkan setiap pengecualian ke suatu layanan, perubahan, atau rentang waktu, wajibkan adanya penyetuju dan alasan, serta terapkan kedaluwarsa otomatis. Pulihkan kebijakan default setelahnya dan ukur cakupan pengecualian sebagai metrik audit.