安全事件应急响应等级，别一上来就定最高级

定级错了，后面全歪。安全事件应急响应等级这东西不好定，但最容易出问题的不是定得准不准，而是一出事就往最高级报，好像不顶格就显得不重视。顶格报完之后人被叫起来一堆，日志没人细看，群里消息刷得比告警还快，正在查的那个人被@到没法干活。等级是用来调资源的，不是用来表态的。

安全事件应急响应等级到底在定什么

它定的不是「这事有多严重」这么虚的东西，定的是一串要兑现的动作：几分钟内有人看、要不要打断周末、通知到哪一层、谁能拍板把服务停掉、事后要不要写报告。等级在内部更像一张通行证，定了高档才有资格去叫醒别人、才有资格申请回滚、才有资格动那个平时没人敢碰的负载均衡。定低了，你就只是建个工单，第二天上班再看。所以别把它当作文题，签之前先问自己一句：这张条子上写的资源，我这边拿得出来吗。

一上来就顶格，代价在哪

一个很常见的场景：上传目录里多了个php文件，站长紧张，直接按最高级走。安全、运维、领导全被叫起来，客户对接人也惊动了，查了两个钟头发现是个陈年测试文件。损失不在这一次，在下一次——真出事的时候群里没人第一时间冒头了，狼来了喊两回就没人信。

还有一层代价比较隐蔽：关键系统被晾着。人的注意力就那么点，一次事件拉进来七八个人，另一条线上正在慢查询的数据库就没人管。定级定高了，挤掉的是别的系统的响应资源，这笔账平时不算，复盘的时候才看得见。

定级看几个维度，别做成评分表

我见过把定级做成打分的，五个维度各占二十分，加完一算再查表。算完黄花菜都凉了，事故还在扩散。实际能用的就那么几条：影响面有多大（用户能不能下单、首页能不能开）、数据敏不敏感、还在不在扩散、对外可不可见、有没有绕过认证。

举两个对比。后台一个运营账号被盗，能发文章能改活动页，但碰不到数据库——这种我一般按中档走，改密码、查登录IP、看看有没有留后门，当天闭环。另一个是数据库账号出现在外网连接日志里，或者备份文件能被直接下载——这种不管有没有被拖走，先按高档起，因为一旦成立就不可逆。

首页被改和一个后台子页面被改，不是一个量级；只能读一个静态页和能直接进管理后台，也不是一个量级。这几条里只要「还在扩散」或者「能绕过认证」有一条成立，我一般就直接往上抬一档，剩下的不细算。模糊着用，比精确着装像。

定低了的坑，比定高了更难补

定高了浪费人力，定低了丢现场。进程被重启过、日志被轮转过、快照按周期被覆盖掉，等你想复盘的时候手里什么都没有。这条我吃过亏：当时觉得是个小异常，重启一下好了，过两天再查，现场已经没了。所以凡是「要不要重启」「要不要重装」这类动作，先定级，再动手。

该通知没通知是另一种麻烦。客户从别的地方知道了事故，比事故本身更伤。至于什么情况要对外报、报给谁、多长时间内报，各家服务商和监管口径不一样，以服务商或官方页面说明为准，别自己拍。

三档够用，允许中途升级

档位不用多。三档足够跑：一档建工单，第二天上班处理；二档当班处理，同时通知业务负责人；三档拉人、启动对外沟通、准备回滚方案。四档五档写出来很漂亮，真出事没人翻那张表。

比档位数量更重要的是允许升级。值班的人先按二档起手，看半小时扩散情况再决定要不要抬到三档，这比一开始拍脑袋定死靠谱。安全事件应急响应等级不是一次定终身，它是个随信息增加会变的判断。降级也要留个记录，写一句为什么降，别悄悄改。

谁拍板，谁记录

值班的人得有升级权，不然等他一层层请示完，事情早过去了。但降级最好别一个人说了算，尤其涉及停服、回滚、对外通报这几种动作。记录就两行：一行写定级依据，一行写时间点。这两行不是写给领导看的，是写给半年后的自己看的——那时候你只记得「处理过一个事」，细节全忘。

别把客户嗓门当技术等级

客户在群里连发十几条，说网站打不开了，情绪很足，这种压力很容易把等级直接推到顶。但声量和严重度是两条线：技术上可能只是一个证书过期，商务上确实是大事。两条线各走各的，技术等级按技术维度定，商务影响单独开一条线通报，别混在一起算，混一起算出来的等级没有参考价值。

要落地，就两件事：把三档写成一页纸，贴在值班的人一眼能看到的地方，写清谁响应、多久响应、通知谁；再规定每次定级都要留一行依据。剩下的靠练，一年挑一次真实的小事故把流程走一遍，比写十页预案有用。定级这活儿，宁可先低后高，别先高后低——往上抬大家都理解，往下压容易伤士气。