wsdl获取逻辑修改事故的复盘
一、事故描述
EDI在对SOAP服务进行调用的时候会解析商家的wsdl。
- 初始逻辑是只获取http协议的地址，但是新上线的商家A的协议为https，导致无法获取请求地址，访问商家异常。
EDI侧修改解析wsdl获取地址逻辑，增加对https的支持；商家A恢复正常；
此时商家B出现了问题，其wsdl中提供了两个地址，一个是http，一个是https，但是https的地址是不可用的。这次修改支持https后，错误的获取到了https地址，导致商家B调用异常。
EDI侧再次修改解析wsdl获取地址逻辑，优先使用与wsdl地址协议相同的地址，商家B恢复正常。
而由于组织变动，之前的运维监控团队解散，无人监控到商家B的异常。导致商家B的问题到次日才发现，造成了商家货物堆积现象。
二、事故初始反思
1）事故原因
- 商家B的wsdl不符合规范，wsdl中暴漏的服务不可用
- EDI侧修改没有完全兼容之前逻辑
- EDI侧上线后没有完整检查所有受影响的商家
- 运维团队解散，导致问题延迟发现，扩大了事故影响
2）事故预防
- 规范上线流程
- 上线前做完整商家测试
- 上线前通知相关方做好监控
- 上线时灰度验证，发现问题及时回滚
- 上线时观察所有受影响商家是否正常
- 增加监控指标，核查监控指标确定系统健康度
3）事故发现
- 异常监控
- 帮助新的运维团队订阅业务异常，做到及时发现故障
- 分离http调用等异常为系统异常，由EDI侧研发监控
4）事故处理
- 及时回滚，快速恢复故障
- 及时复核受影响的所有商家，通知业务侧
- 隔离重要商家到单独集群，降低故障率
三、更高维度反思
1）运维团队监控/EDI侧监控 ——> 多方边界
从监控职责上分为两方EDI平台侧和运维侧，而此次事故暴露出的是这个边界不清晰。由谁监控如果没有明确的边界，必然会造成事故延迟发现。
事故不光要从技术角度去看，还要从组织的角度上去看。一个中间件的使用方是多个部门，这时候如果没有厘清中间件、使用方、客户、实施运维团队的责任边界，那么会出现职责灰度地带。这些灰度地带一但出问题，必然没有人发现，直到问题扩大到更大的区域。
2）商家侧wsdl不合理 ——> 新功能开发要基于标准，不妥协
早期wsdl只支持http实际上是对商家侧不符合标准的一种妥协。作为一个中间件，这种在原则上是不允许的。当多个商家都不符合标准，且互相冲突的时候，平台根本无法兼顾。此时只有坚守标准，才能拉齐场景。
3）多次修改上线 ——> 上线要有正式书面完整流程
上线流程书面化，严格遵守，不要存在侥幸心理。