网站中危

上周三凌晨两点，网站中危我盯着监控面板上那条突然翘起来的网站中危CPU曲线，心里咯噔一下。网站中危网站没挂，网站中危但响应时间从180毫秒蹿到了2.3秒。网站中危用户那边可能只是网站中危觉得“今天有点卡”，可我知道，网站中危这已经踩进中危的网站中危坑里了。

中危这个词，网站中危在安全圈和运维圈里含义不太一样。网站中危安全那边说的网站中危中危，通常指漏洞能导致数据泄露但利用条件苛刻，网站中危或者能搞掉单点服务但进不了内网。网站中危运维这边说的网站中危中危，更像是网站中危一种状态——系统没崩，但已经在悬崖边上晃悠了。我这次遇到的属于后者。

查了半小时，定位到一个商品详情页的接口。平时QPS也就两百出头，那天晚上突然涨到一千二。不是攻击，是运营那边推了个限时秒杀，没跟技术打招呼。数据库连接池被打满，慢查询堆了三百多条。你说这事大吗？不大，重启一下连接池能顶一阵。但要是没发现，再过二十分钟，主库的IO就得跑满，然后整个站点雪崩。

这就是中危最讨厌的地方。它不像高危那样一刀见血——比如SQL注入直接拖库，或者命令执行直接拿shell。中危更像慢性病，平时没感觉，发作起来要命。我见过一个电商站，图片服务器磁盘写满了没人管，结果用户上传的头像全部丢失，客诉电话打爆。磁盘写满算高危吗？不算，但造成的业务影响一点不小。

还有一种中危是配置层面的。比如Nginx的client_max_body_size没设对，用户传个大图就报413。开发觉得是前端问题，前端觉得是后端问题，最后查两天发现是运维漏了个参数。这种问题不会上漏洞扫描报告，但每天都有用户骂骂咧咧地关掉页面。

我自己的判断标准很简单：能靠重启或者加机器扛过去的，算中危；需要改代码或者改架构才能解决的，算高危；重启都救不回来的，那是灾难。按这个标准，大部分线上问题都落在中危区间。它们不致命，但消耗你大量精力，而且反复发作。

去年帮一个朋友看他的小论坛，Discuz搭的，日活不到五百。他说最近老有人注册机刷广告。我登服务器一看，验证码还是最老那种四位数字，没开任何频率限制。这算高危吗？对一个大站算，对他这个体量，撑死算中危。我给他加了个简单的IP限流和滑块验证，世界清净了。但他那个PHP版本还是5.6，我没动。动了可能整个站就起不来了，那才是真灾难。

所以中危的处理策略特别考验人。你不能像对待高危那样一刀切——直接下线服务或者封IP段，业务方会跟你拼命。你也不能像对待低危那样放着不管，哪天量变引起质变，锅还是你的。多数时候，你只能盯着，加监控，设阈值，准备预案。然后祈祷那个阈值别被触发。

我现在养成了一个习惯，每天上班先看三个数：数据库连接数、磁盘IO等待、接口P99延迟。这三个数只要有两个同时飘红，不管有没有报警，我都当一次中危来排查。花二十分钟确认没事，比花两小时救火划算得多。

说到底，网站运维里大部分时间不是在跟黑客斗智斗勇，而是在跟这些不上不下的中危状态周旋。它们不刺激，不光彩，但决定了用户打开你网站时是舒舒服服看完一篇文章，还是骂一句“什么破站”然后点返回。