网站上线流量归零？运维盲区正 silently 吞噬用户

文章配图，仅供参考

　　我原以为这种低级错误早该绝迹了，结果上周帮某金融公司做压力测试，发现他们生产环境的慢查询日志居然只保留七天——七天！开发说“我们每天看日志”，可流量突增那会儿正好赶上周末，等周一发现时，最早的问题记录早被轮替掉了。更绝的是，他们的监控系统把“QPS下降”和“连接数超限”分成了两个独立告警，结果那天同时触发时，值班运维只看到了QPS告警，以为又是爬虫波动，直接给忽略了。

　　跟开发互怼的群聊里，有个细节我到现在都记得：运维说“你们SQL没加索引”，开发甩出执行计划截图“明明有索引”，结果一查发现是索引失效——因为表数据量涨了三倍，但统计信息还是三个月前更新的。这时候就该怪DBA没开自动统计信息收集？可人家DBA说“我们开了，但收集任务被某个定时脚本给kill了”——至于哪个脚本？没人知道，工单系统里连相关记录都没有。

　　深夜的执行计划最吓人。有次我蹲在机房看某表的全表扫描，发现扫描行数从预期的三千暴涨到三百万，可表大小明明没变。一查发现是某个隐藏的触发器在偷偷更新数据，而这个触发器是半年前某个紧急修复时加的，连文档都没留。更魔幻的是，触发器里调用的存储过程还用了动态SQL，参数拼接时漏了个空格，导致优化器直接放弃了索引。

　　说到动态SQL，上个月某支付公司的事故更绝：他们把用户ID拼进了SQL的IN子句里，结果某天某个VIP用户的ID里带了单引号，直接引发了SQL注入——虽然没丢数据，但把连接池给打爆了。运维事后复盘说“我们防了XSS和CSRF，就是没防这种边界情况”，可问题是，他们的代码审查流程里根本没要求检查动态SQL的参数校验，连最基本的预编译都没做。

　　第三杯咖啡喝完时，我突然意识到，这些事故的共性根本不是技术问题——是运维和开发之间的“信息黑洞”。开发以为运维会监控所有指标，运维以为开发会测试所有边界情况，结果谁都没覆盖到那些“看起来不可能出问题”的角落。就像去年三月那次，慢查询的CPU占用率其实早就超了阈值，但运维的监控大屏把CPU使用率按核数平均了，单个核的爆高被稀释成了“正常”。

　　我见过最离谱的“运维盲区”是某互联网公司的灾备演练。他们号称“双活架构”，结果切换时发现主库的某张表没同步到备库——因为那张表是测试环境用的，后来被开发临时改成了生产表，但同步配置没更新。更绝的是，他们的同步工具会跳过没有主键的表，而那张表恰好没主键——开发说“我们用UUID做唯一标识，不需要主键”，运维说“我们不知道这张表是生产表”，结果切换时直接丢了三小时数据。

　　现在每次听到有人说“我们监控了所有指标”，我都想笑。去年帮某游戏公司做优化时，发现他们的慢查询告警阈值设的是“执行时间超过两秒”，可他们大部分查询的执行时间都在一秒到两秒之间波动——这意味着只要稍微卡一下，就会触发告警，而真正的恶性问题（比如全表扫描）反而被淹没在了海量告警里。后来我们改成“执行时间超过基线50%”，告警量直接降了九成，但真正的问题一个都没漏。

　　优胜劣汰的道理在运维领域特别明显：那些能活下来的系统，往往不是因为技术多牛，而是因为踩过的坑足够多，把所有可能的盲区都填平了。可新系统呢？谁有时间等你踩完所有坑？所以我现在特别反感那种“先上线再优化”的思路——你连监控都没铺全，优化个屁啊？等流量来了，连问题出在哪儿都不知道，只能看着曲线图干瞪眼。

　　下一步我打算搞个“运维盲区清单”，把这些年踩过的坑都列出来，比如“隐藏的触发器”“动态SQL的参数校验”“统计信息过期”“同步工具的跳表规则”……可转念一想，这清单能列完吗？每个系统的业务逻辑都不一样，盲区也千奇百怪。或许真正的解决方案不是列清单，而是建立一套“自查机制”——让开发和运维互相检查对方的“默认假设”，比如开发以为运维会监控索引碎片率，运维以为开发会测试动态SQL的边界情况，这些假设不摆到台面上，永远都是隐患。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!