UIOC
為了保證可用率99.99%，除了在應用架構、資源容量上做足功夫外，運維人員還要面對一個事實，那就是異常、故障、突發(fā)事件總會發(fā)生，這在管理上必須有一個流程方法來應對之。
在我們組織內(nèi)部有兩個處理流程，對于突發(fā)重大事件，有專門召集各方聯(lián)合診斷的UIOC(ugency incident office center)，緊急事故處理中心。而一般事件，我們通過事件管理通道滿足用戶需求。
多團隊合作
UIOC的目的在于快速調動IT資源，高效協(xié)同診斷事件，在這個過程中，開發(fā)關注應用邏輯、運營關注業(yè)務影響、運維關注底層資源、DBA關注數(shù)據(jù)庫。
流程啟動的第一步是將大家召集就位。溝通工具、渠道有多種，面對面溝通、郵件列表、即時通訊、視頻會議等，不同團隊類型有不同的處理習慣。但在事前，我們就應當將這些通道提前建立，并驗證隨時可用。
UIOC是一個聯(lián)合診斷、積極配合過程，通常會有一個經(jīng)驗豐富的人員來現(xiàn)場指揮、協(xié)調各團隊間的工作。
UIOC溝通工具很重要
UIOC六步驟
UIOC流程啟動后，如沒有統(tǒng)一管理，則很容易陷入到一片混亂中，我們一般會參照下面五點次序進行問題分析：
- 1.問題描述
啟動UIOC后，會對問題、異常進行一個簡單描述，如xx系統(tǒng)的xx功能無法使用。
另外，高層會關注業(yè)務影響，在這個步驟中，運營人員應當迅速的抽取出業(yè)務變化率。
- 2.應用架構
在問題、業(yè)務影響描述清楚后，下一步是系統(tǒng)負責人對應用的整體部署架構進行說明(對于問題所在模塊一目了然的這步可省略)。
這個整體部署架構中包括了主要的配置信息、關聯(lián)方等，其主要目的在于縮小問題范圍。
- 3.版本變更
依據(jù)應用架構的輸出來判斷在這個范圍內(nèi)是否有組件版本發(fā)布、基礎資源變更。
大部分故障都是由“變”而起，不是外部(訪問量、安全攻擊)，就是內(nèi)部(版本、變更)。
該步驟幫助我們發(fā)現(xiàn)內(nèi)部變化，如若找到相關影響對象，可以考慮準備回滾步驟、方案。
- 4.信息收集
以上三步應當是習慣性地快速完成， 如仍無法準確定位到問題點的話，極有可能陷入到僵持狀態(tài)中。
信息收集階段，各團隊開始各自挖礦，開發(fā)人員查看用戶訪問量、應用異常日志，運維人員檢查基礎資源情況，包括性能數(shù)據(jù)、日志信息，DBA檢查數(shù)據(jù)庫等待事件、top sql等，再將各自發(fā)現(xiàn)的可疑點共享出來，盡可能形成問題關聯(lián)，比如存儲發(fā)現(xiàn)IO延時比較高，請DBA確認是否有影響(不是所有的延時都影響數(shù)據(jù)庫)。
5.****行為決策
UIOC強調的是快速恢復，而不是問題分析，亦即找到問題點后可快速采取恢復方案，而不是將時間耗費在窮根問底。
UIOC準確的說是發(fā)現(xiàn)問題點在哪里，而不是回答為什么會有這個問題點，對于已發(fā)現(xiàn)的問題點，應當問：
◆是否可主備切換
◆是否可功能降級
◆是否可快速擴容
◆是否可版本回滾
在該步驟中確定快速恢復方案。
6.實施驗證
在決策完畢后，實施方案，并做好驗證，確保系統(tǒng)恢復正常。
事件處理
事件處理的是一些相對UIOC的緊急度要低、影響面較小的異常。在我們組織內(nèi)部，對計算、存儲、網(wǎng)絡以及中間件的事件團隊進行了整合，因此事件量大，涉及范圍廣，在這里介紹一些通用方法來幫助一線人員。
通用方法
1.是否可重現(xiàn)
問題是否可重現(xiàn)對于快速解決問題來說非常重要，但開發(fā)人員說我可以立即重現(xiàn)這個問題，好了，運維一線同事請放心，我們總有辦法或工具幫助我們定位到問題點。
最怕的是問題出現(xiàn)之后就不會再有了，需要追溯原因，或者說問題的重現(xiàn)需要準備大量資源，比如特定時間段出現(xiàn)，我們要考慮部署相關工具，例如tcpdump抓包。
2.是否有參考環(huán)境
幫助你進一步快速解決問題的是一個參照物，例如一個子系統(tǒng)有多套環(huán)境，stg1、stg2，有參照物意味著你快速定位問題又進了一步。
3.是否可分段排查
問題是否可以分段(類似于網(wǎng)絡異常)
找到路徑上的懷疑項，通過組件替換、繞行以及驗證等方式排除。
是否有日志、資源信息。
在第三步先是縮小問題范圍，之后就是對此范圍內(nèi)的組件進行日志、資源信息檢查，例如中間件日志、Windows事件管理器等。
在這個過程中發(fā)現(xiàn)的信息可求助于社區(qū)、百度、谷歌尋找解決答案，如果有廠商服務支持，也可以將這些信息提交給后方。
基礎資源信息中關于性能的部分，如果組織內(nèi)監(jiān)控管理做得完善，那么這些異常告警會提前發(fā)出，也有一個集中、易用的可視化界面查看。
5.是否可以Trace
Trace意味著對問題點的活動數(shù)據(jù)進行采集或者全量查看。
Trace的使用要謹慎，Trace會影響到組件性能，甚至導致其異常退出，應當盡量避免在生產(chǎn)環(huán)境使用。
其包括的步驟包括：
應用服務器Debug開關
tcpdump抓包
strace系統(tǒng)調用
systemtap探針
heapdump內(nèi)存分析
應該避免
1.碎片干擾
作為運維人員，一定要避免掉入到碎片干擾的陷阱中。
有時候開發(fā)人員并不會向你描述問題，而是拋出一段Exception stack(他也是專業(yè)人士)。
如果你不弄清楚問題，不追溯源頭，而直接陷入到類似的Exception stack中，有時可以很快解決問題，但有時你將走一段彎路，最終你會發(fā)現(xiàn)問題根本原因和這個碎片一點關系都沒有。
正確的做法是問題現(xiàn)象+異常信息，對于問題的快速診斷，二者缺一不可。
2.地毯掃蕩
在上層壓力下很容易出現(xiàn)地毯掃蕩情況，對所有組件的所有配置進行一次掃蕩檢查，例如從網(wǎng)絡設備、到物理機器、虛擬機、操作系統(tǒng)、中間件，這種情況也應當避免。
上層壓力，下層疏導
3.消極配合
地毯掃蕩和消極配合看似是矛盾的，積極配合看似就是地毯掃蕩，當別人提出問題，希望你檢查你所負責的相關資源時，你就陷入到了地毯掃蕩之中。
總結而來，我們應該避免地毯掃蕩，而避免的方法是遵循的問題處理方法論，將問題范圍縮小到一定程度才開始進行地毯掃蕩的。而對關聯(lián)他的團隊，我們應當是一個積極的配合態(tài)度。
4.無所不能
越是經(jīng)驗豐富、技術實力強的同事越容易陷入到這里。當他們找到問題點時，會竭盡全力的用各種高難度技術手段來幫助解決，例如在網(wǎng)絡上無數(shù)次nat，在操作系統(tǒng)上hack掉問題點等，而其無意中卻埋下了一個坑。
這些技術手段雖然可解決問題，但有可能增加運維復雜度、也有可能存在未驗證的缺陷風險。我們并不是無所不能，無所不能應當控制在規(guī)范標準之內(nèi)，或者放在研發(fā)驗證之中。
我們不是無所不能的
