記一次線上問題排查

時間 2019-12-11

標籤一次線上問題排查简体版

原文原文鏈接

　　這周在上線一個功能的時候，碰到了「fail to respond」問題(上一篇文章)，問題雖然解決了，可是解決的過程很痛苦，走了不少彎路，我以爲有必要記錄下來。html

　　情景還原：項目A（公司內部項目），項目A裏面有調用項目B的接口（項目B是公司接入的第三方項目，相似於rabbitMQ的存在）。線下環境，一切ok；上線了，「一個接口都調不通」。docker

　　問題分析：碰到這個問題，我也很懵逼，咋線下好好的，到了線上就不行了呢？第一反應是去看日誌。一看日誌，居然是json解析異常，打印異常信息的時候，順便還把調用接口返回的內容給打印了出來，我一看，接口返回的內容：尼瑪，這不是官網的html嘛，這麼跑到官網去了？json

第一次交鋒，運維甩鍋

　　如今問題很明確了瀏覽器

期待返回：{code:1000,message:abc,result:xxx}服務器

實際返回：<html><head>….</head></html>網絡

　　代碼裏進行解析的時候，確定json解析異常。出現這問題，確定是運維的鍋，立刻就跑去找運維。運維聽完問題，立刻氣勢很足的說：沒有問題的啊，都用了這麼長時間了，早有問題早就暴露出來了啊！運維

我堅持說：代碼是不會騙人的啊，調項目B的，如今返回了官網的html，確定不對啊curl

運維聽了，很不負責任的說：奧，那別人怎麼就沒碰到這問題呢？你提測單裏的地址配錯了吧？測試

我：內心一萬個MMP。可是，仍是得求運維大爺幫忙排查問題，賠笑了一下，讓運維再幫忙看下線上的配置（咱們的配置文件是放在配置中心的，開發沒查看的權限，只有運維才能夠看），看了配置文件，配置的是對的啊，不死心的我，又讓運維登陸線上的docker環境，ping一下www.b.read.com，結果，是ping的通的！在運維得意的眼神中，開發落魄的回到工位。url

第二次交鋒，運維的錯判

　　當時，我早已經不在狀態了，我記得那天，我忙的暈頭轉向，同時有三件事情要處理：一個線上問題排查（急）、一個新功能上線（就是這個功能）、還有本身的開發工做要作，並且今天出問題的功能是以前開發人員遺留下來的，雖然是上線了，可是，沒有測試！沒有測試！真是屋漏偏逢連夜雨，感冒發燒大姨媽！知道本身的狀態已經不對了，就跟旁邊的同事討論，尋求突破。旁邊的同事，仍是比較給力的，聽完個人描述，確定的說：確定是運維的問題，而且，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
一個接口不能用，並不表明全部接口不能用

由於第一個接口就調用失敗，我就認爲所有不能用，就沒有嘗試其餘的接口了，其實，仍是能夠再試一試其餘接口的，也許第一個接口比較特殊呢？

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。