題幹與適用場景
你發現團隊常用的一份事故運行手冊包含已移除的服務步驟，繼續照做可能擴大故障。請說明你如何在不打斷目前值班的情況下保護團隊、驗證替代流程、推動廢棄或改寫，並回答如何證明改進真的被採用。
面試官考察點
- 是否會先降低錯誤操作風險，再討論文件責任歸屬。
- 是否能把「文件過時」轉化為可重現、可驗收的遷移計畫。
- 是否能用 STAR 講清影響、協作、取捨和後續指標。
回答前需要釐清的問題
- 哪些步驟已經失效，是否會刪除資料、擴大流量或阻塞恢復？
- 目前值班人員從哪裡開啟這份手冊，是否有快取連結或自動引用？
- 新流程的 owner、演練環境和緊急回滾路徑是什麼？
30 秒回答框架
我會先在手冊頂部標註風險並提供臨時安全路徑，通知值班和事件負責人，避免有人繼續執行失效步驟。然後用一次演練或沙盒驗證替代流程，和服務 owner 一起更新入口、權限和回滾說明。廢棄或發布新版本後，我會透過連結存取、演練成功率、誤操作數和行動項完成率確認遷移，而不是只看合併請求是否通過。
分步驟深入解答
1. 先隔離危險步驟
確認手冊中哪些命令或決策會造成不可逆影響。若存在風險，在頂部加醒目警告、停用自動連結或把舊版本移到明確的存檔位置；保留一條經值班負責人確認的臨時路徑。
2. 還原真實使用路徑
檢查值班目錄、搜尋結果、機器人訊息、權限和快取書籤，找出團隊實際開啟的版本。只改主儲存庫檔案卻忽略複製連結，會讓舊內容繼續流通。
3. 驗證替代流程
在沙盒或低風險時段執行新步驟，記錄前置條件、觀察訊號、停止條件和回滾。GitLab 將 runbook 用於常見故障的初步識別與處理，複雜情形則由 playbook 或升級流程承接；文件邊界應與真實職責一致。
4. 與相關團隊共同改寫
邀請服務 owner、值班代表和安全或合規聯絡人複核。把爭議拆成事實、假設和待驗證項，避免由單人憑記憶重寫關鍵命令。每段步驟都說明適用範圍和失敗時的升級入口。
5. 設計發布與廢棄策略
新版本先發布為候選，舊版本標記廢棄日期和替代連結。若舊流程可能造成嚴重損害，先移除執行權限或改成唯讀說明，再按變更流程發布。回滾策略要與部署權限和最近可用版本一致。
6. 用演練驗證採用
讓不參與編寫的人按新手冊完成一次演練，觀察是否能找到入口、識別前置條件並在停止條件觸發時升級。記錄完成時間、錯誤步驟和提問，不用作者自測代替真實使用。
7. 把改進納入維護節奏
設定 owner、複查日期和觸發條件，例如服務拓撲、告警名稱或權限變更時自動開更新任務。過時手冊的根因可能是變更流程沒有文件檢查，應把它納入發布清單和事故檢討行動。
高品質示範回答
我會先確認失效步驟的風險，在手冊頂部加警告並通知值班和事件負責人，提供一條經確認的臨時安全路徑。接著檢查團隊實際使用的連結和機器人入口，在沙盒中驗證替代流程，記錄前置條件、停止條件和回滾。邀請服務 owner 與值班代表共同複核，發布新版本並標記舊版本廢棄。最後讓未參與編寫的人做演練，用找到入口的時間、誤操作和升級是否及時來驗收，並把複查觸發條件加入變更流程。
常見錯誤
- 只刪除舊手冊，沒有給值班人員安全替代路徑。
- 只改儲存庫中的檔案，不檢查快取連結、機器人和書籤。
- 讓作者自己演練後就宣布文件可用。
- 把所有故障步驟塞進 runbook，不區分 playbook 和升級邊界。
- 只統計文件合併次數，不衡量誤操作和演練結果。
追問及應對
如果目前正發生事故怎麼辦？
先由 incident lead 確認臨時路徑和風險，暫停失效步驟的傳播，再把文件修復納入事故行動項。不要在救火中進行未驗證的大規模重寫。
如果服務 owner 不願承認手冊過時怎麼辦？
帶上具體步驟、最近變更和可重現的失敗證據，提出小範圍演練。把討論聚焦在使用者風險和維護責任，不評價個人。
舊手冊被很多外部團隊引用怎麼辦？
保留穩定重定向或相容說明，通知消費者並設定遷移截止日期。對高風險命令先限制權限，再逐個確認遷移完成。
什麼時候應該徹底刪除舊版本？
替代路徑經過演練、有明確 owner，所有關鍵入口已遷移且有回滾方案後再刪。安全或合規要求更嚴格時遵循保留政策。
如何應對新流程在演練中失敗？
停止發布，記錄失敗前置條件和觀察訊號，修正流程後重新演練。失敗本身是發布門檻沒有通過的證據，不應靠口頭解釋繞過。
你會怎樣用 STAR 回答？
說明過時手冊帶來的具體風險和任務，再講你如何通知、驗證、協作和發布，最後給出誤操作減少、演練通過率或遷移完成率等結果與後續維護機制。