Gesaan
Ceritakan tentang masa anda menemui risiko kebolehpercayaan yang tidak dikuantifikasi dalam sesuatu pelancaran, mendesak untuk menjeda atau mengecilkan skopnya, dan kemudiannya mendapat kelulusan untuk memulakannya semula dengan bukti. Penemu duga ingin mengetahui pertimbangan, komunikasi, tindakan dan hasil anda, bukan sekadar senarai istilah teknikal.
Senario dan batasan
Gunakan projek sebenar dengan kekangan masa yang jelas, pengguna atau perkhidmatan yang terjejas, isyarat yang tersedia pada masa itu dan kuasa membuat keputusan anda. Anda mungkin telah menjeda pelancaran penuh, beralih kepada canary kecil atau menambah keupayaan rollback terlebih dahulu. Jangan bentangkan fakta yang diketahui kemudian sebagai bukti yang anda miliki pada masa itu.
Perkara yang dinilai
Ujian ini menilai sama ada anda menukar gerak hati menjadi risiko yang boleh disahkan, mengubah percanggahan pendapat menjadi kriteria keputusan bersama dan melindungi kebolehpercayaan tanpa mengabaikan penghantaran. Penyelarasan pelancaran Google SRE menekankan kebolehpercayaan dan komunikasi rentas pasukan; semakan insiden GitLab menekankan pemahaman keputusan dan bukannya meletakkan kesalahan pada individu.
Struktur jawapan rujukan
Gunakan STAR-L: Situation (Situasi) memberikan tempoh masa pelancaran dan isyarat risiko; Task (Tugas) menyatakan hasil pengguna dan kuasa yang anda miliki; Action (Tindakan) menerangkan cara anda mencadangkan jeda, mentakrifkan metrik, mengatur pengesahan, menyelaraskan pihak berkepentingan dan mengekalkan keupayaan rollback; Result (Hasil) memberikan hasil pelancaran, kesan kepada pengguna dan penambahbaikan; Learning (Pembelajaran) menunjukkan bagaimana kriteria kawalan baharu dimasukkan ke dalam proses.
Butiran kritikal
Kuantifikasikan risiko dengan had kadar ralat (error-rate ceiling), kependaman laluan kritikal, sampel canary, tempoh rollback atau versi kebergantungan. Nyatakan pihak yang memegang keputusan muktamad, cara semua orang melihat data yang sama dan syarat yang membolehkan pelancaran disambung semula. Sertakan kerugian yang dielakkan dan kos sebenar akibat menjeda.
Perangkap lazim
Menyatakan bahawa orang mendengar kerana anda betul; hanya menerangkan pembaikan teknikal; menjadikan rakan sekerja sebagai punca risiko; mendakwa sifar risiko; melaporkan kejayaan tanpa menyatakan kos menjeda; atau menggantikan kriteria konkrit dengan "kami menambah baik pemantauan."
Rubrik penilaian
Jawapan yang kukuh mempunyai garis masa yang konkrit, tindakan peribadi dan hasil yang boleh disahkan. Jawapan tersebut mengakui tekanan perniagaan dan risiko kebolehpercayaan, menerangkan keputusan eskalasi dan pelancaran semula, serta mengubah pembelajaran menjadi perubahan proses. Jawapan yang lemah mengandungi konflik abstrak, tiada nombor atau tiada sumbangan keputusan peribadi.
Soalan susulan
Bagaimana jika ketua produk tidak bersetuju dengan jeda tersebut?
Kumpulkan risiko, perkara yang tidak diketahui, pilihan yang boleh dibalikkan (reversible) dan tarikh akhir dalam satu rekod keputusan. Cadangkan canary terkecil atau pengesahan singkat. Jika ia melebihi kuasa anda, gunakan saluran eskalasi yang dipersetujui, rekodkan bantahan dan nyatakan risiko yang diterima.
Bagaimanakah anda membuktikan bahawa jeda tersebut tidak menjadi halangan yang berpanjangan?
Tetapkan pemilik, kaedah pengesahan dan tarikh akhir bagi setiap perkara yang tidak diketahui, berserta kriteria mula semula yang jelas. Kemas kini status setiap hari; teruskan apabila kriteria dipenuhi dan kecilkan skop atau nilaikan semula apabila kriteria tidak dipenuhi.
Bagaimanakah anda memastikan semakan kekal bebas daripada menyalahkan (blameless)?
Huraikan keadaan sistem, isyarat yang hilang, konteks keputusan dan perubahan proses menggunakan garis masa berfakta dan bukannya membuat andaian tentang motif peribadi. Nyatakan tingkah laku anda sendiri yang perlu ditambah baik dan jejak sama ada tindakan diselesaikan.