IT团队故障反思（1）-敬畏504
问题即成长
1、现状描述
1）用户信息登记页，证件类型无法从后端获取到
2）业务逻辑涉及的内容缺失
3）大量用户反馈无法正常操作
4）业务受损，影响面较大
如图：
信息无法获取
页面内容无法呈现
2、现状定性
1）最有可能是后端接口出现问题
2）网络问题
3）前端解析异常
3、基于故障点跟踪定位问题
1）前端链路分析，如图：
2）看到504错误，第一时间想到是否是网关或代理问题
3）那就分析下请求链路，涉及504的服务器或代理节点还是比较多的：
4）这里涉及504的可能存在3个地方：NG，防火墙，CDN
5）找运维配合排查响应日志：WAF拦截日志，NG日志，CDN日志
4、结合近期的操作思考
1）为什么同一个页面多个action请求，偏偏就是同一个请求超时（20s）得不到响应?
2）在排查的过程中，故障自动恢复了。隔天又出现了，其它页面也出现同样的情况？
3）回故最近上线了什么版本？
4）从程序部署、代码级分析结合日志排查都没找出BUG，排查进入“死胡同”。
5）开始没有留意其它应用是否有报类似的情况。后来发现有些应用也有类似情况。
5、故障定位
1）涉及的服务器，没有内存溢出，没有CPU使用异常，磁盘IO也很稳定
2）其他服务器的应用也有类似情况发生
3）综上确认重启服务器不能解决问题
4）同时能够确认不是应用程序的BUG。
5）继续扩大范围排查：从客户端到应用，都经历了什么？
6）内部几个服务器及网关，代理层，防火墙等日志均无504相关问题，那么问题很有可能在CDN上。
7）与CDN相关技术沟通，通过排查日志，发现CDN确实有504的日志
CDN的504
5、尝试修复
1）改用阿里CDN
2）监控CDN流量
3）部份手机恢复
4）切完30分钟左右故障解除
5）综上，确认CDN确实有问题，至于什么问题，还未清楚
6）将其他类似问题的服务切换CDN后，也逐渐恢复了。再次证实CDN问题
7）测试验证，并反馈产品部门
8）运维向百度提故障单
9）收到百度回复：https://oa.yihu.cn/Upload/Atts/201810/15/8836_1535538.PDF
6、故障总结
1）要熟悉常见的网络错误码，不同开头的代表不同端，一定要有基本的反应，比如此次的504问题：
2）问题出现后的，第一反应很正常，但未必就是对的，比如此问题，第一反应是后端接口出问题，如果一开始过多关注接口层面的情况，可能会浪费很多时间，当然这个问题我们也相应确认过。
3）一定就故障的问题点，马上断点调试跟踪，这是做IT很自然的手段（此步骤必做）
4）要有全盘考虑的思路，不要把目光局限单个场景，所以分析整个链路及经过的节点很重要
5）排查过程要留意其他应用节点有没类似问题，这样便于排查和规避一些判断。经常不同节点的不同应用若出现同样问题，那很大程度上可以排除应用代码本身的bug。
6）日志是很重要的手段，此次处理的不足之处在于，对于一个请求没有配一个唯一的GUID，排查时增加了排查的时间成本。因此，我们也意识到日志系统还不完善：首先是没有整个链路的日志平台；其次是没有贯穿整个业务生命周期的唯一ID。基于这点，我们队日志系统也提出了相应的改造。
反思：如果故障不能重现，那就很难快速定位到问题，很有可能成为系统隐藏的故障，后续的影响可能更大。所以，日志系统的重要性就不言而喻。
7）不要一有问题就重启服务器，做IT解决故障，一定要规避这种思维惯性。有时重启服务器不但不能解决问题，反而会影响整个排查问题的思路和时间，更有可能会对生产线其他业务造成影响。所以，一定要有排除法的思维，把可能的问题逐一过滤，然后缩小范围，根据线索定位。不到万不得已不要重启服务器。
8）除了定位问题时，通过现象假设的可能原因，我们也要多回顾下近期有没做了什么部署或修复动作，因为很有可能一个问题是由其他的应用触发的，或是由于修复了一个问题导致了一个新的问题。
技术上存在的问题守恒定律：每修复一个问题的时候，可能会带来新的问题，只不过这个新的问题是潜伏的，隐藏的，无法让人直接感知罢了。我们要做的，就是在这个问题的生态中，尽量规避显性问题，防范隐藏问题，提升系统健壮性，让问题发生在自己可控的范围，降低对业务的影响。
最后，感谢我们团队此次分享故障分析的架构师。通过这次分享，无论是新员工还是老研发，都获益匪浅。
