運維人員必須隨時掌握伺服器的執行狀況，除常規的伺服器配置、資源占用情況等資訊外，業務在執行時會產生大量的日誌、異常、告警、狀態報告等，我們統稱為「事件」。通常每台伺服器每個時刻都會產生大量這樣的「事件」，在有數萬台伺服器的場合下，每天產生的「事件」數量是數億級的，儲存量可能是tb級別的。
在過去，我們通常採用的方法是將日誌保留在本地，當發現問題時，會登入出問題的伺服器檢視日誌、排查故障，通過sar、dmesg等工具檢視歷史狀態；監控agent或者指令碼也會將部分狀態資料匯報到類似於zabbix這樣的監控軟體中，集中進行監控和告警。
當伺服器規模越來越大時，如何統
一、自動化處理這些「事件」的需求就越來越強烈，畢竟登入伺服器檢視日誌這種方式效率很低，而成熟的監控軟體（比如zabbix、zenoss等）只能收集和處理眾多「事件」當中的一部分，當伺服器數量多了以後，其擴充套件能力、二次開發能力也非常有限。在具體實踐中，當監控指標超過百萬級別時，就很少再使用這種單一的解決方案了，而是組合不同的工具和軟體，分類解決問題。
在通用設計方法中，有「大工具、小系統，小工具、大系統」的說法，這也符合unix的設計哲學，每個工具只做好一件事，一堆小工具組合起來可以完成很複雜的工作。如果使用的是一些大工具或者系統，表面上看功能很多，但是當你想處理更複雜的業務時，就會發現每乙個功能都不夠用，而且還很難擴充套件，它能做多「大」事取決於它的設計，而不是你的能力。
乙個由典型的小工具組成的大系統，任何乙個部分都可以被取代，你完全可以用自己更熟悉的工具來做，而且對工具或者元件的替換，對整體沒有太大影響。
一提到海量資料的儲存、分析和處理，大家就會想到各種各樣的大資料平台。是的，大資料平台確實是用來處理海量資料的，但反過來不見得成立，對海量資料的分析和處理，並不總是或者只依賴大資料平台。
「分類」這個詞聽上去樸實無華，然而處理複雜問題最基本的方法就是分類，甚至「分類方法」也是機器學習非常重要的組成部分。「海量資料處理」這是乙個巨集大的命題，聽上去讓人一頭霧水，但當你對「事件」或者需要處理的問題分類後，每一部分看上去就是乙個可以解決的問題了。
我們會在《智慧型運維》一書中詳細介紹如何對海量「事件」進行分類和處理。
每乙個分類都對應一種或多種資料處理、分析和儲存方式。也可以說，當你對資料、需求完成分類後，基本的框架也就定了下來，剩下的工作就是整合這些工具。
下圖是乙個多維度模型示例。真實世界的情況是（至少按弦理論學家所說的是），除我們可以感知的3個「延展維」外，還有6個「蜷縮維」，它們的尺寸在蒲朗克長度的數量級，因此我們無法感知到。
多維度模型示例
當然，運維資料中的「多維度」，還沒有複雜到這樣難以理解。
在相對複雜的業務場景下，乙個「事件」除包含我們常用的「時間」（何時發生）、「地點」（哪個伺服器/元件）、「內容」（包括錯誤碼、狀態值等）外，還應當包含地區、機房、服務池、業務線、服務、介面等，這就是多維度資料。
很多時候，資料分析人員可能要使用各種維度、組合各種指標來生成報告、dashboard、告警規則等，所以是否支援多維度的資料儲存和查詢分析，是衡量乙個系統是否具有靈活性的重要指標。
對多維度資料的處理，很多時候是乙個協議/模型設計問題，甚至都不會牽扯具體的分析和處理框架，設計良好的協議和儲存模型，能夠兼顧簡潔性和多維度。
不同的設計理念會對應不同的處理模型，沒有優劣之分，只有哪個更合適的區別。
多資料來源或者說異構資料來源已經很普遍了，畢竟在複雜場景下並不總是只產生一種型別的資料，也不是所有資料都要用統一的方式處理和儲存。
在具體的實踐中，通常會混合使用多種儲存介質和計算模型。
這裡列出的只是一部分。
如何從異構的多資料來源中獲取資料，還要考慮當其中某個資料來源失效、服務延遲時，能否不影響整個系統的穩定性。這考量的不僅僅是各種資料格式/api的適配能力，而且在多依賴系統中快速失敗和sla也是要涉及的點。
多資料來源還有乙個關鍵問題就是如何做到資料和展現分離。如果展現和資料的契合度太高，那麼隨便一點變更都會導致前端介面展現部分的更改，帶來的工作量可能會非常大，很多爛尾的系統都有這個因素存在的可能性。
ddos（分布式拒絕服務）攻擊，指借助於客戶/伺服器技術，將多台計算機聯合起來作為攻擊平台，對乙個或多個目標發動攻擊。其特點是所有請求都是合法的，但請求量特別大，很快會消耗光計算資源和頻寬，下圖展示了乙個ddos攻擊示例。
ddos攻擊示例
當我們的大腦在短時間內接收到大量的資訊，達到了無法及時處理的程度時，實際上就處於「拒絕服務」的狀態，尤其是當重大故障發生，各種資訊、蜂擁而至的警報同時到達時。
典型的資訊過載的場景就是「告警」應用，管理員幾乎給所有需要的地方都加上了告警，以為這樣即可高枕無憂了。
怎樣從成千上萬條資訊中發現有用的，過濾掉重複的、抖動性的資訊，或者從中找出問題根源，從來都不是一件容易的事情，所以業界流傳著「監控容易做，告警很難報」的說法。
還有乙個場景就是監控，當指標較少、只有數十張dashboard時，尚且可以讓服務台 24小時關注，但是當指標達到百萬、千萬，dashboard達到數萬張時（你沒看錯，是數萬張圖，得益於grafana/graphite的靈活性，dashboard可以用程式自動產生，無須運維工程師手工配置），就已經無法用人力來解決dashboard的巡檢了。
歷史的發展總是螺旋上公升的，早期我們監控的指標少，對系統的了解不夠全面，於是加大力度提高覆蓋度，等實現了全面覆蓋，又發現資訊太多了，人工無法處理，又要想辦法降噪、聚合、抽象，少→多→少這一過程看似簡單，其實經過了多次迭代和長時間的演化。
感興趣的朋友可以在《智慧型運維》一書中繼續了解這類問題在實踐中的解決方法。
有些方法屬於工程方法，有些方法屬於人工智慧或機器學習的範疇。
業務模型（或系統部署結構）複雜帶來的最直接影響就是定位故障很困難，發現根源問題成本較高，需要多部門合作，開發、運維人員相互配合分析（現在的大規模系統很難找到乙個能掌控全域性的人），即使這樣有時得出的結論也不見得各方都認可。
在開發層面，應對複雜業務的一般思路是採用soa、微服務化等，但從運維的角度講，完成微服務化並沒有降低業務的複雜度（當然結構肯定變清晰了）。
在這裡，又不得不強調工程能力的重要性。在複雜、異構和各種技術棧混雜的業務系統中，如果想定位故障和發現問題，在各個系統中就必須有乙個可追蹤、共性的東西。然而，在現實中若想用某個「體系」來一統天下，則基本不可能，因為各種非技術因素可能會讓這種努力一直停留在規劃階段，尤其是大公司，部門之間的鴻溝是技術人員無法跨越的。
所以，下面給出的幾種簡單方法和技術，既能在異構系統中建立某種關聯，為智慧型化提供一定的支援，又不要求開發人員改變技術棧或開發框架。
當這些工程（自動化、標準化）的水平達到一定高度後，我們才有望向智慧型化方向發展。
故障定位又稱為告警關聯（alarm correlation)、問題確定（problem determination）或根源故障分析（root cause analysis），是指通過分析觀測到的徵兆（symptom），找出產生這些徵兆的真正原因。
在實踐中通常用於故障定位的機器學習演算法有關聯規則和決策樹。
還有很多方法，但筆者也在探索中，所以無法推薦乙個「最佳」方法。究竟什麼演算法更適合，只能取決於實踐中的效果了。
需要注意的是，並不是用了人工智慧或機器學習，故障定位的效果就一定很好，這取決於很多因素，比如特徵工程、演算法模型、引數調整、資料清洗等，需要不斷地調整和學習。還是這句話：智慧型化的效果不僅僅取決於演算法，工程能力也很重要，而且好的資料勝過好的演算法。
本書結合大企業的智慧型運維實踐，全面完整地介紹智慧型運維的技術體系，讓讀者更加了解運維技術的現狀和發展。同時，幫助運維工程師在一定程度上了解機器學習的常見演算法模型，以及如何將它們應用到運維工作中。
圖書詳情：
智慧型運維 從場景中積蓄運維變革的未來
伴隨金融機構數位化轉型的加速，it運維從理念到模式正在向智慧型運維全面邁進。作為率先實現智慧型運維工程化落地的全棧it運維服務商，雲智慧型 北京 科技 總裁劉洪濤先生為 新金融世界 分享了智慧型運維對於金融數位化和fintech的意義，以及智慧型運維在金融機構落地過程中的注意要點。金融數位化的運維變...
支撐AIOps的運維角色和技能有哪些？
aiops artificial intelligence for it operations 即智慧型運維，是將人工智慧的能力與運維相結合，通過機器學習的方法來提公升運維效率。在傳統的自動化運維體系中，重複性運維工作的人力成本和效率問題得到了有效解決。但在複雜場景下的故障處理 變更管理 容量管理 ...
支撐AIOps的運維角色和技能有哪些？
aiops artificial intelligence for it operations 即智慧型運維，是將人工智慧的能力與運維相結合，通過機器學習的方法來提公升運維效率。在傳統的自動化運維體系中，重複性運維工作的人力成本和效率問題得到了有效解決。但在複雜場景下的故障處理 變更管理 容量管理 ...