題幹與適用場景
一個開發平台發現合併請求經常等待審查，作者反覆催促；另一方面，審查者擔心硬性時限鼓勵草率批准。團隊考慮設定程式碼審查 SLO，並參考公開工程流程對回饋時效、阻塞問題和協作價值的規定。
請從使用者問題、指標定義、分層策略、通知與責任、品質護欄、實驗設計和回滾完整回答。SLO 是團隊營運契約，不應直接等同於單個審查者的績效排名。
面試官考察點
面試官看重候選人是否把「等待時間」拆成可行動階段，能否平衡交付速度、審查品質、作者體驗和審查者負擔。
強回答會討論中位數與長尾、緊急變更豁免、跨時區輪值、阻塞與非阻塞評論、樣本分層、品質回歸和反作弊，而不是只給一個 24 小時數字。
回答前需要澄清的問題
- 目標是減少首次回饋等待，還是縮短建立到合併的總週期？
- 哪些變更需要兩位維護者批准，哪些可以走快速路徑？
- 如何處理休假、跨時區、依賴外部團隊和大型重構？
- 品質訊號有哪些：回滾、缺陷、返工、審查遺漏還是安全事件？
- SLO 面向團隊、程式庫、服務等級還是個人？
30 秒回答框架
「我會先把首次回應、阻塞問題處理和最終合併分成三個指標，按變更風險、大小和依賴團隊分層，不給個人設單一排名。先在一個程式庫試點，提供輪值、提醒和延期原因，品質護欄同時看回滾、缺陷、返工和安全問題。若等待下降但缺陷或審查深度惡化，就停止擴展並調整分層，而不是繼續壓時限。」
分步驟深入解答
先定義使用者價值和範圍
作者等待首次有用回饋時，無法判斷程式碼方向是否正確；審查者則需要上下文和完整 CI。產品目標應優先減少無意義等待，同時保留安全、架構和測試審查。不要把所有等待都歸因於審查者，區分作者未準備、CI 未完成和外部依賴。
設計分段指標
記錄建立到首次回應、首次回應到所有阻塞項關閉、關閉到合併、總週期和重新開啟次數。分別報告 P50、P90/P95 與逾時比例；只看平均值會掩蓋大改動和夜間請求。每個時間段要有開始、結束事件和統一時區規則。
按風險和工作量分層
小型低風險改動可採用短首次回應目標；安全、資料庫、跨服務和大型重構需要更長窗口與更多審批。緊急修復要有明確標籤和事後複核，不能讓所有請求都走緊急通道。分層欄位由系統產生或稽核，避免作者任意降低風險。
配套通知和責任機制
輪值表、候選審查者推薦、工作時間提醒和升級路徑比單純倒數計時更有效。提醒應指向佇列和職責，不公開羞辱個人。GitLab 公開流程強調回饋及時、討論可追蹤及維護者對最終判斷負責，可轉化為團隊流程而非個人競賽。
建立品質護欄
把回滾率、線上缺陷、返工輪次、審查遺漏、安全掃描命中、變更失敗率與 SLO 一起觀察。對比同風險層、同程式庫和同發布窗口，避免把高風險變更天然較慢當成失敗。抽樣複核評論是否覆蓋需求、測試、可維護性和安全邊界。
設計可解釋的延期
允許審查者選擇結構化原因，如等待上下文、外部依賴、維護者缺席或需要安全專家；延期不會自動算違規，但必須顯示佇列狀態和下一次更新時間。產品應優先消除系統性瓶頸，例如缺少輪值或 CI 排隊，而不是強迫個人加班。
執行試點與評估
選擇一個流量穩定的程式庫，先建立兩週基線，再按風險層逐步啟用提醒和輪值。比較等待分布、合併週期、作者滿意度、審查負擔和品質護欄；用對照程式庫或分時段實驗避免把發布季節性誤認為效果。
回滾和長期治理
若逾時下降伴隨回滾或缺陷上升，暫停擴大範圍，關閉個人排名和強制升級，保留團隊級目標與人工複盤。季度複審分層、SLO 窗口、休假策略和品質權重；當程式庫規模、團隊時區或合規要求改變時重新校準。
高品質示範回答
「我會把 SLO 設計成團隊級服務契約：首次有用回饋、阻塞項處理和最終合併分別測量，按風險、工作量和依賴分層。輪值、推薦和升級負責減少等待，延期用結構化原因記錄，個人不按單一逾時排名。試點同時觀察 P50/P95 等待、作者體驗、審查負擔、回滾、缺陷、返工和安全遺漏；如果速度改善但品質惡化，就暫停擴展並修正分層、責任或 CI 瓶頸。」
常見錯誤
- 給所有 MR 一個 24 小時目標 → 大改動和安全變更被迫草率 → 按風險與工作量分層。
- 用個人逾時排名 → 審查者搶單或快速批准 → 面向團隊佇列和品質結果。
- 只看平均等待 → P95 長尾被隱藏 → 報告分段 P50/P90/P95。
- 把提醒當治理 → 沒有輪值和升級仍會堵塞 → 補足責任、佇列和上下文。
- 只看合併速度 → 缺陷和回滾上升 → 把品質護欄納入同一評估。
- 取消所有延期 → 跨時區和合規工作被懲罰 → 允許可解釋延期並顯示下一步。
追問及應對
追問一：為什麼不直接用總週期作為 SLO？
總週期混合作者準備、CI、外部依賴和審查，責任不可行動。分段指標能定位瓶頸，產品仍可把總週期作為結果指標。
追問二：緊急修復是否可以跳過 SLO？
可以走明確緊急路徑，但必須保留最小安全檢查和事後複核。若緊急標籤被濫用，應稽核標籤來源和後續缺陷，而不是取消所有例外。
追問三：如何證明速度沒有犧牲品質？
按風險層對比回滾、缺陷、返工、安全遺漏和評論覆蓋，並觀察至少一個穩定週期。單次成功發布不足以證明因果，需要對照或分階段實驗。
追問四：誰應該為 SLO 失敗負責？
團隊負責佇列、輪值和工具；作者負責準備上下文；審查者負責及時且有依據的回饋；維護者負責最終判斷。避免把系統性缺口轉化為個人懲罰。