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

08-23

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

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月出版。

------------

更多科技資訊請見微信公眾號：博文視點Broadview（微信號：bvbooks）