写 Bug 的人也需要第二大脑：一次线上事故的复盘记录
一只阿木木约 12 分钟写 Bug 的人也需要第二大脑：一次线上事故的复盘记录
副标题：从「周五晚被电话吵醒」到「有模板、有记录、有改进」
我是一只阿木木，一个写后端代码、也常写 Bug 的普通人。
如果你也是写后台、值班、被电话吵醒过的那种人，大概率经历过这种场景：
• 手机半夜震个不停：“线上有问题，快看一下！” • 各种报警、群消息、语音 call 一起涌进来 • 你一边开着日志、一边连着数据库、一边和产品语音，对着屏幕满头问号
那一刻你脑子里只有一件事：先把火灭了。
但等问题解决、大家散场之后：
• 事故细节已经记不清 • 问题是怎么排查出来的？后来怎么修复的？ • 哪些地方其实可以提前预防？ • 下次遇到类似情况，还会不会再乱成一团？
坦白说，之前的我是——每次线上事故都是「重新体验一次恐慌」。
等下一次再出事，又从零开始懵。
直到有一次事故之后，我认真做了一次复盘，
并且把这次经历塞进了我的第二大脑（Obsidian + AI）里。
现在再遇到线上问题的时候：
• 我有一个事故记录模板，一边处理一边填 • 我能在 Obsidian 里，迅速找到过去类似问题的排查思路 • 事后复盘，有模板、有卡片、有 checklist，
每次事故都真的变成了「成长的 Bug 修复」。
这篇文章，是一次完整的故事复盘：
• 那次真实的线上事故，到底发生了什么 • 在慌乱和压力中，我是怎么一点点用第二大脑「托住自己」的 • 事后我是如何把这次事故，固化成「可复用的知识和流程」
希望你看完之后，可以带走三样东西：
1. 一套可以直接照抄的「事故记录模板」 2. 一条线上事故时「第二大脑介入」的流程 3. 以及，也许是最重要的——写 Bug 的人，可以怎样不再写同样的 Bug
一、事故那天的晚上：报警、恐慌和一地鸡毛
时间是某个周五晚上 10 点多。
那天我本来已经洗完澡，打开了游戏，准备愉快入坑。
手机突然开始疯狂震动：
• 钉钉：[严重告警] 支付成功率突降 • 监控群： • 「有用户反馈支付失败」 • 「订单量突然掉了一半」 • 产品给我打电话：「是不是你下午发版的那个功能出了问题？」
一瞬间，熟悉的「完了、好像是我搞的」感袭来。
1.1 初步信息：一团糊
我连上电脑，打开监控和日志，大概看到这些信号：
• 某支付接口的 5xx 报警暴涨 • 订单系统请求量下降，成功率下滑 • 后台有少量「重复扣款」投诉（用户说钱扣了两次）
脑子里的问号越来越多：
• 是第三方支付通道的问题？ • 还是我们新加的重试逻辑出问题？ • 为什么有「支付失败」和「重复扣款」这两种看起来相反的现象？
平时写 Bug 的时候，你会觉得「这 Bug 不大，下次小心点就是」。
但线上一出事，这种「不大」就会在你心里被放大成：
「是不是会闹到领导那里？」
「是不是会影响 KPI？」
「会不会搞出新闻那种大事故？」
1.2 情绪状态：脑子完全不清醒
那 10 分钟我的真实状态是：
• 开了十几个窗口，切来切去 • 想起以前的类似问题，但只模模糊糊地记得一点 • 群里大家你一言我一语，我根本顾不上记录
那一刻我很清楚地意识到一件事：
不是我不会排查问题，而是我根本装不下这么多东西。
我需要一个「外置大脑」，帮我把现在发生的事装起来。
这就是这次事故中，「第二大脑」真正开始发挥作用的地方。
二、第二大脑是怎么介入这次事故的？
很多人听「第二大脑」，会以为是平时记读书笔记的那种系统。
但对我来说，它在事故里更像一个「作战记录板 + 应急手册」。
这次事故里，它帮了我三件大事：
1. 稳定住我的「注意力」：有模板，有结构，不至于乱成一团 2. 快速调出「旧经验」：过去类似事故的排查记录能马上看到 3. 为事后的复盘和改进打基础：现在记录的东西，未来都能用得上
下面我就按照时间线，把这三件事展开讲。
三、现场记录：从「乱七八糟的对话」变成「结构化事故日志」
3.1 打开 Obsidian，先建一条事故记录
意识到自己开始慌乱之后，我做了一个当时看起来有点「拖后腿」的动作：
打开 Obsidian，新建了一条事故记录笔记。
我有一个预先准备好的模板，叫：tpl_线上事故记录.md，内容长这样：
Markdown
# 线上事故记录｜{简要标题}
## 1. 基本信息
- 发生时间：
- 发现人/渠道：
- 涉及系统/服务：
- 当前影响范围（粗估）：
---
## 2. 现象 & 指标
- 监控报警：
- 用户反馈：
- 日志特点：
---
## 3. 临时决策 & 行动
- 临时止血措施：
- 涉及的操作（回滚/限流/手工处理）：
- 当前负责人：
---
## 4. 排查思路（实时记录）
时间线（按时间倒序补）：
- [22:10] 做了什么？观察到什么？
- [22:15] 假设 A（后来被推翻）
- [22:25] 聚焦在 X 服务的 Y 接口
...
---
## 5. 初步结论（事故当晚）
- 疑似根因：
- 后续需要验证的点：
- 预计第二天要做的事：那一刻我做的，就是一边排查、一边在这条笔记里补时间线：
• 22:12：第一次看到支付成功率下滑 • 22:18：发现最近 1 小时内有多次重试记录 • 22:25：怀疑和下午上线的幂等逻辑有关 • 22:30：先对部分流量熔断，避免进一步重复扣款
看起来像是在「记日记」，但这有两个非常直接的好处：
1. 每做一步，我都会强迫自己「用一句话说清楚我在干嘛」
——这样可以防止自己在日志里乱翻半小时，忘了目标2. 一旦群里有人问「现在情况怎么样了」，
我可以直接从笔记里拷一段发过去，而不是临时组织措辞
3.2 用 AI 帮我从混乱对话里抓要点
事故过程中，群里消息飞得很快：
• 运维在报硬件和网络情况 • 前端在说用户反馈 • 产品在问「影响多少订单？」 • 领导在问「能不能先恢复核心功能？」
我根本没空一条条理清楚。
我做了这样一件事：
• 定期（比如每 10–15 分钟），把最近一段群聊的关键内容复制出来 • 丢给 AI，说：
text
这是我们在事故过程中的一段对话记录，内容比较乱：
{粘贴最近 10 分钟的群聊关键信息}
请你帮我：
1. 用 3–5 条 bullet，总结出目前大家已经确认的事实（避免重复讨论）
2. 用 2–3 条 bullet，总结出目前还存在分歧/不确定的点
3. 给出 1–2 条建议：接下来最优先要验证的假设是什么？AI 给出的结果，我会：
• 把「已确认的事实」贴回事故记录的【现象 & 指标】部分 • 把「待验证的问题」贴在【排查思路】里，作为接下来行动的 checklist
在这个过程中，AI 没有替代任何技术判断，
但帮我做了一件很关键的事：
在大家都很紧张、说话混乱的时候，
有人帮你按时间把信息「理一理」。
这对当时那个脑子快烧糊的我来说，非常重要。
四、问题定位：第二大脑帮我「叫出问题的名字」
这个事故的根因，最后被我们确认是：
在新增的重试机制 + 不完善的幂等 Key 设计之下，
在某些边缘网络场景下，出现了重复扣款。
这个结论听起来有点教科书，但我们当时得到它，其实走了不少弯路。
4.1 过去的踩坑记录，被我从 Obsidian 里翻了出来
在排查的过程中，有一个瞬间让我印象很深：
• 我在事故记录里写了一句：
「感觉和最近加的幂等逻辑 / 重试策略有关系」• 然后我突然想起：
「我好像以前记过一条关于重试 + 幂等导致重复操作的笔记。」
于是我在 Obsidian 里搜了下「幂等」「重试」，
翻出了几个月前写的一条卡片：
Markdown
# 案例｜重试 + 幂等Key失误导致重复执行
## 场景
...
## 根因
- 幂等 Key 设计只考虑了请求体的一部分
- 重试时生成了新的 Key，没有命中幂等缓存
## 教训
- 幂等 Key 设计需要完整覆盖「业务唯一性」维度
- 重试和幂等必须联合设计，而不是分别看这条笔记本来只是我之前看一篇技术博客 + 自己想法的产物，
当时记完也没多想。
但是在这次事故里，它起到了两个作用：
1. 帮我叫出了问题的名字：
「重试 + 幂等 Key 设计不完善 → 可能导致重复扣款」2. 给了我一个排查路径：
检查最近上线代码里幂等 Key 是怎么设计的、重试策略是怎么写的
于是接下来的动作就非常顺：
• 看配置：最近是不是改过重试策略 • 看代码：幂等 Key 包含哪些字段 • 查日志：问题订单的 Key 是否多次出现
几轮对比下来，问题基本指向：
「我们在一个子场景里，没有把用户 ID 和业务订单号一起纳入幂等 Key，
导致重试时命中错误。」
如果没有那条之前的 Obsidian 卡片，我多半还是能查出来，
但很可能会多走很多「先怀疑第三方 → 先怀疑网络 → 再怀疑新代码」的弯路。
4.2 AI 在这里做了什么？
在这个阶段，我主要让 AI 做两件事：
1. 帮我验证理解有没有问题
text
我现在对问题的初步理解是这样的：
{用自己的话描述：重试 + 幂等 Key 设计不完善 → 某条件下重复扣款}
请你从后端工程师的角度看看：
1. 我的理解有没有明显错误或逻辑漏洞？
2. 在这个问题上，还有哪些可能的隐含风险，是我现在没想到的？2. 帮我写给非技术同事能看懂的解释
text
请帮我把下面这段技术原因，改写成产品/运营也能看懂的版本：
{粘贴技术原因说明}
要求：
- 不提幂等、重试这些术语
- 用现实生活中的比喻解释「重复扣款」是怎么发生的
- 控制在 200 字以内得到的结果，我发给了产品和运营，
他们也能更快地理解：「这是哪里出问题了、接下来要干嘛」。
五、事后复盘：把事故变成第二大脑里的「知识资产」
事故当晚，我们做了临时止血和紧急处理：
• 限制了有风险的部分请求 • 手工处理了少数重复扣款的用户 • 准备第二天白天上线修复版本
真正决定这次事故「值不值」的，是之后的那一周。
5.1 用 Obsidian + AI 完整走了一次复盘流程
事后，我专门在 Obsidian 里，为这次事故建了一条复盘笔记：2024-支付重复扣款事故-复盘.md
模板大致是：
Markdown
# 线上事故复盘｜支付重复扣款
## 1. 事故概览（事实）
- 时间：
- 发现方式：
- 影响范围（用户数 / 金额 / 时长）：
- 最终根因（简述）：
---
## 2. 详细时间线（来自事故记录）
- [22:10] ...
- [22:18] ...
...
---
## 3. 技术原因分析
### 3.1 表面原因（代码/配置层面）
### 3.2 深层原因（设计/流程/沟通层面）
---
## 4. 哪些是「做对了的」？
- 本次排查中的亮点：
- 哪些预警/监控/流程起了作用：
---
## 5. 哪些是「没做好的」？
- 技术欠缺：
- 流程缺失：
- 沟通问题：
---
## 6. 后续行动 & 负责人
- 行动 1：
- 行动 2：
---
## 7. 对我个人的启发（成长 Bug 修复）
- 哪些认知是以前没有的？
- 我打算在自己的第二大脑里新增哪些卡片/模板？这里面有几部分，我是用 AI 来「加速」的：
1. 时间线：直接从那晚的「事故记录笔记」里拷过来，
再请 AI 帮我压缩 & 衔接语句。2. 「做对了什么 / 没做好什么」：
我先写 bullet，再让 AI 帮我分类和优化表述。3. 「技术解释」：
先写工程师版，再让 AI 帮我生成「面向产品/运营版」。
但是有一个部分，是我坚持自己写的——
5.2 「成长 Bug 修复」：把这次事故，修进自己的第二大脑
在复盘的最后一节，我给自己留了一个「成长 Bug 修复」小节。
我会诚实写下几条东西，比如：
• 以前以为「重试机制」= 尽量帮用户成功，现在知道必须和幂等严格绑定 • 自己有「上线压力大时，习惯先放过一些边缘场景」的坏习惯 • 每次事故后才写复盘，很容易只记得结果，忘了自己当时的思考过程
然后，我会在第二大脑里干三件事：
1. 新增一条「幂等 + 重试设计 checklist」卡片
Markdown
# Checklist｜幂等 + 重试设计自查
- 幂等 Key 是否覆盖了业务上的「唯一性」？
- 重试策略是否考虑了：
- 第三方超时
- 客户端重试
- 我们自己的后台重试
- 是否对「幂等失败」有监控？
- 是否在评审时进行了一次「最坏场景」演练？2. 更新「线上事故记录模板」
加入了一项：
Markdown
## 0. 事故级别 & 决策人
- 级别（P0/P1/...）：
- 临时决策拍板人：避免未来在「谁有权拍板先止血」上浪费时间。
3. 在个人「成长 Bug 列表」里，新增一条
Markdown
# 成长 Bug｜习惯在压力下牺牲边缘场景
- 触发案例：支付幂等性事故
- 现象：评审时觉得「这种情况很少，不会发生吧」，没有继续往下推
- 修复方式：
- 对关键链路的「边缘场景」，至少列出 3 种最坏情况
- 在 Obsidian 里建一个「最坏场景清单」模板，下次上线前过一遍这三件事，让这次事故真正留在了我的第二大脑里，
而不是变成「某年某月我好像也出过一次线上问题」这种模糊记忆。
六、如果你也想让线上事故不再白挨骂，可以这样开始
说完故事，总结一下这次经历里「第二大脑 + AI」真正做了什么。
6.1 事故当下：一个简单的「作战记录」模板
你可以抄我这个事故记录模板，放进任何笔记软件：
Markdown
# 线上事故记录｜{简要标题}
## 1. 基本信息
- 时间：
- 发现方式：
- 涉及系统：
- 影响范围（初步）：
## 2. 现象 & 指标
- 报警：
- 用户反馈：
- 监控变化：
## 3. 临时行动（止血）
- 措施：
- 风险：
## 4. 排查时间线（实时补）
- [hh:mm] 做了什么，看到什么
## 5. 当晚初步结论
- 疑似根因：
- 第二天要验证的事：关键点不是模板有多完整，而是：
从下一次事故开始，一边排查，一边按这个结构记录。
6.2 事后复盘：用 AI 帮你「写清楚」，而不是「替你负责」
复盘时可以用到两个简单的 Prompt：
1）整理时间线
text
下面是我在事故处理过程中记录的一些零散片段：
{粘贴你的时间线/聊天记录片段}
请你帮我：
1. 按时间顺序整理一条清晰的事故处理时间线
2. 使用「[时间] 做了什么 → 得到什么结果」的格式输出2）帮你把技术原因翻译成非技术版
text
这是我写的技术原因说明：
{技术分析}
请帮我改写成产品/运营也能看懂的版本：
- 不用太多术语
- 强调「发生了什么 → 对用户有什么影响 → 我们做了什么修复」
- 控制在 200 字以内6.3 长期：在第二大脑里，建立你的「事故知识库」
每次事故结束，你可以在第二大脑里做 3 件小事：
1. 建一条「事故卡片」：
• 标题： 案例｜xxx 事故• 包含时间、原因、影响、解决方案
• 变成 checklist 或设计原则，放进你的知识库
• 这次暴露了你哪方面的习惯 / 认知问题？ • 你准备怎么修？
做了几次之后，你会发现：
你不再只是一个「在生产上救火的写 Bug 人」，
而是一个「把每次 Bug 都修进自己系统里的工程师」。
七、尾声：写 Bug 的人，也配拥有第二大脑
以前我总觉得：
• 第二大脑是给那些「高效人士」「终身学习者」用的 • 写 Bug 的人，先把 Bug 写少点再说吧
但经历过几次线上事故之后，我反而更坚定了一件事：
越是会写 Bug 的人，越需要第二大脑。
因为：
• 我们要在压力下做决策，要在混乱中抓重点，要在事后诚实面对问题 • 光靠一时的记忆和勇气，是撑不住的 • 你需要一个「外置空间」，帮你记录、整理、沉淀，再慢慢升级自己
所以我现在把第二大脑当成是：
• 代码层面的「日志 + 监控 +告警 + 自恢复」 • 自己成长层面的「记录 + 复盘 + 模板 + 升级」
如果你最近也经历过线上事故、或者正在担心哪天会遇到，
不妨从今天开始，先给自己准备一条最简单的「事故记录模板」——
下一次手机半夜响起来的时候，
至少你不会再完全靠「硬扛」，
而是有一块地方，能帮你把这次宝贵（又痛苦）的经历，好好留住。
如果你愿意，可以在评论里简单写下：
• 你最近一次印象最深的线上事故 • 以及，你现在有没有在用某种方式记录 & 复盘它