网站安全应急预案

凌晨三点，网站监控大屏上一条告警弹出：数据库连接数飙到峰值，安全CPU使用率逼近100%。应急预案值班工程师揉了揉眼睛，网站确认这不是安全误报——攻击者正用分布式请求冲击登录接口，每秒上千次的应急预案尝试像潮水一样拍打着服务器。

这种场景，网站任何网站都可能遇到。安全预案不是应急预案写来应付检查的，是网站拿命换来的经验。我见过太多团队，安全平时不演练，应急预案真出事时手忙脚乱，网站连日志都不知道去哪查。安全

先把角色定死。应急预案谁负责决策？谁动手操作？谁对外沟通？别搞“全员参与”那套虚的——出事儿时，现场能拍板的人最多两个。一个技术总指挥，懂架构，能判断是断网、被黑还是代码bug；一个对外联络人，管客户、管媒体、管上级。其他人该干嘛干嘛，别在群里刷屏“+1”。

其次，通信录必须贴在墙上。不是手机里存着就行——服务器宕机时你未必能解锁手机。打印一份，包含云服务商24小时电话、域名解析商、安全厂商应急响应团队，甚至包括机房所在大厦的物业电话。我经历过一次事故，最后发现是机柜空调漏水，物业电话比安全专家管用。

分级响应，别一上来就拔网线。小问题，比如某个页面被挂马，先隔离服务器，保留现场证据，再分析入侵路径。大问题，比如核心数据库被勒索加密，立刻启动备份恢复流程，同时报警。这里有个细节：备份不能只存一份，至少做“3-2-1”策略——3份数据，2种介质，1份异地。否则攻击者连你的备份一起删，那才叫欲哭无泪。

演练比预案本身重要。每季度搞一次故障注入，故意把某个服务停掉，看团队反应。第一次演练，我们的人花了20分钟才找到备用服务器入口——因为平时没人碰过那台机器。后来把登录方式写进运维手册，第二次演练缩短到3分钟。纸上谈兵没用，得真刀真枪练。

恢复业务不等于结束。事后两小时必须出初步报告：什么时间、什么原因、影响范围、已采取措施。别等完美结论——攻击者手法往往复杂，先给个中间版本，让管理层和客户安心。三天内出完整复盘，包括日志分析、漏洞修补、流程改进项。我见过最糟糕的案例，事发了半个月，报告还写“原因正在排查中”，客户直接流失三分之一。

最后说点实在的。预案里必须留一条“认怂”路径——如果攻击强度超出能力，别硬扛。该切CDN的切CDN，该上高防IP的上高防，甚至临时把网站改成只读模式。保住数据，比保住在线时长重要。用户能理解你被攻击，不能接受你数据丢失。

网站安全没有一劳永逸。预案是活文档，每次事故都是更新机会。别等出了大事才翻出来看——平时多读两遍，心里有数，手上有招，真到凌晨三点那一刻，你才能冷静地按下那个正确的按钮。