題幹與適用場景
假設平台使用者和業務量成長，團隊同時面對可用性、延遲、資料正確性、合規風險和新功能需求。請說明你如何識別最重要的可靠性問題、估算影響和投入、選擇路線圖順序，並向利益相關者解釋取捨。
Google SRE 將 error budget 作為可靠性與發布速度之間的共同決策機制；AWS Well-Architected Tool 建議按業務重要性和實施努力排序，並持續追蹤改進。回答重點是把可靠性翻譯為使用者和業務結果，不是羅列監控指標。
它不同於“如何定義新功能成功指標”：本題要在資源有限時做跨團隊投入排序；也不同於“事故復盤”：重點是事前如何分配下一階段資源。
面試官考察點
- 是否從關鍵使用者旅程和業務影響定義可靠性。
- 是否使用 SLO、錯誤預算、風險和成本形成可解釋框架。
- 是否能比較立即修復、緩解、架構改造和接受風險。
- 是否給出負責人、里程碑和驗證指標。
- 是否能在資料不足時先做低成本學習，而不是假裝精確。
回答前需要釐清的問題
- 哪些使用者旅程或客戶承諾最重要？
- 目前 SLO、錯誤預算和主要故障類別是什麼？
- 問題造成的是流失、收入損失、合規風險、支援成本還是工程負擔？
- 可靠性改進的工程量、依賴和機會成本是多少？
- 哪些風險可以短期緩解，哪些必須根治？
- 誰擁有產品、工程、財務和合規決策權？
- 投入成功如何驗證？時間範圍多長？
- 是否存在必須立即停止發布的錯誤預算政策？
30 秒回答框架
“我先按關鍵使用者旅程定義 SLO，並把事故、延遲、資料錯誤和合規問題映射到業務影響。然後用錯誤預算、影響範圍、風險嚴重度、工程努力和學習價值排序。我會先處理高影響且可快速降低風險的項目，同時為根治性改造設里程碑；若錯誤預算耗盡，暫停非必要發布。每項投入都有負責人、目標指標和復查日期，向產品和工程共同說明放棄了什麼。”
分步驟深入解答
步驟一：定義使用者與業務後果
從支付、登入、發布、資料匯出等關鍵旅程出發，區分可用性、延遲、正確性和隱私。不要把所有內部警示都當作同等優先順序。
步驟二：建立可靠性基線
確認 SLO、錯誤預算消耗、故障頻率、影響使用者數、恢復時間和客服工單。指標必須能對應使用者體驗或業務承諾。
步驟三：拆分解決方案
把候選工作分成止血、緩解、根治和監測四類。止血可能是限流或降級，根治可能是資料模型或架構改造；兩者應在路線圖中關聯。
步驟四：比較影響、成本和學習價值
AWS 建議同時考慮改進重要性和實施努力，並用迭代里程碑追蹤結果。比較時要把機會成本也寫出來。
| 決策維度 | 需要回答的問題 | 證據例子 |
|---|---|---|
| 使用者影響 | 誰會受影響，頻率和嚴重度如何？ | 關鍵旅程失敗率 |
| 風險 | 是否有安全、合規或不可逆損害？ | 事故與審計記錄 |
| 投入 | 工程量、依賴和維護成本？ | 人週與里程碑 |
| 速度 | 能否先做可逆緩解？ | 降級或限流實驗 |
| 學習 | 哪個小實驗能減少不確定性？ | 分階段觀測 |
步驟五：使用錯誤預算做發布決策
當服務在預算內，可繼續推進高價值功能並安排可靠性債務；預算耗盡時，暫停非必要變更，優先恢復 SLO。錯誤預算不是無限授權，仍需考慮安全和合規硬約束。
步驟六：協調路線圖與資源
給每個項目指定負責人、目標、依賴和完成條件。把可靠性工作放入與功能相同的規劃節奏，明確本季度不做的事項和原因。
步驟七：驗證結果和調整
追蹤 SLO、錯誤預算、故障恢復時間、客服量、客戶留存或成本變化。若改進沒有降低使用者影響，重新評估假設，而不是繼續投入沉沒成本。
步驟八：向利益相關者講清取捨
用一頁決策記錄說明選擇、證據、風險、替代方案和復查日期。不要把可靠性描述成工程團隊的偏好；說明它保護了哪個使用者結果和業務承諾。
高品質示範回答
“我會先把平台拆成登入、核心交易和報表三個使用者旅程，為每個旅程確認 SLO、錯誤預算和影響使用者。接著按錯誤預算消耗、關鍵客戶影響、合規風險、工程努力和可逆性排序。
假設核心交易的錯誤預算連續兩週被消耗，我會先做限流和降級，恢復關鍵路徑，再安排根因改造；報表延遲若只影響低頻使用者，可以先記錄並設定里程碑。我會和工程負責人確認人力與依賴，把每項工作寫成目標、負責人和驗證指標。預算耗盡期間暫停非必要發布，並向銷售說明客戶承諾的影響。
每兩週復查錯誤預算、恢復時間和客服工單。如果短期緩解已經消除影響，就重新評估根治項目；如果指標沒有改善，就停止原方案並尋找新路徑。這樣可靠性投入與使用者結果、發布節奏和機會成本保持一致。”
常見錯誤
- 把所有警示按技術嚴重度排序，不看使用者影響。
- 只說“可靠性很重要”，不給 SLO 或錯誤預算。
- 只做永久架構改造，忽略可逆緩解和學習價值。
- 把錯誤預算當成允許忽略安全、合規的額度。
- 沒有負責人、里程碑和復查日期。
- 只報告延遲和可用性，不驗證客戶和業務結果。
- 只講工程團隊，不說明產品和商業取捨。
追問及應對
追問一：業務方堅持先做新功能怎麼辦？
把錯誤預算、客戶影響和替代方案量化；若預算耗盡，提出明確的變更凍結規則，並由有權限的人做風險決定。
追問二：沒有足夠資料怎麼排優先順序？
先做低成本埋點、故障分類或小範圍實驗，明確學習目標和停止條件，避免用假精度排序。
追問三：可靠性改進永遠沒有終點怎麼辦？
用 SLO 和錯誤預算定義足夠好的邊界，比較邊際收益與機會成本，並定期復查是否仍匹配使用者承諾。
追問四：短期緩解會增加長期債務怎麼辦？
記錄債務、負責人和到期條件，把緩解與根治里程碑綁定；若到期仍未完成，降低範圍或升級風險。
追問五：如何證明投入帶來價值？
比較改進前後的 SLO、故障恢復、客服量、客戶影響、留存或成本，並說明對照期間和不確定性。
追問六：不同客戶的可靠性需求不同怎麼辦？
按關鍵旅程、合同承諾和客戶影響分層，必要時提供不同 SLO 或隔離容量，但不能讓低優先順序客戶承擔不可接受風險。