线上故障复盘别光写检讨：用数据算清楚，这次事故到底伤了多深
作者：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%。
不过，这个公式更适合数值越低越好的指标。对于可用性、补偿完成率等数值越高越好的指标，应当采用相应的改善计算方式。
而且，单次演练的结果不代表未来一定会取得相同效果。我们还需要通过多次演练和真实事件持续验证。
复盘不是为了证明我们已经做了整改，而是为了证明系统真的比以前更不容易出问题了。
七、再往前走一步：让事件后分析形成自动化闭环
如果每次事故都靠人工从日志、监控平台、数据库和工单系统里复制数据，工作量会非常大，也容易遗漏信息。
所以，当团队具备一定基础后，可以考虑把事件后分析逐渐做成自动化流程。
一个比较实用的方案是：
通过告警系统生成统一的事件编号。
自动记录异常开始、发现、止损和恢复时间。
按事件时间窗口查询日志、指标和调用链。
根据请求 ID、订单号等标识统计受影响业务。
汇总受影响服务、失败请求和待补偿任务。
生成初步事件报告，由值班人员确认根因和业务影响。
将整改任务关联到事件编号，并跟踪验证结果。
在这里，AI 也可以发挥作用，但我不建议一上来就让 AI 自动判断根因并直接生成最终结论。
更稳妥的方式是先让程序完成确定性的数据统计，再让 AI 帮忙归纳异常时间线、整理日志特征、比较可能的根因，并给出需要进一步验证的假设。
例如，AI 可以提示：
“数据库连接等待时间在 14:01 开始上升，订单接口超时在 14:02 增加，建议检查该时间段的慢 SQL、连接池使用情况和批处理任务。”
但这只是待验证的分析线索，不是已经证实的根因。
最终结论仍然应该有证据支撑：什么指标异常了，什么日志对应上了，哪条调用链能够解释问题，哪些业务记录确实受到影响。
这也是我一直坚持的一个观点：AI 可以帮助我们更快地找到答案，但不能替我们跳过验证答案的过程。
写在最后
做运维这么多年，我越来越觉得，故障复盘最怕的不是技术不够复杂，而是把事情说清楚了，却没有真正搞清楚事情。
一份有价值的复盘报告，不应该只有“故障原因、处理过程、整改措施”这几个固定栏目。
它还应该告诉我们：故障到底影响了多少用户和业务，影响持续了多久，根因是如何传播的，哪些风险仍然存在，以及整改之后究竟改善了多少。
刚开始做事件后分析，不需要马上搭建复杂的平台。先把时间、错误率、受影响业务量和恢复完整度这几个基础指标统计准确，再逐步加入服务依赖分析、风险评分和整改效果验证，就已经能解决很多实际问题。
最后分享一个我认为很重要的判断标准：
如果一次事故复盘结束后，我们只能回答“发生了什么”，却无法回答“影响有多大、为什么会这样、下次能改善多少”，那么这次复盘还没有真正完成。
事故本身不一定能避免，但每一次事故，都应该帮助我们减少下一次事故的概率，缩短下一次故障的恢复时间。
这才是事件后分析真正的价值。
—— Echo_Wish
