WEBKT

从"救火"到"防火"：用睡眠中断频率构建团队 burnout 预警系统

7 0 0 0

告警疲劳的隐性成本：为什么 MTTR 掩盖了真相

在可观测性建设中，我们精通计算服务的可用性指标，却鲜少量化人的可用性。当 PagerDuty 的告警在凌晨 3 点第四次响起时，我们记录的是 incident 的解决时长，却忽略了工程师睡眠结构的碎片化对认知能力的长期侵蚀。

传统 SRE 指标（MTTR/MTTF）只衡量系统恢复速度，属于事后补救型度量。要建立 burnout 预警模型，我们需要引入前置性健康指标——将"睡眠中断频率"作为团队可持续性的核心信号。

核心指标定义：夜间告警率 (NAR) 与睡眠碎片化指数 (SFI)

1. 夜间告警率 (Nighttime Alert Rate)

定义为工作日 23:00-07:00 期间，人均每周接收的需人工介入的告警数量：

NAR = (NightAlerts × SeverityWeight) / (OnCallEngineers × 7days)

SeverityWeight: P1=1.0, P2=0.6, P3=0.2（仅计算 P1/P2 级别）

2. 睡眠碎片化指数 (Sleep Fragmentation Index)

通过智能手表/手环 API（如 Apple HealthKit、Fitbit Web API）获取睡眠阶段数据：

SFI = (AwakeCount × MeanAwakeDuration) / TotalSleepTime

健康阈值参考：

  • 🟢 SFI < 0.15：恢复性睡眠
  • 🟡 0.15 ≤ SFI < 0.30：轻度碎片化，认知能力下降 15-20%
  • 🔴 SFI ≥ 0.30：深度睡眠缺失，决策失误率显著上升

团队健康度衰减模型：从指数衰减到恢复函数

将团队健康度建模为随时间变化的动态系统，受损耗项（告警中断）和恢复项（休息/睡眠）共同影响：

H(t) = H₀ × e^(-λt) + Σ(Recoveryᵢ × e^(-(t-tᵢ)/τ))

参数说明：

  • H₀: 初始健康基线（标准化为 100）
  • λ: 衰减系数，与 NAR 正相关：λ = 0.05 × NAR_weekly
  • Recoveryᵢ: 第 i 次充分休息（连续 48h 无告警 + 睡眠时长 > 7h）带来的恢复量
  • τ: 恢复衰减时间常数（通常取 3-5 天）

Burnout 风险指数 (BRI) 计算

当健康度持续低于阈值，触发 burnout 风险累积：

BRI(t) = ∫[H_threshold - H(t)]⁺ dt / T_window
  • 黄色预警：BRI > 20（持续 1 周健康度 < 70）
  • 橙色预警：BRI > 50 或连续 3 天 SFI > 0.30
  • 红色预警：BRI > 80，强制下线干预

工程化落地：构建健康度观测 Pipeline

数据采集层

告警数据源：

# Prometheus Recording Rule
- record: sre:nighttime_alerts:rate1w
  expr: |
    sum by (engineer) (
      increase(pagerduty_incidents_total{
        severity=~"P1|P2",
        hour_of_day>=23 or hour_of_day<7
      }[1w])
    )

睡眠数据接入：
通过 Oura Ring、Whoop 或 Apple Health 的 OAuth 授权，将睡眠数据脱敏后汇入时序数据库（建议单独部署 VictoriaMetrics 实例，避免与生产监控混用）。

预警决策层

使用 Prometheus Alertmanager 的 custom webhook 集成健康度计算服务：

# 伪代码：健康度计算服务
def calculate_team_health(team_id):
    nar = query_prometheus(f"sre:nighttime_alerts:rate1w{{team='{team_id}'}}")
    sfi = query_health_api(team_id)
    
    # 计算衰减
    lambda_decay = 0.05 * nar
    current_health = BASELINE * math.exp(-lambda_decay)
    
    # 检查干预记录
    last_recovery = get_last_recovery_date(team_id)
    if (now - last_recovery).days >= 2:
        current_health *= 0.8  # 连续工作衰减
        
    return current_health, sfi

可视化与干预

在 Grafana 构建团队健康度仪表盘：

  • 热力图：展示每人每周 NAR 分布
  • 趋势图：H(t) 衰减曲线与 BRI 累积线
  • 干预看板：自动生成的 on-call 轮换建议（基于健康度动态调整）

从预警到干预：动态 on-call 机制

当系统检测到工程师进入黄色预警区，自动触发以下策略：

  1. 强制冷却期：连续 72h 移除 on-call 排班，即使团队人手紧张
  2. 认知卸载：将告警路由至 secondary on-call，仅保留 shadow 模式（观察但不处理）
  3. 根因加速：触发"告警降噪"专项，要求 48h 内将误报率降低 50%

关键原则：预警系统的价值不在于预测 burnout，而在于强制中断 burnout 的累积进程。

实施路线图

阶段 周期 关键动作 成功指标
Phase 1 2周 接入 PagerDuty/Opsgenie API，计算 NAR 基线 获得 4 周历史 NAR 数据
Phase 2 4周 接入 50% 工程师睡眠数据，建立 SFI 关联模型 NAR 与 SFI 相关系数 > 0.6
Phase 3 持续 上线 BRI 自动计算与动态排班系统 Burnout 主动离职率下降 30%

伦理与隐私边界

采集生理数据必须遵循最小可用原则：

  • 仅存储 SFI 计算后的聚合值，不保留原始睡眠阶段明细
  • 健康度数据仅限工程师本人及直属 TL 可见，HR 仅接收匿名化趋势报告
  • 提供"隐私模式"选项，允许工程师关闭睡眠数据采集（此时仅依赖 NAR 推算健康度）

** burnout 不是个人意志力的问题，而是系统设计的失败。** 当我们开始用观测系统的思维观测团队本身，才能真正实现"可持续的可靠性工程"。

你的团队上周的 NAR 是多少？是否已经开始记录睡眠碎片化数据？欢迎在评论区分享你们的实践。

运维观察员 告警疲劳SRE团队健康

评论点评