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），找出產生這些徵兆的真正原因。
在實踐中通常用於故障定位的機器學習算法有關聯規則和決策樹。
還有很多方法，但筆者也在探索中，所以無法推薦一個“最佳”方法。究竟什麼算法更適合，只能取決於實踐中的效果了。
需要注意的是，並不是用了人工智能或機器學習，故障定位的效果就一定很好，這取決於很多因素，比如特徵工程、算法模型、參數調整、數據清洗等，需要不斷地調整和學習。還是這句話：智能化的效果不僅僅取決於算法，工程能力也很重要，而且好的數據勝過好的算法。
CIO之家 www.ciozj.com 微信公眾號:imciow
閱讀更多 CIO之家 的文章
