Gesaan dan konteks
Anda mendapati bahawa runbook insiden yang kerap digunakan mengandungi langkah-langkah untuk perkhidmatan yang telah dipadam dan boleh memburukkan lagi gangguan perkhidmatan (outage). Terangkan cara anda melindungi pasukan bertugas (on-call) tanpa mengganggu liputan semasa, mengesahkan pengganti, melupuskan atau menulis semula runbook, dan membuktikan bahawa penambahbaikan tersebut telah diguna pakai.
Perkara yang dinilai oleh penemu duga
- Mengurangkan risiko tindakan tidak selamat sebelum memperdebatkan siapa pemilik dokumentasi tersebut.
- Mengubah keadaan "dokumen sudah lapuk" kepada pelan migrasi yang boleh dihasilkan semula dan disahkan.
- Menggunakan STAR untuk menerangkan impak, kerjasama, pertukaran pertimbangan (trade-offs) dan metrik tindakan susulan.
Soalan untuk dijelaskan terlebih dahulu
- Langkah manakah yang tidak sah, dan adakah ia boleh memadam data, meluaskan trafik atau menghalang pemulihan?
- Di manakah jurutera on-call sebenarnya membuka runbook tersebut, termasuk pautan cache dan bot?
- Siapakah pemilik kepada pengganti tersebut, apakah sandbox yang wujud, dan bagaimanakah rollback kecemasan berfungsi?
Jawapan 30 saat
Saya akan menandakan risiko tersebut di bahagian atas runbook, memaklumkan kepada pasukan on-call dan pemilik insiden, serta menyediakan laluan sementara yang disahkan supaya tiada sesiapa mengulangi langkah yang tidak sah itu. Saya akan menguji pengganti dalam sandbox, mengemas kini pautan, kebenaran dan panduan rollback bersama pemilik perkhidmatan, kemudian menerbitkan dan mendeprekasikan versi lama. Penerimaan akan diukur melalui akses pautan, kejayaan latihan (drill), pengurangan tindakan yang salah dan tindakan susulan yang diselesaikan, bukan sekadar perubahan dokumentasi yang digabungkan (merged).
Analisis terperinci langkah demi langkah
1. Asingkan langkah-langkah berbahaya
Kenal pasti arahan atau keputusan yang mempunyai impak yang tidak boleh diubah (irreversible). Tambahkan amaran yang jelas, nyahdayakan pautan automatik atau alihkan versi lama ke arkib yang jelas sambil mengekalkan laluan sementara yang diluluskan oleh pemilik on-call.
2. Bina semula laluan akses sebenar
Periksa indeks on-call, hasil carian, mesej bot, kebenaran dan penanda halaman dalam cache untuk mencari versi yang sebenarnya digunakan oleh jurutera. Menyunting repositori sumber sahaja akan membiarkan pautan yang disalin terus beredar.
3. Sahkan pengganti
Jalankan langkah baharu dalam sandbox atau tetingkap berisiko rendah dan rekodkan prasyarat, isyarat, syarat berhenti (stop conditions) dan rollback. GitLab menerangkan runbook sebagai pengenalpastian awal dan pengendalian rutin, dengan playbook atau laluan eskalasi untuk kes yang lebih kompleks; sempadan dokumen harus sepadan dengan tanggungjawab sebenar.
4. Tulis semula bersama pasukan pemilik
Minta pemilik perkhidmatan, wakil on-call serta penyemak keselamatan atau pematuhan untuk memeriksa perubahan tersebut. Asingkan fakta, andaian dan pemeriksaan terbuka daripada menulis semula arahan kritikal berdasarkan ingatan semata-mata. Setiap langkah menyatakan skop dan titik masuk eskalasi apabila ia gagal.
5. Rancang penerbitan dan pelupusan
Terbitkan versi baharu sebagai calon dan berikan tarikh susut nilai (deprecation) serta pautan pengganti kepada versi lama. Jika laluan lama boleh menyebabkan kemudaratan serius, alih keluar kebenaran pelaksanaan atau jadikan ia baca sahaja (read-only) sebelum mengikut proses perubahan. Pastikan rollback sejajar dengan kebenaran pelaksanaan (deployment) dan versi terkini yang boleh digunakan.
6. Uji penerimaan dengan latihan (drill)
Minta seseorang yang tidak menulis runbook tersebut untuk menyelesaikan latihan. Perhatikan sama ada mereka menemui titik masuk, mengenali prasyarat dan melakukan eskalasi pada syarat berhenti. Rekodkan masa, langkah yang salah dan soalan daripada menggantikan penggunaan sebenar dengan ujian kendiri oleh penulis.
7. Tambah pencetus penyelenggaraan
Tetapkan pemilik, tarikh semakan dan pencetus seperti perubahan topologi, nama amaran (alert-name) atau kebenaran. Dokumentasi yang lapuk mungkin menunjukkan bahawa semakan perubahan tidak mengandungi pemeriksaan dokumentasi; tambahkannya pada senarai semak pelepasan dan tindakan semakan insiden.
Contoh jawapan
Saya akan mengesahkan risiko langkah yang tidak sah, menambah amaran, memaklumkan kepada pasukan on-call dan pemilik insiden, serta menyediakan laluan sementara yang disahkan. Saya akan memeriksa pautan yang sebenarnya digunakan oleh orang ramai, menguji pengganti dalam sandbox dengan prasyarat, syarat berhenti dan rollback, serta menyemaknya bersama pemilik perkhidmatan dan wakil on-call. Kemudian saya akan menerbitkan versi baharu, mendeprekasikan versi lama dan menjalankan latihan dengan seseorang yang tidak menulisnya. Metrik penerimaan akan merangkumi pencarian entri, tindakan yang salah, masa eskalasi dan penyelesaian migrasi, bersama pencetus penyelenggaraan dalam proses perubahan.
Kesilapan lazim
- Memadamkan runbook lama tanpa laluan pengganti yang selamat.
- Menyunting repositori sambil mengabaikan pautan dalam cache, bot dan penanda halaman.
- Mengisytiharkan kejayaan selepas penulis sahaja yang menyelesaikan latihan.
- Meletakkan setiap prosedur kegagalan ke dalam runbook tanpa sempadan playbook atau eskalasi.
- Mengira penggabungan (merge) dokumentasi dan bukannya tindakan yang salah serta hasil latihan.
Soalan susulan dan jawapan
Bagaimana jika insiden sedang aktif berlaku?
Minta ketua insiden mengesahkan laluan sementara dan risiko, hentikan penyebaran langkah yang tidak sah dan tambahkan pembetulan dokumentasi ke dalam senarai tindakan insiden. Jangan lakukan penulisan semula secara besar-besaran yang belum diuji semasa menangani insiden kecemasan (firefight).
Bagaimana jika pemilik perkhidmatan menafikan bahawa runbook tersebut telah lapuk?
Kemukakan langkah yang tepat, perubahan terkini dan bukti kegagalan yang boleh dihasilkan semula, kemudian cadangkan latihan berskala kecil. Tumpukan perbincangan pada risiko pengguna dan pemilikan penyelenggaraan, bukan pada individu tersebut.
Bagaimana jika banyak pasukan luaran menggunakan runbook lama?
Kekalkan pengalihan (redirect) yang stabil atau nota keserasian, maklumkan pengguna dan tetapkan tarikh akhir migrasi. Hadkan kebenaran arahan berisiko tinggi terlebih dahulu, kemudian sahkan migrasi mengikut pasukan demi pasukan.
Bilakah anda patut memadamkan versi lama sepenuhnya?
Hanya selepas pengganti lulus latihan, mempunyai pemilik, semua titik masuk kritikal telah dialihkan dan rollback tersedia. Ikuti peraturan penyimpanan yang lebih ketat apabila keselamatan atau pematuhan memerlukannya.
Bagaimana jika pengganti gagal dalam latihan?
Hentikan penerbitan, rekodkan prasyarat dan isyarat yang gagal, betulkan prosedur dan jalankan semula latihan. Kegagalan adalah bukti bahawa kriteria pelepasan belum dipenuhi, bukan alasan untuk mencipta dalih.
Bagaimanakah anda menceritakan kisah ini menggunakan STAR?
Terangkan risiko dan tugasan yang konkrit, kemudian langkah-langkah pemberitahuan, pengesahan, kerjasama dan penerbitan. Akhiri dengan pengurangan tindakan yang salah, kadar kelulusan latihan atau penyelesaian migrasi berserta mekanisme penyelenggaraan yang anda tambahkan.