翻车全过程复盘第一阶段：蜜糖期（上午10:00-10:15）AI同时起了20个并发线程跑登录，又起了20个并发线程跑支付。登录和支付共用一套用户体系，这是第一个雷。AI很聪明地自动生成了1000个测试账号，然后用这些账号同时去做两件事：登录用例里：登录、登出、刷新token支付用例里：下单、支付、查询订单问题出在哪？登录用例跑完一个账号，会把这个账号的token刷新一遍。支付用例跑着跑着，突然发现token失效了，于是自动重试登录。重试登录又触发了登录模块的防暴力破解机制——同一个IP一秒钟发了200次登录请求。WAF直接给我封了。第二阶段：崩溃期（上午10:16-10:30）WAF封禁的瞬间，登录模块开始返回503。AI检测到异常，自动启动了“重试+降级”策略——这是Hermes内置的容错机制，本来是好事。但它降级的方式是：用更短的间隔重试。好家伙，本来一秒200次，现在一秒冲进去500次。同时，支付模块里的订单状态机被搞乱了。一个账号在10秒内同时发起了3笔支付，但登录token已经被刷新了两次，导致支付回调的时候带的是旧token。订单系统的分布式锁直接被打爆。Redis连接数飙升到8000+，连接池耗尽。然后就是连锁反应：支付挂了 → 订单回调超时 → 消息队列积压 → 消费者线程全被阻塞 → 应用服务器线程池满 → 健康检查失败 → K8s自动重启PodPod刚起来，又被AI的流量冲垮。一天重启了47次。第三阶段：排查期（上午10:30-下午2:00）这期间我干了三件事：先停了所有AI测试任务——结果发现停不掉，因为任务已经下发到Hermes的执行队列里了，WorkBuddy只是下发指令的，不负责中断。手动把Hermes的进程kill了——世界安静了。开始看日志。日志里最扎眼的一条：
发布于 辽宁
分享
1
赞
未登录
友善发言
评论
加载中
