📚 课程目录第3章发布MTTR的复盘口径

3. 发布MTTR的复盘口径：如何定义“修复开始”与“修复结束”的时间点、不同团队（开发/测试/运维）的口径对齐方法

发布MTTR（Mean Time to Repair，平均修复时间）是衡量质量门禁失效后，团队从发现误报/漏报到完成修复并恢复发布流程的关键指标。然而，在实际复盘过程中，“修复开始”与“修复结束”的时间点定义往往因团队视角不同而产生分歧，导致MTTR数据失真，无法有效指导规则调优。

本章将首先明确标准化的时间点定义，然后提供一套跨团队（开发、测试、运维）的口径对齐方法，确保复盘数据具备横向可比性。

为了消除歧义，我们采用“事件驱动”的方式定义两个关键时间点，而非基于主观的“开始工作”或“完成工作”。

时间点	定义	触发事件（Event）	数据来源
T_start（修复开始）	质量门禁判定为误报/漏报，且团队确认需要修复的最早可追溯时间点。	1. 门禁告警被人工确认为“误报”或“需修复”。 2. 对应的Jira/Bug工单状态变更为“待处理”或“进行中”。 3. 代码仓库中创建了第一个修复分支（hotfix branch）。	门禁系统日志、工单系统时间戳、Git仓库事件。
T_end（修复结束）	修复方案已通过验证，并成功解除对发布流程的阻塞的时间点。	1. 修复代码合并至目标分支（如master/release）。 2. 质量门禁重新扫描通过，状态变为“绿色”。 3. 发布流水线（CI/CD Pipeline）解除阻塞，继续执行。	CI/CD系统状态、代码合并事件、门禁扫描结果。

关键原则： T_start 不早于“确认需要修复”的时刻，T_end 不晚于“解除发布阻塞”的时刻。避免将“问题发现时间”或“代码评审时间”计入MTTR，以保证指标聚焦于“修复动作”本身。

开发、测试、运维团队对“修复”的理解天然存在差异。以下表格展示了各团队视角下的MTTR计算偏差，以及统一对齐后的标准口径。

团队	常见偏差视角	偏差原因	对齐后的标准口径
开发团队	T_start = 开始写代码；T_end = 代码提交。	认为“修复”仅指代码变更，忽略门禁确认和流水线恢复环节。	T_start = 门禁确认误报/工单进入待处理；T_end = 修复代码合并至目标分支。
测试团队	T_start = 收到修复版本；T_end = 回归测试通过。	将“验证”环节视为修复的一部分，导致MTTR偏长。	T_start = 门禁确认误报；T_end = 门禁重新扫描通过（包含自动化验证）。
运维团队	T_start = 收到告警；T_end = 发布流水线恢复。	关注系统可用性，将“告警响应”和“流水线恢复”全部计入。	T_start = 门禁确认误报；T_end = 发布流水线解除阻塞。

  对齐方法总结： 所有团队统一以“门禁系统事件”作为时间锚点。开发关注代码合并，测试关注门禁扫描，运维关注流水线状态。通过自动化工具（如Webhook）将这三个事件的时间戳自动上报至统一的MTTR计算平台，消除人工记录带来的口径差异。

下图展示了从误报确认到发布恢复的完整时间线，并标注了各团队应关注的关键事件节点。

建立统一的事件总线： 将门禁系统、工单系统、Git仓库、CI/CD流水线的事件（Event）统一接入到一个消息中间件（如Kafka或RabbitMQ）。
定义标准事件Schema： 每个事件必须包含 event_type（如 gate_alert_confirmed、hotfix_branch_created、merge_to_target、pipeline_unblocked）、timestamp、service_name、release_version。
开发MTTR计算服务： 该服务订阅事件流，根据 service_name 和 release_version 进行聚合，自动计算每次修复的 T_start 和 T_end。
配置复盘看板： 在Grafana或自研平台上展示每个团队的MTTR趋势，并支持下钻到单次修复的详细事件时间线。

避坑提示： 避免使用“工单关闭时间”作为T_end。工单关闭往往滞后于实际修复完成，且不同团队关闭工单的习惯不同，会导致MTTR虚高。始终以自动化系统事件（代码合并、门禁通过、流水线恢复）为准。

对齐口径后，建议通过以下方式校验数据一致性：

通过以上定义、对齐方法和落地步骤，发布MTTR将成为一门可量化、可对比、可优化的工程指标，为后续的质量门禁规则调优提供坚实的数据基础。