智能運維（AIOps）中幾處問題的解決方案與思路

上一篇文章中我們介紹了 智能運維的定義和發展現狀 ，但是智能運維需要解決的問題還有很多：海量資料存儲、分析、處理，多元度，多資料源，資訊過載，複雜業務模型下的故障定位。本文針對每一類問題給出了經過實踐證明的解決方案和思路，同時說明為什麼要這麼做，以及在工程和算法上會遇到的問題。

1 海量資料的存儲、分析和處理

運維人員必須随時掌握伺服器的運作狀況，除正常的伺服器配置、資源占用情況等資訊外，業務在運作時會産生大量的日志、異常、告警、狀态報告等，我們統稱為“事件”。通常每台伺服器每個時刻都會産生大量這樣的“事件”，在有數萬台伺服器的場合下，每天産生的“事件”數量是數億級的，存儲量可能是TB級别的。

在過去，我們通常采用的方法是将日志保留在本地，當發現問題時，會登入出問題的伺服器檢視日志、排查故障，通過sar、dmesg等工具檢視曆史狀态；監控Agent或者腳本也會将部分狀态資料彙報到類似于Zabbix這樣的監控軟體中，集中進行監控和告警。

當伺服器規模越來越大時，如何統一、自動化處理這些“事件”的需求就越來越強烈，畢竟登入伺服器檢視日志這種方式效率很低，而成熟的監控軟體（比如Zabbix、Zenoss等）隻能收集和處理衆多“事件”當中的一部分，當伺服器數量多了以後，其擴充能力、二次開發能力也非常有限。在具體實踐中，當監控名額超過百萬級别時，就很少再使用這種單一的解決方案了，而是組合不同的工具和軟體，分類解決問題。

在通用設計方法中，有“大工具、小系統，小工具、大系統”的說法，這也符合UNIX的設計哲學，每個工具隻做好一件事，一堆小工具組合起來可以完成很複雜的工作。如果使用的是一些大工具或者系統，表面上看功能很多，但是當你想處理更複雜的業務時，就會發現每一個功能都不夠用，而且還很難擴充，它能做多“大”事取決于它的設計，而不是你的能力。

一個由典型的小工具組成的大系統，任何一個部分都可以被取代，你完全可以用自己更熟悉的工具來做，而且對工具或者元件的替換，對整體沒有太大影響。

一提到海量資料的存儲、分析和處理，大家就會想到各種各樣的大資料平台。是的，大資料平台确實是用來處理海量資料的，但反過來不見得成立，對海量資料的分析和處理，并不總是或者隻依賴大資料平台。

“分類”這個詞聽上去樸實無華，然而處理複雜問題最基本的方法就是分類，甚至“分類方法”也是機器學習非常重要的組成部分。“海量資料處理”這是一個宏大的命題，聽上去讓人一頭霧水，但當你對“事件”或者需要處理的問題分類後，每一部分看上去就是一個可以解決的問題了。

我們會在《智能運維》一書中詳細介紹如何對海量“事件”進行分類和處理。

• 實時資料和非實時資料。
• 格式化資料和非格式化資料。
• 需要索引的資料和隻需要運算的資料。
• 全量資料和抽樣資料。
• 可視化資料和告警資料。

每一個分類都對應一種或多種資料處理、分析和存儲方式。也可以說，當你對資料、需求完成分類後，基本的架構也就定了下來，剩下的工作就是內建這些工具。

2 多元度、多資料源

下圖是一個多元度模型示例。真實世界的情況是（至少按弦理論學家所說的是），除我們可以感覺的3個“延展維”外，還有6個“蜷縮維”，它們的尺寸在普朗克長度的數量級，是以我們無法感覺到。

多元度模型示例

當然，運維資料中的“多元度”，還沒有複雜到這樣難以了解。

在相對複雜的業務場景下，一個“事件”除包含我們常用的“時間”（何時發生）、“地點”（哪個伺服器/元件）、“内容”（包括錯誤碼、狀态值等）外，還應當包含地區、機房、服務池、業務線、服務、接口等，這就是多元度資料。

很多時候，資料分析人員可能要使用各種次元、組合各種名額來生成報告、Dashboard、告警規則等，是以是否支援多元度的資料存儲和查詢分析，是衡量一個系統是否具有靈活性的重要名額。

對多元度資料的處理，很多時候是一個協定/模型設計問題，甚至都不會牽扯具體的分析和處理架構，設計良好的協定和存儲模型，能夠兼顧簡潔性和多元度。

不同的設計理念會對應不同的處理模型，沒有優劣之分，隻有哪個更合适的差別。

多資料源或者說異構資料源已經很普遍了，畢竟在複雜場景下并不總是隻産生一種類型的資料，也不是所有資料都要用統一的方式處理和存儲。

在具體的實踐中，通常會混合使用多種存儲媒體和計算模型。

• 監控資料：時序資料庫（RRD、Whisper、TSDB）。
• 告警事件：Redis。
• 分析報表：MySQL。
• 日志檢索：Elasticsearch、Hadoop/Hive。

這裡列出的隻是一部分。

如何從異構的多資料源中擷取資料，還要考慮當其中某個資料源失效、服務延遲時，能否不影響整個系統的穩定性。這考量的不僅僅是各種資料格式/API的适配能力，而且在多依賴系統中快速失敗和SLA也是要涉及的點。

多資料源還有一個關鍵問題就是如何做到資料和展現分離。如果展現和資料的契合度太高，那麼随便一點變更都會導緻前端界面展現部分的更改，帶來的工作量可能會非常大，很多爛尾的系統都有這個因素存在的可能性。

3 資訊過載

DDoS（分布式拒絕服務）攻擊，指借助于客戶/伺服器技術，将多台計算機聯合起來作為攻擊平台，對一個或多個目标發動攻擊。其特點是所有請求都是合法的，但請求量特别大，很快會消耗光計算資源和帶寬，下圖展示了一個DDos攻擊示例。

DDoS攻擊示例

當我們的大腦在短時間内接收到大量的資訊，達到了無法及時處理的程度時，實際上就處于“拒絕服務”的狀态，尤其是當重大故障發生，各種資訊、蜂擁而至的警報同時到達時。

典型的資訊過載的場景就是“告警”應用，管理者幾乎給所有需要的地方都加上了告警，以為這樣即可高枕無憂了。

然而，接觸過告警的人都知道，郵件、短信、手機推送、不同聲音和顔色提醒等各種來源的資訊可以輕松擠滿你的空間，很多人一天要收上萬條告警短信，手機都無法正常使用，更别談關注故障了。

怎樣從成千上萬條資訊中發現有用的，過濾掉重複的、抖動性的資訊，或者從中找出問題根源，從來都不是一件容易的事情，是以業界流傳着“監控容易做，告警很難報”的說法。

還有一個場景就是監控，當名額較少、隻有數十張Dashboard時，尚且可以讓服務台 24小時關注，但是當名額達到百萬、千萬，Dashboard達到數萬張時（你沒看錯，是數萬張圖，得益于Grafana/Graphite的靈活性，Dashboard可以用程式自動産生，無須運維工程師手工配置），就已經無法用人力來解決Dashboard的巡檢了。

曆史的發展總是螺旋上升的，早期我們監控的名額少，對系統的了解不夠全面，于是加大力度提高覆寫度，等實作了全面覆寫，又發現資訊太多了，人工無法處理，又要想辦法降噪、聚合、抽象，少→多→少這一過程看似簡單，其實經過了多次疊代和長時間的演化。

感興趣的朋友可以在《智能運維》一書中繼續了解這類問題在實踐中的解決方法。

• 資料的聚合。
• 降低次元：聚類和分類。
• 标準化和歸一化。

有些方法屬于工程方法，有些方法屬于人工智能或機器學習的範疇。

4 複雜業務模型下的故障定位

業務模型（或系統部署結構）複雜帶來的最直接影響就是定位故障很困難，發現根源問題成本較高，需要多部門合作，開發、運維人員互相配合分析（現在的大規模系統很難找到一個能掌控全局的人），即使這樣有時得出的結論也不見得各方都認可。

在開發層面，應對複雜業務的一般思路是采用SOA、微服務化等，但從運維的角度講，完成微服務化并沒有降低業務的複雜度（當然結構肯定變清晰了）。

在這裡，又不得不強調工程能力的重要性。在複雜、異構和各種技術棧混雜的業務系統中，如果想定位故障和發現問題，在各個系統中就必須有一個可追蹤、共性的東西。然而，在現實中若想用某個“體系”來一統天下，則基本不可能，因為各種非技術因素可能會讓這種努力一直停留在規劃階段，尤其是大公司，部門之間的鴻溝是技術人員無法跨越的。

是以，下面給出的幾種簡單方法和技術，既能在異構系統中建立某種關聯，為智能化提供一定的支援，又不要求開發人員改變技術棧或開發架構。

• 日志标準化：日志包含所約定的内容、格式，能辨別自己的業務線、服務層級等。
• 全鍊路追蹤：TraceID或者RequestID應該能從發起方透傳到後端，辨別唯一請求。
• SLA規範化：采用統一的SLA約定，比如都用“響應時間”來約定性能名額，用“慢速比”來衡量系統健康度。

當這些工程（自動化、标準化）的水準達到一定高度後，我們才有望向智能化方向發展。

故障定位又稱為告警關聯（Alarm Correlation)、問題确定（Problem Determination）或根源故障分析（Root Cause Analysis），是指通過分析觀測到的征兆（Symptom），找出産生這些征兆的真正原因。

在實踐中通常用于故障定位的機器學習算法有關聯規則和決策樹。

還有很多方法，但筆者也在探索中，是以無法推薦一個“最佳”方法。究竟什麼算法更适合，隻能取決于實踐中的效果了。

需要注意的是，并不是用了人工智能或機器學習，故障定位的效果就一定很好，這取決于很多因素，比如特征工程、算法模型、參數調整、資料清洗等，需要不斷地調整和學習。還是這句話：智能化的效果不僅僅取決于算法，工程能力也很重要，而且好的資料勝過好的算法。

本文選自《智能運維：從0搭建大規模分布式AIOps系統》，作者彭冬、朱偉、劉俊等，電子工業出版社2018年7月出版。

本書結合大企業的智能運維實踐，全面完整地介紹智能運維的技術體系，讓讀者更加了解運維技術的現狀和發展。同時，幫助運維工程師在一定程度上了解機器學習的常見算法模型，以及如何将它們應用到運維工作中。

圖書詳情：

https://item.jd.com/12403162.html