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

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