Google 和 Facebook 如何大規模處理 IT 事件管理 —— 2016 SRE 大會之我見

OneAPM官方技術部落格發表於2016-06-15
Go事件

【編者按】本文作者為 Maria Arbisman，主要介紹 Google 與 Facebook 兩大巨頭是如何大規模處理 IT 事件管理。文章系國內 ITOM 管理平臺 OneAPM 編譯呈現。

2016 年舉辦的可靠性工程師學會大會 (SREcon 2016) 匯聚了來自全球各地的多家企業，探討企業在繼續擴充套件業務的同時其網站可靠性工程師所面臨的各種問題，包括“究竟什麼才能成就強大的 SRE 團隊”這樣的準生存問題。似乎很多公司都會把精幹的軟體工程師和運營人才拼湊在一起，以此確保網站可靠性工程職能。但無論怎樣精心組織這些團隊，他們都是在努力讓過去一直依賴於人力的過程自動化。這些過程通常圍繞效能、可用性、效率、監測、事件管理、延遲和可靠性。

全球頂尖企業的發言人向與會者介紹了最佳實踐，也坦率地探討了其方法的一些侷限性。我發現兩個討論組特別有意思（我剛寫完一篇有關根源分析進化論的文章），這兩個討論組的主角是當今最最成功的兩家企業：Google 和 Facebook。以下內容就是我對這兩家企業如何應對 IT 事件管理的重要領悟。

Facebook 深入探討的問題是：“人類應當留意哪些 IT 告警？”

Facebook 的產品工程師 Brian Smith 首先向我們介紹了 Facebook 用來確定 IT 事件應否入人類法眼（這一過程被稱為 SAR，即訊號、可行動性和關聯性）的準則的初步定義。

  • 訊號 — 這是誤報嗎？一定是訊號不足！

  • 可行動性 — 收到這一告警時，能立即採取措施嗎？

  • 關聯性 — 收到這一告警時，有其他告警傳達相同內容或重疊嗎？如果是，請刪除其中一個告警。

Smith 表示，使用 SAR 方法並在每個棧區只持續關注一個告警，就能提高可行動性和關聯性。他解釋道，Facebook 利用這一方法消除了 97% 的告警，從而減少了每天收到的噪音，也提高了總體運營效率。

Google 的問題是“在 IT 事件管理中，哪個指標最為重要？”

Google 的專案經理 Sue Lueder 要求她的團隊在事後分析中採用一種標記系統，這有助於精準地指出他們認為在優化 IT 事件管理時最重要的五大關鍵欄位：

  1. 開始時間

  2. 結束時間

  3. 檢測時間

  4. 鑑別分流時間

  5. 確定根源時間

Google 利用這一系統，結合一份包括僥倖脫險和級聯故障的嚴重程度量表，來確定後期告警的閾值，不斷要求其團隊選擇“如果這一事件再次發生，你是否願意接受”。

Facebook 和 Google 的 IT 事件管理法適用於你的企業嗎？

從事後標記到確定可執行的告警，這兩家科技巨頭（L2 公司創始人 Scott Galloway 戲稱 Facebook 和 Google 為數字大動亂的天啟四騎士之二）費盡心血，只為完善他們的事件管理例程，讓所有成功進化的小規模事件管理能在其企業內得到充分利用。

但不是每家企業都能像 Facebook 和 Google 這樣。對其他企業來說，解決方案用過即棄、使用過多操作人員或建立大量並行的資料中心這些方法完全行不通。

如果你真的按照這些方法來，最後還是不能實時探測新問題和消除虛假告警。對於擴充套件操作，正確的方法是藉助計算機來執行這些企業中目前由人類來管理的事務。通過這一轉變，機器能夠進行持續的分析，而解決問題仍然依靠人類，只要敢於創新，就能取得更豐碩的業務成果。

如果產品環境規模較小，或者需要應付和單一根源掛鉤的事件時，Facebook 的方法會是個很好的選擇。可惜的是，現代企業的產品環境往往較大，要應付的事件也相對複雜，所以如果每個棧區丟棄所有告警只保留一個，會有極大風險，這是因為事件告警風暴往往有多個起因（Forrester 公司的一份報告進一步佐證了這一結論，該報告指出，有 74% 的 IT 事件不是由 IT 部門而是由其他人員彙報的，而這些其他人員甚至包括終端使用者 — 這可不太樂觀）。

相反，如果解決方案不僅能挑選出資料中的異常現象和常規模式，進而顯示整個基礎架構內多個告警之間的緊密聯絡，還能洞察你曾經遇到的各種問題，那麼你的整體服務質量就能得到提升，這是因為把資料放在上下文中來考慮並理解這些指標背後的事態發展，會讓響應更有效更及時。

增加實時分析解決方案也可以進一步提高 Google 系統的效率，因為這一解決方案可以改進 Google 的過程，讓操作人員解決問題花費的所有時間以及所需的所有關鍵指標都得以實時儲存並按照具體“情況”（“情況”由一組相關聯的或“叢集的”事件來定義）編入目錄，從而瞬間生成其五大關鍵欄位分析，而無需返回、檢查、在事後分析過程中給所有內容所標記。我們知道，事後分析過程成本高昂，尤其是在沒有可動態捕捉取證活動的工具時。

除了這些關鍵欄位之外，我們認為，如果能增加診斷步驟和關鍵解析行動指標來比對事件叢集（“情況”）之間的相似性，也是非常有益的，這不僅縮短了平均檢測時間，也能利用歷史資料來幫助指引後期響應，從而加快解決問題的步伐。

我們堅信，未來，事件資料分析必須在事件發生時就要集中精力實時處理資料。不過，使用自適應式事件管理模式的企業也應該廣開門路，積極降低運營成本，把人類解放出來，讓他們去做最拿手的工作：創新。

本文系 OneAPM 工程師編譯整理。OneAlert 是 OneAPM 旗下產品，是國內第一個 SaaS 模式的雲告警平臺，整合國內外主流監控/支撐系統，實現一個平臺上集中處理所有 IT 事件，提升 IT 可靠性。想閱讀更多技術文章，請訪問 OneAPM 官方技術部落格。

本文轉自 OneAPM 官方部落格

原文地址：https://www.moogsoft.com/whats-new/blog/google-facebook-incident-management-scale-insights-srecon-2016/

相關文章