[[157738]]

　　作者介紹

余何，外號(hào)：眾神的大師兄，運(yùn)維心靈捕手，十余年IT金融運(yùn)維經(jīng)驗(yàn)，一直任職于某世界100強(qiáng)企業(yè)，參與并主導(dǎo)過各大神秘項(xiàng)目，熱愛開源、感悟運(yùn)維、癡迷于IT技術(shù)。

　　前言

　　It is the time you have wasted on your rose that makes your rose so important.

　　這是平凡的世界，不平凡的運(yùn)維專欄的第一期，我很難以一種感性的方式告訴別人運(yùn)維是做什么的，以至于對(duì)不同人會(huì)有不同的譬喻。

　　對(duì)于父母，運(yùn)維是當(dāng)前世界上很穩(wěn)定的工作(讓老人安心)。

　　對(duì)于妻子，運(yùn)維是計(jì)算機(jī)世界的特工組織(熬夜不歸的好理由)。

　　對(duì)于朋友，運(yùn)維并不是幫人裝殺毒軟件(告訴別人它不是什么也很重要)。

　　對(duì)于業(yè)內(nèi)人士，運(yùn)維是可用率99.99%(我覺得以后要換一種方式)。

　　對(duì)于公司老板，運(yùn)維是一門并不需要知道它有多精彩，但必須重視的崗位(這真的很難，也很矛盾)。

　　好了，讓我們開啟今天的主題，運(yùn)維事件處理經(jīng)驗(yàn)談。

[[157739]] 

　　運(yùn)維是一朵需要花時(shí)間照料的玫瑰

　　UIOC

　　為了保證可用率99.99%，除了在應(yīng)用架構(gòu)、資源容量上做足功夫外，運(yùn)維人員還要面對(duì)一個(gè)事實(shí)，那就是異常、故障、突發(fā)事件總會(huì)發(fā)生，這在管理上必須有一個(gè)流程方法來應(yīng)對(duì)之。

　　在我們組織內(nèi)部有兩個(gè)處理流程，對(duì)于突發(fā)重大事件，有專門召集各方聯(lián)合診斷的UIOC(ugency incident office center)，緊急事故處理中心。而一般事件，我們通過事件管理通道滿足用戶需求。

　　多團(tuán)隊(duì)合作

　　UIOC的目的在于快速調(diào)動(dòng)IT資源，高效協(xié)同診斷事件，在這個(gè)過程中，開發(fā)關(guān)注應(yīng)用邏輯、運(yùn)營(yíng)關(guān)注業(yè)務(wù)影響、運(yùn)維關(guān)注底層資源、DBA關(guān)注數(shù)據(jù)庫(kù)。

　　流程啟動(dòng)的第一步是將大家召集就位。溝通工具、渠道有多種，面對(duì)面溝通、郵件列表、即時(shí)通訊、視頻會(huì)議等，不同團(tuán)隊(duì)類型有不同的處理習(xí)慣。但在事前，我們就應(yīng)當(dāng)將這些通道提前建立，并驗(yàn)證隨時(shí)可用。

　　UIOC是一個(gè)聯(lián)合診斷、積極配合過程，通常會(huì)有一個(gè)經(jīng)驗(yàn)豐富的人員來現(xiàn)場(chǎng)指揮、協(xié)調(diào)各團(tuán)隊(duì)間的工作。

[[157740]] 

　　UIOC溝通工具很重要

　　UIOC六步驟

　　UIOC流程啟動(dòng)后，如沒有統(tǒng)一管理，則很容易陷入到一片混亂中，我們一般會(huì)參照下面五點(diǎn)次序進(jìn)行問題分析：

　　1.問題描述

　　啟動(dòng)UIOC后，會(huì)對(duì)問題、異常進(jìn)行一個(gè)簡(jiǎn)單描述，如xx系統(tǒng)的xx功能無法使用。

　　另外，高層會(huì)關(guān)注業(yè)務(wù)影響，在這個(gè)步驟中，運(yùn)營(yíng)人員應(yīng)當(dāng)迅速的抽取出業(yè)務(wù)變化率。

　　2.應(yīng)用架構(gòu)

　　在問題、業(yè)務(wù)影響描述清楚后，下一步是系統(tǒng)負(fù)責(zé)人對(duì)應(yīng)用的整體部署架構(gòu)進(jìn)行說明(對(duì)于問題所在模塊一目了然的這步可省略)。

　　這個(gè)整體部署架構(gòu)中包括了主要的配置信息、關(guān)聯(lián)方等，其主要目的在于縮小問題范圍。

　　3.版本變更

　　依據(jù)應(yīng)用架構(gòu)的輸出來判斷在這個(gè)范圍內(nèi)是否有組件版本發(fā)布、基礎(chǔ)資源變更。

　　大部分故障都是由“變”而起，不是外部(訪問量、安全攻擊)，就是內(nèi)部(版本、變更)。

　　該步驟幫助我們發(fā)現(xiàn)內(nèi)部變化，如若找到相關(guān)影響對(duì)象，可以考慮準(zhǔn)備回滾步驟、方案。

　　4.信息收集

　　以上三步應(yīng)當(dāng)是習(xí)慣性地快速完成， 如仍無法準(zhǔn)確定位到問題點(diǎn)的話，極有可能陷入到僵持狀態(tài)中。

　　信息收集階段，各團(tuán)隊(duì)開始各自挖礦，開發(fā)人員查看用戶訪問量、應(yīng)用異常日志，運(yùn)維人員檢查基礎(chǔ)資源情況，包括性能數(shù)據(jù)、日志信息，DBA檢查數(shù)據(jù)庫(kù)等待事件、top sql等，再將各自發(fā)現(xiàn)的可疑點(diǎn)共享出來，盡可能形成問題關(guān)聯(lián)，比如存儲(chǔ)發(fā)現(xiàn)IO延時(shí)比較高，請(qǐng)DBA確認(rèn)是否有影響(不是所有的延時(shí)都影響數(shù)據(jù)庫(kù))。

#p#

　　5.行為決策

　　UIOC強(qiáng)調(diào)的是快速恢復(fù)，而不是問題分析，亦即找到問題點(diǎn)后可快速采取恢復(fù)方案，而不是將時(shí)間耗費(fèi)在窮根問底。

　　UIOC準(zhǔn)確的說是發(fā)現(xiàn)問題點(diǎn)在哪里，而不是回答為什么會(huì)有這個(gè)問題點(diǎn)，對(duì)于已發(fā)現(xiàn)的問題點(diǎn)，應(yīng)當(dāng)問：

　　◆是否可主備切換

　　◆是否可功能降級(jí)

　　◆是否可快速擴(kuò)容

　　◆是否可版本回滾

　　在該步驟中確定快速恢復(fù)方案。

　　6.實(shí)施驗(yàn)證

　　在決策完畢后，實(shí)施方案，并做好驗(yàn)證，確保系統(tǒng)恢復(fù)正常。

　　事件處理

　　事件處理的是一些相對(duì)UIOC的緊急度要低、影響面較小的異常。在我們組織內(nèi)部，對(duì)計(jì)算、存儲(chǔ)、網(wǎng)絡(luò)以及中間件的事件團(tuán)隊(duì)進(jìn)行了整合，因此事件量大，涉及范圍廣，在這里介紹一些通用方法來幫助一線人員。

　　通用方法

　　1.是否可重現(xiàn)

　　問題是否可重現(xiàn)對(duì)于快速解決問題來說非常重要，但開發(fā)人員說我可以立即重現(xiàn)這個(gè)問題，好了，運(yùn)維一線同事請(qǐng)放心，我們總有辦法或工具幫助我們定位到問題點(diǎn)。

　　最怕的是問題出現(xiàn)之后就不會(huì)再有了，需要追溯原因，或者說問題的重現(xiàn)需要準(zhǔn)備大量資源，比如特定時(shí)間段出現(xiàn)，我們要考慮部署相關(guān)工具，例如tcpdump抓包。

　　2.是否有參考環(huán)境

　　幫助你進(jìn)一步快速解決問題的是一個(gè)參照物，例如一個(gè)子系統(tǒng)有多套環(huán)境，stg1、stg2，有參照物意味著你快速定位問題又進(jìn)了一步。

　　3.是否可分段排查

　　問題是否可以分段(類似于網(wǎng)絡(luò)異常)

　　找到路徑上的懷疑項(xiàng)，通過組件替換、繞行以及驗(yàn)證等方式排除。

　　是否有日志、資源信息。

　　在第三步先是縮小問題范圍，之后就是對(duì)此范圍內(nèi)的組件進(jìn)行日志、資源信息檢查，例如中間件日志、Windows事件管理器等。

　　在這個(gè)過程中發(fā)現(xiàn)的信息可求助于社區(qū)、百度、谷歌尋找解決答案，如果有廠商服務(wù)支持，也可以將這些信息提交給后方。

　　基礎(chǔ)資源信息中關(guān)于性能的部分，如果組織內(nèi)監(jiān)控管理做得完善，那么這些異常告警會(huì)提前發(fā)出，也有一個(gè)集中、易用的可視化界面查看。

　　5.是否可以Trace

　　Trace意味著對(duì)問題點(diǎn)的活動(dòng)數(shù)據(jù)進(jìn)行采集或者全量查看。

　　Trace的使用要謹(jǐn)慎，Trace會(huì)影響到組件性能，甚至導(dǎo)致其異常退出，應(yīng)當(dāng)盡量避免在生產(chǎn)環(huán)境使用。

　　其包括的步驟包括：

　　應(yīng)用服務(wù)器Debug開關(guān)

　　tcpdump抓包

　　strace系統(tǒng)調(diào)用

　　systemtap探針

　　heapdump內(nèi)存分析

　　應(yīng)該避免

　　1.碎片干擾

　　作為運(yùn)維人員，一定要避免掉入到碎片干擾的陷阱中。

　　有時(shí)候開發(fā)人員并不會(huì)向你描述問題，而是拋出一段Exception stack(他也是專業(yè)人士)。

　　如果你不弄清楚問題，不追溯源頭，而直接陷入到類似的Exception stack中，有時(shí)可以很快解決問題，但有時(shí)你將走一段彎路，最終你會(huì)發(fā)現(xiàn)問題根本原因和這個(gè)碎片一點(diǎn)關(guān)系都沒有。

　　正確的做法是問題現(xiàn)象+異常信息，對(duì)于問題的快速診斷，二者缺一不可。

　　2.地毯掃蕩

　　在上層壓力下很容易出現(xiàn)地毯掃蕩情況，對(duì)所有組件的所有配置進(jìn)行一次掃蕩檢查，例如從網(wǎng)絡(luò)設(shè)備、到物理機(jī)器、虛擬機(jī)、操作系統(tǒng)、中間件，這種情況也應(yīng)當(dāng)避免。

[[157743]] 

　　上層壓力，下層疏導(dǎo)

　　3.消極配合

　　地毯掃蕩和消極配合看似是矛盾的，積極配合看似就是地毯掃蕩，當(dāng)別人提出問題，希望你檢查你所負(fù)責(zé)的相關(guān)資源時(shí)，你就陷入到了地毯掃蕩之中。

　　總結(jié)而來，我們應(yīng)該避免地毯掃蕩，而避免的方法是遵循的問題處理方法論，將問題范圍縮小到一定程度才開始進(jìn)行地毯掃蕩的。而對(duì)關(guān)聯(lián)他的團(tuán)隊(duì)，我們應(yīng)當(dāng)是一個(gè)積極的配合態(tài)度。

　　4.無所不能

　　越是經(jīng)驗(yàn)豐富、技術(shù)實(shí)力強(qiáng)的同事越容易陷入到這里。當(dāng)他們找到問題點(diǎn)時(shí)，會(huì)竭盡全力的用各種高難度技術(shù)手段來幫助解決，例如在網(wǎng)絡(luò)上無數(shù)次nat，在操作系統(tǒng)上hack掉問題點(diǎn)等，而其無意中卻埋下了一個(gè)坑。

　　這些技術(shù)手段雖然可解決問題，但有可能增加運(yùn)維復(fù)雜度、也有可能存在未驗(yàn)證的缺陷風(fēng)險(xiǎn)。我們并不是無所不能，無所不能應(yīng)當(dāng)控制在規(guī)范標(biāo)準(zhǔn)之內(nèi)，或者放在研發(fā)驗(yàn)證之中。

[[157744]] 

　　我們不是無所不能的

如何一起愉快地發(fā)展

“高效運(yùn)維”公眾號(hào)（如下二維碼）值得您的關(guān)注，作為高效運(yùn)維系列微信群的唯一官方公眾號(hào)，每周發(fā)表多篇干貨滿滿的原創(chuàng)好文：來自于系列群的討論精華、運(yùn)維講壇線上精彩分享及群友原創(chuàng)。“高效運(yùn)維”也是互聯(lián)網(wǎng)專欄《高效運(yùn)維最佳實(shí)踐》及運(yùn)維2.0官方公眾號(hào)。

提示：目前高效運(yùn)維新群已經(jīng)建立，歡迎加入。您可添加蕭田國(guó)個(gè)人微信號(hào)xiaotianguo8 為好友，進(jìn)行申請(qǐng)，請(qǐng)備注“申請(qǐng)入群”。

重要提示：除非事先獲得授權(quán)，請(qǐng)?jiān)诒竟娞?hào)發(fā)布2天后，才能轉(zhuǎn)載本文。尊重知識(shí)，請(qǐng)必須全文轉(zhuǎn)載，并包括本行。