这周我负责的系统，生产出事故了，整个处理过程一言难尽。
产线送到汇丰银行的对账文件，一连几天都失败了，检查系统、主机、网络等，仍然一筹莫展，未能发现明显线索。
周五，对账文件已积压一周，客户的赔付款已大概率出现延迟。
业务人员着急，通过各种渠道表达不满，如果对方投诉，今年部门和个人绩效将大打折扣。
加上大环境不景气，IT行业哀鸿遍野，打开抖音、脉脉，都是大厂裁员、大龄待业的消息，令人烦躁。
下午各方电话打过来，直属领导开始给他们一一做解释。
我在管控平台建了变更单，按照昨天和开发讨论的方案，把失败的实例从F5资源池剔除了，之后打开服务日志，远程连线金服同事，把积压的对账文件一笔一笔送过去。
当晚，开发和运营团队怀着忐忑的心情，排障到深夜。
周六和银行联合排查，终于发现是银行响应超时导致，长舒一口气~
现象描述
资金网关系统，向银行sftp服务器上传对账文件失败，应用报错如下：
1 | [ERRO]Sftp failed: |
排查过程
- 该问题是14号以来暴露，翻遍集团变更通知，发现网络领域13号凌晨，实施了应用主机所在机房的重大变更。
立即向网络团队发起问询，对方排查20分钟后，反馈的结果是无影响。 - 根据应用系统架构，拉上F5、主机领域的专家会诊，也没有发现明显线索。
- 对集群实例展开全面巡检，发现其中1台主机，内核报错，巡查结果可以防范风险，并不能解释文件送盘失败的原因。
- 运营和网络支持人员，分别在应用主机、出口网关抓包，获取上传失败时双方通信过程。
- 通过分析抓包文件，发现到银行的数据包有至少3次重传，应用超时时间30s，最后发出了一个RST包，终止会话。
- 为什么会发起重传呢，直接原因是没有收到对端响应。
- 为什么没有收到响应？ 有两种可能，要么是数据包在线路上丢了，没有到达银行，要么银行已经收到，但由于某种原因，没有响应。
- 立即通知网络组，向运营商发起问询，14号以后专线变更，运营商给出了否定答复。
- 立即联系业务，要求银行周末配合抓包，排查问题。
- 银行迫于业务压力，周六安排科技人员支持排查。 按照反馈的失败时间段，检查网络记录，行方也发现了三次重传，最终双方达成一致，失败原因是银行响应超时。
经验总结
- 阿里云双11出现大规模故障，集团领导借机发文，再一次强调运营稳定的重要性。
- 上次资金系统的UIOC发生在22年5月份，我亲自经历了，决不能再次重演。
- 日常运营工作繁杂，对系统的监视、告警的关注，决不能丝毫松懈。