6月12号凌晨两点，网站运维群里弹出一条告警：主站首页的整改加载时间从1.2秒飙到了8.7秒。我爬起来打开电脑，报告第一眼看到的范文是首页顶部轮播图的位置变成了一个裂开的图标——图片全挂了。再往下翻，网站评论区加载不出来，整改搜索框输入关键词后返回的报告是空白页。这不是范文小毛病。

天亮之后，网站我们拉了个临时小组，整改三个人，报告我、范文后端老张、网站前端小林。整改先把问题拆开看。报告首页图片挂掉是因为CDN回源配置被改错了，原本指向静态资源服务器的路径被误写成了一个内网地址。这个改动是前一天下午上线的，当时只测了文章详情页，没覆盖首页。评论区加载失败是另一个问题：数据库连接池被一个慢查询占满了，那个查询在文章表里做了全表扫描，因为有人删了一个联合索引。搜索框空白是第三个问题，ES集群的一个节点磁盘满了，分片分配失败，但日志里只报了连接超时，没报磁盘错误。

三个问题，三个不同的原因，凑在同一天爆发。表面上看是巧合，实际上暴露的是同一个毛病：我们改东西之前不查影响范围，改完之后不验证全链路。老张后来跟我说，那个索引是半年前加的，当时为了优化一个报表查询，没想到文章列表也在用。小林说CDN配置是运维直接改的，没走发布流程。我说那你们有没有想过，如果首页挂了，用户第一反应是关掉页面，不会去点评论区，也不会去搜索。我们连发现问题都发现得晚。

整改从6月13号开始，到6月20号结束，一共七天。做了几件事。第一，把CDN配置、数据库索引、ES集群参数全部纳入版本管理，任何改动必须走Git提交，不允许在控制台直接改。第二，加了一个首页健康检查脚本，每五分钟跑一次，检查图片、评论区接口、搜索接口三个关键路径，任何一个失败就发告警到值班手机。第三，把慢查询日志的阈值从2秒调到500毫秒，每天自动生成报告发到技术群。第四，ES集群加了两块盘，同时把分片分配策略改成按磁盘使用率动态调整。

这些事听起来不复杂，但做起来花了五天。最麻烦的是历史配置的梳理。老张翻了三年的Git记录，发现至少有二十多处配置是在控制台直接改的，没留任何文档。他一边翻一边骂，说这跟考古差不多。小林那边把前端的资源加载逻辑重写了一遍，图片改成懒加载，评论区接口加了缓存，搜索框加了防抖。我负责写那个健康检查脚本，用Python写的，跑在另一台机器上，不依赖主站。

6月20号晚上，我们做了一次全链路压测。首页加载时间回到1.1秒，评论区接口P99是230毫秒，搜索接口P99是410毫秒。压测到第三轮的时候，ES集群的一个节点又报警了，磁盘使用率到了85%。这次没等它挂，自动扩容脚本直接加了一块盘。老张说，这才叫整改，不是等它炸了再修。

现在过去两周了，首页没再出过问题。但我知道，这种平静是假的。只要还有人直接在控制台改配置，只要还有索引没人知道谁在用，只要还有慢查询藏在日志里，下一次故障就在路上。整改报告写完了，但整改这件事，没有写完的时候。