网站维护日志

凌晨两点十七分，网站维护监控警报把我从沙发上拽起来。日志数据库连接池爆了，网站维护错误日志刷得比弹幕还快。日志我灌了口凉咖啡，网站维护手指在键盘上敲出第一行排查命令——这已经是日志本月第三次了。

问题出在缓存策略上。网站维护当初图省事，日志热点数据全塞Redis，网站维护没设过期时间。日志结果内存像漏水的网站维护桶，一点一点渗光。日志更蠢的网站维护是，代码里有个死循环在批量刷新缓存，日志服务器CPU烧到九十度，网站维护风扇转得跟直升机似的。

我一边骂自己当初偷懒，一边把缓存key按业务模块拆成三档：核心交易数据保留二十四小时，用户画像两小时，流量统计十分钟。改完配置，内存占用从87%降到34%。警报声停下来的那一刻，办公室安静得能听见空调滴水。

第二天早上，产品经理跑过来问昨晚是不是升级了搜索功能。他以为我优化了排序算法——其实只是把索引重建的定时任务从凌晨一点挪到了四点。用户没变，数据没变，但深夜的搜索延迟从1.8秒掉到0.9秒。谁也没想到，凌晨三点的小区宽带拥堵才是真凶。

这行干久了，慢慢摸出个规律：大部分故障不是技术崩了，是技术跟现实世界撞车了。上周五晚高峰，支付回调超时率飙到15%。排查半天，发现是某地光纤被施工队挖断，运营商自动切换线路后，跨省延迟暴涨。代码没变，变的是地下三米的一根光缆。

维护日志最值钱的部分，不是记录了怎么修好，而是记下那些“差点出事”的瞬间。比如周三下午，某个老接口突然返回502，持续了四分钟又自己恢复。查了半天，是隔壁部门上线新系统，误调了我们的测试环境。没造成损失，但那次排查让我把接口鉴权逻辑重新写了一遍——加了调用方白名单和频率限制。

现在我的日志本上密密麻麻写满了类似的事。上周新来的实习生问我，为啥要把这些鸡毛蒜皮记这么细。我说你记的不是故障，是系统的脾气。它什么时候会闹别扭，哪些地方容易卡壳，什么操作会把它惹毛——这些破事，比任何架构文档都真实。

今天下午，监控曲线平稳得让人心慌。我泡了杯茶，把过去三十天的日志翻出来对比。流量峰值后移了二十分钟，用户停留时长多了十一秒，某个冷门页面的点击率涨了三倍——没人知道为什么，但我猜是某个老用户在朋友圈分享了个链接。这种没有结论的观察，我也照记不误。

凌晨四点，手机震了一下。不是警报，是自动备份完成的推送。我关掉电脑，窗外天刚泛白。日志写到今天，满打满算一百四十七天。系统还是那个系统，但我知道它哪个角落藏着什么坑，哪段代码是前任留下的雷，哪台服务器散热风扇有异响。这种默契，不是靠监控指标能量出来的。

明早还有个大版本要上线。但愿这页日志，别出什么幺蛾子。