记一次线上问题排查

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/zy_281870667/article/details/84504585

  这周在上线一个功能的时候,碰到了“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的接口,阉割了一个小功能,项目终于可以正常使用了!

总结和反思

  1. 不坚定,轻信运维

    域名无法解析,那就是运维没有配置域名解析,一定要让运维确定配置了域名解析,要坚定!(其实还是缺乏运维方面的知识)

  2. ping的通,并不代表调用正常

    潜意识的认为ping的通,网是通的,调用就正常的,有问题就是程序问题。其实不一定的,看真的是否被调用,得看项目的access log

  3. 一个接口不能用,并不代表所有接口不能用

    因为第一个接口就调用失败,我就认为全部不能用,就没有尝试其他的接口了,其实,还是可以再试一试其他接口的,也许第一个接口比较特殊呢?

阅读更多

没有更多推荐了,返回首页