11.10 事件响应：B 历史补拉迟到时怎样止损与恢复
返回第十一卷 · 诊断方法：11.04 · SLO 与告警：11.08 · 过载级联：11.09 · 技术写作：10.11
11.10 事件响应：B 历史补拉迟到时怎样止损与恢复
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.09 用未来 S5 的纸上案例解释数据库慢、B 重连补拉、重试放大和队列增长。到事件响应时，团队最先要守住的仍是用户结果：有权的 B 在重连后，是否能从 c-a 的权威历史补到 m-9/seq9？A 当前 S2 能否收到内存受理 200，是另一个确认点；未来 S3 权威数据库提交、E9 可消费与 B 应用确认也不能互相代替。若只报“CPU 回到 30%”或“队列清零”，并没有证明 B 的历史恢复了。11.01 确认点 · 11.08 用户结果指标
本章的情景属于未来系统演练：纸上假设权威 DB 中已经有 m-9/seq9，B 重连后界面缺这条消息，补拉请求超时；是否还有其他设备、会话或消息受影响，起初未知。这是一个需要调查的用户症状，严重程度要看影响范围、持续时间、数据是否可恢复和现有止损能力，不能单凭“某人说卡顿”或“某个依赖红了”断定级别。Google SRE 的事件管理方法把恢复服务、明确职责、定期通信和保存证据结合起来。Google SRE：Managing Incidents
| 事件入口要写清 | 本题纸上记录 | 暂不能宣称 |
|---|---|---|
| 报告者和动作 | 虚构 B 设备重连、请求有权历史 | 所有用户都无法发送 |
| 缺口身份 | c-a/m-9/seq9，只用虚构身份 | 私有正文、真实用户资料 |
| 当前症状 | B 未在约定时间看到该历史项，补拉超时 | 权威消息丢失或数据库坏盘 |
| 现有反证 | 纸上有权查询能找到权威 m-9/seq9 | B 已收到、设备 ACK 已到 |
| 待量化范围 | 设备/版本/会话/时间窗与失败比例 | 凭一条用户报告编造受影响人数 |
二、分级启动与角色：谁决策、谁改系统、谁通报
一个事件刚开始可以只有值班人，但一旦用户影响扩大、需要同时查数据库与网关、或多个动作可能冲突，就应明确职责。Incident Commander（IC）维护全局状态、优先级和决定；Ops负责获授权的实际系统变更与回退；Comms按约定频率向相关方更新已知/未知；Planning维护时间线、行动、交接和后续事项。小事件可一人兼数职，但当前谁承担哪个责任要写出来，避免两个人分别调高重试和重启数据库。Google SRE：事件职责
| 角色 | 演练中的主要问题 | 交接给谁 |
|---|---|---|
| IC | 用户影响到哪、现在先止损还是继续取证、下一检查点何时 | 向 Ops 下达单一变更方向，向 Comms 提供可发布事实 |
| Ops | 限并发/停多层重试是否可逆，真实状态与回退门是什么 | 把执行前后证据交回 IC 与记录者 |
| Comms | 哪些事实可说，影响范围哪些仍未知，下次更新时间 | 同步给有权的内部/外部接收者 |
| Planning | 决策、事实来源、临时开关、待办和轮班风险 | 给下一班与复盘作者完整状态 |
“谁修改系统”应有单一协调入口，不意味着只有一个人能做所有技术工作；多个专家可并行读证据、提出候选，但变更由负责 Ops 依 IC 的当前决策执行并记录。事件期间无关发布应按既有流程暂停或评审，防止引入新变量；本章没有授权任何真实变更或外部通信。Google SRE 的事件响应教材也强调清晰角色、主动沟通和可传递的事件状态。Google SRE Workbook：Incident Response
三、把事实、推断、未知与行动放在同一页
以下是虚构事件卡，每项都要附观察位置与时刻。纸上事实可以作为推演输入；根因结论仍要靠反证，而不是写在事实栏里：
| 类别 | T+5 分钟时的纸上记录 | 下一步 |
|---|---|---|
| 已知事实 | 有权 DB 历史可查 m-9/seq9；B 设备本地仍缺；补拉请求超时 | 对照相同设备/会话/游标的请求链 |
| 已知事实 | 每秒约 100 个独立补拉意图、约 300 次下游尝试 | 查客户端/网关各自重试来源与当前队列 |
| 推断候选 | 池等待、慢 SQL、磁盘、网关慢端或两层重试放大 | 用 11.06/11.09 的分段指标逐项反证 |
| 未知 | 其他用户/会话范围、最早影响时间、设备 ACK 覆盖率 | 定义统计窗口，核对观测缺口 |
| 待决行动 | 是否收紧补拉并发、暂时停某层重试 | 先写预期用户结果、风险与回退条件 |
本表的“300 次尝试/秒”只是这次演练给定的观测；11.09 的 100×3×3=900/s 是两层都用满尝试时的最坏上界，不能把上界当本次实测。若时间线里出现“数据库坏了”，请追问是日志、查询耗时、连接池等待还是存储错误支持这个判断；若没有，就改写成待验证候选。Google SRE 的排障方法将假设和观察分开，并反复用证据排除候选。Google SRE：Effective Troubleshooting
时间线要标事件发生时间、记录时间与来源。跨机器时钟可偏移，不能把 B 手机和数据库各自的墙上时间戳直接相减得到精确耗时；用相同请求身份、各进程自身持续时间和关联事件核对。私有正文、真实令牌、用户资料不进入普通事故记录；m-9/c-a/u-b 均是虚构标识。08.02 跨机器时间 · 11.03 脱敏观测
四、止损动作要有预测、风险与停止门
事件中不必等根因完全查明才止损，但每个变更应回答：为什么此刻做、预计改善哪类用户结果、可能伤害哪类用户、何时回退。在本题中，纸上可先选择一项可逆候选：对未来历史补拉设有界并发与重试预算，让尚未进入数据库的无望请求早退；同时保留有权历史补拉的重试入口。Ops 在隔离演练里每次只改一项主要变量，记录用户意图/尝试比、池等待、拒绝/超时和 B 缺口的前后变化。11.09 限载与重试预算
| 止损候选 | 预期效果 | 必须并报的副作用 | 立即停止/回退条件 |
|---|---|---|---|
| 收紧历史补拉并发 | DB 池等待/无效查询减少 | B 补拉被延后或拒绝的比例 | 权威查询或 A 发送受影响反而扩大 |
| 停一层自动重试 | 下游尝试/用户意图比下降 | 客户端更早看到暂时失败 | 可恢复请求没有保留游标/后续重试路径 |
| 隔离慢读资源 | 历史读不占满关键写资源 | 两池共享 DB 的总负荷仍可能高 | m-9 等权威写或成员权限出现回归 |
不应盲重启数据库/网关、删除队列、无条件重放权威 m-9 或把当前 /v1 的 6 B/409/404 合同改掉。重启可能造成冷缓存与再一次重连风暴；丢掉可恢复通知前也必须确认权威消息仍在且授权补拉能追平。若操作需要真实环境权限与变更审批，应由实际负责人按当地流程处理，本章只设计演练。Google SRE 在级联故障讨论中提醒：恢复动作若移动负载或制造冷缓存，也会加重事故。Google SRE：级联故障
五、通报只写已知影响、未知和下次更新
Comms 的第一份状态不需要虚构“根因已定位”或“十分钟修好”。面向有权接收者的纸上模板可以写：
时间：T+6 分钟（虚构）
已知：部分有权设备的 c-a 历史补拉出现超时；当前样本中 m-9/seq9 在权威历史可查。
范围：设备/会话总范围仍在核对，A 侧发送受理和其他功能尚未完成评估。
行动：正在限制无效重试并核对有权历史补拉；未执行权威消息重放。
下次更新：T+16 分钟；若风险扩大提前更新。模板里的“部分”也需要至少有两个样本或聚合证据支撑；若只有 B 的单条报告，应说“收到 B 设备的补拉失败报告，其他范围未知”。更新时用同一版本、同一确认点对照前一版，明确哪些信息已经修正。内部诊断日志可比对稳定的虚构身份；对外通报只使用必要的功能、影响范围与状态，不发正文、令牌、真实用户或猜测的责任人。10.11 技术写作与协作
沟通节奏要事先选定并持续兑现：哪怕仍未知根因，也可以如期说明“已验证什么、哪项措施在观察、下一次何时更新”。一个可信的未知栏比把推断写成结论更能帮助后续接班和用户决策。Google SRE：Managing Incidents
六、纸上 T0–T+30：恢复要逐站验证
这条时间线是假设的演练过程，不是本项目发生过的事故。它刻意安排“队列下降”先于“设备追平”，防止把资源图好转误记为用户恢复。
| 纸上时刻 | 演练观察/决定 | 还缺什么才可继续 |
|---|---|---|
| T0 | B 报告重连后 m-9/seq9 缺口 | 受影响会话/设备范围、客户端版本 |
| T+2 | 补拉超时告警触发，IC 明确角色 | 告警分母与遥测覆盖；不能直接宣称全站事故 |
| T+5 | 权威记录存在、B 缺口未补、下游尝试高于意图 | 池/SQL/网关阶段，根因仍未知 |
| T+8 | IC 选择一项可逆限载；Ops 记录前后 | 拒绝与 B 等待是否增加，A 发送是否保持合同 |
| T+12 | 有权查询再次核对 m-9/seq9 与 outbox/E9 责任 | broker/网关/设备后续位置，不把 outbox 当送达 |
| T+20 | 纸上队列开始下降 | 是完成增多还是拒绝增多？缺口仍有多少？ |
| T+30 | B 的教学设备按历史补到 seq9 并给应用确认 | 其他样本/会话、长窗结果与临时开关是否可撤 |
恢复证据从权威事实走到派生与设备：先确认有权 DB 历史的 m-9/seq9，再看 outbox E9、broker 消费位置、网关待发与 B 的应用确认/补拉游标。B 若离线 25 小时、教学 broker 仅保留 24 小时，要从有成员权限的权威 DB 历史恢复，而非宣布 E9 已过期所以永远丢失。07.12 离线恢复
T+20 的队列下降可能因为更快完成，也可能因为新请求被大量拒绝；必须并列看客户端合格机会、超时/拒绝、追平比例与未完成数。T+30 的一台 B 设备追平也不能证明所有受影响设备都已恢复。IC 可在多个观察窗口里看到用户结果、重试比例、池等待、积压和权限行为稳定后，决定逐步撤限或结束事件；若再放量使队列回涨，就停在上一档。11.08 SLI 与缺失样本
七、交班、事件结束与复盘分开
轮班交接至少留下一张事件状态卡：当前用户影响及证据范围、权威与设备确认、已做/未做的变更、临时限额/开关及 owner、回退方式、下一观察时刻、尚未验证的假设和谁有权限执行。没有 owner 或到期条件的临时限流可能变成长期隐性容量损失。Planning 应把时间线、证据链接和决定原样保存，Ops 确认实际状态，IC 确认下一班职责，Comms 延续更新承诺。Google SRE：交接与事件状态
事件结束只表示当前恢复门有足够证据满足，不等于根因已经完全证明；“数据库慢”可能只是中间症状。11.11 再按已知事实、促成因素、防线失效和行动项做无责备复盘，评估哪些改进真正减少下一次用户影响。不要在应急时为了写完复盘而延迟止损，也不要因为止损成功就删掉未知项。11.09 反馈链
固定 openimsdk/open-im-server 提交 f6411a8a1a31d3df36f4c2b3ad28481a94141e1f 的 send.go 选定分支调用 MsgToMQ 后返回；另一 Mongo 消费路径调用 BatchInsertChat2DB。这两段只提示发送与 Mongo 消费分属异步阶段，不证明 OpenIM 发生过本章事件、有本题 SQL/outbox、某个事故根因或设备恢复结果。OpenIM 阅读地图
八、22 道分层练习：完成一张事件状态卡
先按角色与证据答题，再检验止损会改变哪些业务结果。展开反馈前写清“已知、推断、未知”。
基础 1–8：事件入口与职责
1. B 历史补拉失败，A 的 S2 200 能证明 B 恢复吗？
不能。A 的内存受理与 B 的未来历史恢复是不同确认点。
2. B 单条报告足以宣称全部用户受影响吗？
不足。先固定报告事实，其他用户/会话范围标未知并取证。
3. IC 首先负责什么？
维持全局事件状态、优先级、角色分工、决策与检查点。
4. 谁按协调后的决定修改系统并记录回退？
Ops；专家可并行读证据，但变更有单一协调入口。
5. Comms 可以把“数据库坏盘”写给用户吗？
若只是猜测不能。只写有证据的影响、未知项、当前动作和下次更新时间。
6. Planning 要保存什么？
事实来源、时间线、决策、临时开关、待办、下一检查点与交接风险。
7. 事故记录能写真实消息正文和令牌吗？
不应。使用最少必要的脱敏证据与有权限的受控关联信息。
8. T+5 的 300 次尝试/秒等于 300 位新用户需求吗？
不等于。本演练约 100 个意图/秒，额外尝试来自重试；仍须追具体层级。
指挥 9–16：事实与止损的边界
9. `m-9/seq9` 在有权权威库可查，能证明 B 已处理吗？
不能。还要查网关与 B 的应用确认/补拉游标。
10. 池等待高是事实还是“坏盘”结论？
若有同窗测量是池等待事实；坏盘仍是需独立证据的候选。
11. 为什么一次只改一个主要止损变量？
便于判断用户结果和资源变化来自哪项动作，并有清楚回退门。
12. 收紧补拉并发后，哪种坏结果可能增加？
B 的请求被延后或拒绝，须并报完成、超时、拒绝和历史缺口。
13. 能为止损直接重放权威 m-9 生成新消息吗？
不能。先守原权威身份/序号，避免重复或改变事实。
14. T+20 队列下降就能宣布事件结束吗？
不能。可能只是拒绝增多，须看有权补拉和设备追平。
15. B 离线 25 小时，broker 保留 24 小时，应怎样恢复？
按成员权限从权威 DB 历史查 seq9 缺口，不能只靠 broker。
16. 跨机器墙上时间戳可直接相减定精确网络耗时吗？
不能。要核对时钟偏差、稳定身份与各进程自身持续时间。
恢复 17–22：结束条件与交接
17. T+30 一台 B 设备补到 seq9，可证明所有用户恢复吗？
不能。要核对其他受影响样本、会话和观察窗口。
18. 放量后重试比例和 DB 等待再次升高，应怎样做？
停止继续放量，回到上一安全档，保留证据并重新评估瓶颈。
19. 临时限流开关交班时至少记什么？
当前值、目的、owner、到期/撤销条件、回退方法和下一观察点。
20. 事件结束是否等于根因完全证明？
不等于。结束按恢复门，根因与改进行动在 11.11 复盘继续验证。
21. 两处固定 OpenIM 源码能证明本章真实事故吗？
不能。只支持选定发送与 Mongo 消费的异步边界。
22. 一张可交班状态卡至少交什么？
用户影响与范围、事实/推断/未知、权威/设备证据、行动与回退、临时开关/owner、下一检查点与沟通责任。
本章完成标准与后续路径
能把 B 的报告写成有确认点与未知范围的事件卡，为 IC/Ops/Comms/Planning 分配责任，按 T0–T+30 逐站记录事实、止损副作用和恢复门，并输出不含私有内容的交接状态，才算完成第一轮。所有事件和动作都是纸上演练，不是实际事故或值班记录。下一章11.11 复盘与改进将用同一材料做无责备复盘与改进收益验证。