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