上周三凌晨两点，网站维护监控告警显示主站响应时间从180ms飙到2.3秒。工作我爬起来连上VPN，总结发现是网站维护某个促销页面的图片没压缩，单张图12MB，工作用户一窝蜂进来直接拖垮了带宽。总结这种事不是网站维护第一次了，但每次原因都挺具体——不是工作“系统需要优化”这种空话，而是总结某个文件、某行配置、网站维护某个忘记关掉的工作调试接口。

先说这季度处理最多的总结：数据库慢查询。三月份用户反馈“订单列表打不开”，网站维护我抓了slow log，工作发现一条查三个月前订单的总结SQL没走索引，全表扫了470万行。加上索引后从8秒降到0.3秒。类似的问题还有三个，都是业务迭代时新加的查询条件没跟上索引调整。我的做法是每周五下午跑一遍pt-query-digest，把Top 5慢查询拎出来，能当场改的改，改不了的排进下个迭代。这比等用户投诉再动手强得多。

缓存这块踩了个坑。四月初为了扛住流量高峰，给商品详情页加了Redis缓存，结果忘记设过期时间。三天后运营改了价格，前端还是旧数据，客服电话被打爆。后来改成主动刷新+5分钟兜底过期，又加了个后台按钮让运营自己清缓存。技术方案再漂亮，不给业务留手动开关就是给自己挖坑。

安全方面没出大事，但小动作不断。五月扫描发现后台登录接口没限制失败次数，有人用脚本跑了六千次弱密码尝试。虽然没成功，还是赶紧加了IP限流和验证码。另外把服务器上几个默认端口改了，SSH只允许密钥登录。这些事做起来不复杂，就是得细心。我习惯每两周用OpenVAS扫一遍，报告里标红的必须当周处理掉。

备份恢复演练是这季度做得最值的一件事。之前备份文件一直正常生成，但从没实际恢复过。六月找了个测试环境，把上周的备份还原，发现用户上传的图片目录没包含在备份脚本里——因为当初写脚本的人只备份了数据库和代码。要是真出故障，图片全丢。现在备份策略改成数据库+代码+上传目录+配置文件，每周日凌晨全量，每天增量，恢复脚本也写好了放在运维手册里。

性能监控加了几个自定义指标。除了CPU、内存这些常规项，现在会盯“购物车放弃率突增”“支付回调延迟”这类业务指标。上个月支付回调延迟从200ms跳到1.5秒，查出来是第三方支付平台的问题，提前发了公告，没等用户骂上门。监控不是看曲线好不好看，是看业务有没有异常。

这季度还清理了服务器上17个僵尸进程和3个没人维护的定时任务。有个crontab每天凌晨跑一个PHP脚本，日志显示它已经报错三个月了，没人发现。删掉之后磁盘IO降了8%。技术债就是这样，不主动还，它就悄悄吃资源。

下季度打算把配置管理从手工改文件换成Ansible，现在三台Web服务器的nginx配置有细微差异，每次改都得登录三遍。另外想试试把日志集中到ELK，现在查问题得挨个服务器tail，效率太低。这些事不急，但得排上日程。

维护这活没什么高深技巧，就是眼睛尖一点、手快一点、记录全一点。每次故障处理后写个简短复盘，不用长篇大论，三行字：什么现象、什么原因、怎么改的。攒了二十几条之后，再出问题翻翻记录，八成能找到相似案例。比任何文档都管用。