概述

---

在3月2日晚上，大概8點(diǎn)左右，本想打道回府，回家休息，突然被人在bug群@了一下，說是管理后臺(tái)，訪問不了，界面上出現(xiàn)了:

503 service temporarily unavailable 復(fù)制代碼

我趕緊嘗試訪問了一下，確實(shí)如此，但不是每次都不行，而是偶發(fā)503的錯(cuò)誤提示。當(dāng)時(shí)我是沒有立刻動(dòng)手去定位問題，而是先拉了一個(gè)臨時(shí)處理群，這樣做的原因是：

• 先將線上出故障了這件事情同步出去，要讓相關(guān)的人知道，像運(yùn)維、測(cè)試、你的上級(jí)、產(chǎn)品等；
• 一定是先止損，優(yōu)先【線下去處理故障】，而不是【直接在線上處理故障】；

群拉完后，我簡(jiǎn)單同步現(xiàn)象后，就開始分析了，首先想的第一點(diǎn)就是：

是不是因?yàn)樽隽司€上變更導(dǎo)致的，比如有發(fā)版之類的。

從這個(gè)點(diǎn)切入去想的原因是源于自己處理線上故障的經(jīng)驗(yàn)，大部分都是發(fā)版導(dǎo)致的，能回滾的優(yōu)先回滾，第一時(shí)間降低影響。因此我打開了發(fā)版日歷（技術(shù)團(tuán)隊(duì)是有維護(hù)一個(gè)發(fā)版日歷的，記錄了每次發(fā)版或者變更的內(nèi)容），發(fā)現(xiàn)3月2號(hào)當(dāng)天，在線上做了如下兩件事情：

• 部分服務(wù)接入了阿里云WAF，這個(gè)是因?yàn)榘踩?#xff0c;需要接入；
• 管理后臺(tái)對(duì)應(yīng)的前后端服務(wù)，確實(shí)也發(fā)版了；

火速電話公司的安全專家，先臨時(shí)關(guān)閉WAF，但關(guān)閉后沒有用，訪問管理后臺(tái)還是一直出現(xiàn)503提示，沒辦法了，得立刻回滾當(dāng)天上線的內(nèi)容，正當(dāng)運(yùn)維要操作回滾的時(shí)候，我反而制止了它。因?yàn)?#xff1a;

管理后臺(tái)突然又能訪問了。

😂，跟產(chǎn)品和業(yè)務(wù)方確認(rèn)了一下，他們也反饋系統(tǒng)恢復(fù)了。好吧，這個(gè)也算一個(gè)好消息，畢竟可以給技術(shù)團(tuán)隊(duì)多一些時(shí)間去定位問題。

系統(tǒng)臨時(shí)性恢復(fù)后，我這邊也就沒那么大的壓力和緊迫感了，靜下心來開始著手仔細(xì)分析，找出根因。

---

分析過程

---

是否有突增的流量過來

使用阿里云的SLS日志平臺(tái)，寫了個(gè)簡(jiǎn)單的腳本，執(zhí)行后發(fā)現(xiàn)，流量一直很平滑。雖然是管理后臺(tái)的服務(wù)，但是還是要先看看流量的，因?yàn)橛锌赡苡幸恍┒〞r(shí)任務(wù)或者重量級(jí)業(yè)務(wù)操作，導(dǎo)致瘋狂的調(diào)用管理后臺(tái)服務(wù)。

是否是發(fā)版導(dǎo)致的?

由于發(fā)版的內(nèi)容還不少，很難一下子分析出是哪些代碼導(dǎo)致的，只能利用阿里的日志平臺(tái)以及監(jiān)控平臺(tái)，從故障發(fā)生的時(shí)間范圍里，尋找一些蛛絲馬跡。

首先是查看故障時(shí)間內(nèi)，對(duì)應(yīng)的后端服務(wù)有無返回狀態(tài)碼非200的，可以使用阿里的SLS日志平臺(tái)，寫個(gè)簡(jiǎn)單命令查詢一下即可：

xxxx_app_id:yyyy not statusCode: 200 復(fù)制代碼

上面的一些查詢字段，是可以在SLS上自己定義的。最終發(fā)現(xiàn)返回的狀態(tài)碼都是200的，這個(gè)就有點(diǎn)奇怪，但還是繼續(xù)看一下有無異常日志。

xxxx_app_id:yyyy and logLevel: ERROR 復(fù)制代碼

發(fā)現(xiàn)也沒有，初步判斷，不是后端代碼上線導(dǎo)致的，便轉(zhuǎn)而開始用阿里云的監(jiān)控平臺(tái)觀察后端服務(wù)pod節(jié)點(diǎn)的運(yùn)行情況，但也沒有什么收獲，pod既無重啟的情況，內(nèi)存、CPU usage也都正常，也沒有什么慢的請(qǐng)求。

當(dāng)時(shí)就有點(diǎn)摸不著北了，由于那會(huì)也比較晚了，后臺(tái)管理系統(tǒng)也暫時(shí)沒有出現(xiàn)問題了，我就先回家了。而隔天又有其他重要緊急的事情要處理，我就忘記去跟這個(gè)事情了，一直到3月6號(hào)早上，又開始出現(xiàn)503問題了，持續(xù)時(shí)間是兩分鐘，然后就又自己恢復(fù)了。

這次我就把手頭上的事情先全部放下，全力跟進(jìn)這個(gè)問題。經(jīng)過3月2號(hào)晚上的分析，感覺跟后端服務(wù)沒有關(guān)系，那會(huì)不會(huì)是前端的node服務(wù)有問題呢? 當(dāng)然平時(shí)如果線上出故障，我很少認(rèn)為會(huì)是前端問題，都是先從后端服務(wù)定位起。

但這次沒辦法，死馬當(dāng)活馬醫(yī)，于是便到阿里云上去看一下前端pod節(jié)點(diǎn)的運(yùn)行情況，發(fā)現(xiàn)有重啟的情況，我感覺發(fā)現(xiàn)新大陸了，馬上去確定pod重啟時(shí)間，但是很遺憾，我沒權(quán)限看，就臨時(shí)去看一下這個(gè)pod的內(nèi)存波動(dòng)情況，一般來說，pod有重啟的話，內(nèi)存會(huì)短暫釋放，果然，在故障期間，前端的pod的內(nèi)存占用有下降的趨勢(shì)，然后故障后的幾秒，內(nèi)存占用又恢復(fù)了日常水平。

于是便火急火燎的跑去找了一下運(yùn)維：

把前端的xxx pod有重啟的情況，我懷疑管理后臺(tái)503問題，是這個(gè)原因?qū)е碌?#xff0c;你能不能把這個(gè)pod重啟前的日志發(fā)我一下。

當(dāng)時(shí)運(yùn)維回復(fù)說，重啟前的日志找不到了哦。當(dāng)然，這句話我是不信的。就讓運(yùn)維去查一下或者找阿里云的售后，看看怎么拿到pod重啟前的日志。果然，可以使用kubectl命令，找到日志：

kubectl describe pod xxxx-pro-vyyyyyyyy | grep 'State: ' -A 5

日志里有幾個(gè)信息：

• 一個(gè)是pod重啟前的代碼報(bào)錯(cuò)日志；
• 一個(gè)是pod具體的重啟時(shí)間；
• 一個(gè)是Exit Code，這個(gè)code等于1，說明pod重啟，是服務(wù)自身的報(bào)錯(cuò)導(dǎo)致的。

報(bào)錯(cuò)日志如下：

TypeError [ERR_HTTP_INVALID_HEADER_VALUE]: Invalid value "undefined" for header "Content-Length"

到此，基本就清楚了，請(qǐng)求先經(jīng)過阿里WAF和阿里nginx-ingress后，由nginx-ingress轉(zhuǎn)發(fā)給前端的service，進(jìn)而進(jìn)入到pod，但是由于pod同一時(shí)間都在重啟，暫時(shí)無法提供服務(wù)，service這一層就不知道pod的狀態(tài)，nginx-ingress自然也就無法知道service的狀態(tài)，于是便返回了503。等重啟完畢后，就又正常提供服務(wù)，之所以偶發(fā)的出問題，原因就在這里。

于是便找了前端的開發(fā)leader去定位原因，最后他回復(fù)說，要改一個(gè)底層文件，兼容一下Content-Length為空的情況，改完后，簡(jiǎn)單在在測(cè)試環(huán)境和預(yù)發(fā)布環(huán)境測(cè)試一下，過一下核心主流程，沒問題后，就上線了。

從3月9日上線到現(xiàn)在，暫時(shí)沒有發(fā)現(xiàn)503問題了。

那靈魂一問來了，這個(gè)底層文件，從2021年來一直都沒有改動(dòng)過，也沒出過啥事，為啥最近才開始出問題呢? 答案是：

比較難查，不知道是哪些請(qǐng)求會(huì)沒有Content-Length，但肯定是發(fā)版導(dǎo)致的。

總結(jié)

以上是生活随笔為你收集整理的解决一个偶现的503 bug,花了俺不少时间的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。