【編者按】本文作者為 Maria Arbisman，主要介紹 Google 與 Facebook 兩大巨頭是如何大規(guī)模處理 IT 事件管理。文章系國內(nèi) ITOM 管理平臺 OneAPM 編譯呈現(xiàn)。
2016 年舉辦的可靠性工程師學(xué)會大會 (SREcon 2016) 匯聚了來自全球各地的多家企業(yè)，探討企業(yè)在繼續(xù)擴(kuò)展業(yè)務(wù)的同時其網(wǎng)站可靠性工程師所面臨的各種問題，包括“究竟什么才能成就強(qiáng)大的 SRE 團(tuán)隊(duì)”這樣的準(zhǔn)生存問題。似乎很多公司都會把精干的軟件工程師和運(yùn)營人才拼湊在一起，以此確保網(wǎng)站可靠性工程職能。但無論怎樣精心組織這些團(tuán)隊(duì)，他們都是在努力讓過去一直依賴于人力的過程自動化。這些過程通常圍繞性能、可用性、效率、監(jiān)測、事件管理、延遲和可靠性。
全球頂尖企業(yè)的發(fā)言人向與會者介紹了最佳實(shí)踐，也坦率地探討了其方法的一些局限性。我發(fā)現(xiàn)兩個討論組特別有意思（我剛寫完一篇有關(guān)根源分析進(jìn)化論的文章），這兩個討論組的主角是當(dāng)今最最成功的兩家企業(yè)：Google 和 Facebook。以下內(nèi)容就是我對這兩家企業(yè)如何應(yīng)對 IT 事件管理的重要領(lǐng)悟。
Facebook 深入探討的問題是：“人類應(yīng)當(dāng)留意哪些 IT 告警？”
Facebook 的產(chǎn)品工程師 Brian Smith 首先向我們介紹了 Facebook 用來確定 IT 事件應(yīng)否入人類法眼（這一過程被稱為 SAR，即信號、可行動性和關(guān)聯(lián)性）的準(zhǔn)則的初步定義。
信號 — 這是誤報嗎？一定是信號不足！
可行動性 — 收到這一告警時，能立即采取措施嗎？
關(guān)聯(lián)性 — 收到這一告警時，有其他告警傳達(dá)相同內(nèi)容或重疊嗎？如果是，請刪除其中一個告警。
Smith 表示，使用 SAR 方法并在每個棧區(qū)只持續(xù)關(guān)注一個告警，就能提高可行動性和關(guān)聯(lián)性。他解釋道，F(xiàn)acebook 利用這一方法消除了 97% 的告警，從而減少了每天收到的噪音，也提高了總體運(yùn)營效率。
Google 的問題是“在 IT 事件管理中，哪個指標(biāo)最為重要？”
Google 的項(xiàng)目經(jīng)理 Sue Lueder 要求她的團(tuán)隊(duì)在事后分析中采用一種標(biāo)記系統(tǒng)，這有助于精準(zhǔn)地指出他們認(rèn)為在優(yōu)化 IT 事件管理時最重要的五大關(guān)鍵字段：
開始時間
結(jié)束時間
檢測時間
鑒別分流時間
確定根源時間
Google 利用這一系統(tǒng)，結(jié)合一份包括僥幸脫險和級聯(lián)故障的嚴(yán)重程度量表，來確定后期告警的閾值，不斷要求其團(tuán)隊(duì)選擇“如果這一事件再次發(fā)生，你是否愿意接受”。
Facebook 和 Google 的 IT 事件管理法適用于你的企業(yè)嗎？
從事后標(biāo)記到確定可執(zhí)行的告警，這兩家科技巨頭（L2 公司創(chuàng)始人 Scott Galloway 戲稱 Facebook 和 Google 為數(shù)字大動亂的天啟四騎士之二）費(fèi)盡心血，只為完善他們的事件管理例程，讓所有成功進(jìn)化的小規(guī)模事件管理能在其企業(yè)內(nèi)得到充分利用。
但不是每家企業(yè)都能像 Facebook 和 Google 這樣。對其他企業(yè)來說，解決方案用過即棄、使用過多操作人員或創(chuàng)建大量并行的數(shù)據(jù)中心這些方法完全行不通。
如果你真的按照這些方法來，最后還是不能實(shí)時探測新問題和消除虛假告警。對于擴(kuò)展操作，正確的方法是借助計(jì)算機(jī)來運(yùn)行這些企業(yè)中目前由人類來管理的事務(wù)。通過這一轉(zhuǎn)變，機(jī)器能夠進(jìn)行持續(xù)的分析，而解決問題仍然依靠人類，只要敢于創(chuàng)新，就能取得更豐碩的業(yè)務(wù)成果。
如果產(chǎn)品環(huán)境規(guī)模較小，或者需要應(yīng)付和單一根源掛鉤的事件時，F(xiàn)acebook 的方法會是個很好的選擇?？上У氖?，現(xiàn)代企業(yè)的產(chǎn)品環(huán)境往往較大，要應(yīng)付的事件也相對復(fù)雜，所以如果每個棧區(qū)丟棄所有告警只保留一個，會有極大風(fēng)險，這是因?yàn)槭录婢L(fēng)暴往往有多個起因（Forrester 公司的一份報告進(jìn)一步佐證了這一結(jié)論，該報告指出，有 74% 的 IT 事件不是由 IT 部門而是由其他人員匯報的，而這些其他人員甚至包括最終用戶 — 這可不太樂觀）。
相反，如果解決方案不僅能挑選出數(shù)據(jù)中的異?，F(xiàn)象和常規(guī)模式，進(jìn)而顯示整個基礎(chǔ)架構(gòu)內(nèi)多個告警之間的緊密聯(lián)系，還能洞察你曾經(jīng)遇到的各種問題，那么你的整體服務(wù)質(zhì)量就能得到提升，這是因?yàn)榘褦?shù)據(jù)放在上下文中來考慮并理解這些指標(biāo)背后的事態(tài)發(fā)展，會讓響應(yīng)更有效更及時。
增加實(shí)時分析解決方案也可以進(jìn)一步提高 Google 系統(tǒng)的效率，因?yàn)檫@一解決方案可以改進(jìn) Google 的過程，讓操作人員解決問題花費(fèi)的所有時間以及所需的所有關(guān)鍵指標(biāo)都得以實(shí)時存儲并按照具體“情況”（“情況”由一組相關(guān)聯(lián)的或“集群的”事件來定義）編入目錄，從而瞬間生成其五大關(guān)鍵字段分析，而無需返回、檢查、在事后分析過程中給所有內(nèi)容所標(biāo)記。我們知道，事后分析過程成本高昂，尤其是在沒有可動態(tài)捕捉取證活動的工具時。
除了這些關(guān)鍵字段之外，我們認(rèn)為，如果能增加診斷步驟和關(guān)鍵解析行動指標(biāo)來比對事件集群（“情況”）之間的相似性，也是非常有益的，這不僅縮短了平均檢測時間，也能利用歷史數(shù)據(jù)來幫助指引后期響應(yīng)，從而加快解決問題的步伐。
我們堅(jiān)信，未來，事件數(shù)據(jù)分析必須在事件發(fā)生時就要集中精力實(shí)時處理數(shù)據(jù)。不過，使用自適應(yīng)式事件管理模式的企業(yè)也應(yīng)該廣開門路，積極降低運(yùn)營成本，把人類解放出來，讓他們?nèi)プ鲎钅檬值墓ぷ鳎簞?chuàng)新。
本文系 OneAPM 工程師編譯整理。OneAlert 是 OneAPM 旗下產(chǎn)品，是國內(nèi)第一個 SaaS 模式的云告警平臺，集成國內(nèi)外主流監(jiān)控/支撐系統(tǒng)，實(shí)現(xiàn)一個平臺上集中處理所有 IT 事件，提升 IT 可靠性。想閱讀更多技術(shù)文章，請?jiān)L問 OneAPM 官方技術(shù)博客。
本文轉(zhuǎn)自 OneAPM 官方博客
