凌晨 3 点线上挂了，你只有一个人：独立开发者的事故响应 Runbook

凌晨三点，你的手机在震动

先还原一个每个独立开发者都经历过的场景：凌晨 3 点 17 分，手机在床头柜上震。你迷迷糊糊摸过来，看到 Telegram 里躺着一条 "DOWN: api 挂了"。你脑子里同时闪过五个问题：是真挂了还是监控误报？多少用户受影响？上次发布是几点？我现在该先看日志还是先回滚？要不要发个公告？

大公司有答案：on-call 轮班表、值班手册、事故指挥官、war room。但你没有。你就是轮班表、值班手册和事故指挥官本人——而且是凌晨 3 点、认知能力只剩白天三成的那个版本。

这篇文章是写给那个版本的你的。它不讲"如何预防事故"（那是可观测性和测试的事），只讲一件事：报警响了之后，你一个人，按什么顺序做什么。全文 10 节，前 5 节是"战时动作"，后 5 节是"模板与复盘"。建议你今晚花 1 小时，把第 3 节的告警通道搭好、第 5 节的回滚命令练一遍——事故不会等你准备好。

先划清和已发文章的边界：本站之前发过《给 vibe 项目装上「眼睛和耳朵」：一人团队的可观测性实战》，那篇讲怎么装监控、看日志、设告警，是"报警之前"的事。这篇是它的续集——报警之后，你怎么办。

一、承认现实：on-call 就是你，没有轮班表

一人团队的事故响应和大公司的最大区别，不在于工具，而在于决策者只有一个，且这个决策者会在半夜被叫醒。大公司的 runbook 是为了"让任何一个值班的人都能按流程走"；你的 runbook 是为了"让凌晨 3 点的你，能按白天的你写好的流程走"。这是两种完全不同的写作对象：前者防新人犯错，后者防你自己犯蠢——困、慌、急的时候，人会做白天绝不会做的事，比如直接在生产环境改代码。

所以这份 runbook 的第一原则是：所有决策前置。什么时候起床、什么时候回滚、什么时候发公告，这些判断不要在凌晨 3 点做，要在现在——清醒的周日晚上——做。事故发生时你只负责执行，不负责思考。这听起来有点反直觉，但所有成熟的应急体系都是这个逻辑：消防员不会等进了火场才开始想灭火步骤。

第二原则是：runbook 必须短。大公司的事故手册可以 50 页，因为 war room 里有 10 个人分头看。你的 runbook 超过一页纸，凌晨 3 点你就不会看。后面给你的所有模板都按"一页纸"标准写：分级清单是一张表，黄金 15 分钟是 5 个动作，回滚 SOP 是 10 行命令。能背下来的流程，才是事故时真正存在的流程。

核心判断：一人团队不需要"更完善"的事故流程，需要"更短"的。完善是给有 10 个人的团队用的，短是给只有你一个人的凌晨 3 点用的。

二、事故分级：三档判定清单，以及最重要的"放过清单"

分级的意义只有一个：决定你现在要不要起床。一人团队没有"升级给二线"的选项，分级直接对应你的睡眠。我的版本只有三档，判定标准全部围绕"损失是否在扩大"：

• SEV1：立刻起床，正在发生不可逆损失。判定条件（满足一条即 SEV1）：支付链路挂了（用户付不了钱、扣款异常）；用户数据在丢失或损坏；全站不可用超过 5 分钟；安全事件（数据泄露、未授权访问）。共同点：每一分钟都在烧钱、烧数据或烧信任。
• SEV2：天亮处理，睡前花 5 分钟看一眼。判定条件：核心功能部分受损但有替代路径（比如 AI 生成功能挂了，但历史记录还能看）；非付费链路全挂（博客、落地页）；性能严重下降但服务可用。共同点：用户疼，但损失不在扩大，明早 9 点处理和凌晨 3 点处理，结果几乎一样。
• SEV3：记下来，下个工作日修。判定条件：边缘功能 bug、偶发且影响面小、文案或样式问题、单个用户反馈且无法复现。共同点：记下来比爬起来重要。

重点来了——"放过清单"。我见过太多独立开发者（包括三年前的我）把 SEV3 当 SEV1 处理：凌晨 3 点爬起来修一个只有 3 个用户遇到的边缘 bug，修到 5 点，第二天白天效率归零，第三天在疲惫中推了一版有问题的代码，制造了一场真正的 SEV1。这就是事故响应的黑色幽默：过度响应本身会制造事故。

所以我的铁律是：凌晨 3 点起床的唯一标准，是"损失正在扩大，且只有我能止住"。两个条件缺一不可：损失没在扩大（SEV2/SEV3），回去睡；损失在扩大但用户自己能绕过去、或者等天亮处理结果一样，回去睡。SEV2 和 SEV3 的正确处理方式，是花 30 秒在手机上记一条待办，然后继续睡。你的睡眠是第二天产品迭代的燃料，为 SEV3 熬夜等于拿明天的收入换今天的安心——不划算。

判定清单建议存成手机备忘录置顶，事故时 10 秒内能翻出来：

事故分级速查（独立开发者版）
SEV1 立刻起床：付钱链路挂 / 数据在丢 / 全站 500 / 安全事件
SEV2 天亮处理：核心功能部分坏但有替代路 / 非付费链路挂 / 严重变慢但可用
SEV3 记下睡觉：边缘 bug / 偶发小问题 / 文案样式 / 无法复现的个案
起床标准：损失正在扩大 AND 只有我能止住。两个条件缺一不可。

一句话版本：SEV1 是"着火了"，SEV2 是"有烟"，SEV3 是"有人说好像闻到烟味"。只有着火值得你凌晨 3 点起床。

三、告警通道：15 分钟、0 元、能把你叫醒

先说一个残酷的事实：邮件告警等于没有告警。半夜没人看邮件，白天邮件也被淹没在各种通知里。告警通道的唯一 KPI 是：SEV1 发生时，5 分钟内把你从床上叫起来。达不到这个标准，其他做得再漂亮都是摆设。

一人团队今晚就能搭好的思路只有一种：外部可用性监控 + 强推送。为什么必须是外部监控？因为你自己的服务器挂了，跑在同一台机器上的监控脚本大概率一起死——让别人替你看着，才叫监控。vibe 项目大多跑在 Vercel、Railway、Render 这类平台上，平台自带的状态通知只能告诉你"平台挂了"，告诉不了你"你的应用挂了"，这一层必须自己补。

选型表（全部有免费档，搭建都是 15 分钟量级）：

环节	方案	免费额度	优点	缺点
可用性监控	UptimeRobot	50 个监控点，5 分钟间隔	注册即用，老牌稳定	免费版间隔 5 分钟，发现延迟稍高
可用性监控	Better Stack	10 个监控点，3 分钟间隔 + 免费状态页	监控和状态页一体，界面现代	免费监控点较少
可用性监控	自建 Uptime Kuma	无限制（自己出服务器）	1 分钟间隔，功能全，可挂 Telegram 通知	要自己维护，服务器挂了它也挂——只适合做第二层
强推送	Telegram Bot	完全免费	消息必达、可置顶、可设特殊提示音	需要科学上网环境（对国内开发者是硬伤）
强推送	Bark / Server 酱	免费	直接推到 iOS / 微信，国内可用	Bark 只支持苹果，Server 酱依赖微信模板消息
强推送	Pushover	一次性 5 美元	可设"紧急优先级"持续响铃直到确认	要花 5 美元（但这是全表最值得花的 5 美元）

我的判断很直接：先用 UptimeRobot（或 Better Stack）+ 你手头最顺手的推送，今晚就搭起来。别在选型上纠结一周——告警通道的价值在于"有"，不在于"完美"。一个 5 分钟间隔的免费监控，胜过下周才搭好的 1 分钟间隔的完美方案。等你有了第一个付费用户，再考虑 Pushover 的紧急优先级（持续响铃直到你确认，那 5 美元是全表 ROI 最高的一笔 spending）。

另外补两个容易被漏掉的监控项：一是 SSL 证书过期（UptimeRobot 免费版就带证书过期提醒，多少 vibe 项目死于某天早上证书过期）；二是关键词监控——不只监控"服务通不通"，还要监控"关键页面包不包含某个关键词"，比如支付成功页必须包含"订单号"，防止"服务 200 但业务逻辑全挂"的假活状态。

告警通道的验收标准只有一条：找个周末白天，手动把服务停 5 分钟，看手机会不会响。没演练过的告警通道，等于没有。

四、黄金 15 分钟：止血的 5 个固定动作

SEV1 确认，起床了。接下来 15 分钟只做 5 件事，按固定顺序，一件做完再做下一件。这个顺序是我从几次真实事故里提炼的，每一步的"为什么"都对应一个曾经踩过的坑：

1. 冻结发布（第 0-2 分钟）。第一件事不是看日志，是锁死发布通道：Vercel / Railway 上暂停自动部署，或者在群里（如果有协作者）发一句"现在起禁止 push"。为什么放第一？因为一半以上的事故恶化，都来自慌乱中的"再推一版试试"。人在凌晨 3 点的直觉是"做点什么"，而"做点什么"里最危险的就是改代码。先让系统保持现状，现状再烂，也比"现状 + 一版没经过 CI 的热修"强。
2. 确认影响面（第 2-5 分钟）。回答三个问题：多少用户受影响？是哪个链路？从什么时候开始的？看监控看板和错误追踪（Sentry 之类），不要直接钻进日志——日志是显微镜，影响面是地图，先看地图。影响面决定后面所有决策的力度：只有 5% 用户受影响的支付 bug，和全站 500，是两种完全不同的处理节奏。
3. 看最近变更，不看代码逻辑（第 5-10 分钟）。直接查"最近一次发布是什么时候、改了什么"。经验数字：线上事故里超过一半和最近一次变更直接相关。先看 git log、发布记录、 feature flag 的开关状态，而不是打开代码逐行找 bug。找 bug 是"修"，找变更是"定位"，止血阶段只需要定位。如果你用 AI 写代码，这个习惯更重要——AI 一次改 20 个文件时，你根本记不住它动了什么，只有发布记录是可信的。
4. 回滚或切流量（第 10-15 分钟）。如果 10 分钟还没定位到根因，回滚。注意这不是"建议"，是写进 runbook 的硬规则：10 分钟定位不到 = 回滚。回滚不需要知道根因，回滚只需要知道"上一个版本是好的"。切流量的变体：如果用了 feature flag，直接关掉新功能的 flag，比整站回滚更快。具体 SOP 见第 5 节。
5. 对外发声（和第 4 步并行）。状态页更新一句"我们已知晓服务异常，正在处理"，社群里同步一句。哪怕你还没找到原因，也要先发声。沉默是信任杀手：用户能接受"服务挂了"，不能接受"服务挂了且没人说话"。SEV1 的公告不需要完美，需要快——"已知晓 + 正在处理 + 每 30 分钟更新"是万能公式。

注意这 5 个动作里没有"修 bug"。黄金 15 分钟的目标不是"修好"，是"止血"——让损失停止扩大。修 bug 是止血之后、喝着咖啡慢慢干的事。把"止血"和"修复"混在一起，是新手最常见的错误：你在全站 500 的情况下改代码，每改一次都在赌。

五、一键回滚 SOP：已经发布、必须回滚时的执行清单

回滚之所以需要 SOP，是因为它反直觉：人都想"再查 10 分钟找到根因"，回滚感觉像认输。但数据站在回滚这边——回滚是回到"已知好的状态"，热修是押注"我的新改动是对的"。凌晨 3 点，你的判断力不配押注。

先说前置条件。回滚 SOP 能成立，依赖三件事，平时就要准备好，事故时现准备来不及：

• 每次发布打不可变的版本 tag（git tag + 容器镜像 tag），回滚目标必须是一个明确的版本号，而不是"上一个"。Vercel / Railway / Fly.io 都支持一键回退到某次部署，先去控制台找到那个按钮在哪——事故时现找等于没有。
• 数据库迁移必须可逆或向前兼容。这是回滚最大的坑：代码回滚了，数据库迁移回不去。铁律是：删字段、改字段类型的迁移，永远分两步走（第一步加新字段双写，第二步下线旧字段）；只做加字段、加表的迁移，回滚才安全。如果这次事故就是迁移惹的祸，回滚代码之前先确认数据层能不能回。
• 回滚命令必须一条能执行。把回滚步骤写成脚本或收藏成书签，别指望凌晨 3 点的你能想起 fly deploy --image xxx 的完整参数。

执行清单（复制到你的 runbook 里，事故时逐项打勾）：

一键回滚 SOP（SEV1 且 10 分钟未定位根因时执行）
[ ] 1. 确认回滚目标版本：上一个稳定版本的 tag / 部署 ID：________
[ ] 2. 数据库检查：本次发布是否含破坏性迁移？是 → 停止，先处理数据层；否 → 继续
[ ] 3. 执行回滚：平台一键回退 / fly deploy --image <tag> / vercel rollback
[ ] 4. 验证：健康检查端点返回 200，核心链路（登录→下单→支付）手动走一遍
[ ] 5. 监控观察 10 分钟：错误率曲线回落到基线
[ ] 6. 状态页更新：从"处理中"改为"已恢复，正在观察"
[ ] 7. 冻结发布 2 小时：根因没找到之前，不推任何新代码
注意：回滚后不要立刻"修好再发布"，先睡，天亮再复盘（见第 8 节）。

回滚决策的硬规则，写进 runbook："10 分钟定位不到根因，无条件回滚"。这条规则保护的不是系统，是你——它把"要不要回滚"从凌晨 3 点的艰难决策，变成白天的你早就做好的决定。

六、事故时间线模板：进行中就开始记，不要事后补

时间线是事故响应里最容易被跳过、事后最后悔没写的东西。它的价值有两个：一是进行中帮你保持节奏——写下来"14:05 做了什么"，能防止你在慌乱中重复做同一件事；二是复盘时唯一可信的素材。事后补的时间线全是美化过的：你会不自觉地把"我瞎试了 40 分钟"写成"我系统地排查了 40 分钟"。

所以规则是：时间线在事故进行中就开始记，手机备忘录、纸、都行，格式不重要，时间戳重要。每做一个动作记一行，精确到分钟。下面是整理成文档的模板，事故结束后 10 分钟内填完归档：

# 事故时间线 — <一句话标题，如：支付回调 500 导致掉单>

- 事故编号：INC-20261011-001（日期 + 当天序号）
- 级别：SEV1 / SEV2 / SEV3
- 开始时间：2026-10-11 03:17（UTC+8）
- 发现方式：告警推送 / 用户反馈 / 自己发现
- 影响面：约 XX 用户 / 支付链路 / 持续 XX 分钟
- 负责人：<你的名字>（一人团队就写自己，写下来是为了复盘时知道"当时只有我"）

## 时间线（所有时间用 UTC+8，精确到分钟）
- 03:17 — UptimeRobot 告警：API 5xx 比例超过阈值
- 03:19 — 确认影响面：支付回调接口 500，约 30% 订单受影响
- 03:21 — 冻结发布，暂停自动部署
- 03:24 — 查发布记录：02:40 发布 v1.4.2，改动了回调验签逻辑
- 03:29 — 10 分钟未定位根因，执行回滚到 v1.4.1
- 03:35 — 回滚完成，错误率回落到基线
- 03:40 — 状态页更新为"已恢复，正在观察"
- 04:00 — 观察 20 分钟无复发，发布恢复，睡觉

## 根因（一句话，先占位，复盘时再精确）
<如：v1.4.2 的验签逻辑未兼容旧版回调参数，导致验签失败抛 500>

## 行动项（复盘后补，见第 8 节）
- [] <行动项 1> 负责人：我 截止：<日期>

注意模板里"发现方式"这一栏：如果你连续三次事故的发现方式都是"用户反馈"而不是"告警推送"，说明你的告警通道是摆设——这是时间线模板附赠的自我审计功能。

七、沟通模板：状态页公告、社群公告、付费用户邮件

一人团队在沟通上有个天然劣势：没人帮你写公告。但也有个天然优势：用户对独立开发者的容忍度远高于大公司，只要你诚实、及时、说人话。沟通的三条铁律：不甩锅（用户不关心是 Vercel 挂了还是你的 bug，写"我们的服务"就够了）；不承诺具体恢复时间点（除非你 100% 确定，用"每 30 分钟更新一次"代替）；SEV1 必须给付费用户单独发邮件，免费用户看状态页就够了。

模板 1：状态页公告（四阶段，直接填空）

<时间> — 我们监测到 <服务/功能> 出现异常，<一句话描述用户侧症状>。
技术团队（就是我）正在定位原因，每 30 分钟更新一次进展。


<时间> — 已定位原因：<一句话根因，如：今日发布的验签逻辑存在兼容问题>。
正在执行回滚 / 修复，预计 <时间> 前恢复。（只有确定才写预计时间）


<时间> — 服务已恢复，错误率回到正常水平，正在持续观察。
如仍遇到问题请回复本邮件 / 在社群 @ 我。


<时间> — 事故已解决，服务完全恢复。本次事故影响 <时长/范围>，
详细复盘将在 <日期> 发布在博客 / 社群公告。

模板 2：社群公告（Discord / 微信群 / Twitter，口语化）

刚收到告警，<功能> 从 <时间> 开始不稳定，
<一句话症状>。我正在处理，状态页会实时更新 👉 <状态页链接>
预计每 30 分钟同步一次进展。受影响的朋友可以直接在这里 @ 我。
（恢复后追加一条：已恢复，观察中。这次是我的问题，复盘会发出来。）

模板 3：付费用户邮件（SEV1 专用，事故后 24 小时内发出）

主题：关于 <日期> <服务> 故障的说明与补偿

Hi，我是 <你的名字>，<产品名> 的独立开发者。

<日期> <时间段>，<服务> 发生了约 <时长> 的服务中断，
原因是 <一句话根因，不说黑话>。在此期间 <具体影响，如：约 30% 的
订单未能及时回调，但没有造成资金损失，数据已全部补齐>。

这次事故的完整复盘在这里：<链接>。
为表歉意，你的账户已延长 <X> 天会员 / 已发放 <X> 元代金券。

一人维护产品，故障难免，但"及时说清楚"是我能给你的承诺。
有任何问题直接回复这封邮件，我会亲自回。

<你的名字>

关于补偿说一句：独立开发者不需要学大公司的"按 SLA 赔付"表格，延长几天会员真诚道歉，效果远好于抠字眼的 SLA 条款。用户为独立产品付费，买的本来就是"一个靠谱的人在维护"，事故沟通恰恰是展示"靠谱"的最高光时刻——处理得好，一场 SEV1 能换来一批更忠诚的用户。

八、复盘模板：无责复盘的 5 个问题、一个根因、一个行动项

"无责复盘"对大公司意味着"不对当事人追责"，对一人团队意味着更难的一件事：不对自己进行道德审判。复盘时你很容易写成"我太蠢了，居然没发现那个 bug"——这种自我批斗除了让你下次不敢写真实根因，一点用没有。复盘的对象是系统，不是人，哪怕这个"人"就是你。

模板固定为 5 个问题 + 一个根因 + 一个行动项，多一个不要：

# 事故复盘 — INC-20261011-001

## 5 个问题
1. 发生了什么？（只讲事实，不讲感受：什么时间、什么症状、持续多久）
2. 影响有多大？（多少用户、哪个链路、有没有丢数据/丢钱，量化）
3. 根因是什么？（技术根因一句话，见下）
4. 为什么没有更早发现？（告警缺失 / 告警没叫醒我 / 监控有盲区）
5. 下次如何更快恢复或根本避免？（对应下面的行动项）

## 一个根因（用 5 Why 往下钻，只写最后一条）
例：支付回调 500 → 验签逻辑没兼容旧参数 → 发布前只测了新版回调 →
没有旧版回调的自动化测试 → 每次发布靠人工点一遍。
根因：关键链路的发布验证依赖人工，没有自动化回归。

## 一个行动项（有且只有一个，必须可执行）
- [] 给支付回调加新旧双版本参数的自动化回归测试，接入 CI 发布门禁
负责人：我 截止：2026-10-18
验收标准：下次发布前 CI 自动跑，挂了就拦住发布

注意"有且只有一个行动项"的设计：一人团队的行动项超过一个，等于零个。你的带宽只够做一件，那就只写一件——写最重要的那件。行动项还必须满足"第 9 节的标准"：要么变成一条告警规则（下次更早发现），要么变成一颗自动化测试（下次发布前拦住）。写"下次小心一点"这种行动项，不如不写。

复盘的验收标准：三个月后重看这篇复盘，你能清楚说出"因为那次事故，我现在多了哪条告警/哪个测试"。说不出来，这篇复盘就是废纸。

九、预防闭环：每次事故必须沉淀为一条告警或一颗测试

第 8 节的行动项二选一，这里展开讲透。告警规则解决"发现"问题，自动化测试解决"拦截"问题，一次事故至少要堵住其中一头：

• 沉淀为告警规则——适用于"发现太晚"类事故。例子：这次是用户先发现支付回调挂了，告警没响 → 加一条"支付回调 5xx 比例超过 1% 持续 2 分钟就推送"的规则。告警规则越具体越好，"API 5xx 告警"不如"支付回调 5xx 告警"——前者半夜叫醒你 10 次有 9 次是误报，误报多了你就会关掉告警，那才是真正的灾难。
• 沉淀为自动化测试——适用于"发布带 bug"类事故。例子：验签逻辑没兼容旧参数 → 加一个"旧版回调参数必须验签通过"的回归测试，放进 CI 发布门禁。vibe 项目的测试策略不需要全覆盖，只给"挂了会丢钱/丢数据"的链路写测试，其他随缘——这是独立开发者的测试 ROI 最优解。

再补一个多数人没做过的动作：每月一次的一人版"消防演习"。找个周末白天，在 staging 环境故意搞挂一个服务，然后按这篇 runbook 走一遍：告警响没响、几分钟看到、分级判得对不对、回滚命令一次成功还是翻了文档。演习时发现的问题（比如回滚命令少了个参数），都是免费的；事故时发现的，都是拿用户信任交的学费。演习不用隆重，30 分钟，泡杯咖啡，当成游戏打。

最后给预防闭环定个 KPI：同一根因的事故不允许发生第二次。第一次是学费，第二次是失职。如果同一个告警规则缺失导致了两次事故，说明你的复盘行动项根本没执行——回去看第 8 节重写。

十、反模式：5 个一人团队事故响应最常见的错误

1. "再给我 10 分钟"说了 6 次，天亮了还没回滚。这是头号反模式。定位问题有心流快感，回滚有认输感，人性会让你一直"再查 10 分钟"。解法就是第 5 节的硬规则：10 分钟定位不到，无条件回滚。把决策权从凌晨 3 点的你手里拿走，交给白天的你。
2. 直接热修生产。跳过 CI、跳过测试，在服务器上 vim 改代码，改完"好像好了"。热修的问题不是"这次没修好"，而是"生产环境和代码仓库从此不一致"——下次发布会把热修覆盖掉，同一个 bug 会回来找你两次。热修一时爽，排查火葬场。
3. 事故期间连环发布。慌乱中"修一下推一版，好像更糟了，再推一版"，一晚上推了 4 版，每版都让水更浑。第 4 节第 1 步"冻结发布"就是防这个的：止血期间，发布通道是只读的。
4. 沉默。用户在群里问了两小时"是不是挂了"，你因为忙着排查一句没回。记住：用户能接受故障，不能接受被无视。发声只需要 30 秒（第 7 节的模板复制粘贴），30 秒换用户信任，是全场 ROI 最高的操作。
5. 复盘写完不执行，或者复盘开成自我批斗。前者让复盘变成废纸（第 8 节的验收标准就是防这个的），后者让你下次不敢写真实根因，复盘越写越假。复盘时对自己说这句话："系统有问题，不是我有问题；我要修的是系统。"

今晚的 1 小时待办：把 runbook 变成你的

文章看到这里，别收藏了事。今晚花 1 小时，做完下面 4 件事，你的事故响应能力就超过了 90% 的 vibe 项目：

1. 15 分钟：注册 UptimeRobot（或 Better Stack），加上首页、API 健康检查、支付链路三个监控点，接上 Telegram / Bark 推送。
2. 10 分钟：把第 2 节的分级速查存成手机备忘录置顶，再加一条："SEV1 才起床，其他的记下来睡觉"。
3. 15 分钟：找到你部署平台的"回退到某次部署"按钮，点进去看一眼，确认你知道在哪；把回滚命令写成备忘录。
4. 20 分钟：复制第 6、7、8 节的模板，存进你的笔记软件，填上你的产品名和状态页链接——事故时你没时间填空。

最后重复一遍这篇的核心观点：一人团队的事故响应，拼的不是技术，是"凌晨 3 点的你"能不能执行"白天的你"写好的流程。runbook 是你留给深夜自己的唯一援军。现在去写，趁你还清醒。