题干与适用场景
一个开发平台发现合并请求经常等待评审，作者会反复催促；另一边，评审者担心硬性时限鼓励草率批准。团队考虑设置代码评审 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 失败负责？
团队负责队列、轮值和工具；作者负责准备上下文；评审者负责及时且有依据的反馈；维护者负责最终判断。避免把系统性缺口转化为个人惩罚。