线上故障复盘别光写检讨：用数据算清楚，这次事故到底伤了多深

作者：Echo_Wish

做运维久了，你会发现一件挺有意思的事：线上出故障的时候，所有人都很忙；等故障恢复了，所有人又都很忙着写复盘报告。

报告里通常少不了几个经典问题：故障原因是什么？影响了哪些服务？持续了多长时间？后续怎么避免？

这些问题当然都得回答，但我一直觉得，很多故障复盘最大的问题，不是没有结论，而是结论太笼统，影响靠估算，整改凭感觉。

比如，一次数据库连接池耗尽，导致部分接口请求失败。复盘报告最后写着：

• 故障持续 15 分钟。

• 部分用户受到影响。

• 根因是数据库连接池配置不合理。

• 后续优化连接池参数，加强监控。

看起来挺完整，对吧？

但仔细想想，还有一堆关键问题没回答：到底有多少请求失败？有多少用户受到影响？哪些业务受损最严重？故障恢复后，积压任务有没有处理完？这次修改连接池参数，究竟能降低多少风险？

如果这些问题答不上来，那么这份复盘报告很可能只是把事故经过重新描述了一遍，并没有真正量化事故。

今天咱们就聊聊一个很实用的运维话题：事件后分析，如何通过量化方法评估根因和影响？

重点不是为了凑一堆漂亮的数据，而是让每一次故障都能留下可验证、可追踪、可改进的结论。

一、先搞明白：故障恢复了，不代表事故结束了

先说一个常见场景。

某天下午，订单服务突然出现大量超时。运维排查后发现，数据库连接池被占满，重启服务后，接口逐渐恢复正常。

从监控上看，错误率已经回到正常水平，大家松了一口气。

但业务部门很快反馈：有些用户重复提交了订单，有些订单没有及时生成，还有部分消息一直积压在队列里。

这就说明一个问题：服务恢复，只能证明当前故障症状消失了，不能证明故障造成的影响已经消除。

在事件后分析中，我建议至少把影响拆成四个维度。

这四个维度不能互相替代。

例如，两个故障都持续了 10 分钟，一个只影响内部测试接口，另一个影响支付接口。虽然持续时间相同，但业务影响可能完全不在一个量级。

同样，两个故障都产生了 1000 次失败请求，如果一个接口每秒处理 10 次请求，另一个每秒处理 5000 次请求，那么这两个故障的严重程度也不一样。

因此，复盘的第一步不是急着写根因，而是先把故障的影响范围和程度算清楚。

二、根因影响评估，先从四个数字开始

我认为，刚开始做量化分析，不必上来就引入复杂的机器学习模型。把几个基本指标计算准确，往往比堆一套复杂算法更有价值。

1. 故障持续时间：别只记录发现时间

假设：

• 14:02，监控首次发现接口错误率异常。

• 14:05，运维确认发生故障。

• 14:17，接口错误率恢复正常。

这里至少存在三个不同的时间概念。

故障持续时间可以按实际受影响区间计算，即 14:02 到 14:17，共 15 分钟。

发现延迟是异常开始到监控发现的时间。如果实际异常在 13:58 就开始，那么发现延迟是 4 分钟。

恢复耗时则可以进一步拆成确认、定位、止损、恢复等阶段。

为什么要拆这么细？

因为不同阶段对应不同的改进方向。

发现太晚，说明监控或告警存在问题；定位太慢，说明排障能力或可观测性不足；止损太慢，可能意味着缺少限流、熔断或降级机制。

如果复盘只写一句“故障持续 15 分钟”，就很难知道下一步应该优化什么。

2. 错误率：用比例判断实际冲击

假设某个接口在 15 分钟内总共接收了 30,000 次请求，其中 1,200 次失败。

那么故障期间的请求失败率为：

错误率=失败请求数总请求数×100%错误率=\frac{失败请求数}{总请求数}\times100%错误率=总请求数失败请求数×100%

代入数据：

120030000×100%=4%\frac{1200}{30000}\times100%=4%300001200×100%=4%

4% 看起来好像不算特别高，但还不能直接判断事故有多严重。

如果正常情况下错误率只有 0.1%，那么 4% 已经是正常水平的 40 倍。

这里需要注意：倍数必须结合基线理解，不能单独拿来当严重程度。 当正常错误率接近零时，倍数甚至可能失去解释意义。

更合理的做法，是同时记录故障期间错误率、正常基线和绝对失败请求数。

3. 业务影响量：技术指标最终要落到业务上

继续拿订单服务举例。

假设 1200 次失败请求中：

• 800 次是查询订单失败。

• 250 次是提交订单失败。

• 150 次是订单状态更新失败。

这三类失败的业务后果明显不同。

查询失败，可能主要影响用户体验；提交订单失败，可能直接影响交易转化；状态更新失败，则可能造成订单状态不一致。

这里不能简单地把 1200 次失败全部等同于 1200 笔损失订单。

因为一次业务操作可能重试多次，同一笔订单也可能对应多次 HTTP 请求。

正确做法是结合订单号、请求 ID、幂等键等业务标识进行去重，并区分：

• 请求失败次数。

• 去重后的受影响业务单数。

• 最终确认未完成的业务单数。

• 已通过重试或补偿恢复的业务单数。

只有把这几个数字分开，才能避免把技术请求量误当成真实业务损失。

4. 恢复完整度：别让遗留问题藏在故障之后

服务恢复后，还要继续检查消息队列积压、失败任务、数据一致性和补偿结果。

例如，故障期间产生了 500 条待处理消息，恢复后成功处理 450 条，剩下 50 条仍在重试。

此时，如果只看接口监控，可能已经一切正常，但业务链路显然还没有完全恢复。

我们可以定义一个简单的补偿完成率：

补偿完成率=已完成补偿数量需要补偿总数量×100%补偿完成率=\frac{已完成补偿数量}{需要补偿总数量}\times100%补偿完成率=需要补偿总数量已完成补偿数量×100%

本例中，完成率是 90%。

不过，这个指标也有边界：如果 50 条遗留消息的重要程度远高于已经处理的 450 条，单看 90% 仍然会误导判断。

因此，实际复盘还要关注剩余任务的业务价值、超时情况和处理时限。数量指标负责告诉我们“还有多少”，业务规则负责判断“剩下的有多严重”。

三、用 Python 把事故数据算出来，别让复盘停留在口头描述

既然我们已经明确了评估维度，就可以写一个简单的分析脚本，把故障期间的关键指标统一计算出来。

下面用一个订单服务故障案例进行演示。

Python

執行

from datetime import datetime

incident = {
    "detected_at": "2026-10-13 14:02:00",
    "recovered_at": "2026-10-13 14:17:00",
    "total_requests": 30000,
    "failed_requests": 1200,
    "affected_orders": 320,
    "pending_tasks": 500,
    "completed_tasks": 450,
}

# 1. 计算故障持续时间
start = datetime.strptime(
    incident["detected_at"], "%Y-%m-%d %H:%M:%S"
)
end = datetime.strptime(
    incident["recovered_at"], "%Y-%m-%d %H:%M:%S"
)

duration_minutes = (end - start).total_seconds() / 60

# 2. 计算请求错误率
total = incident["total_requests"]
failed = incident["failed_requests"]

error_rate = failed / total if total else 0

# 3. 计算补偿完成率
pending = incident["pending_tasks"]
completed = incident["completed_tasks"]

recovery_rate = completed / pending if pending else 1

# 4. 输出量化结果
print(f"故障持续时间：{duration_minutes:.1f} 分钟")
print(f"请求失败率：{error_rate:.2%}")
print(f"受影响订单数：{incident['affected_orders']}")
print(f"补偿完成率：{recovery_rate:.2%}")
print(f"剩余待处理任务：{pending - completed}")

这里有个细节值得注意：示例中的开始时间取的是监控发现时间，而不是经过证据确认的真实故障起始时间。

这意味着，计算结果是“从发现到恢复的时间”，不一定是完整的实际影响时长。

生产环境中，建议把 incident_start_at、detected_at、mitigated_at 和 recovered_at 分开记录，避免把不同阶段混为一谈。

另外，代码里的 affected_orders 应当来自去重后的业务数据，而不是直接把失败请求数量填进去。

脚本本身并不复杂，真正重要的是数据口径一致。否则，代码算得越精确，结果反而越容易误导人。

四、找到根因之后，还得算清楚它影响了多少系统

很多事故复盘写到根因分析时，就开始出现这样的结论：

“由于数据库连接池配置不足，导致订单服务请求超时。”

这句话可能没错，但还不够。

我们还要回答：连接池问题为什么会影响订单服务？订单服务又会不会影响支付、库存、消息通知等其他系统？

这就涉及根因的传播路径。

假设某个业务系统存在以下依赖关系：

数据库连接池耗尽

直接故障源

订单服务超时

直接受影响服务

库存处理延迟

订单通知延迟

注意，这是一种假设的依赖关系，实际影响必须通过调用链、日志、消息记录和业务数据验证，不能因为两个服务存在调用关系，就认定它们一定受到影响。

我建议给每次事故建立一份受影响服务清单，至少包含服务名称、依赖关系、异常时间段、失败请求量、业务影响和证据来源。

然后根据实际调用链，逐层确认影响范围。

例如，可以统计每个服务的错误率变化：

Python

執行

services = [
    {
        "name": "order-service",
        "total": 10000,
        "failed": 800,
    },
    {
        "name": "inventory-service",
        "total": 5000,
        "failed": 200,
    },
    {
        "name": "notification-service",
        "total": 3000,
        "failed": 60,
    },
]

for service in services:
    total = service["total"]
    failed = service["failed"]

    error_rate = failed / total if total else 0

    print(
        f"{service['name']}: "
        f"失败 {failed} 次，"
        f"错误率 {error_rate:.2%}"
    )

有了这些数据，我们才能判断故障是局部问题，还是已经沿着依赖链扩散。

进一步还可以比较各服务的正常基线与故障期间指标，识别异常传播的时间顺序，帮助定位真正的故障源头。

但要提醒一句：最先出现异常的服务，不一定就是根因所在。

比如，订单服务最先报错，可能只是因为数据库先发生了性能抖动，而数据库异常又来自某条慢 SQL 或突增的批处理任务。

因此，根因分析不能只看谁先报警，还要结合时间线、调用链和底层资源指标，找到能够解释整条异常链路的原因。

五、给根因做量化评估：别把“看起来严重”当成结论

影响范围弄清楚之后，接下来还有一个实际问题：如果根因不止一个，应该优先处理哪个？

比如：

• 数据库连接池配置不合理。

• 某条 SQL 缺少合适的索引。

• 服务没有设置合理的超时和熔断。

• 告警发现异常太晚。

这些问题都值得改，但团队资源有限，不可能一天全部解决。

这时候，可以尝试给根因建立一个简单的风险评分模型。

我比较推荐从四个维度入手：

如果希望得到一个可用于排序的初始模型，可以把每个维度按 1～5 分打分，再设置权重。

例如：

Python

執行

weights = {
    "scope": 0.25,       # 影响范围
    "severity": 0.35,    # 业务严重性
    "likelihood": 0.25,  # 再次发生可能性
    "recovery": 0.15,    # 检测与恢复难度
}

root_causes = [
    {
        "name": "数据库连接池耗尽",
        "scope": 5,
        "severity": 5,
        "likelihood": 4,
        "recovery": 4,
    },
    {
        "name": "告警发现延迟",
        "scope": 3,
        "severity": 3,
        "likelihood": 4,
        "recovery": 3,
    },
]

for item in root_causes:
    score = sum(
        item[key] * weight
        for key, weight in weights.items()
    )

    item["score"] = round(score, 2)

for item in sorted(
    root_causes,
    key=lambda x: x["score"],
    reverse=True,
):
    print(f"{item['name']}：{item['score']} 分")

这段代码的作用不是给事故定罪，而是帮助团队建立统一的讨论标准。

这里的权重只是演示值，不是什么行业标准。不同业务需要不同的权重，涉及数据丢失、资金安全或生产停线的场景，还应设置不可被普通加权分数抵消的硬性风险规则。

此外，这个评分模型适合初步排序，不应直接拿来代表事故损失金额，更不能用它替代专业的故障等级判定。

为什么我强调这一点？

因为量化的意义不是把主观判断包装成一个小数点后两位的结果，而是让团队知道自己依据什么做决定。

如果每次评分都没有明确标准，只是几个人坐在会议室里随便打分，那么最后得到的 4.35 分和 3.70 分，并不会比“我觉得这个问题更严重”高明多少。

六、真正有价值的复盘，不是追着根因问责，而是评估整改效果

这是我觉得整个事件后分析里最容易被忽略的一部分。

事故发生后，团队往往会提出一长串整改措施：

• 优化数据库连接池。

• 增加慢 SQL 监控。

• 调整接口超时时间。

• 增加告警规则。

• 完善应急预案。

这些措施听起来都合理，但如果没有验证标准，几周之后就可能变成一份无人追踪的待办清单。

所以，每项整改都应该有一个可以验证的目标。

举个例子。

假设此次故障中，监控发现异常比实际故障开始晚了 4 分钟。团队决定增加一条针对连接池使用率和请求超时率的联合告警。

那么整改目标就不应该只是“已增加告警规则”，而可以进一步定义为：

• 在模拟故障中，告警能够在约定时间内触发。

• 告警信息包含受影响服务、异常指标和排查入口。

• 值班人员能够根据告警定位到相关资源。

• 在后续演练中，验证从异常发生到确认故障的耗时是否下降。

同样，数据库连接池优化也不能只看参数有没有调整，而应该观察压测条件下的连接池等待时间、请求延迟、错误率和数据库资源消耗。

这里要注意，前后指标必须尽可能保持相同的测试负载、采样口径和统计窗口，否则即使数字变好了，也不一定是整改真正发挥了作用。

我们甚至可以用一个简单的指标衡量整改效果：

改善率=整改前指标−整改后指标整改前指标×100%改善率=\frac{整改前指标-整改后指标}{整改前指标}\times100%改善率=整改前指标整改前指标−整改后指标×100%

假设同等条件下，故障恢复耗时从 20 分钟下降到 12 分钟，那么恢复耗时改善率为 40%。

不过，这个公式更适合数值越低越好的指标。对于可用性、补偿完成率等数值越高越好的指标，应当采用相应的改善计算方式。

而且，单次演练的结果不代表未来一定会取得相同效果。我们还需要通过多次演练和真实事件持续验证。

复盘不是为了证明我们已经做了整改，而是为了证明系统真的比以前更不容易出问题了。

七、再往前走一步：让事件后分析形成自动化闭环

如果每次事故都靠人工从日志、监控平台、数据库和工单系统里复制数据，工作量会非常大，也容易遗漏信息。

所以，当团队具备一定基础后，可以考虑把事件后分析逐渐做成自动化流程。

一个比较实用的方案是：

1. 通过告警系统生成统一的事件编号。

2. 自动记录异常开始、发现、止损和恢复时间。

3. 按事件时间窗口查询日志、指标和调用链。

4. 根据请求 ID、订单号等标识统计受影响业务。

5. 汇总受影响服务、失败请求和待补偿任务。

6. 生成初步事件报告，由值班人员确认根因和业务影响。

7. 将整改任务关联到事件编号，并跟踪验证结果。

在这里，AI 也可以发挥作用，但我不建议一上来就让 AI 自动判断根因并直接生成最终结论。

更稳妥的方式是先让程序完成确定性的数据统计，再让 AI 帮忙归纳异常时间线、整理日志特征、比较可能的根因，并给出需要进一步验证的假设。

例如，AI 可以提示：

“数据库连接等待时间在 14:01 开始上升，订单接口超时在 14:02 增加，建议检查该时间段的慢 SQL、连接池使用情况和批处理任务。”

但这只是待验证的分析线索，不是已经证实的根因。

最终结论仍然应该有证据支撑：什么指标异常了，什么日志对应上了，哪条调用链能够解释问题，哪些业务记录确实受到影响。

这也是我一直坚持的一个观点：AI 可以帮助我们更快地找到答案，但不能替我们跳过验证答案的过程。

写在最后

做运维这么多年，我越来越觉得，故障复盘最怕的不是技术不够复杂，而是把事情说清楚了，却没有真正搞清楚事情。

一份有价值的复盘报告，不应该只有“故障原因、处理过程、整改措施”这几个固定栏目。

它还应该告诉我们：故障到底影响了多少用户和业务，影响持续了多久，根因是如何传播的，哪些风险仍然存在，以及整改之后究竟改善了多少。

刚开始做事件后分析，不需要马上搭建复杂的平台。先把时间、错误率、受影响业务量和恢复完整度这几个基础指标统计准确，再逐步加入服务依赖分析、风险评分和整改效果验证，就已经能解决很多实际问题。

最后分享一个我认为很重要的判断标准：

如果一次事故复盘结束后，我们只能回答“发生了什么”，却无法回答“影响有多大、为什么会这样、下次能改善多少”，那么这次复盘还没有真正完成。

事故本身不一定能避免，但每一次事故，都应该帮助我们减少下一次事故的概率，缩短下一次故障的恢复时间。

这才是事件后分析真正的价值。

—— Echo_Wish