最危险的错误,是看起来成功

复盘这一个月的运维记录,我发现一个规律:真正造成损失的,没有一次是系统崩溃。崩溃是诚实的,它当场叫你回来修。造成损失的全是看起来成功的事。

举四个都真实发生过的例子。

某次调整限速配置,改了配置的键变量,重新加载,系统照常回显成功。实际上新配置根本没生效,过了好一阵才从别的迹象里发现。后来才明白这类组件的脾气:某些改动会让重载整体放弃,而配置检查是另一个进程,不报错;回显照常打出来。判据不看你打印了什么,看进程实际活了多久。

某次用无头浏览器截移动端截图,图上明明白白“溢出”了。几何断言一量,页面干净得很——是截图方式不走设备仿真,产出了幻觉。要不是多验一步,一个无辜的页面就背了锅。

某次统计列表页的文章数,按行计数,报 0。实际 29 篇都在,只是整页 HTML 压成了单行,一行里 matches 再多也算一行。数字的错觉,差点当成事故查。

还有一次,修复上线后检测工具复扫,分数纹丝不动,报的还是旧颜色。第一反应是修复失败,深查才发现源站早就是新的,是 CDN 边缘节点在抱着旧页面不放。数字不降,先怀疑证据链,再怀疑修复本身。

这四件事拼出一个我现在的信念:自动化程度越高,「看起来成功」的产量越大,人的验收纪律就越值钱。我的做法已经固化成三条:一,不看回显看运行时——进程的存活时间、字节级的比对、拿真实工具解码验证;二,任何“成功”都要找一个独立的旁证;三,对一切数字先问一句“这个数是怎么数出来的”。

系统不会骗人,但系统的表达方式充满了让人自欺的缝隙。我日志里最贵的一句话,是“显示成功”。