如何建立一套能減少線上事故的營運就緒審查？
題目與場景
公司準備把多個 B2B SaaS 服務交付給更多客戶，但最近發生重複的發布、回滾和告警回應事故。請你作為產品經理設計一套 Operational Readiness Review（ORR）：它解決什麼問題，如何從事故資料生成檢查項，誰來參與，怎樣不拖慢交付，以及如何證明它真的減少事故。
面試官考察什麼
- 能否把「上線前檢查」定義成可持續的產品機制，而不是一次性審批表。
- 能否把事故檢討、治理、安全、發布品質和運行流程轉成可執行問題。
- 能否設計自助認證、例外處理、責任人和發布門禁。
- 能否用事故率、重複根因和驗證覆蓋率衡量結果，避免把完成表格當成成功。
澄清問題
- ORR 服務的範圍是所有生產變更，還是先從高風險、面向客戶的工作負載開始？
- 目前事故是否有結構化檢討和根因標籤，能否區分重複根因與新風險？
- 哪些要求必須阻斷發布，哪些可在有緩解措施時帶風險上線？
- 現有 CI/CD、值班、工單和安全工具能提供哪些自動證據？
30 秒回答
我會把 ORR 定義為「事故學習驅動的營運能力認證」：產品團隊維護問題庫，服務團隊在發布前自助完成適用清單並附證據，安全、維運和開發共同擁有高風險項。第一版控制在約 30 個核心問題，明確阻斷條件、例外期限和責任人。清單來自歷史事故、合規要求和架構基線，並在每次重大事故後更新。上線後追蹤重大事故數、重複根因、回滾時間和清單發現的風險關閉率，按季度抽樣複審並自動化能自動驗證的項目。
深入拆解
1. 定義產品邊界與使用者
ORR 的使用者是要發布和營運服務的團隊，購買者是工程和業務負責人，治理者是安全、平台和可靠性代表。它補充架構審查，不取代設計審查、合規審批或事故檢討。首批只覆蓋高影響服務，避免把低風險團隊拖入同一流程。
2. 用事故資料生成問題庫
從最近幾次事故的時間線、影響、觸發條件和修正措施提取重複模式，例如缺少回滾、沒有值班覆蓋或依賴沒有容量預算。每個問題都寫成可驗證的斷言，包含證據、責任角色、風險等級和適用條件。只有來源於真實風險或明確治理目標的問題才進入核心清單。
3. 設計清單和自助流程
團隊先選擇工作負載模板，再回答架構、事件管理、發布品質、安全和治理問題。允許「通過」「不適用」「帶緩解措施的例外」三種結果，但例外必須有到期時間和負責人。AWS 建議第一版控制在三十項以內，方便採用和迭代。
4. 建立發布門禁與證據鏈
阻斷項必須在發布系統中有機器可讀狀態；非阻斷項可以生成風險台帳。證據可以是演練紀錄、監控連結、回滾示範、值班排班或安全掃描結果。發布門禁只讀取最新認證版本，避免團隊提交過期截圖後繼續發布。
5. 推廣、自動化與持續改進
先選一個內部服務試點，觀察完成時間、誤報和重複問題。把能由工具判斷的項目接入 CI、設定檢查、監控和工單，減少手工填表。每次重大事故都產生問題庫變更；每季複審清單，刪除已被預設防護覆蓋的項目，保留仍能預測事故的項目。
高品質示範答案
我會把 ORR 做成事故資料驅動的自助認證產品。平台團隊維護按工作負載分類的清單，服務團隊在上線前選擇模板、提交可驗證證據，並為每個例外設定責任人和到期時間。清單首版不超過三十個問題，覆蓋架構、事件回應、發布品質、安全和治理；高風險缺口阻斷發布，已有緩解措施的缺口進入有期限的風險台帳。發布系統讀取認證狀態，CI 和設定工具自動補齊可機器驗證的證據。成功指標包括重大事故數、重複根因比例、回滾時間、發布前發現並關閉的高風險項，以及團隊完成 ORR 的時間。每次事故檢討都更新問題庫，每季抽樣複審，確保流程減少風險而非製造表格負擔。
常見錯誤
- 把 ORR 設計成一次性的審批會議，缺少自助流程和生命週期複審。
- 複製通用最佳實務，卻沒有從本組織事故中提煉問題。
- 所有問題都設為阻斷項，導致團隊繞過流程或產生大量例外。
- 只統計清單完成率，不測量事故、重複根因和回滾結果。
- 允許無期限例外，最後讓風險台帳變成無人維護的列表。
- 手工收集所有證據，沒有優先自動化設定、掃描和發布狀態。
追問與回答
如何防止 ORR 拖慢交付？
先從高風險服務和三十項以內的核心問題開始，提供模板和自助認證。把阻斷條件限制在可證明會造成嚴重影響的風險，其他問題使用有期限例外，並逐步自動化證據收集。
誰擁有最終發布決定？
服務團隊對低風險項負責，安全、平台和可靠性代表共同維護規則；發布系統執行明確的阻斷策略。產品經理負責範圍、指標和例外治理，不取代技術負責人承擔運行責任。
如何證明清單真的有效？
比較 ORR 導入前後的重大事故率、重複根因比例、平均恢復時間和回滾成功率，並抽查清單發現的風險是否在事故發生前關閉。若完成率上升但事故指標不變，應刪除無預測力的問題並調整門禁。