最近搞350.12这块儿可把我折腾得够呛，先说说怎么碰上的。那天晚上正盯着监控，突然一堆报警邮件噼里啪砸过来，点开一看全是350.12报错，用户投诉跟雪花片似的往工单系统里飞。
一、撸起袖子开始查
我第一反应就是去翻日志，好家伙，满屏的报错信息看得我脑壳疼。直接表现就是请求卡死，前端转圈圈转半天弹个超时，后台日志里清一色的ConnectionReset。顺手查了服务器负载，CPU内存都挺正常，网络流量也没爆，这就奇了怪了。
二、瞎猜乱试踩大坑
一开始以为是数据库连接池不够用，手贱把连接数上限从50调到200，重启服务后观察了半小时，屁用没有，报错频率一点没降。接着怀疑是某个第三方接口抽风，拿着traceID顺着链路追，结果发现调用第三方的那段流程压根没走到！350.12这狗屁错误在进业务逻辑层之前就炸了。
急得我抓耳挠腮的时候，突然注意到时间点特别有规律：每天早晚高峰必现，而且集中在某个区域机房接入的用户。赶紧喊运维兄弟一起蹲着，在报错最猛的时候掐着秒表抓包。好家伙，真给逮着了：TCP握手阶段SYN包发出去石沉大海，连三次握手都建不起来！
- 问题1：负载均衡抽风 - 高峰流量打到某个节点时，这货偷偷把SYN包吃了不回应，装作自己不在家
- 问题2：防火墙误杀 - 安全组策略有个隐藏规则，把特定地理位置的IP段当坏人给屏蔽了
- 问题3：老赖线程 - 有个陈年代码里的后台线程卡死没释放，占着茅坑不拉屎
三、土办法硬刚解决
负载均衡那个最要命，我直接冲机房把问题节点电源给拔了（别学我！），先保用户体验再说。接着在防火墙上把误杀规则暂时关了，流量肉眼可见地正常起来。至于那个老赖线程嘛翻出三年前的老代码，在初始化方法里加了个兜底的finally块强制回收，虽然姿势难看但真管用。
你以为这就完了？Too young！隔天又冒出个更邪门的：某些用户传的参数里带中文就必现350.12。查编码查得我眼冒金星，发现是某个祖传jar包里的字符串转换有bug，把UTF-8字符吞了半截。没辙，连夜扒出Git仓库里五年前的备份版本，把那个工具类替换掉才算消停。
四、血泪换来的经验
折腾完这摊子烂事儿，我算是彻底悟了：
- 看见350.12先别动代码，带上秒表去抓包，十有八九是网络层作妖
- 老系统升级时重点检查线程池，那帮陈年老线程比蟑螂还能苟
- 用户地域特征就是破案关键，这回要不是盯着地图看IP段，现在还在瞎折腾
最绝的是这事儿还有后续。搞完故障第三天，财务部大姐突然拍桌子骂街，说报销系统打不开了——原来我修350.12的时候，顺手改的防火墙规则把她访问财务系统的IP给误伤了！这破系统就跟屎山似的，踹一脚能掉下来十吨陈年bug。下次再遇见350.12，我打算先给服务器上柱香。