3. MTTR 复盘口径设计原则

MTTR（Mean Time to Repair）是衡量故障恢复效率的核心指标，但其数值高度依赖“从何时开始计时、到何时结束计时”的口径定义。若口径不统一，不同团队、不同故障之间的 MTTR 将失去可比性，复盘结论也会产生误导。因此，MTTR 复盘口径的设计必须遵循四项基本原则：一致性、可重复性、可审计性、自动化优先。

3.1 四项原则概述

3.2 一致性：统一起止事件定义

MTTR 的计时窗口由“开始时间”和“结束时间”界定。一致性原则要求：所有故障必须使用相同的可观测事件作为计时锚点，而非依赖人工主观判断。

• 开始时间（T_start）：推荐使用 告警触发时间 或 监控指标首次异常时间，而非“工程师接到电话时间”或“创建工单时间”。
• 结束时间（T_end）：推荐使用 核心业务指标恢复时间（如错误率降至基线、P99 延迟回落到阈值内），而非“工程师关闭工单时间”或“代码合并时间”。
• 排除项：非故障期间的维护窗口、已知计划内变更导致的指标波动，应从 MTTR 计算中排除。

3.3 可重复性：消除人工计算偏差

可重复性原则要求：给定相同的监控时间序列数据和告警事件日志，任何 SRE 工程师或自动化脚本执行相同的口径逻辑，必须得到完全一致的 MTTR 值。

实现可重复性的关键措施：

• 口径代码化：将起止事件判定逻辑编写为可执行的查询语句（如 PromQL、SQL）或配置规则，而非写在文档中。
• 版本化管理：口径定义随代码仓库一起管理，每次修改需经过 Code Review，确保变更可追溯。
• 输入数据固定：指定使用哪个数据源（如 Prometheus 指标、ELK 日志）的哪个字段作为时间戳来源。

-- 示例：可重复的 MTTR 计算 SQL 查询（PostgreSQL）
-- 输入：故障事件表 incident_event，包含 incident_id, event_type, event_time
-- 口径定义：T_start = 首次 'alert_firing' 事件，T_end = 最后 'metric_recovered' 事件
SELECT
    incident_id,
    MIN(CASE WHEN event_type = 'alert_firing' THEN event_time END) AS t_start,
    MAX(CASE WHEN event_type = 'metric_recovered' THEN event_time END) AS t_end,
    EXTRACT(EPOCH FROM (
        MAX(CASE WHEN event_type = 'metric_recovered' THEN event_time END) -
        MIN(CASE WHEN event_type = 'alert_firing' THEN event_time END)
    )) / 60 AS mttr_minutes
FROM incident_event
WHERE incident_id = 'INC-2025-001'
GROUP BY incident_id;

3.4 可审计性：全链路可追溯

可审计性原则要求：每一个 MTTR 值的计算过程，都应能追溯到原始事件、时间戳来源、口径版本和执行环境。 这不仅是合规要求，更是持续优化口径的基础。

3.5 自动化优先：减少人工介入

自动化优先原则是前三项原则落地的工程保障。其核心思想是：凡是能通过监控系统、告警系统、CMDB 自动获取的时间戳，绝不依赖人工录入。

• 自动采集 T_start：通过 Prometheus Alertmanager 的 startsAt 字段或监控系统的异常检测触发时间。
• 自动采集 T_end：通过告警恢复事件 endsAt 或自定义的“业务指标恢复检测器”自动判定。
• 自动计算与归档：故障关闭后，自动化流水线立即计算 MTTR 并写入可观测性数据平台，同时生成审计日志。
• 人工兜底：仅在系统无法自动判定（如网络分区导致监控数据丢失）时，才允许人工补充，且补充操作必须记录审计日志。

3.6 四项原则的关系与落地流程

下图展示了四项原则在 MTTR 复盘口径设计中的协同关系与落地流程：

3.7 原则冲突时的优先级

在实际落地过程中，四项原则可能发生冲突。例如：为了追求自动化优先，系统自动采集的时间戳可能因时钟偏差导致一致性受损。此时建议的优先级排序为：

1. 一致性 > 自动化优先：如果自动化采集的时间戳来源不一致（如不同集群的时钟未同步），应优先修复时间同步问题，而非强行自动化。
2. 可审计性 > 可重复性：当口径需要调整时，保留完整的审计日志比单纯追求计算可重复更重要，因为审计日志能解释口径变更的原因。
3. 可重复性 > 自动化优先：如果自动化脚本存在 Bug 导致计算结果不可重复，应优先修复脚本逻辑，确保计算结果稳定后再上线自动化。

3.8 本章小结