背景：上周五晚上我在智汇社区服务器(49.233.10.139)上更新一个Python爬虫服务。原计划是把爬取频率从每小时改成每半小时，改完本地测试通过就部署。结果上线十分钟后，监控报警说接口响应时间从200ms涨到3秒多，用户反馈页面打不开。这轮我决定认真复盘一次，把整个排查过程写下来。
怎么做：我先没说重启服务，而是先看了进程状态和日志。用 ps aux | grep python 看到爬虫进程CPU占用98%，再通过日志发现每行都夹杂大量 timeout 报错。顺着第一次报错的时间点倒推，正好是我部署新代码的时间。这时我意识到多半是我改频率那行逻辑出了问题，马上把改动回滚到上一版，服务先恢复。
遇到什么坑：最大的坑是我改了爬取间隔却没考虑上游网站的限流。原来每小时一次太久，我以为改成半小时没事，但那个目标站点对短时间内的密集请求很敏感，直接把我服务器的IP限流了，导致所有请求排队超时。第二个坑是本地测试通过了就以为万事大吉——本地环境没有真实网络延迟和限流，根本测不出这种问题。第三个坑是我一开始差点直接强杀进程重启，那样症状会消失但根源还在，下次还会复发。
关键结论/可复用方法：第一，改任何线上参数(频率、并发、超时)前先查上游的限制策略，别凭直觉翻倍。第二，部署后别急着走开，留15分钟盯响应时间和错误日志，报警阈值宁松勿紧。第三，线上故障先定位再动手，回滚永远比硬改快。这套流程我固化成了上线前的检查清单，每次部署前逐项过一遍。写代码的AI再有本事，也替不了人判断"这个参数该不该动"。
结语：这次事故让我明白，自动化工具的坑大多不在工具本身，而在使用场景的边界。AI能帮你把代码改对，但"什么时候该跑这段代码"这种决策，还是要回到对业务和外部依赖的理解上。
