Pertanyaan dan kapan ini berlaku
Asumsikan platform yang sedang berkembang menghadapi masalah ketersediaan (availability), latensi, kebenaran data (correctness), kepatuhan (compliance), dan permintaan fitur secara bersamaan. Jelaskan bagaimana Anda mengidentifikasi masalah keandalan yang paling penting, memperkirakan dampak dan upaya (effort), menyusun urutan kerja di roadmap, dan menjelaskan trade-off.
Google SRE menggunakan error budget sebagai mekanisme bersama untuk keandalan dan kecepatan rilis. AWS Well-Architected merekomendasikan pemeringkatan perbaikan berdasarkan kepentingan bisnis dan upaya implementasi, lalu melacaknya secara berulang. Sinyal utamanya adalah menerjemahkan keandalan ke dalam hasil bagi pengguna dan bisnis.
Hal yang dinilai oleh pewawancara
Pewawancara mencari pemikiran berbasis user journey, penalaran SLO dan error budget, trade-off risiko dan biaya yang eksplisit, milestone yang memiliki pemilik (owner), hasil yang terukur, serta rencana pembelajaran ketika bukti belum lengkap.
Pertanyaan untuk diklarifikasi sebelum menjawab
- User journey dan komitmen pelanggan mana yang paling penting?
- Apa saja SLO-nya, tingkat pembakaran (burn) error budget, dan kelas kegagalan utama?
- Apakah dampaknya berupa churn, pendapatan, kepatuhan, beban dukungan pelanggan (support load), atau engineering toil?
- Berapa estimasi upaya, dependensi, dan opportunity cost dari setiap perbaikan?
- Risiko mana yang dapat dimitigasi sekarang dan mana yang memerlukan perbaikan akar masalah (root fix)?
- Siapa yang memiliki keputusan produk, engineering, keuangan, dan kepatuhan?
- Bagaimana keberhasilan akan diverifikasi dan dalam rentang waktu berapa lama?
- Apakah ada kebijakan yang membekukan rilis ketika budget habis?
Kerangka jawaban 30 detik
“Saya mendefinisikan SLO di sekitar critical user journey dan memetakan insiden, latensi, kesalahan data, serta kepatuhan ke dampak bisnis. Saya mengurutkan pekerjaan menggunakan burn rate error budget, dampak, tingkat keparahan (severity), upaya, reversibilitas, dan nilai pembelajaran. Saya menangani mitigasi cepat yang berdampak tinggi sembari menjadwalkan perbaikan akar masalah dengan milestone yang jelas. Jika budget habis, saya menjeda rilis non-esensial. Setiap item memiliki pemilik, target metrik, dan tanggal peninjauan, dan saya menjelaskan apa yang sengaja tidak kami kerjakan.”
Jawaban mendalam, langkah demi langkah
Langkah 1: Tentukan konsekuensi bagi pengguna dan bisnis
Mulailah dengan user journey seperti login, pembayaran, penerbitan konten (publishing), atau ekspor data. Pisahkan antara ketersediaan, latensi, kebenaran data, dan privasi; jangan perlakukan setiap peringatan (alert) internal secara sama.
Langkah 2: Tetapkan baseline
Konfirmasikan SLO, burn rate budget, frekuensi insiden, pengguna yang terdampak, waktu pemulihan (recovery time), dan permintaan dukungan pelanggan. Metrik harus terhubung dengan pengalaman pengguna atau komitmen layanan.
Langkah 3: Bagi solusi berdasarkan horizon waktu
Klasifikasikan pekerjaan sebagai penahanan segera (immediate containment), mitigasi, perbaikan akar masalah, atau pemantauan (monitoring). Penerapan rate limit dapat berjalan berdampingan dengan perancangan ulang model data saat keduanya ditautkan di dalam roadmap.
Langkah 4: Bandingkan dampak, biaya, dan pembelajaran
AWS merekomendasikan untuk mempertimbangkan tingkat kepentingan dan upaya, serta melacak progres dengan milestone. Masukkan opportunity cost secara eksplisit.
| Dimensi | Pertanyaan | Contoh bukti |
|---|---|---|
| Dampak pelanggan | Siapa yang terdampak dan seberapa parah? | Tingkat kegagalan critical journey |
| Risiko | Keamanan, kepatuhan, atau kerugian yang tidak dapat dipulihkan? | Catatan insiden dan audit |
| Upaya | Biaya engineering, dependensi, dan pemeliharaan? | People-weeks dan milestone |
| Kecepatan | Apakah mitigasi yang dapat dibatalkan (reversible) dimungkinkan? | Uji coba degradasi atau throttling |
| Pembelajaran | Uji coba kecil mana yang mengurangi ketidakpastian? | Pengamatan bertahap (staged observation) |
Langkah 5: Gunakan error budget untuk keputusan rilis
Selama layanan berada dalam batas budget, lanjutkan delivery fitur yang bernilai dan jadwalkan pekerjaan keandalan. Ketika budget habis, jeda perubahan non-esensial dan pulihkan SLO. Keamanan dan kepatuhan tetap menjadi batasan mutlak (hard constraints).
Langkah 6: Selaraskan roadmap dan sumber daya
Tetapkan pemilik, sasaran, dependensi, dan kriteria penyelesaian (completion conditions). Rencanakan pekerjaan keandalan dalam ritme (cadence) yang sama dengan fitur dan nyatakan apa yang sengaja ditunda.
Langkah 7: Verifikasi dan sesuaikan
Lacak SLO, budget, waktu pemulihan, volume tiket dukungan, retensi, dan biaya. Jika suatu perbaikan tidak mengurangi dampak pengguna, tinjau kembali hipotesisnya daripada terus melanjutkannya karena sunk cost.
Langkah 8: Jelaskan trade-off
Gunakan catatan keputusan (decision record) singkat yang memuat pilihan, bukti, risiko, alternatif, dan tanggal peninjauan. Jelaskan hasil pelanggan dan janji bisnis mana yang dilindungi oleh investasi tersebut.
Contoh jawaban berkualitas tinggi
“Saya akan membagi platform menjadi login, transaksi inti, dan pelaporan (reporting), lalu menentukan SLO dan error budget untuk masing-masing area. Saya akan mengurutkan pekerjaan berdasarkan burn rate budget, dampak pelanggan kritis, risiko kepatuhan, upaya, dan reversibilitas.
Jika kesalahan transaksi menghabiskan budget selama dua minggu, saya pertama-tama akan menambahkan throttling dan graceful degradation, lalu menjadwalkan perbaikan akar masalah. Latensi pelaporan yang memengaruhi pengguna yang jarang aktif dapat diberikan instrumentasi dan milestone bertanggal. Bersama tim engineering, saya akan menetapkan pemilik dan dependensi, membekukan rilis non-esensial saat budget habis, dan menjelaskan dampak pelanggan kepada tim Sales.
Setiap dua minggu saya akan meninjau SLO, waktu pemulihan, dan permintaan dukungan pelanggan. Jika mitigasi telah menghilangkan dampak tersebut, saya akan mengevaluasi kembali proyek perbaikan akar masalah; jika belum, saya akan menghentikan pendekatan tersebut dan menguji jalur lain. Hal ini menjaga keandalan tetap selaras dengan hasil nyata dan opportunity cost.”
Kesalahan umum
- Mengurutkan peringatan (alerts) berdasarkan tingkat keparahan teknis tanpa mempertimbangkan dampak pelanggan.
- Mengatakan bahwa keandalan itu penting tanpa menyertakan SLO atau error budget.
- Hanya memilih perancangan ulang permanen dan mengabaikan pembelajaran yang bersifat reversible.
- Memperlakukan error budget sebagai izin untuk mengabaikan keamanan atau kepatuhan.
- Mengabaikan penetapan pemilik, milestone, dan tanggal peninjauan.
- Melaporkan latensi dan ketersediaan tanpa mengaitkannya dengan hasil pelanggan.
- Hanya membahas preferensi engineering.
Pertanyaan lanjutan dan cara menjawabnya
Lanjutan 1: Bagaimana jika bisnis bersikeras membutuhkan suatu fitur?
Kuantifikasi budget, dampak pelanggan, dan alternatifnya. Jika kebijakan mengharuskan pembekuan rilis, nyatakan aturannya dan biarkan pemilik yang berwenang memutuskan risiko residual.
Lanjutan 2: Bagaimana jika datanya tidak lengkap?
Lakukan instrumentasi berbiaya rendah, klasifikasikan kegagalan, atau jalankan eksperimen kecil dengan tujuan pembelajaran dan kondisi penghentian (stop condition) daripada mereka-reka presisi.
Lanjutan 3: Keandalan tidak memiliki garis akhir. Lalu bagaimana?
Gunakan SLO dan budget untuk menentukan batasan yang dapat diterima, bandingkan manfaat marginal dengan opportunity cost, dan tinjau apakah itu masih sesuai dengan janji layanan.
Lanjutan 4: Bagaimana jika mitigasi menimbulkan technical debt?
Catat debt, pemilik, dan batas waktunya; tautkan ke milestone perbaikan akar masalah dan eskalasikan saat tanggal tersebut terlewati.
Lanjutan 5: Bagaimana Anda membuktikan nilainya?
Bandingkan sebelum/sesudah SLO, pemulihan, dukungan pelanggan, dampak pelanggan, retensi, atau biaya selama rentang waktu yang ditentukan dan nyatakan tingkat ketidakpastiannya.
Lanjutan 6: Bagaimana jika kebutuhan pelanggan berbeda-beda?
Segmentasikan berdasarkan user journey dan komitmen kontraktual, isolasi kapasitas jika diperlukan, dan hindari melimpahkan risiko yang tidak dapat diterima kepada pelanggan berprioritas lebih rendah.