工作突发状况怎么处理？我亲历数据库连接被打满后，总结出4步止血法
周五 16:47，我正准备关电脑。钉钉机器人弹出一条 Prometheus 告警：PostgreSQL 连接数 498/500，持续 2 分钟超过 85%。我当时在一家 12 人的 SaaS 小团队，名义上负责产品，实际上什么都要搭把手。Grafana 上 API 5xx 从 0.2% 涨到 17%，P95 从 180ms 拉到 5.2 秒，客服群里已经有客户在问“系统是不是挂了”。说实话，我懵了半分钟，脑子里第一反应是重启数据库，但手没敢点。
一、先别把突发状况当一种东西：4类，优先级完全不同
我后来把工作突发状况分成 4 类，处理顺序完全不一样。线上故障优先止血，例如数据库连接打满、支付回调失败、CDN 回源 502。交付事故优先对齐预期，例如客户明天要演示，但核心功能没跑通。人际突发优先隔离情绪，例如核心同事突然提离职、群里公开甩锅。组织突发优先确认权限，例如老板突然改目标、预算被砍、汇报线换人。分错类型，你就会用“技术方案”去解“人的问题”，越解越乱。
对比一下：大厂遇到线上故障，通常有 on-call、值班表、SRE、事故等级 P0-P3、故障群机器人自动拉人；小团队往往只有“谁看见谁上”。外包项目更麻烦，你没有生产库权限，连日志都要等甲方转发。这不是能力差距，是系统差距。所以别拿大厂模板硬套，先看你手里有几张牌：能否重启、能否回滚、能否联系到决策人、能否让客户等 30 分钟。
二、我的独立观点：先降信息熵，再降技术债
大多数突发状况处理失败，不是技术方案不够好，而是信息熵太高。群里 20 个人，每个人都问“好了吗”“什么原因”“谁负责”，真正能动手的人被消息淹没。我的做法是：一旦确认影响面，立刻建一个临时群，群名写清日期和故障，例如 inc-20240614-db。只拉 6 种角色：直接处理人、备份处理人、客服/销售接口人、决策人、记录人、旁观看板人。旁观看板人只能看，不能问。
同步模板只有 5 行：现在影响谁；影响多大，最好带数字；已经做了什么；下一步做什么；下一次同步时间。比如：影响 3 个付费客户，订单创建失败率 17%；已暂停报表导出，连接池从 20 降到 8；下一步查 pg_stat_activity 慢查询；17:10 同步。禁止在故障群里发“在吗”“有人吗”“这个谁会”，也禁止当场复盘责任。责任是事后的事，当下只做止血。
三、42分钟实操时间线：从498/500到恢复
16:47 告警：PostgreSQL 连接数 498/500，Grafana 显示 5xx 上升。16:49 我确认影响面：不是全部客户，主要是走订单创建和报表导出的 3 个客户。16:52 拉 inc 群，拉了后端 2 人、运维 1 人、客服 1 人、销售 1 人，共 6 人。16:55 先止血：暂停两个定时报表任务，把应用连接池 pool_size 从 20 调到 8，重启两个 worker，不是重启数据库。17:03 连接数降到 210，5xx 从 17% 降到 3.8%，但还没完。
17:08 根因假设：销售为了周五演示，让大客户导入 12 万行 CSV，导入脚本直接连生产库，没走队列，也没限流。17:15 把导入任务切到只读从库，限制每秒 200 行。17:29 连接数回到 90 左右，P95 回到 240ms，客服通知客户“可重试，失败订单会人工核对”。17:40 我把时间线写进事故记录，只写事实，不写“谁粗心”。整个过程中，最危险的动作是“重启数据库”，因为连接会瞬间打满，可能让恢复更慢。
四、事后复盘：只改一个变量，别写20条整改
很多团队复盘会写 20 条整改，最后一条都没落地。我的规则是：下一次迭代只允许改一个变量。我们当时只先做了一件事：加监控规则，连接数 > 400 持续 1 分钟告警，并区分主库/从库。第二周才做导入任务独立库，第三周才做连接池隔离。每件事都有负责人和日期，没日期的不进看板。复盘文档不超过 1 页，包含：影响客户数、持续时间、直接原因、触发条件、一个改进项、验证方式。
对比大厂和小团队：大厂可以上混沌工程、全链路压测、故障演练，成本高但提前暴露问题；小团队更现实的是“限制爆炸半径”：大导入走独立库、周五 16:00 后禁止大变更、生产库权限只给 2 个人、每个定时任务有开关。外包团队则要先谈权限和响应时限，写进合同：日志访问几小时内给、生产变更谁审批、故障联系人是谁。别等出事再找甲方。
五、如果你现在正遇到突发状况，按这5步走
第一步，10 分钟内确认影响面：多少客户、哪个功能、错误率、开始时间。第二步，建临时群，只拉必要的人，设一个记录人。第三步，能止血就先止血，降级、限流、回滚、暂停任务，比找根因优先。第四步，每 10-15 分钟同步一次，用数字说话，不用“快好了”。第五步，恢复后 24 小时内写一页事故记录，48 小时内定一个改进项。别贪多，突发状况最怕的是“边救火边开大会”。
最后说点个人感受。那天我手是抖的，但我在群里只打了三句话：影响面、已做动作、下次同步时间。不是因为我冷静，是因为我知道一旦群里开始刷“完了”，所有人都会失去节奏。工作突发状况不会越来越少，它只会换形式。你能练的不是预测所有意外，而是让团队在意外里少说废话、少做危险动作、少改一堆变量。这个能力，比任何应急预案都值钱。