On-Call与事后复盘：SRE的必修课

可视化演示

展示系统处理流水线、实时性能指标曲线及多方案对比分析，包含数据流转、吞吐延迟监控与方案评估。

值班排班轮换

急诊科护士台的白板上，永远贴着一张本周值班表。谁今晚当班，谁是备班，写得一清二楚。患者被推进来，护士不需要翻通讯录找“现在该联系谁”——值班医生的名字就在那里。On-Call 排班要解决的，正是同一个问题：系统故障随时可能发生，必须有一个明确的“当班医生”。

在 SRE 的语境里，On-Call 指的是工程师轮流担负“值班兜底”职责，7×24 小时覆盖线上系统。排班不是随便拉个名字填上去，它有自己的原则：轮换要公平，不能总让同一个人接深夜的电话；技能要匹配，支付系统故障不能只派一个前端工程师去扛；还要有主备双岗，Primary 是第一响应人，Secondary 负责在他失联时代为接警，避免“一个人的假期毁掉整个备份计划”。

有了值班表，还要把“谁能做什么”划清楚。一线值班工程师拥有处置权，可以按照既定手册执行重启、降级、回滚操作，但没有权限在深更半夜临时改架构。遇到搞不定的问题时，走升级路径：一线 → 二线专家 → 技术负责人 → 管理层，每一级都有明确的响应时限。团队通常会给值班响应定 SLA（服务等级目标），比如 15 分钟内必须接警确认。

一张好的值班表，让系统永远处于“有人管”的状态，就像急诊室永远有医生在。它不是行政表格，而是整个可靠性体系的地基——地基没打牢，后面的一切告警治理、手册、复盘都是空中楼阁。

告警治理分诊

急诊科的分诊护士是全院最忙的人。患者涌进来，她必须在几秒内判断：这个是心梗，红色标签，立刻抢救；那个是擦伤，绿色标签，先去排队。如果没有这道分诊，所有患者挤作一团，真正的危重病人反而会被耽误。告警系统就是系统的“分诊台”，而 SRE 团队每天最重要的功课之一，就是让每条告警都像分诊标签一样清晰、分级、可行动。

业界常见的做法是把告警分成 P0、P1、P2 等级。P0 意味着核心业务完全不可用，比如所有用户都无法下单，必须立刻唤醒值班工程师；P1 是部分功能受损，比如某个接口延迟飙升但业务还在跑；P2 则是不影响用户的隐患，可以等到第二天上班再处理。分级的意义在于：不是所有告警都配得上凌晨三点的电话。

但光有分级还不够，告警治理还要做三件事。第一是去重：同一台机器的磁盘故障，往往触发十几条关联告警，需要按根因合并成一条。第二是聚合：把短时间内同一服务的一堆相似告警打包成一个“事件”，值班工程师只需处理一张工单。第三是定“可行动标准”：一条合格的告警，必须能直接对应一个处置动作。如果收到告警后工程师只会想“哦，知道了”然后关掉它，这条告警就是噪声，应该被删掉。判断分诊做得好不好，可以用准确率来度量：

分诊台的价值，是让医生的注意力流向真正需要的地方。告警治理的终极目标同样是“让值班工程师被有意义的告警唤醒”。如果告警天天狼来了，真正的大故障来临时，值班工程师反而会麻木无视——那才是比故障本身更大的灾难。

值班手册

医院的抢救室墙上，永远挂着心肺复苏流程图。哪怕是最资深的医生，在慌乱中也会下意识地看一眼：先判断意识，再开放气道，然后胸外按压。这张图不依赖任何人的记忆，它是整个科室沉淀下来的“标准动作”。SRE 团队里的值班手册（Runbook），就是贴在系统旁边的抢救流程图。

手册的核心定位是：把处理已知故障的最佳路径写成文档，让值班工程师在困意浓重的凌晨也能照着做。它通常包含四段式结构：症状识别——“支付接口 P95 延迟超过 2 秒”；排查步骤——“先查数据库连接池，再查下游依赖”；处置动作——“重启连接池、摘除异常节点”；升级条件——“如果 10 分钟内未恢复，呼叫二线”。每一步都写清楚“做什么、怎么做、做到什么程度算完”。

优秀的手册背后，是一个持续维护的故障场景库。磁盘写满、证书过期、连接池耗尽、模型推理漂移——凡是发生过的故障，都应沉淀为一条场景文档。复盘会更新手册，季度演练验证手册，版本管理记录手册变更。手册要的就是“哪怕换了个新人值班，他也能靠手册稳住局面”。为什么手册这么重要？因为它直接压缩故障恢复中最不可控的定位阶段：

手册把“老师傅的经验”变成了科室的公共资产。一个经验丰富的工程师离开，手册还在，新人就不会从头开始摸黑。值班手册不是摆设，它是整个团队用一次次故障换来的“抢救流程图”，值得像对待代码一样对待它。

事后复盘文化

医院里最严肃的会议，是死亡病例讨论会。特别之处在于，开场前主持人会先强调一条铁律：今天不追究某个医生的责任，我们只讨论系统。手术流程是否有漏洞？术前检查是否缺了环节？设备维护是否到位？因为大家心里都清楚，如果今天把责任推给某一个医生，明天就没人敢如实描述自己犯过的错。

SRE 的复盘文化，正是从这种“无指责”原则生长出来的，英文叫 Blameless Postmortem。复盘不是批斗会，而是“系统的病例讨论会”。它要还原三样东西：时间线——故障从发生到恢复的每一分钟发生了什么；影响面——多少用户受影响、损失了多少交易；根因——到底是哪一层设计缺陷让这次故障成为可能。复盘的参与者只有一个共同目标：让下一次故障不要以同样的方式发生。

实操中，团队最常用的工具是“5 Whys“：连续追问五个”为什么“，从表象一路挖到系统根因。比如”数据库连不上”→“为什么连不上？连接池耗尽”→“为什么耗尽？突发流量”→“为什么突发流量击穿连接池？没有限流”→“为什么没有限流？架构评审漏掉了这个场景”。追问到第五层，你会发现：几乎所有事故的根因，都不是某个人的手滑，而是流程、架构或制度里的某个空洞。

如果复盘的结论是“工程师小明操作失误”，那这个复盘是失败的，因为开除小明，下一个工程师还会在同样的流程漏洞前跌倒。真正无指责的复盘文化，是把矛头从人身上移开，对准系统本身——这样团队才敢说真话，故障真相才不会被掩埋。

复盘报告撰写

一份规范的病历，从“主诉、现病史、查体、辅助检查”开始写起，任何一个医生拿到手，三分钟就能了解病人的来龙去脉。复盘报告（Postmortem）就是系统的“病历”，它的作用不只是记录，更是让下一次处理故障的人站在前人的肩膀上。

一份合格的复盘报告，结构是固定的，大致包含六个部分：标题（一句话说清是什么故障）、影响摘要（多长时间、多大范围、多少损失）、时间线（精确到分钟的关键事件）、根因分析（对应第 4 节的因果链）、行动项（每条都有负责人和截止日）、附录（监控截图、日志链接等证据）。结构固定的最大好处是：任何人打开报告，都能按同样的路径快速定位自己想看的部分。

写报告时，有两个特别容易犯的错。一是把事实和推断混在一起——“可能是缓存没刷新”和“02:31 缓存过期导致 502”是两回事，事实要写“是什么”，推断要标注“我猜测”。二是措辞带指责性——“工程师没有配置超时”这句话里藏着个人归因，不如写成“系统未对下游请求配置超时”。中性用词让读者把注意力放在系统缺陷上，而不是寻找责任人。报告写完后要共享到团队知识库，可检索、可评论。在复盘中，证据比结论更重要，怀疑可以用公式来表达——报告里对每个根因判断都可以标注信心程度：如果观察到新证据，我们对某个根因的信心应该更新：

一份好病历，能让下一位医生少走弯路；一份好报告，能让下一次故障的 MTTR 缩短一半。写复盘报告不是走流程、交作业，而是用文字把事故的教训冻存起来，让它在未来反复给团队输送经验。

改进行动跟踪

医生开了药，一定会叮嘱病人：“一周后来复查。”如果只开药不复查，医生永远不知道药有没有效，病情有没有变化。复盘会开完、报告发出去，只是“开了药”，更关键的是跟踪行动项有没有真正落地——这是绝大多数团队最薄弱的一环。

复盘产生的行动项，通常可以分成三类。修复类：立刻要做的，比如“重启数据库、恢复备份”；预防类：中期要做的，比如“为连接池添加水位告警”；研究类：需要进一步调研的，比如“评估自动扩容方案是否可行”。分类之后，每个行动项必须遵循三条铁律：责任到人（写清“谁”负责，而不是“团队”负责）、明确截止时间（具体到日期，而不是“尽快”）、可验证（定义“什么状态算完成”）。

跟踪机制通常落在看板上：待办、进行中、已验证三列。每周的 SRE 例会上，第一件事就是过一遍行动项看板，而不是讨论新点子。更严格的团队还会做效果验证：同类故障在接下来的三个月内有没有复发？某个行动项上线后，相关告警数量是否下降？如果行动项变成了一纸空文，复盘就退化成了“大型情绪安慰现场”。要度量行动的闭环程度，可以用一个简单的公式：

复盘会开得再热闹，如果一个月后行动项一个都没动，那就是一次彻底的浪费。就像处方必须吃到疗程结束，复盘的终点不是报告发布，而是改进真正改变了系统。只有跟踪到位的复盘，才配叫闭环。

疲劳风险管控

医院有一条不成文的规矩：连续值班超过一定时长，医生必须离岗休息。因为疲惫的医生，手会抖，判断会迟钝，一个微小的疏忽可能直接要了患者的命。SRE 值班也一样——凌晨 4 点被叫醒的工程师，犯错概率远高于白天精神饱满时。过度疲劳不仅威胁线上系统，还会快速烧光工程师的激情，导致团队人才流失。

疲劳的危害常常被低估。连续几天的 On-Call，工程师会陷入“白天写代码，晚上被警醒”的状态，注意力碎片化，甚至产生焦虑。研究睡眠剥夺的文献显示：连续清醒 24 小时后，人的认知能力相当于血液酒精浓度 0.1% 的状态——几乎是酒后开车。为此，成熟的 SRE 团队会制定硬性制度：单次值班不超过 12 小时；夜间接警后第二天可以晚到或补休；每人每周 On-Call 的天数设上限；值班后强制安排“恢复时间”。

除了硬性的疲劳限制，轮换制度也很重要。值班不能总是老面孔，要让新人定期上手、老人在旁护航；激励补偿要跟上，值班津贴、调休、公开认可，让承担压力的人得到回报。比这些更底层的是心理安全：值班时犯了错，不会被羞辱、不会进绩效黑名单，这样的人才会在复盘中如实说出“我当时漏看了一个指标”，而不是找借口掩饰。疲劳带来的失误风险，可以用一个经验模型来理解：

一个系统的可靠性，终究由人来守护。而疲惫的守护者本身就是最大的漏洞。保护值班的人，就是在保护系统本身——这听起来像一句口号，但它是 SRE 团队用无数个失眠的夜晚换来的血泪教训。

AI 应用场景

Python 演示

# -*- coding: utf-8 -*-"""从事件时间线生成复盘报告,并输出需要跟踪的行动项."""from datetime import datetime EVENTS = [    ("2025-01-06 02:31:00", "detect", "告警:支付API P95延迟超过2秒"),    ("2025-01-06 02:33:00", "ack",    "值班工程师接警,开始排查"),    ("2025-01-06 02:50:00", "diag",   "定位到数据库连接池耗尽"),    ("2025-01-06 03:05:00", "fix",    "重启连接池并扩容,服务恢复"),] def fmt_time(ts):    return datetime.strptime(ts, "%Y-%m-%d %H:%M:%S") def build_timeline(events):    rows = [{"time": fmt_time(ts), "kind": kind, "desc": desc}            for ts, kind, desc in events]    rows.sort(key=lambda r: r["time"])    return rows def calc_mttr(rows):    start, end = rows[0]["time"], rows[-1]["time"]    return (end - start).total_seconds() / 60.0 def suggest_actions(rows):    actions = []    for r in rows:        if r["kind"] == "diag":            actions.append("为连接池增加水位告警,并写入值班手册")        elif r["kind"] == "fix":            actions.append("评估连接池自动扩容方案,标记负责人")    return actions def render_report(rows):    lines = ["# 复盘报告: 支付API延迟故障", ""]    for r in rows:        lines.append("- {} [{}] {}".format(            r["time"].strftime("%H:%M"), r["kind"], r["desc"]))    lines.append("")    lines.append("MTTR: {:.1f} 分钟".format(calc_mttr(rows)))    lines.append("")    lines.append("## 行动项")    for act in suggest_actions(rows):        lines.append("- [ ] " + act)    return "\n".join(lines) def main():    rows = build_timeline(EVENTS)    print(render_report(rows)) if __name__ == "__main__":    main()

1. rows.sort(key=lambda r: r["time"])把所有事件按时间排序，确保复盘时间线真实可靠。
2. return (end - start).total_seconds() / 60.0用最后一个事件减去第一个事件的时间差，换算成分钟，算出 MTTR。
3. if r["kind"] == "diag":定位阶段的信息最能反映系统缺陷，所以从这里提炼预防类行动项。
4. lines.append("- [ ] " + act)用 Markdown 的未勾选复选框 - [ ] 标记每个行动项，方便导入看板跟踪。
5. if __name__ == "__main__":让脚本既能被其他模块导入复用，又能直接运行输出报告。

常见误区

面试题