行為面試：分享一次你在不遺失使用者的情況下退役舊系統
題幹與適用場景
面試官想知道你是否真正推動過一項有歷史包袱的改變。舊系統可能仍能運作，卻消耗大量值班時間、無法符合安全要求，或阻礙新產品。請說清楚你如何決定退役、遷移使用者並處理反對意見。
這道題不是要你描述一次技術重寫，也不是把遷移成功歸功於「團隊合作」。回答要讓面試官聽見你的判斷、行動、證據與結果。
面試官考察什麼
重點包括：能否從使用者工作流程而非系統年齡出發；能否用資料識別真正受影響的人；能否把風險、責任人和時間點公開；能否在有爭議時堅持使用者目標並在決定後共同執行。Amazon 的面試指引強調 STAR、具體個人貢獻和可量化結果；Google SRE 的退役案例也強調使用者工作流程、溝通與遷移工具。
回答前要釐清的問題
先確認「退役」是停止新使用者、只讀保留、完全下線，還是替換一條內部流程。再確認你的角色、影響範圍、遷移期限、可用替代品和不可逆風險。若無法公開公司資料，可說明數字是經去識別化的真實口徑或面試假設。
30 秒回答框架
我會用五句說：背景和代價；我負責的目標；我如何用存取資料和使用者訪談劃分遷移批次；我如何設計雙軌、回復和溝通；結果、教訓與下一次會改什麼。每句都用「我」說明行動，用數字說明結果。
分步驟深入分析
第一步：把「舊」翻譯成可驗證的問題
不要因為技術棧老就宣布下線。先量化維護工時、故障、成本、合規缺口和仍在使用的關鍵流程。按使用者、工作流程、資料規模和存取頻率分組，找出替代方案尚未覆蓋的例外。Google SRE 透過存取模式理解使用者工作流程，避免只憑系統統計決定遷移。
第二步：建立遷移證據與最小可行路徑
為每類使用者定義目標狀態：直接遷移、轉換工具、只讀封存或暫緩。提供相容性清單、資料校驗、演練環境和明確停止條件。先選低風險批次做試點，讓替代系統能力和遷移成本用真實結果說話。
第三步：處理反對意見與利害關係人
把反對者的顧慮拆成資料遺失、工作中斷、責任不清或替代方案不足。與支援、客服、安全和替代系統負責人一起建立問題清單和每週決策記錄。遇到不同意見時先用證據討論；決定後明確誰負責執行、誰有權暫停，不要讓爭論一直拖延。
第四步：設計雙軌、回復和溝通
遷移期間保留舊系統的只讀或回退能力，給每批使用者一個可驗證的完成訊號。提前發出影響範圍、原因、截止日期、遷移步驟和求助入口；發生失敗時說明事實、補救行動和下一次更新。錯誤通知不受影響的使用者，或漏掉真正受影響的使用者，都會損害信任並增加客服工作。
第五步：定義結果與復盤
結果指標可以包括遷移完成率、關鍵工作流程成功率、回退次數、故障工時、使用者求助量和維護工時。不要只報「舊系統已關閉」；同時說明受影響使用者是否完成任務、營運負擔是否下降，以及哪些例外被保留。復盤應寫下錯誤假設、早期訊號和下一次遷移會提前做的驗證。
高品質示範回答
我曾負責一套仍被少數客戶使用的舊報表流程。它每週約占用 20 小時人工維護，替代方案已覆蓋大多數查詢，但高峰客戶擔心歷史資料不一致。我先按存取日誌和客戶工作流程劃分使用者，發現 82% 的存取可以直接遷移，另外 18% 需要歷史資料轉換。
我把目標設為先完成低風險批次，而不是立即關閉舊流程。工程為兩套結果產生校驗報告，支援團隊準備按客戶分組的通知，我負責每週公開遷移表和暫停條件。試點兩週後，關鍵報表一致率達到 99.9%，沒有發生回退；對剩餘使用者，我們提供轉換工具和只讀封存，並把最終截止日期延後一次。
最終舊流程維護工時從每週約 20 小時降到 4 小時，所有仍有存取的客戶都有替代路徑。復盤發現我們低估了一個地區的匯出格式，所以後來把地區和匯出方式加入最初分群，而不是在截止日期前才補救。
常見錯誤與改進
- 只說「系統太舊」：補充使用者影響、維護代價和替代證據。
- 只講技術重寫：說明你如何調查工作流程、分批和溝通。
- 把反對者描述成阻力：呈現其風險證據和你如何回應。
- 只報遷移百分比：補充關鍵任務成功率、回退和求助量。
- 聲稱零風險：說明保留的只讀、回復或延期期限。
追問及應對
What if the replacement is not ready for every user?
Keep a documented exception path: read-only archive, conversion tooling, or a time-boxed extension. Define the owner and exit condition for each exception instead of forcing a risky cutover.
How did you convince a stakeholder who opposed retirement?
I asked which failure they were protecting against, measured that workflow, and ran a small migration to test the replacement. If the decision still went against their preference, I recorded the risk and committed to the agreed plan with a pause condition.
What would you do if migration caused data loss?
Stop the batch, preserve the old source, identify the affected records, and communicate a concrete recovery timeline. After restoring service, add an automated reconciliation check and revise the next batch gate.
How do you know the project succeeded?
Use user-outcome and operating metrics together: critical workflow success, migration completion, rollback and support volume, plus maintenance hours. A closed system without a safe user path is not a successful retirement.