记一次线上问题排查
这周在上线一个功能的时候，碰到了“fail to respond”问题(上一篇文章)，问题虽然解决了，但是解决的过程很痛苦，走了很多弯路，我觉得有必要记录下来。
情景还原：项目A（公司内部项目），项目A里面有调用项目B的接口（项目B是公司接入的第三方项目，类似于rabbitMQ的存在）。线下环境，一切ok；上线了，“一个接口都调不通”。
问题分析：碰到这个问题，我也很懵逼，咋线下好好的，到了线上就不行了呢？第一反应是去看日志。一看日志，竟然是json解析异常，打印异常信息的时候，顺便还把调用接口返回的内容给打印了出来，我一看，接口返回的内容：尼玛，这不是官网的html嘛，这么跑到官网去了？
第一次交锋，运维甩锅
现在问题很明确了
期待返回：{code:1000,message:abc,result:xxx}
实际返回：<html><head>….</head></html>
代码里进行解析的时候，肯定json解析异常。出现这问题，肯定是运维的锅，马上就跑去找运维。运维听完问题，马上气势很足的说：没有问题的啊，都用了这么长时间了，早有问题早就暴露出来了啊！
我坚持说：代码是不会骗人的啊，调项目B的，现在返回了官网的html，肯定不对啊
运维听了，很不负责任的说：奥，那别人怎么就没碰到这问题呢？你提测单里的地址配错了吧？
我：心里一万个MMP。但是，还是得求运维大爷帮忙排查问题，赔笑了一下，让运维再帮忙看下线上的配置（我们的配置文件是放在配置中心的，开发没查看的权限，只有运维才可以看），看了配置文件，配置的是对的啊，不死心的我，又让运维登录线上的docker环境，ping一下www.b.read.com，结果，是ping的通的！在运维得意的眼神中，开发落魄的回到工位。
第二次交锋，运维的错判
当时，我早已经不在状态了，我记得那天，我忙的晕头转向，同时有三件事情要处理：一个线上问题排查（急）、一个新功能上线（就是这个功能）、还有自己的开发工作要做，而且今天出问题的功能是之前开发人员遗留下来的，虽然是上线了，但是，没有测试！没有测试！真是屋漏偏逢连夜雨，感冒发烧大姨妈！知道自己的状态已经不对了，就跟旁边的同事讨论，寻求突破。旁边的同事，还是比较给力的，听完我的描述，肯定的说：肯定是运维的问题，并且，ping的通，又不能代表就是正确返回！我一听，是这样的啊。于是又去找运维，这次去，刚才帮我排查的运维不在（称呼之前的运维A吧），我就找负责当天上线的运维B，运维B是新来的，他说他刚来，对什么的不熟。尼玛，这就尴尬了！
这时，运维B旁边的一个运维老人，就叫他运维C吧，运维C搭话了，说：我们这个项目B啊，读和写的域名是不一样的，你配置的是写的域名，配错了，读操作应该是www.b.read.com（现在配的是www.b.write.com，错误的）
“假的吧，读和写居然还不是一个域名？”我满脸不可置信
“是的啊，读和写不是一个的，只是之前都是写操作，你们开发配的都是www.b.write.com，没配置过www.b.read.com，所以你不知道有这个域名”运维C很认真的说
“奥，是的，之前都是写操作，读操作现在是第一次”，我觉得有点道理，读操作，我的确是第一个，“那我发邮件让重发一次了？”，因为重发得抄送直属领导、总监、和全部开发人员，有点不情愿
“要重发邮件的，不然我们这边没法走流程”，运维C很认真的说
“好吧”虽然有点不情愿，但是，要搞定这问题，必须得发邮件。
发邮件，走流程，再次上线了，但是，结果还是出异常了，不过，这次异常跟上次异常不一样。
上次异常是：json解析异常，返回错误的html
这次的异常是：
response：503 service unvailable
什么鬼，怎么还有问题？这503是什么情况？百度了这个错误出现的情况，又没发现和我情况很吻合的，看了下时间已经过了五点半了（公司的规定，五点半以后非特殊情况，不上线），我又一时想不出解决方案，就做开发任务去了，这个问题第二天再看吧（当然这个项目是技术项目，不影响业务的，不然，如果是产品项目，搞不定的话，今晚就别回家了，哈哈）
第三次交锋，问题终解决
第二天，早上上班，第一件事，就是找运维A处理，因为运维A的资历最老，对公司最熟悉。我把昨天改成www.b.read.com域名的事情跟他说了，他就很诧异：你改成www.b.read.com干嘛，这个域名有配置过嘛？
我就很无语：这个是你们运维让我改的啊，我还特意上一个fixbug啊！
他一愣，找其他运维了解情况，然而，最终结论是：根本就没有配置www.b.read.com域名，也就是说我昨天fixbug是白上了，不仅白上了，今天还得再上一个，再改回来！尼玛！
我突然想起，昨天没改之前，不也是错误的嘛？我就问运维A，运维A想了想，在服务器上curl www.b.write.com，发现返回的就是官网的html，又去看了什么配置，又问了其他运维有没有配置 www.b.write.com的域名解析，都回答没有。然后，很直白的告诉我：昨天的问题，是没有配置域名解析。
我：。。。。
搞半天，居然是这么弱智的问题，就是域名解析没配置，所以，解析不到就跑到官网去了，就返回了官网的html。真狗血。
我又问A为什么运维C会说“读和写是两个域名”？A解释道：开发的机器是不能访问线上的服务器的，但是，日常工作中开发又需要访问线上项目B，所有，就有了矛盾。那运维那边是怎么解决的呢？运维那边是在线下配置了一个域名，即www.b.read.com，通过这个域名中转，间接的提供给开发访问。www.b.read.com这个域名只存在线下的，运维C可能没搞清楚，以为线上环境也配了www.b.read.com域名，所以才有那么一说。
好吧，事情总算是搞清楚了。回去发邮件，㕛走一个fixbug！（这里吐槽一下啊，都是犯错，运维犯错了，私下改改配置就可以了，其他的什么都不用做了；开发犯错了，就得发邮件，抄直属领导、抄总监、抄全体测试人员、还要走流程。做开发，真的很亏！）
第四次交锋，还有坑！
这一次上线，我觉得事情已经十拿九稳了，满怀信心的测试，哪知，“一个接口都不能用”！翻异常信息，一看，这次异常信息变了，是HttpClient调用超时，程序里我可是设置20秒的啊，如果连20秒都超时，那这个是根本没法使用啊。为了排除是网络的问题，我在浏览器上，调用项目B的接口（项目B提供了站内的API调用），等待了一分钟，直接504 gateway time-out
无奈之下，跟直属领导反映了，直属领导有点不高兴了，毕竟花时间、花精力做的东西，要上线了，居然说不能用，这是打脸啊。虽然有点不高兴，但是没怎么责怪我，还跟我一起分析，确定是不是还有的救。在无意中，调用了项目B的其他接口，居然是可以调的通的！我差点不敢相信我的眼睛，再调用第二次，还是可以的！再调用最初的接口，失败，再调用，失败。调用其他的接口，成功！尼玛，我都差点怀疑人生了，都是一个项目的接口，怎么有的是ok的，有的就是不ok的呢？
领导看我一脸疑问，跟我解释，项目B调用超时的接口，是获取source的，而项目B是无法直接返回source，它应该是对所有的消息进行group by，进而得到所有的source。这个方案在线下是没问题的，但是，一旦到了线上，数据量太大，那它这个方案必定超时。而其他的接口，就可以顺利调用，不会超时。
到这里，一切真相大白了。
最终，放弃了获取source的接口，阉割了一个小功能，项目终于可以正常使用了！
总结和反思
-
不坚定，轻信运维
域名无法解析，那就是运维没有配置域名解析，一定要让运维确定配置了域名解析，要坚定！（其实还是缺乏运维方面的知识）
-
ping的通，并不代表调用正常
潜意识的认为ping的通，网是通的，调用就正常的，有问题就是程序问题。其实不一定的，看真的是否被调用，得看项目的access log
-
一个接口不能用，并不代表所有接口不能用
因为第一个接口就调用失败，我就认为全部不能用，就没有尝试其他的接口了，其实，还是可以再试一试其他接口的，也许第一个接口比较特殊呢？
