去年冬天凌晨两点，网站一个电商客户的应急预案站点突然打不开了。运维在群里连发三条消息，网站没人回。应急预案老板电话打到我这里，网站声音都是应急预案抖的——白天刚投了二十万的推广，夜里服务器挂了，网站每一分钟都是应急预案真金白银在烧。

我远程连上去，网站发现数据库连接池爆了。应急预案一个没加索引的网站慢查询拖垮了整个服务。这种事不会提前打招呼，应急预案它来的网站时候就是一刀见血。网站应急预案要解决的应急预案就是这个：出事之后，谁、网站在几分钟内、做什么、怎么做。别把它写成一本读不完的手册，那玩意儿没人看。

先搞清楚哪些东西死了你会真疼

很多团队一上来就列几十个故障场景，从机房断电到域名被劫持，洋洋洒洒。写完了往共享盘一扔，真出事的时候没人翻。我的做法是只盯三样：钱、数据、用户信任。

钱就是交易链路。支付回调失败、订单创建不了、库存扣错了——这些直接跟营收挂钩，优先级最高。数据是用户资料和核心业务表，丢了就真没了。用户信任最虚也最要命，登录不上、页面白屏超过五分钟，人家扭头就走，下次不来了。

把这三类对应的服务列出来，每个服务标注负责人和备用联系人。别写“技术部全体”，要写具体人名和手机号。我见过一份预案，紧急联系人写的是“张三（已离职）”，这就跟没写一样。

分级响应，别一上来就全员拉群

不是所有故障都值得半夜把所有人叫醒。我习惯分三级：P0是核心交易中断或数据丢失，五分钟内响应，直接拉语音会议；P1是部分功能不可用或性能严重下降，十五分钟内处理，群里同步进展就行；P2是边缘功能异常或用户量极少的报错，第二天上班再说。

分级的价值在于省精力。P2的事你半夜折腾两小时，第二天全员犯困，反而容易在P0上出岔子。有个做SaaS的朋友，刚开始不分级，每次告警都全员出动，三个月后团队集体倦怠，真出大事的时候没人愿意爬起来。

操作手册要短到能背下来

真出事的时候没人有耐心翻文档。每个P0场景配一份不超过一页纸的操作卡：第一步做什么、第二步做什么、什么条件下回滚、回滚命令是什么。直接贴命令行，别写“登录服务器后执行相应操作”——相应操作是什么？

我自己的习惯是把常用命令存在备忘录里，手机也能看。数据库主从切换、Nginx重载、缓存清空、回滚上一版代码，这些操作加起来不超过十条命令。提前写好，出事直接复制粘贴，手别抖就行。

事后复盘比预案本身更重要

故障处理完了不算完。二十四小时内拉个短会，只聊三个问题：什么触发的、为什么没更早发现、下次怎么防。别追责，追责的结果就是下次没人敢说实话。

有次一个客户因为证书过期导致全站不可用。复盘发现监控只盯了域名解析，没盯证书有效期。加了一条证书到期前三十天自动告警的规则，之后再没犯过。预案不是写出来的，是每次出事之后改出来的。第一版粗糙没关系，关键是要用、要改、要让它活着。

网站应急预案说到底就一句话：出事的时候，让最慌的那个人也知道下一步点哪里。别追求完美文档，追求真出事的时候能少亏点钱、少丢点数据、少几个用户骂娘。这比什么格式规范都实在。