行為面試：講一次你在第三方故障中帶隊恢復的經歷
題幹與適用場景
你的支付、身分、訊息或資料供應商發生中斷，產品出現部分不可用。面試官希望聽到一段真實經歷：你如何確認事實、劃分角色、保護客戶、協調供應商、決定降級或回滾，並把一次外部故障轉成可驗證的改進。
面試官考察點
- 能否用事實說明客戶影響和優先級，而不是只描述「供應商很差」。
- 是否建立清晰的事故指揮、技術處理和溝通責任。
- 能否在資訊不完整時做可逆決定並明確升級條件。
- 是否對依賴治理、演練和指標承擔長期 ownership。
回答前需要釐清的問題
- 故障影響哪些客戶、地區、流程和資料完整性，是否仍在擴大？
- 你當時的正式職責和決策權限是什麼，誰是事故指揮人？
- 是否有備用供應商、快取、佇列、降級或人工通道？
- 哪些資訊已確認，哪些只是供應商推測？
- 恢復後如何證明客戶沒有重複扣款、遺失訊息或權限錯誤？
30 秒回答框架
我會按 STAR 講一個具體事件：先用監控和客戶樣本確認影響範圍，再立即指定事故指揮、技術處理和對外溝通角色。短期選擇可逆的降級或暫停寫入，設定升級和複查時間點；與供應商共享最小必要證據並要求明確 ETA。狀態頁和客戶支援使用同一事實版本。恢復後核對資料、補償和指標，推動備用路徑、依賴 SLO 和演練落地。
分步驟深入解答
第一步：鎖定事實與影響
記錄開始時間、受影響功能、錯誤率、租戶範圍和資料風險。用請求日誌、供應商狀態和少量可重現樣本交叉驗證，不把單一客戶回饋直接當成全局結論。
第二步：建立事故角色
指定一名事故指揮人統一優先級，一名技術負責人處理緩解，一名溝通負責人維護狀態更新。明確誰能暫停寫入、切換供應商或批准客戶補償，避免多人同時發出互相衝突的指令。
第三步：選擇可逆緩解
比較重試、佇列、快取、唯讀模式、備用通道和功能關閉的副作用。涉及支付、身分或資料寫入時，先保護一致性，設定重複操作檢查和截止時間；任何方案都記錄觸發條件、負責人和回退方法。
第四步：協調供應商與內部團隊
向供應商提交時間線、請求 ID、區域和錯誤樣本，避免傳送敏感資料。內部每隔固定時間複查證據與 ETA；如果供應商資訊與自身觀測衝突，以可重現的業務指標決定下一步。
第五步：面向客戶溝通
狀態頁只發布已確認的影響、範圍、開始時間和下一次更新時間，不猜測根因或承諾恢復時間。高價值或受監管客戶由支援和客戶成功團隊按統一腳本溝通，記錄請求和補償需求。
第六步：驗證恢復與資料完整性
錯誤率下降不等於恢復完成。核對積壓佇列、重複寫入、遺失事件、權限狀態、支付對帳和客戶關鍵流程；逐步放量並保留回退開關，直到連續觀察窗口通過。
第七步：復盤與長期改進
復盤聚焦時間線、決策證據和系統條件，不把責任推給個人。為依賴設定可觀測 SLO、逾時和熔斷邊界，增加備用路徑、合約升級條款、故障演練和季度複審，並由明確 owner 跟蹤完成。
高品質示範回答
我會講一次真實的訊息供應商中斷。告警顯示傳送失敗率升高，我先用租戶和地區切片確認影響，發現交易確認訊息延遲但資料庫寫入仍安全。團隊由事故指揮、技術緩解和客戶溝通三人分工；我們暫停非關鍵通知，把可重試訊息放入帶去重鍵的佇列，並設定每十分鐘複查。供應商只收到請求 ID、時間線和區域，不包含客戶內容。狀態頁公布已確認範圍，支援團隊使用同一腳本。恢復後我們回放佇列、對帳傳送結果並抽樣核對客戶狀態，確認無重複或遺失。復盤增加備用通道、依賴 SLO、供應商演練和按租戶的積壓指標，指定我負責季度驗證。
常見錯誤
- 把故事講成供應商指責，沒有自己的判斷和行動。
- 沒有明確事故角色，所有人同時改配置或對外承諾。
- 未核對副作用就切換重試，造成重複扣款或訊息風暴。
- 狀態頁發布未經確認的根因和恢復時間。
- 復盤只寫「加強監控」，沒有 owner、截止時間和驗收指標。
追問及應對
如果供應商不回應，你會怎麼辦？
按合約升級路徑聯絡值班和管理層，同時依據自身指標執行已批准的降級或備用方案。供應商沉默不應阻止保護客戶和資料。
什麼時候應該暫停寫入？
當繼續寫入可能造成不可逆的資料不一致、重複扣款或權限錯誤，且沒有可靠冪等保護時暫停。先明確誰能恢復寫入及恢復前必須完成的核對。
如何證明這段經歷不是事後編造？
給出可核對的時間線、指標變化、本人負責動作和結果；區分已確認事實與當時假設，不誇大個人權限或供應商承諾。
你會如何衡量長期改進？
觀察依賴錯誤導致的客戶影響時長、備用路徑成功率、積壓恢復時間、重複或遺失事件、演練通過率和未關閉行動項，而不是只看告警數量。