内容摘要：凌晨三点，运维群里弹出一条消息：主站返回502，负载均衡器健康检查全红。值班同事从床上爬起来，花了22分钟才把服务拉回来。事后复盘发现，问题本身不复杂——某个后端节点磁盘写满，导致健康检查失败，流量却

凌晨三点，网站运维群里弹出一条消息：主站返回502，应急预案负载均衡器健康检查全红。网站值班同事从床上爬起来，应急预案花了22分钟才把服务拉回来。网站事后复盘发现，应急预案问题本身不复杂——某个后端节点磁盘写满，网站导致健康检查失败，应急预案流量却没有自动摘除。网站真正让人后背发凉的应急预案是：从故障发生到有人察觉，中间隔了整整11分钟。网站这11分钟里，应急预案用户看到的网站是错误页，而团队没人知道。应急预案

这就是网站为什么每个网站都需要一份应急预案。不是那种写在Confluence里落灰的文档，而是能在凌晨三点把你叫醒、并且让你知道第一步该做什么的东西。

先搞清楚：你的网站最怕什么

预案不是从“怎么写”开始的，是从“怕什么”开始的。拿电商站举例，最怕的通常不是服务器宕机——宕机反而好办，切流量、重启、换节点，路径清晰。真正棘手的是数据库主从延迟飙升、支付回调丢失、CDN被刷流量这类“半死不活”的状态。服务没挂，但用户在骂。

所以第一步是列清单。把过去一年出过的故障翻出来，按影响面和恢复时长排个序。再让开发、运维、客服各写三条“我最怕发生的事”。三份清单叠在一起，基本就是你的风险地图。

分级响应，别拿大炮打蚊子

不是所有故障都值得把CTO从被窝里拽出来。我们内部把事件分成三级：P3是单节点故障、页面样式错乱这类，值班工程师自行处理，事后报备；P2是核心功能不可用但可降级，比如搜索挂了但下单正常，需要组长介入；P1是全站不可用或数据面临丢失风险，触发全员响应。

分级的意义在于：P3不需要开会，P1不需要犹豫。最怕的是所有故障都走同一套流程，结果小问题拖成大事故，大事故还在等审批。

每个角色知道自己该干什么

预案里最没用的一句话是“相关人员立即处理”。“相关人员”是谁？“立即”是多快？我们后来改成具体到人：值班工程师负责5分钟内确认故障等级并拉群；DBA负责数据库相关操作的执行；前端负责人判断是否需要切静态降级页；客服主管在10分钟内拿到对外话术模板。每个人只记自己的动作，不用背整本预案。

降级方案比修复方案更重要

故障发生时，第一目标不是“修好”，是“让用户能用”。我们给主站准备了静态降级页，商品详情挂掉时自动切到缓存版本，下单接口超时则引导用户稍后重试并自动发放优惠券补偿。这些降级逻辑平时就写好、定期演练，真出事时一个开关就能生效。修数据库可能要一小时，切降级页只要三十秒。

演练不是走过场

每季度我们会做一次“盲演”：随机挑一个非核心服务，人为制造故障，不提前通知。观察的是：多久有人发现？第一反应是什么？沟通渠道是否顺畅？有一次演练暴露了一个尴尬问题——值班同事在群里@了所有人，但没人知道谁该去查日志。后来我们加了“第一响应人”轮值制度，每天有一个人专门负责初期排查。

复盘要写，但别写成八股

故障恢复后48小时内出复盘报告，只写三件事：时间线（精确到分钟）、根因（至少问五个为什么）、改进项（必须有负责人和截止日期）。不写“加强监控”这种废话，改成“在Nginx层增加对后端节点磁盘使用率的主动探测，超过85%自动摘除，老王负责，下周三前上线”。

预案不是写完就完了。每次故障、每次演练、每次架构调整，都要回头改一版。我们那份预案从最初的3页变成了现在的11页，但值班同事说，真出事时翻到的那一页，永远是最新的。