返回第十一卷 · 事件响应：11.10 · 级联故障：11.09 · SLO：11.08 · 技术写作：10.11

11.11 复盘与改进：一次 IM 补拉迟到后怎样减少复发

DeepTutor 八节初稿经技术与教学审阅后的静态课程。事件、指标、角色、改进行动及验证计划均为脱敏纸上演练，没有真实事故、Go/IM/数据库/监控运行、故障注入、外发沟通或站点构建。当前 S2 /v1 仍是正文非空且最多 6 UTF-8 B、原始 HTTP 请求正文最多 4096 B、同 ID 重复 409、非成员目标隐藏 404、200 accepted_in_memory 仅为本进程内存受理；未来 S3 /v2 的 stored_in_teaching_db 是提议且仍为 6 B，R9 6→9 B 待审。09.02 当前合同

一、复盘的目标是减少下一次用户损害

11.10 的纸上事件响应已让 B 的一台设备从有权历史补到 c-a/m-9/seq9，但这只说明该设备的恢复门在演练中通过。其他设备范围、最早受影响时刻以及最初让历史查询变慢的原因，仍未完全查明。事件结束与学习完成是两件事：复盘要说明用户影响、已知时间线、促成因素、哪些防线有用或失效，以及下一次怎样验证改进。它不能把未知补成一个听起来完整的“根因故事”。11.10 恢复与未知

无责备复盘不是不讨论人的操作；它要问当时的人看到了什么、工具给了什么选项、系统允许什么失败路径，再设计让下一位工程师更容易做对的防线。把“值班人太慢”写成原因，无法解释为什么慢依赖、两层重试和缺口观测能同时存在；把所有问题归于“数据库坏了”也会遗漏放大机制。Google SRE 的复盘指南强调贡献因素、用户影响、可追踪行动以及不把个人当作故障根因。Google SRE：Postmortem Culture · Workbook：Postmortem Culture

本章与 10.11 的技术写作、11.10 的实时响应形成递进：10.11 教文档要让后来者可复核；11.10 教事件期间谁做什么；现在审阅应急之后的因果和改进收益。所有纸上数字只用于推理，不作为本仓库或 OpenIM 的真实可靠性成绩。

二、先冻结证据：影响、时间线与缺失项

从事件卡抽取一个有来源的最小版本，按“给定事实、可推断、尚未知”标注：

纸上时间	已给的观察	不能直接推出
T0	B 报告重连后 m-9/seq9 缺口	全部设备受影响、权威消息丢失
T+2	历史补拉超时的教学告警	告警覆盖了全部受影响用户
T+5	有权 DB 历史可查 m-9/seq9；约 100 用户意图/s 对应 300 下游尝试/s	最初触发一定是 DB 池或磁盘
T+8	纸上采取一项有回退门的限载/控重试动作	动作必然单独造成后来改善
T+12	权威与 outbox/E9 责任得到核对	B 设备已处理 E9
T+20	队列下降	全部用户已补齐；可能只是拒绝增加
T+30	一台 B 设备按历史补到 seq9	其他设备和会话全部恢复

三倍放大是这次演练的纸上观察：300 下游尝试/s ÷ 100 独立意图/s=3。11.09 的 100×3×3=900/s 是两层各耗尽三次尝试时的最坏条件上界，不是本事件的实测。复盘若把 900 当 T+5 的事实，就会高估负载并误排改进优先级。11.09 放大上界

影响栏至少要写：被证实的 B 设备/会话样本、起止时间的可观测界限、是否能从权威历史补回、其他设备/客户端版本覆盖率。没有受影响用户总数的证据就保留“未知”，不写“只影响一人”或“影响所有人”。同时区分 A 当前 S2 内存受理、未来 S3 权威提交、未来 S5 设备补拉；一个阶段恢复不能替代另一个阶段。11.01 业务确认点

三、触发、放大、防线与检测是四条不同问题

“数据库慢”描述 T0–T+5 的症状/候选位置，不自动回答为什么变慢。可能的初始触发包括连接池长期占用、某查询计划退化、存储设备尾延迟或热点分区；本演练没有足够证据选定其中一个。更有把握的是 T+5 观察到下游尝试/用户意图约三倍，说明额外尝试在消耗依赖容量；它可能是促成因素，却不必是最初触发。11.04 假设与反证

问题	本章目前的证据等级	应补的证据
什么首先触发查询变慢？	未证；池/SQL/盘/热点均为候选	T0 前同实例池等待、计划、I/O 和负载基线
什么扩大了用户影响？	纸上 100→300/s 说明尝试放大	两层各自首次/重试次数、取消与队列归属
哪条防线没拦住？	待证；可能缺总重试预算、有界入队或历史读隔离	当时实际配置、入队/拒绝/等待记录与测试
为什么 T+2 才发现？	有一条补拉超时告警，覆盖率未知	客户端起点/确认点、采集延迟与无样本窗口
哪条防线起了作用？	权威 m-9/seq9 仍在、B 可按有权历史追平	权威查询与设备游标的稳定关联

无责备意味着尽可能理解条件与防线：如果当时只展示 DB CPU 而没有“意图/尝试比”，值班人很难及时识别重试放大；如果客户端和网关各自有局部重试预算却没有全链路上限，所有人按各自代码规则行事也会一起制造级联。它不是免除行动责任，而是把“谁做错了”替换为“什么设计让合理的局部行为合起来变坏”。Google SRE：复盘促成因素

四、用反事实检查改进提议，不用时间先后冒充因果

一个反事实问题是：“如果事前只有某项防线，同一慢依赖和同一工作负载还会产生同样用户损害吗？”例如，若客户端与网关共享每个历史补拉意图最多 2 次下游尝试的总预算，纸上 100 意图/s 的下游上限可从本次观察的约 300/s 降到不超过 200/s。但数据库纸上能力若只有 120/s，200/s 仍可能过载；更少重试也可能让更多 B 暂时看到失败。因此它只能成为待验证的缓解候选，不是“改完即可修复”的结论。11.09 重试与限载

另一个候选是“直接扩大连接池”。若根因是池上限过低且数据库有余量，可能有用；若数据库本身已慢，扩大池可能把等待从应用移到 DB，甚至扩大并发压力。只有分开测获取连接等待、SQL/提交耗时、DB CPU/I/O 与用户补拉完成，才能评审它。11.06 连接池等待

候选反事实	若为真，预测	可推翻它的观察
全链路总重试预算能缓解	下游尝试/意图比下降，队列减压，B 仍能最终补回	比值下降但 B 最终恢复率/时长恶化，或 DB 仍超载
扩池能缓解	获取连接等待下降，DB 服务时长稳定	池等下降、SQL/盘队列及用户超时却上升
增加告警能缩短发现	用户坏事件与重试放大在 T+2 前可见且有人能行动	只有更多噪声、无人知道止损步骤

复盘应允许多因素共同促成，不强迫写成一条单因果链。时间线中“限载后队列下降”仍要排除自然负载回落、更多拒绝或依赖自行恢复。Google SRE 的排障方法要求假设可被观测反驳；不能只挑支持自己的图。Google SRE：Effective Troubleshooting

五、行动项有 owner、期限、验收和可能副作用

不是所有未完成工作都要同一优先级。先守授权/权威事实不丢或不泄露，再处理让许多设备不能恢复的放大链、防线覆盖和手册，最后处理纯风格问题。下面是未来隔离教学项目的待评审行动清单，责任人写角色而非真实姓名；期限为相对演练日，不是假称已经排期。Google SRE Workbook：可衡量行动项

优先方向与拟议行动	Owner/复核	可验收结果	可能副作用与回退
P1：按权威序号与权限核对所有受影响 B 的缺口	历史链路负责人；T+3 日复核	m-9/seq9、其他样本的权威与设备游标可对账，未知范围有结论	查询负载过大时分批、限速
P1：跨客户端/网关共用历史补拉意图身份和总重试预算	客户端与网关负责人；T+14 日复核	慢依赖样本下尝试/意图比有界，并报告 B 最终追平率	预算过紧导致失败增多，保留版本化回退
P1：历史补拉有界入队，与关键写路径隔离	网关/数据负责人；T+21 日复核	积压可停止增长，权威写和授权查询仍达教学合同	限流/拒绝上升须有明确补拉入口
P2：补齐客户端补拉结果与重试放大观测	可观测性负责人；T+14 日复核	纸上故障重演时及时区分意图、尝试、超时、设备缺口及覆盖率	标签/日志不得含正文或高基数敏感身份

这不是“全部已批准”。若最初触发仍未知，还需一个调查行动：固定版本和负载，分别检查 DB 池、SQL、盘与热点，给出证据或明确未证。不要把“全面重写后端”“加强培训”“提高警惕”当作没有 owner、期限和完成判据的行动。复盘条目即使合并代码，也要验证风险真的下降；单纯关工单不等于收益。11.05 优化证据

六、验证收益要同时看放大和用户恢复

若未来学习者真的在隔离实现中验证“跨层重试预算”，应固定代码版本、授权数据、初始连接数、100 意图/s 负载及相同慢依赖故障，比较基线和候选：下游尝试/意图比、DB 池等待、队列增长、拒绝/超时、B 的有权历史最终追平比例与耗时。还要在依赖恢复后撤载，检查积压是否清空、旧游标是否补齐和 S2 当前合同是否回归。11.07 可比负载

若只是“DB QPS 从 300 降到 200”，却让 B 的最终追平从 99% 降到 70%，不能宣布用户体验改善。若队列下降仅因拒绝增加，也不算复盘行动验证通过。一个必要失败变式是 B 离线 25 小时，超过教学 broker 24 小时保留：即使实时 E9 不可回放，仍应从有权权威 DB 历史按 seq9 缺口补，且非成员不能借恢复路径读取私有内容。07.12 25 小时反例

本课程没有实际运行或测量，因此这里只交验证设计、预测与反例，不填虚构“降低故障率 40%”。若实验结果不支持提议，应修订行动项，保留失败证据，而不是挑一个有利窗口写成成功。多次长期观察比单次演练绿色更能说明收益；本章不能代替未来真实系统的复核。11.02 样本与窗口

七、回访、知识传递与版本化边界

一份复盘需要有人审阅因果、补齐未知、跟踪行动项及验证收益；过了 T+14 日若行动未完成，应记录延期原因与当前风险，而不是让表格永久显示“进行中”。结论可向需要学习的人传播，但课程只保留脱敏虚构身份、步骤和决策，不包含真实正文、令牌或个人归责。Google SRE：复盘审阅与传播

S2 当前 /v1 的 200 是本进程内存受理；未来 S3 /v2 如果采用数据库提交，是另一版本合同；未来 B 的设备结果又是独立指标。复盘改进若改变重试、错误映射或响应承诺，应在兼容/发布门评审，不能把 R9 6→9 B 这个待审需求混入事故修复，或拿 S2 200 宣称已持久/已送达。09.10 版本兼容 · 10.10 发布门

固定 openimsdk/open-im-server 提交 f6411a8a1a31d3df36f4c2b3ad28481a94141e1f 的 send.go 选定分支调用 MsgToMQ 后返回；另一 Mongo 消费路径调用 BatchInsertChat2DB。两处只提示发送返回与 Mongo 消费是异步阶段，不能证明 OpenIM 发生过本章事故、真实触发、重试倍数、SQL/outbox 或行动收益。OpenIM 阅读地图

八、22 道分层练习：审阅复盘是否真能减少复发

先按“影响—证据—原因候选—行动—验收”独立作答，再看反馈。

基础 1–8：先固定事实

1. 一台 B 在 T+30 补到 seq9，能证明所有用户已恢复吗？

不能。其他设备/会话范围与最早影响时刻仍需证据。

2. T+5 观察到每秒 100 意图、300 下游尝试，放大倍数多少？

300/100=3 倍。

3. 11.09 的 900/s 最坏上界可填成这次 T+5 实测吗？

不能。它是两层重试全用满的条件上界，不是本次观察。

4. “DB 慢”直接等于“磁盘坏”吗？

不等于。还可能是池、SQL、热点等，初始触发未证。

5. T+20 队列下降可单独证明 B 已恢复吗？

不能。可能是拒绝增加，仍需有权历史与设备游标证据。

6. 复盘可以写真实私聊正文帮助复现吗？

不应。使用虚构或最少脱敏证据，并守访问权限。

7. S2 200 可以当未来 B 设备 ACK 吗？

不能。前者仅本进程内存受理，后者是设备结果。

8. 无责备是否意味着不分析值班决策？

不是。分析当时信息、工具与选项，但把改进指向系统防线而非羞辱个人。

因果 9–16：用反事实审提议

9. 本次重试放大是初始触发还是促成因素？

已观察到它扩大下游工作，属于促成证据；最初触发尚未证实。

10. 若每个意图最多 2 次下游尝试，100 意图/s 条件上限多少？

不超过 200 下游尝试/s；这仍可能超过纸上 DB 120/s 能力。

11. 下游尝试下降就能证明重试预算改善用户结果吗？

不能。还要看 B 最终追平、超时/拒绝和依赖恢复后的补拉。

12. 扩大连接池后池等待降了、DB 查询变慢，提议成功了吗？

不一定。排队可能被转移到 DB，用户结果也须改善才算有价值。

13. T+8 限载、T+20 队列降，能单凭先后证明限载是唯一原因？

不能。还需排除自然负载回落、依赖恢复或拒绝增多。

14. T+2 有补拉告警，可直接写“检测防线完全失效”吗？

不能。告警存在；覆盖率、是否够早及是否可行动仍待查。

15. 权威 m-9/seq9 可查是哪类证据？

说明该纸上样本的权威事实保留，是恢复防线的线索；不等于所有设备可见。

16. 为什么要保留反例/失败实验？

它能推翻不成立的改进假设，避免只挑好看的窗口关闭行动。

行动 17–22：把复盘变成可验收改进

17. “加强培训、优化系统”是合格行动项吗？

不合格。缺 owner、具体产物、期限、可验收结果与副作用。

18. 权限泄露风险与格式命名不一致应如何排序？

先守授权与权威数据，再处理容量/恢复和观测，普通风格问题后置。

19. B 离线 25 小时、broker 保留 24 小时，验证哪条恢复防线？

从有权权威 DB 历史按 seq9 缺口补，不依赖 E9 仍在 broker。

20. 行动项合并代码后何时才算完成？

达到预设验证结果、业务回归与回退门，owner 记录证据；只合并不够。

21. 两处 OpenIM 源码能证明这次事故根因吗？

不能。它们只支持选定发送与 Mongo 消费的异步边界。

22. 一份可审复盘至少交什么？

受限影响、带来源时间线、已知/未知、触发候选/促成/防线、可反驳反事实、按风险排序的 owner/期限/验收行动与复核计划。

本章完成标准与后续路径

能用 T0–T+30 证据说明“三倍放大已观察、初始触发未证”，为至少两种缓解候选写反事实和用户副作用，交出有 owner/期限/验收的行动表，并设计 B 离线 25 小时的授权恢复反例，才算完成第一轮。本章没有实际改进结果；后续需学习者在隔离实现中验证。下一章11.12 容量与成本决策将把连接、群扇出、历史保留、容灾余量和长期维护成本放进一张容量决策表。