軟體工程師面試：如何系統化排查線上故障？

題幹與適用情境

09:10，結帳流程只在一個區域發生異常：5xx 從 0.3% 升到 5.2%，p95 延遲從 280 毫秒升到 2.6 秒，10 分鐘前剛完成一次發布，目前尚未確認資料遺失。請說明前 30 分鐘如何判斷嚴重程度、控制影響、縮小範圍、驗證假設、確認復原，並為後續根因分析保留證據。

這是一道跨層故障排查題，適用於軟體工程師、SRE、DevOps、平台與技術支援工程師。它沒有指定故障一定在前端、服務、資料庫、網路或第三方相依服務，核心能力是用證據從症狀收斂到故障邊界，並在使用者仍受影響時控制操作風險。

題目中的時間、錯誤率和延遲都是面試情境輸入，不代表通用告警門檻。回答要分開「復原服務」與「證明根因」：重大事故中可以先執行經過驗證的可逆緩解措施，同時保存日誌、追蹤樣本和變更紀錄；根因結論仍需要能區分競爭假設的證據。

面試官考察重點

第一項訊號是能否先建立準確的問題描述。「系統變慢了」無法引導行動。強回答會補齊預期與實際、開始時間、受影響使用者和區域、持續或間歇、業務損失、資料完整性與安全風險，並用這些資訊決定是否升級為事故。

第二項訊號是優先順序。使用者正在失敗時，首要目標是安全地縮小影響範圍。回復版本、關閉功能、切換流量或降級都可能止損，也可能因資料庫變更、容量不足或協定不相容擴大事故。候選人需要說明選擇條件、核准人、回復路徑和驗證指標，不能把「先回復版本」當成無條件答案。

第三項訊號是排查是否由假設驅動。日誌、指標和追蹤只是證據類型，不是步驟清單。強回答會提出少量可證偽假設，為每個假設寫出預測，再選擇能以最低線上風險區分它們的檢查。發現時間相近的發布只能提高該假設的優先順序，不能直接證明發布就是原因。

第四項訊號是事故協作。多人同時改設定、重啟執行個體或擴大日誌層級，會改變現場並讓證據失效。成熟回答會指定事故負責人、實際操作人和溝通人，凍結無關變更，記錄每次操作及結果，讓同一時間只有明確授權的路徑修改線上狀態。

最後看驗證閉環。錯誤率下降可能來自流量自然回落，重啟後的短暫復原也可能掩蓋洩漏。修復後要與健康對照組比較，檢查延遲、錯誤、飽和度、積壓和業務成功率，並另外核對重複扣款、漏單等資料完整性結果。復原確認與長期防止復發分別有清楚出口。

回答前需要釐清的問題

• 這是方法題還是經歷題？ 方法題可以圍繞給定情境逐步推導；若面試官要求真實經歷，應改用本人可核驗的事故，並說清楚個人權限與團隊分工，不能虛構線上經驗。
• 目前使用者影響和嚴重程度是什麼？ 影響一個低流量內部工具時可以繼續觀察；結帳大範圍失敗、資料損壞或安全事件需要立即升級、限制變更並擴大應變團隊。
• 有資料損壞或安全風險嗎？ 只影響延遲時可維持部分流量；若可能重複扣款、越權或破壞資料，先暫停相關寫入或隔離路徑，證據門檻和復原核准都要提高。
• 發布包含什麼？ 程式碼、設定、資料庫遷移、相依版本和基礎設施變更的回復風險不同。向後不相容的 schema 已開始寫入時，直接回復應用程式可能讓故障更嚴重。
• 健康對照組在哪裡？ 其他區域、舊版本執行個體、未啟用功能的租戶或相同區域的其他端點，都能幫助區分版本、區域、輸入與相依服務問題。沒有對照時要先建立低風險的合成請求或唯讀檢查。
• 我在事故中的角色和權限是什麼？ 事故負責人掌握全局狀態，操作負責人修改系統，溝通負責人更新相關人員。若候選人只是調查者，應說明如何提交證據和升級，不越權修改線上環境。
• 有哪些安全緩解手段？ 功能開關、流量切換、穩定環境、降級和版本回復，只有在容量、狀態相容與回退步驟已確認時才可用；答案會隨這些條件改變。

30 秒回答框架

「我先確認影響範圍、資料風險和嚴重程度，必要時立即升級事故並凍結無關變更。使用者仍受影響時，選擇已驗證、可逆且容量足夠的版本回復、開關或流量切換先止損，同時保存證據。接著按時間、區域、版本、請求類型和相依服務做健康對照，列出少量假設及可證偽預測，用指標定位範圍、追蹤定位路徑、日誌解釋具體失敗。每次只做一個有紀錄的低風險變更。復原後檢查核心 SLI、業務成功率、積壓和資料完整性，再完成根因分析與防止復發事項。」

這段回答給出了行動順序。深入回答需要進一步說明每一步的決策條件，以及什麼證據會讓你放棄目前假設。

分步深入解答

先寫一張「症狀契約」，避免團隊調查不同的問題：

• 預期與實際： 基線 5xx 為 0.3%、p95 為 280 毫秒；目前分別是 5.2% 和 2.6 秒。
• 時間： 09:10 被發現，發布在 10 分鐘前完成；還要查真實開始時間和是否持續。
• 範圍： 目前只確認一個區域受影響；繼續按端點、版本、租戶、裝置和請求輸入分層。
• 影響： 統計失敗結帳數量與業務損失，確認是否有可用的替代路徑。
• 完整性： 分別檢查重複扣款、已扣款未建單、漏記事件和越權；「目前尚未確認」不能寫成「已經證明沒有」。

若影響達到事故門檻，立即建立單一協調面。事故負責人維護優先順序和決策紀錄；操作負責人執行線上變更；溝通負責人按固定節奏更新使用者影響、已知事實、目前動作和下次更新時間。凍結無關發布，並記錄時間線、儀表板快照、代表性追蹤 ID、變更版本和每次操作。保存證據不應阻止止損，但盲目重啟會清掉記憶體現場並改變後續觀測。

接著選擇是否先緩解。可以用一個明確判斷：目前損失是否高於緩解操作的最壞可信風險？ 若存在資料破壞，優先停止寫入或隔離；若近期變更可無損回退，且穩定版本與目標區域容量已確認，可以回復版本或切換；若 schema、訊息格式或外部副作用已經變化，就先採用功能開關、流量限制或相容路徑。任何緩解都要寫下預期訊號、觀察期間和失敗後的撤銷動作。

排查從對照開始，不從最長的日誌開始。沿五個維度尋找「只有一邊壞」的邊界：

1. 時間： 異常前後有哪些程式碼、設定、憑證、流量和相依服務狀態發生變化？
2. 區域： 相同版本在健康區域是否正常？受影響區域的舊版本是否也異常？
3. 版本： 同一區域內，新舊執行個體的錯誤率和延遲是否不同？
4. 請求： 是否集中在某端點、租戶、支付方式、裝置版本或輸入大小？
5. 相依服務： 慢請求的時間花在用戶端、邊緣、應用程式、資料庫、快取還是第三方呼叫？

把候選原因寫進假設紀錄，不只留在聊天裡：

檢查順序綜合考慮發生機率、使用者影響、驗證耗時和對線上的風險。指標擅長回答「從何時、哪裡開始」；分散式追蹤顯示一條請求把時間花在哪個邊界；結構化日誌解釋具體錯誤、重試和狀態轉換；程式碼、設定與部署歷史說明系統發生了什麼變化。單筆日誌不能代表整體，彙總指標也不能解釋單一狀態機，三者要圍繞同一個請求 ID 和時間窗口互相印證。

每個實驗盡量只改變一個變數，並事先寫明結果如何證偽假設。例如把一小部分合成請求送到舊設定，能區分設定與輸入；在線上全面開啟詳細日誌可能放大延遲、暴露敏感資料並改變故障。測試應按「最可能、最安全、區分力最高」排序，在健康副本、預發布或小流量中執行。無法安全重現時，可以保留「最可能根因」的措辭，不能把相關性升級成確定因果。

執行修復或緩解後，用獨立於操作本身的訊號確認復原：5xx、p50/p95/p99、成功結帳率、資源飽和度、連線池與佇列積壓、下游錯誤、重試量和告警狀態。至少與一個健康區域或穩定版本比較，並觀察足以涵蓋正常流量波動的預定窗口。之後做訂單與支付對帳，確認沒有重複、缺失或卡住狀態。只有「使用者結果復原、系統沒有積壓、資料完整性通過」三項同時成立，才關閉止損階段。

根因分析在服務穩定後完成。區分直接觸發因素、讓影響擴大的技術條件和未能提前發現的流程缺口。防止復發事項必須有負責人、期限和驗證方式，例如為區域設定增加金絲雀、替關鍵相依服務增加合成探測、讓請求 ID 貫穿呼叫鏈、加入自動回退條件或演練執行手冊。列出十條沒有負責人和驗收標準的建議，不如完成兩條能被重測的改進。

高品質示範回答

以下調查結果和數字全部是虛構的面試情境資料，用於展示口頭回答方式，不代表真實事故或通用門檻。

「我先把它當作正在進行的結帳事故處理。5xx 從 0.3% 到 5.2%，p95 從 280 毫秒到 2.6 秒，而且使用者流程仍在失敗。我會先確認是否有重複扣款、漏單或安全風險；在沒有排除前，不把『尚未確認資料遺失』說成安全。同時凍結無關發布，指定一人協調、一人執行變更、一人更新相關人員，並保存追蹤樣本和變更紀錄。

近期發布是高優先順序假設，但還不是結論。我會在受影響區域比較新舊執行個體，再用健康區域作為第二個對照。假設資料顯示：受影響區域 v42 的 5xx 是 5.4%，v41 是 5.0%；另一個區域的 v42 只有 0.4%。這會降低『程式碼版本單獨造成』的機率，提高區域設定或相依服務異常的優先順序。

接著看同一類結帳請求的追蹤。假設 91% 的失敗都在支付 token 服務呼叫處逾時，該 span 在受影響區域的 p95 是 2.3 秒，健康區域只有 180 毫秒。變更紀錄又顯示 09:00 發布了區域設定 v17，把該呼叫切到新的代理路徑。我會先保存代表性證據，核對 v17 到 v16 的相容性、設定回復權限和既有連線的處理方式，再只回復該區域的設定，不同時回復程式碼、重啟和擴容。

回復後，我不會看到一次綠燈就宣布結束。假設連續 15 分鐘內 5xx 降到 0.4%、p95 降到 320 毫秒，佇列清空，結帳成功量復原；訂單與支付對帳也沒有發現重複扣款、漏單或卡住狀態。設定回復與這些獨立訊號共同支持代理路徑是直接觸發因素，但我還會在預發布重現，並檢查為什麼區域設定沒有金絲雀和相依服務延遲護欄。

最後的防止復發事項會包括：區域設定先小流量發布；為支付 token 呼叫建立分區域合成探測和尾端延遲告警；自動回退條件同時檢查錯誤率與延遲；執行手冊寫清設定回復與資料對帳步驟。每項都有負責人、完成時間和一次故障演練作為驗收。」

常見錯誤

• 看到近期發布就直接宣布根因 → 時間相關性可能與流量、憑證或下游變化重疊 → 按版本與區域建立對照，用預測能被推翻的檢查驗證。
• 一開始就翻所有日誌 → 沒有時間、範圍和假設，資訊量越大越容易陷入無關異常 → 先量化症狀，再用指標和追蹤縮小到元件與請求群。
• 無條件回復版本 → schema、訊息格式或狀態已變化時，舊版本可能不相容 → 先核對狀態相容、容量和撤銷路徑，選擇風險最低的緩解。
• 多人同時「試一下」 → 並行變更改變現場，無法判斷哪個動作有效，還可能擴大事故 → 設定事故角色，線上變更由單一授權路徑執行並記錄。
• 重啟後復原就認定根因 → 重啟會清空佇列、連線或記憶體狀態，只證明某些狀態被重設 → 繼續尋找觸發狀態的條件，並觀察它是否重新累積。
• 只看平均延遲 → 少量嚴重失敗會被平均值掩蓋 → 同時看錯誤率、延遲分位數、流量與飽和度，並按受影響族群分層。
• 擴大日誌層級但不評估副作用 → 詳細日誌可能增加 I/O、延遲和敏感資料暴露 → 先限定執行個體、時間與欄位，並準備自動關閉。
• 監控復原就跳過資料核對 → 逾時重試可能已經造成重複扣款、漏單或積壓 → 對業務紀錄和外部副作用做明確對帳。
• 檢討只寫「加強監控」 → 沒有指標、門檻、負責人和測試，無法驗證是否改進 → 把行動寫成可執行變更，並用演練或故障注入驗收。

追問及應對

追問一：回復版本後故障沒有改善，下一步是什麼？

先記錄回復確實完成，並確認流量已經到達舊版本；否則「回復無效」本身可能是發布系統問題。若舊版仍壞，降低程式碼回歸假設的優先順序，比較區域設定、相依服務 span、憑證、DNS、流量結構和共享資源。不要立即把新版本再部署回去，除非恢復它有明確收益且風險已評估。

追問二：如果懷疑正在發生資料損壞呢？

止損優先順序提高。暫停相關寫入、隔離受影響租戶或切換成唯讀，保留稽核日誌與原始事件，並讓資料或安全負責人參與復原核准。修復後先在副本或隔離資料上驗證，再做範圍清點、對帳與可回復修復；服務回應變綠不足以授權重新開放寫入。

追問三：沒有分散式追蹤，只有零散日誌怎麼辦？

用閘道存取日誌、時間戳記、執行個體、請求類型和現有關聯欄位建立近似邊界，並發送帶已知識別碼的低風險合成請求逐段檢查。避免臨時在線上全面印出請求內容。事故後補齊貫穿邊緣、服務和相依服務的請求 ID，以及關鍵邊界的延遲、狀態碼和版本欄位；缺少可觀測性本身是需要負責人和驗收的根因放大因素。

追問四：多個團隊都認為問題在對方系統，怎麼推進？

事故負責人按使用者影響分配元件調查，不按組織邊界爭論責任。共享一條時間線和假設紀錄，每個團隊交付可檢驗的預測與證據，例如「請求已在本服務 120 毫秒內成功回傳，某追蹤 ID 的下一段耗時 2 秒」。操作權仍保持單一，溝通人彙整事實，避免每個團隊各自修改線上環境。

追問五：問題間歇出現且無法穩定重現，如何給出根因結論？

先擴大安全的被動觀測：取樣失敗和成功請求、保留版本與輸入維度、記錄資源與相依服務狀態，再尋找能區分假設的自然對照。可以用故障注入或流量重播在隔離環境驗證，但不為追求確定性在線上製造高風險條件。證據只支持機率結論時，明確寫「最可能因素」和剩餘未知項，同時實施能降低影響的護欄與更強觀測。