Perintah dan skenario
Sebuah pemadaman (outage) telah menghabiskan 80% dari error budget bulan ini, tetapi product lead tetap ingin merilis fitur penting sesuai jadwal. Anda bertanggung jawab atas keandalan (reliability) tetapi tidak memiliki hak veto sepihak. Jelaskan bagaimana Anda mempersiapkan fakta, berkomunikasi, menawarkan opsi, mendorong pengambilan keputusan, dan menjalankan retrospektif jika hasilnya buruk.
Hal yang diuji oleh pewawancara
- Apakah Anda mengubah konflik menjadi tujuan bersama dan fakta yang dapat diverifikasi alih-alih menyalahkan pihak lain.
- Apakah Anda membedakan batas risiko, tenggat waktu bisnis, dan dampak yang tidak dapat diubah (irreversible), lalu menawarkan opsi bertahap.
- Apakah Anda dapat memengaruhi keputusan tanpa wewenang formal sambil membuat kepemilikan dan tindak lanjut dapat dilacak.
- Apakah Anda menunjukkan refleksi diri yang nyata, kemampuan mendengarkan, dan kolaborasi lintas fungsi.
Pertanyaan klarifikasi yang perlu diajukan terlebih dahulu
- Layanan, user journey, dan rentang waktu mana yang direpresentasikan oleh 80% tersebut, dan risiko SLO apa yang tersisa?
- Apakah tanggal peluncuran, pendapatan, atau komitmen pelanggan benar-benar tidak dapat diubah, atau dapatkah cakupan dan ukuran peluncuran (rollout) disesuaikan?
- Apakah penyebab insiden, waktu rollback, cakupan pemantauan, dan mitigasi saat ini telah dikonfirmasi?
- Siapa pengambil keputusan akhir, dan apakah ada kebijakan error-budget, release gate, atau jalur eskalasi?
Jawaban 30 detik
Saya akan menerjemahkan konsumsi 80% anggaran menjadi dampak pengguna, sisa risiko, dan waktu pemulihan, lalu mengonfirmasi datanya sebelum bertemu dengan product lead. Saya akan mengakui target tanggal rilis dan menjelaskan dampak terburuk, reversibilitas, serta ketidakpastian dari peluncuran penuh. Saya akan menawarkan rilis bertahap, pengurangan cakupan, penundaan untuk perbaikan terlebih dahulu, atau ketentuan rollback yang eksplisit alih-alih hanya mengatakan "tidak". Setelah kami menyepakati gate keputusan, saya akan mencatat pemilik tanggung jawab dan pemicunya, lalu melacak hasilnya setelah peluncuran. Apa pun yang terjadi, saya akan mendokumentasikan alasannya dalam retrospektif tanpa saling menyalahkan (blameless retrospective) serta meningkatkan pemantauan dan kebijakan.
Pembahasan mendalam
1. Menerjemahkan metrik menjadi dampak yang relevan bagi keputusan
Error budget adalah bahasa bersama antara sasaran layanan dan kegagalan yang dapat diterima, tetapi persentase saja tidak cukup. Saya akan menambahkan user journey yang terdampak, klasifikasi error, tren waktu, sisa anggaran, waktu pemulihan, dan tingkat keyakinan (confidence). Jika bukti berasal dari sisi server sementara pengalaman pengguna belum diverifikasi, saya akan menyatakan ketidakpastian tersebut daripada menciptakan tekanan dengan kepastian palsu.
2. Mendengarkan kendala bisnis sebelum menentukan tujuan bersama
Saya akan menanyakan mengapa tanggal tersebut penting: apakah karena kontrak, peluang pasar, demo pelanggan, atau janji internal. Hal ini memisahkan kendala yang tidak dapat diubah dari preferensi yang dapat dinegosiasikan. Kita dapat membingkai tujuan bersama sebagai upaya mempertahankan nilai rilis sebanyak mungkin tanpa melebihi risiko pengguna yang dapat diterima, sehingga keandalan dan pengiriman tidak menjadi papan skor yang saling bersaing.
3. Memulai dengan opsi alih-alih veto
Saya akan menyiapkan setidaknya tiga pilihan: tunda dan perbaiki terlebih dahulu; rilis ke tenant berisiko rendah atau pengguna internal; atau pertahankan tanggal rilis sambil menonaktifkan kapabilitas berisiko tinggi dengan penghentian otomatis, rollback, dan batas error-rate. Untuk setiap opsi, saya akan mencantumkan dampak pengguna, dampak pendapatan atau komitmen, biaya implementasi, waktu rollback, dan pihak yang menyetujui. Jika buktinya lemah, jalankan eksperimen kecil yang dapat dibatalkan (reversible) untuk mengurangi ketidakpastian.
4. Memperjelas wewenang dan eskalasi
Jika kebijakan menyatakan untuk menjeda rilis setelah anggaran habis, saya akan mengutip kebijakan tersebut dan mengundang tim produk, rekayasa, dan manajer untuk meninjau pengecualian alih-alih memblokirnya secara sepihak. Jika kebijakan tidak mencakup kasus tersebut, saya akan memasukkan fakta, opsi, rekomendasi, dan risiko residual ke dalam catatan keputusan (decision record) lengkap dengan penanggung jawab dan waktu peninjauan. Eskalasikan ketidaksepakatannya, bukan orangnya.
5. Memasang batasan pengaman (guardrails) yang dapat diamati di sekitar peluncuran
Sebelum rilis bertahap, tentukan metrik keberhasilan, ambang henti (stop thresholds), jendela observasi, dan latihan rollback. Ambang batas dapat mencakup error rate yang dihadapi pengguna, penyelesaian alur kritis, latensi, dan burn rate anggaran; contoh angka harus berasal dari baseline layanan. Tugaskan penanggung jawab on-call, siapkan peringatan (alerts), dan satu saluran komunikasi agar semua orang dapat melihat tahapan, penanggung jawab, dan waktu keputusan berikutnya.
6. Menggunakan retrospektif untuk memperbaiki sistem dan hubungan
Jika hasilnya buruk, rekonstruksi lini masa dan informasi yang tersedia pada saat itu daripada mengubah diskusi menjadi siapa yang bersikeras pada pendapat yang salah. Catat sinyal yang terlewat, asumsi yang belum teruji, kegunaan kebijakan, waktu komunikasi, penanggung jawab, dan tanggal. Hasil yang baik juga layak ditinjau karena pengecualian yang berhasil dapat menyembunyikan risiko yang tidak berkelanjutan.
Jawaban lengkap yang kuat
Saya akan mengonfirmasi cakupan layanan, dampak pengguna, jendela waktu yang tersisa, dan keandalan data error-budget, kemudian memahami kendala sebenarnya di balik tanggal peluncuran. Dalam percakapan, saya akan menyatakan kembali tujuan produk dan menjelaskan konsekuensi peluncuran penuh yang mungkin terjadi dalam istilah risiko pengguna bersama. Saya akan menawarkan penundaan untuk perbaikan terlebih dahulu, rilis bertahap berisiko rendah, dan pengurangan cakupan dengan rollback otomatis, dengan mencantumkan dampak, biaya, ambang batas, dan penanggung jawab untuk masing-masing opsi. Jika release gate tersedia, saya akan menjalankan peninjauan pengecualian yang terdokumentasi; jika tidak, saya akan membuat catatan keputusan tertulis dan meneruskannya ke pemilik tanggung jawab bersama. Setelah peluncuran, saya akan memantau metrik pengguna, burn rate, dan kondisi rollback, lalu mencatat peningkatan komunikasi dalam retrospektif tanpa menyalahkan.
Pola kegagalan umum
- Mengatakan "anggaran habis berarti tidak ada rilis" tanpa memeriksa kebijakan, wewenang, atau kendala bisnis.
- Hanya membahas metrik teknis tanpa menerjemahkannya ke dalam dampak pengguna, komitmen, dan reversibilitas.
- Menggambarkan product lead sebagai hambatan alih-alih menunjukkan sikap mendengarkan dan tujuan bersama.
- Menyarankan rilis "canary" tanpa ukuran peluncuran, jendela observasi, ambang henti, atau penanggung jawab rollback.
- Menyalahkan seseorang setelah hasilnya diketahui alih-alih meninjau kesenjangan informasi dan sistem yang ada pada saat itu.
Pertanyaan lanjutan dan pengembangan
Lanjutan 1: Bagaimana jika product lead tetap bersikeras pada peluncuran penuh?
Saya akan memastikan bahwa risiko dan alternatif telah dipahami, lalu mencatat bukti, pengambil keputusan, alasan pengecualian, batas pengaman, dan waktu peninjauan. Jika pilihan tersebut melanggar kebijakan, saya akan menggunakan jalur eskalasi ke pemilik tanggung jawab bersama; dalam batas wewenang saya, saya akan menjalankan peran saya tanpa memblokir secara diam-diam atau menyembunyikan informasi.
Lanjutan 2: Bagaimana jika metriknya saling bertentangan?
Prioritaskan berdasarkan user journey, dengan memisahkan keamanan, alur kritis, dan pengalaman non-kritis, lalu nyatakan keterlambatan data dan interval keyakinan. Perkecil cakupan peluncuran dan perpanjang observasi hingga risikonya memungkinkan keputusan yang dapat dibatalkan (reversible).
Lanjutan 3: Bagaimana Anda membuktikan bahwa komunikasi tersebut meningkatkan kinerja tim?
Periksa apakah catatan keputusan memuat fakta, opsi, penanggung jawab, dan pemicu. Amati apakah rilis berikutnya mendeteksi risiko lebih awal, melakukan rollback lebih cepat, dan menggunakan metrik yang sama di seluruh tim. Gunakan hasil konkret alih-alih sekadar "semua orang merasa prosesnya lebih lancar".
Lanjutan 4: Bagaimana Anda mencegah error budget menjadi senjata antar-tim?
Perlakukan anggaran dan SLO sebagai mekanisme yang disepakati bersama, tinjau ambang batas dan alur pengecualian secara teratur, gunakan pengukuran yang berorientasi pada pengguna, dan publikasikan catatan keputusan. Tim mana pun boleh mengangkat isu risiko, tetapi dasar keputusannya harus dapat diaudit dan direproduksi.