解释“MTTR”与“MTTD”在 CouchDB 运维中的具体计算方式。 - 问题详情 - 创脉思

解读

国内互联网与金融企业在招聘 CouchDB 运维/DBA 时，常把 MTTR（平均修复时间）与 MTTD（平均检测时间）作为衡量 SRE 成熟度与 SLA 达标率的核心指标。面试官问“具体计算方式”，并非让你背诵公式，而是想确认两点：

你是否能把抽象指标落到 CouchDB 的真实故障生命周期；
你是否具备可落地的监控、日志、告警与复盘流程设计能力。
回答时必须给出可审计、可复现、可灰度的国内落地细节，例如使用阿里云 SLS、蓝鲸、夜莺或自研 Prometheus + Loki 方案，并说明如何区分“故障开始”“故障发现”“故障恢复”三个时间戳。

知识点

故障开始时间 T₀：CouchDB 写入返回 500 或连续 3 次心跳检测失败的时刻，以服务端 access log 或 erlang.log 第一条错误为准，避免客户端网络抖动造成误报。
故障发现时间 T₁：监控系统（如夜莺）触发 P1 告警并发送电话/飞书/钉钉通知的时刻，需扣除告警静默期与重复告警合并窗口，以第一条有效告警事件 ID 的时间戳为准。
故障恢复时间 T₂：CouchDB 集群返回 200 且连续 5 个探测周期（默认 30 s）无异常，以负载均衡或探针最后一次标记“健康”的时间戳为准。
MTTD = Σ(T₁ – T₀) / N，N 为考核周期内 P1 故障总数；MTTR = Σ(T₂ – T₁) / N。
国内合规要求：金融类业务需把以上时间戳落库到审计日志库（MySQL 或审计版 MongoDB），保存 ≥5 年，供等保测评与央行现场检查。
必须排除“计划内滚动重启”与“灰度发布”场景，否则会造成指标失真；做法是给节点打上** maintenance_mode=true 标签**，监控系统识别后自动剔除样本。

答案

在 CouchDB 运维体系中，MTTD 与 MTTR 的“具体计算方式”分三步落地：
第一步，统一时钟源。所有节点启用 NTP 并开启 123 端口出站策略，确保 T₀、T₁、T₂ 误差 <1 s，满足国内金融机房合规要求。
第二步，精确定义时间戳。

T₀ 取 erlang.log 中首次出现 {error,emfile} 或 OS Process Error 且持续 30 s 以上的最早时间；
T₁ 取夜莺告警中心第一条 P1 告警的 create_time，需扣除 2 min 的告警合并窗口；
T₂ 取黑盒探针（Consul HTTP check）连续 5 次返回 200 的最后一条 success_time。
第三步，周维度自动计算。通过离线调度跑 SQL：

SELECT
  DATE_FORMAT(create_date,'%x-%v') AS week,
  AVG(UNIX_TIMESTAMP(first_alert)-UNIX_TIMESTAMP(error_start)) AS avg_mttd,
  AVG(UNIX_TIMESTAMP(recover_time)-UNIX_TIMESTAMP(first_alert)) AS avg_mttr
FROM couchdb_incident
WHERE maintenance_flag=0
GROUP BY week;

结果同步到 Grafana，MTTD 目标 ≤5 min，MTTR 目标 ≤30 min，与 SLA 99.95% 对齐。若未达标，触发 5 Why 复盘并录入 Jira，复盘报告需经 SRE 主管与业务方双签才能关闭。

拓展思考

在多活架构（例如北京/上海双集群）中，若采用双向复制，需为每个集群独立计算 MTTR，再按“用户流量权重”加权平均，避免“上海集群故障但北京集群顶流量”导致指标被稀释。
当使用 CouchDB 3.x 的分区数据库时，单个分区宕机不一定会触发全集群告警，此时应把“分区不可用”定义为局部故障，单独设置 MTTR‐partition 指标，阈值可放宽到 60 min，但必须在故障报告中披露受影响的用户范围。
国内部分券商采用**“交易日零故障”政策，若 T₀ 落在 9:15–15:30 之间，即使 1 min 也算 P0，此时可把 MTTD 目标收紧到 ≤1 min，需在边缘节点部署本地哨兵进程**，实现毫秒级探测，避免网络延迟导致 T₁ 滞后。