工作中我們常常會(huì)接收到例如來(lái)自預(yù)警系統(tǒng)的告警郵件或者你的領(lǐng)導(dǎo)轉(zhuǎn)發(fā)來(lái)的線上問(wèn)題，那么當(dāng)我們遇到這類(lèi)問(wèn)題的時(shí)候該如何去完成處理這個(gè)任務(wù)呢？以下的處理方法步驟可以提供參考建議。
一、一般我們目前線上問(wèn)題的來(lái)源：
1.主動(dòng)發(fā)現(xiàn)
相關(guān)owner每天查看系統(tǒng)監(jiān)控情況，主動(dòng)發(fā)現(xiàn)了一些異常的現(xiàn)象。
2.監(jiān)控系統(tǒng)告警
比如應(yīng)用響應(yīng)時(shí)間在某個(gè)時(shí)間段上升了，資源層面cpu、內(nèi)存、io、tcp連接數(shù)、disk、線程數(shù)、GC、連接池等各個(gè)服務(wù)器指標(biāo)異常，可能是某臺(tái)的服務(wù)器出現(xiàn)了異常，但是業(yè)務(wù)還未受到大面積影響
3.你的領(lǐng)導(dǎo)轉(zhuǎn)發(fā)來(lái)自來(lái)組郵件或者產(chǎn)品
通常這類(lèi)郵件會(huì)有明確的uid,日期時(shí)間，服務(wù)名稱，問(wèn)題現(xiàn)象。
4.來(lái)自微信
通常有截圖，這個(gè)時(shí)候可以問(wèn)清楚具體觸發(fā)時(shí)間點(diǎn)，重復(fù)3的操作，遇到非必現(xiàn)問(wèn)題，可以嘗試多種操作來(lái)還原場(chǎng)景
5.生產(chǎn)故障郵件
OPS的發(fā)來(lái)的郵件
二、查問(wèn)題的基本步驟
—了解問(wèn)題概況，評(píng)估影響的范圍
根據(jù)問(wèn)題的來(lái)源，我們首先要確認(rèn)的是這到底不是線上的故障？ 還是個(gè)別的極端case問(wèn)題？極端的case引起的一般我們會(huì)降低優(yōu)先級(jí)。 比如不能下單這樣的就是大大大大大大大大大大大大問(wèn)題。
【tips:針對(duì)不同的問(wèn)題范圍直接會(huì)影響處理問(wèn)題的優(yōu)先級(jí)哦~~~】
如果已經(jīng)確定了是線上故障，我們需要快速響應(yīng)去定位故障點(diǎn)，找其原因。
稍大一點(diǎn)的公司，一般都有自己的監(jiān)控系統(tǒng)（服務(wù)器監(jiān)控，服務(wù)監(jiān)控，業(yè)務(wù)監(jiān)控）和日志系統(tǒng)。具體分析問(wèn)題現(xiàn)象，定位問(wèn)題，看log還是數(shù)據(jù)。一般能快速判是功能還是性能的問(wèn)題。
如果是確定功能問(wèn)題，我們一般可以從日志系統(tǒng)的trace入手：
若有拋錯(cuò)誤，通過(guò)跟蹤日志信息或者特定用戶問(wèn)題追溯來(lái)確定，一般這樣的日志系統(tǒng)都有唯一的標(biāo)識(shí)id串聯(lián)上下游，日志是實(shí)時(shí)的，且支持過(guò)濾，統(tǒng)計(jì)等查詢，可以查看一段時(shí)間的趨勢(shì)情況
如果是確定性能問(wèn)題，我們一般除了日志系統(tǒng)還會(huì)更多的結(jié)合監(jiān)控系統(tǒng)并行靈活組合來(lái)看：
日志系統(tǒng)一般都會(huì)有各類(lèi)型的埋點(diǎn)（自定義埋點(diǎn)，實(shí)時(shí)統(tǒng)計(jì)類(lèi)埋點(diǎn)，PV)，所有數(shù)據(jù)都是實(shí)時(shí)埋點(diǎn)，很短的delay。
監(jiān)控系統(tǒng)里面一般會(huì)有應(yīng)用監(jiān)控，也包括上下游的服務(wù)，調(diào)用SOA，被調(diào)SOA，調(diào)redis監(jiān)控，調(diào)用DAL監(jiān)控，系統(tǒng)本身的監(jiān)控，C#的應(yīng)用還有IIS的監(jiān)控，java的有VM的監(jiān)控等
—協(xié)調(diào)資源
判斷故障的影響面，這點(diǎn)很重要，你需要給一個(gè)明確的范圍，配合關(guān)聯(lián)的產(chǎn)品經(jīng)理，告知有多少用戶（百分比，訂單量）會(huì)受到影響；
再結(jié)合影響面，找你的頭，要么申請(qǐng)hotfix，要么放在就近版本修復(fù)，如果要修復(fù)，一定要讓相關(guān)人員（主管，產(chǎn)品，測(cè)試，關(guān)聯(lián)開(kāi)發(fā)）清楚這個(gè)事情的來(lái)龍去脈。
—深入分析
針對(duì)上面的系統(tǒng)查看，我們一般能找到切入關(guān)鍵點(diǎn)，之后是一個(gè)復(fù)雜的收集信息-假設(shè)-驗(yàn)證—收集信息-假設(shè)-驗(yàn)證的循環(huán)過(guò)程，直到我們找到重現(xiàn)，找到根源。
這里簡(jiǎn)單列舉下常見(jiàn)的一些疑點(diǎn)方向：
- 剛發(fā)布新版本不久后，線上在很短的時(shí)間內(nèi)就出了問(wèn)題。---那很大程度上是由于這次上的版本帶來(lái)的問(wèn)題，重點(diǎn)可以檢查這次代碼的改動(dòng)點(diǎn)是什么。
- 版本是之前的，突然出現(xiàn)內(nèi)存方面的錯(cuò)誤，嚴(yán)重導(dǎo)致服務(wù)不可用。---可能是之前潛在的重大的bug。
- 線上之前一直穩(wěn)定運(yùn)行，業(yè)務(wù)量突增，各服務(wù)的響應(yīng)時(shí)間增長(zhǎng)，QPS先陡增然后下降，最后大量報(bào)錯(cuò)，最嚴(yán)重的時(shí)候出現(xiàn)服務(wù)不可用。---這種情況很大情況下是上游調(diào)用方的突然增加流量，或者是遭遇異常的攻擊。
- 版本是之前上線的，QPS正常，服務(wù)響應(yīng)時(shí)間增長(zhǎng)，日志中出現(xiàn)警告。---可能是數(shù)據(jù)庫(kù)，Redis的連接問(wèn)題，或者定時(shí)任務(wù)出了問(wèn)題，導(dǎo)致等等。。。
- 版本是之前上線的，QPS正常，但服務(wù)響應(yīng)時(shí)間下降，錯(cuò)誤率上升。---可能是下游依賴的服務(wù)有異常。
- 很多服務(wù)大面積出現(xiàn)短暫的業(yè)務(wù)失敗。---很大可能是網(wǎng)絡(luò)問(wèn)題導(dǎo)致。
—問(wèn)題重現(xiàn)，故障排除
確定好問(wèn)題的范圍后，接下來(lái)就是問(wèn)題重現(xiàn)：
功能類(lèi)問(wèn)題，一般比較好重現(xiàn)，如果遇到不是每次都能重現(xiàn)的問(wèn)題。如果是APP問(wèn)題，還可以嘗試借來(lái)手機(jī)還原場(chǎng)景，或者通過(guò)DEBUG模式嘗試定位Dump文件。
根據(jù)前面掌握的基本信息，幫助我們快速去理清楚業(yè)務(wù)發(fā)生的時(shí)序，比如進(jìn)入App頁(yè)，會(huì)發(fā)生什么事情，Native邏輯做了什么，發(fā)起了什么請(qǐng)求（上傳參數(shù)，內(nèi)容），服務(wù)下發(fā)是否為空（檢查服務(wù)下發(fā)），是否正常觸發(fā)了業(yè)務(wù)回調(diào)，業(yè)務(wù)回調(diào)處理完畢頁(yè)面內(nèi)容渲染是否完成。
如果確定是性能問(wèn)題，需要進(jìn)行重現(xiàn)，這個(gè)過(guò)程有時(shí)候是比較困難的。。
- 要先拉取當(dāng)前線上的發(fā)布版本，發(fā)布到測(cè)試環(huán)境，分析場(chǎng)景，準(zhǔn)備相關(guān)的數(shù)據(jù)
- 我們要看上的機(jī)器配置 CPU ，內(nèi)核，磁盤(pán)，物理機(jī)還是虛擬機(jī) ，內(nèi)存， 網(wǎng)絡(luò)io 等
- JDK版本 ，JVM的參數(shù)
- 應(yīng)用開(kāi)關(guān)配置，數(shù)據(jù)庫(kù)， 緩存， redis
- 接口平均的響應(yīng)時(shí)間RT 是的多少， 接口的QPS是多少 平常的性能如何
6.。。
—-驗(yàn)證問(wèn)題是否解決
通常情況下，對(duì)于性能問(wèn)題的驗(yàn)證：
- 如果線上直接保存了dump文件，直接拉下來(lái)分析，若無(wú)，轉(zhuǎn)2
- 一般會(huì)拉取當(dāng)前線上有問(wèn)題的版本看是否能重現(xiàn)問(wèn)題
- 然后先拉取生產(chǎn)一個(gè)穩(wěn)定的版本，進(jìn)行兩者比對(duì)。
- 如果是上線前壓測(cè)過(guò)的版本，我們要詳細(xì)分析壓測(cè)的場(chǎng)景。
- 再切換壓測(cè)一個(gè)開(kāi)發(fā)修復(fù)后的版本進(jìn)行對(duì)比，還要和基線版本對(duì)比。
- 其中比對(duì)包括各項(xiàng)性能指標(biāo)，有的還必須針對(duì)dump文件進(jìn)行對(duì)比分析 。 最終的結(jié)果是一定要所有修復(fù)后的版本性能不能比原來(lái)生產(chǎn)穩(wěn)定的版本差。
- 針對(duì)內(nèi)存的問(wèn)題，我們一般壓測(cè)的時(shí)間會(huì)相對(duì)而言比較長(zhǎng)一點(diǎn)，觀察其趨勢(shì)。
—上線驗(yàn)證
驗(yàn)證修復(fù)后的版本，確認(rèn)OK后，進(jìn)行上線，一般都是灰度發(fā)布完成后進(jìn)行觀察，看是否正常。
三、如何快速恢復(fù)(這個(gè)步驟應(yīng)該和二并行做）
因?yàn)橄到y(tǒng)的可用性決定著公司的客戶利益，影響公司的收益和信譽(yù)，所以一般我們遇到生產(chǎn)故障的第一要?jiǎng)?wù)是，恢復(fù)服務(wù)，盡可能的把對(duì)線上服務(wù)影響降到最低。
怎么來(lái)快速保障把影響減少到最小呢。一般會(huì)參考以下的方法：
- 版本回退：大量報(bào)錯(cuò)的情況下，又沒(méi)有辦法快速定位問(wèn)題根源。一般我們都是功能測(cè)試人員負(fù)責(zé)版本上線，如果在是新版本上線后觀察出現(xiàn)了問(wèn)題，一般都是快速回退，切到近期穩(wěn)定的一個(gè)版本。一般大一點(diǎn)的公司發(fā)布系統(tǒng)都做的比較好，可以快速切換版本，且大部分都采用的是灰度發(fā)布，可以將范圍盡可能減少。
- 備份以及失效轉(zhuǎn)移： 對(duì)于服務(wù)而言，一但某個(gè)服務(wù)器宕機(jī)，就將服務(wù)切換到其他可用的集群服務(wù)器上去。對(duì)于數(shù)據(jù)而言，如果某個(gè)磁盤(pán)出現(xiàn)損壞，就從備份的磁盤(pán)讀取數(shù)據(jù)（一般都是事先就做好了數(shù)據(jù)的同步復(fù)制），這個(gè)一般都是DBA或者運(yùn)維人員去操作。
- 切流量： 一般都會(huì)有開(kāi)關(guān)控制，如果出現(xiàn)問(wèn)題，進(jìn)行關(guān)閉一部分流量。 這個(gè)發(fā)布人員都有權(quán)限。但需要事先和相關(guān)人員溝通好。
- 擴(kuò)容機(jī)器：線上訪問(wèn)壓力大，不能重啟機(jī)器，或者重啟也無(wú)法解決時(shí)，增加集群機(jī)器。
- 重啟：當(dāng)某臺(tái)服務(wù)器的CPU高，或者連接數(shù)飆升時(shí)，會(huì)采取這種方法。這個(gè)一般也是運(yùn)維的人員去完成該操作。
四、如果避免下次再入坑
等找到了根本原因，解決了問(wèn)題之后，我們需要總結(jié)，舉一反三，想想在這個(gè)故障排查和處理過(guò)程中，有哪些環(huán)節(jié)存在弱點(diǎn)？哪些流程/規(guī)范/制度需要優(yōu)化？
這類(lèi)似的問(wèn)題是否在其他系統(tǒng)，模塊或者團(tuán)隊(duì)中也存在？不斷完善，以避免再次踩坑，也在團(tuán)隊(duì)中交流經(jīng)驗(yàn)，共同提高。
再來(lái)聊聊我們的架構(gòu)的一些保護(hù)機(jī)制
現(xiàn)在一般隨著用戶的訪問(wèn)增多，大的系統(tǒng)一般做到一定的規(guī)模后，架構(gòu)都會(huì)經(jīng)歷過(guò)好幾次的變遷，巨無(wú)霸的系統(tǒng)架構(gòu)一般都是縱向和橫向進(jìn)行了拆分的，都是將各個(gè)模塊獨(dú)立部署，降低了系統(tǒng)的耦合性。這樣的架構(gòu)也更好的方便了我們能夠快速排查問(wèn)題。
總之，線上問(wèn)題來(lái)臨肯定有壓力的，但不要怕！！！！！
