如何建立一套能减少线上事故的运营就绪评审？
题目与场景
公司准备把多个 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 引入前后的重大事故率、重复根因比例、平均恢复时间和回滚成功率，并抽查清单发现的风险是否在事故发生前关闭。若完成率上升但事故指标不变，应删除无预测力的问题并调整门禁。