大資料的處理

經過長時間的實踐和總結，我們發現伺服器運營的大資料有以下四個特點，由淺入深，分別是：1）Volume資料體量巨大，特別是騰訊有海量的伺服器，綜合起來，資料量可以到PB級別，需要大容量、高效能的儲存技術，分析的演算法也需要最優化；2）Variety資料型別眾多，涉及大量的執行日誌、部件狀態、生產鏈運營、環境變數等，經常要抽絲剝繭，才能找到有用的資料；3）Value 價值巨大，但並不是每個資料都有價值，需要經過清洗和加工處理後，其產生的效果才能顯現，以機房環境溫度告警為例，數百萬條溫度的資訊，經過分析對比後，才有可能發現溫度異常；4）Velocity資料需要快速處理，特別是告警類的應用，時效性是非常重要的。

下面講講我們是怎麼收集和儲存伺服器運營資料的，給我三分鐘，給你一個帥氣又有營養的答案！

運營系統架構

對於海量伺服器的管理，我們建立了一套功能強大的運營分析系統，從伺服器的帶內和帶外收集了全面的靜態屬性和動態執行資料，對伺服器的每個關節進行的全方位的資料採集和監控。猶如我們平時體檢，把心、肝、脾、肺、腎，甚至每個毛孔，都進行了檢查。系統架構如下圖所示。

儲存和分析

資料收集起來後，除了一部分實時的資料存在本地資料庫，幾乎全部的歷史資料都會儲存在公司級的資料平臺中。這個資料平臺提供了豐富的工具系統，功能全面，涵蓋了資料儲存、分析、實時計算等。例如，TPG是基於postgreSQL的資料庫，用於存放TDW（Tencent distributed Data Warehouse騰訊分散式資料倉儲）離線分析後的結果資料，便於系統呼叫（如伺服器利用率分析,故障分析、伺服器生命週期等生產資料）；Hbase基於No SQL，萬億級的分散式、有序資料儲存，用於存放分析後的結果資料（如溫度功耗分析結果資料）。整體的架構如下圖所示。

大資料的四個實踐

大資料的規劃分析，決策者和開發者首先要從業務驅動的角度，選擇資料生產的業務場景，即要預計資料分析得到的結果能帶來哪些效益。根據公司伺服器運營的特點，我們在以下四個場景做了大資料的分析和應用，給實際的運營帶來的實實在在的好處。

硬碟故障預測

硬碟是伺服器硬體故障率最高的一個部件，如果能提前預測到硬碟故障，對業務體驗、完善備件管理都有莫大的收益。這也是基礎架構運營在經歷自動化、流程化後，需要進一步提升運營效率、降低運營成本的天然要求。

涉及硬碟的運營資料包括業務IO資料、硬碟內部的SMART和硬碟執行的環境變數資料(溫度和溼度)。目前，運營系統對IO資料是每小時採集一次，SMART資料每三小時採集一次，溫度和溼度每半小時採集一次，這些資料合計起來每天的記錄數上億條。硬碟故障預測，適合使用分類演算法，我們使用了目前較為流行的SVM分類演算法，輔以合適的核函式來加快學習計算的效率。

經過了一年多時間的實踐，走了不少彎路，也碰到了很多坑，在硬碟故障標準確定、業務IO分類定義等方面吃了不少的虧，我們在基於SMART資料做的故障預測，達到了令人滿意的效果。在實際運營環境中驗證的結果如下：準確率precision達到98%，預測時間leadtime的整體偏差不超過2天。

需要重點指出的是，我們做的預測結果，除了training階段用歷史資料外，驗證的過程是用現網的實時資料來進行的。就是說，經過SVM演算法得到的預測模型後，我們是用最新採集的實時資料輸入到模型中，得到的ok和fail兩種預測結果，在3天、7天、14天后再對預測的結果進行驗證。這個比傳統的預測方式（訓練和驗證都是使用歷史資料），對現網應用的價值大大提高了。目前在現網環境中，主要的落地場景包括：1）預測出來的結果，經過運營流程，對BG業務提前發出預警，以提高業務運維效率 2）根據預測出來的大規模硬碟故障，對備件進行有效管理。

伺服器利用率分析

騰訊的業務型別和機型都相當多，機器分配給業務後，使用的情況如何？我們需要跟蹤伺服器的利用率情況，下圖是某業務某機型磁碟IO的利用率統計分析圖。分析過程如下：儲存類機型，看到一段時間統計出來的IO的利用率並不高，並且是寫少讀多的應用，是否可以考慮使用IOPS相對不高的廉價硬碟？還是業務的架構存在優化的空間？

伺服器利用率分析給運營帶來的好處在於：1）結合業務模型，發現業務應用伺服器的短板，在發現並修復系統架構缺陷的同時，提高整體利用率；2）對機型選型的優化，例如對於磁碟容量使用率不高的機型，在後續的機型定製中減少硬碟的數量。

故障率分析

伺服器故障分析對伺服器的各個部件的故障率都做了分析和監控，包括1）生成月度故障率報表；2）故障率異常的實時監控和自動告警；3）分析外部條件與故障率的關係；4）與OS的軟體告警資訊聯動起來，及時發現伺服器的亞健康狀態。

上圖是某伺服器硬體最近幾周的故障率統計資訊。按部件給出各個機型的故障率情況，及時發現批次性故障並給出告警

環境監控

2013年8月，華東地區遭遇罕見的高溫天氣，很多機房空調製冷扛不住了，頻繁發生伺服器高溫重啟的事件。如果能把機房環境溫度有效的監控起來，我們就能在發現異常時發出高溫告警，提前採取措施。對伺服器入風口溫度進行採集和監控是一個較為有效的方案。

上圖顯示伺服器入風口溫度變化的異常情況，經過資料的規整和誤差修正，產生了高溫告警。通過自動化流程，及時知會到機房現場負責人。

一些思考

不要被資料誤導

人們很容易被大資料忽悠。在很多場合我們都談了大資料強大的功能和美好的未來，認為可以解決許多社會問題，甚至預測未來。無論大資料如何神奇，若試圖用大資料引領未來只會誤入歧途，因為大資料背後本就存在著“先天不足”：從本質上看，大資料最大的缺陷就在於試圖以確定去“顛覆”混沌與不確定性。之前我們做硬碟故障預測，直觀的認為硬碟的讀寫壓力對硬碟老化和故障是有直接關係的，但經過分析，發現業務使用硬碟的隨機性太大了，硬碟響應IO的模式也很多變，對於業務的IO讀寫比例、塊大小等，有太多的不確定性，就是前面說的混沌，導致前面基於IO做的預測結果非常糟糕。其實這裡要說的就是，目前這個階段，依靠大資料來指導伺服器運營，不靠譜，伺服器運營智慧化遠遠沒有達到。這裡還是要靠運營和開發人員的思維和頭腦，把自動化運營先做好。

資料質量的把控

資料的質量和欄位規範性對後面分析效果的影響很大。但業務開發所設計的資料不是為了運營分析而服務的，很多情況下都是為了功能開發而存在，如果可以在系統構建初期進行介入，其實可用避免很多清洗工作，資料可直接投入分析使用。這裡開發人員和資料分析的人員存在一個gap，如果對資料在系統設計中遇上各種約束的話，開發人員會覺得很痛苦，開發效率非常低；而資料分析人員卻覺得如果資料能做到工具級定製，就是連資料的表欄位的名稱，註釋，連內部關係，都是由系統統一生成，這樣採集完美的。

後來，我們內部經過一段時間的討論和磨合，形成的共識。我們做的是運營系統，歸根到底是為運營服務的，而資料分析是運營的一個重要功能。所以沒有辦法，這個問題還是需要開發階段來解決，開發人員只能克服了。

對大資料未來的設想

精細化的感測器

對於伺服器上感測器的設計，網際網路企業有特殊的需求，對上游硬體廠商的依賴是比較高的。騰訊有大量的伺服器運營資料，非常希望可以跟業界一起在資料、資源、演算法等各個維度可以共享，尋求更多提高運營效率的途徑。這裡的感測器也可以從廣義上來展開，除了伺服器物理上的sensor越來越多，在伺服器各個運營環節都可以在流程中加入各種採集程式碼，把伺服器部署、搬遷、退役等每個細小的步驟都如實的記錄下來。運營系統的不斷優化將使“感測器”體積微型化，它將出現在生產的每一個角落，為運營決策提供更科學的資料支撐。

資料服務即開即用

隨著資料的逐步完善和開放，網際網路和企業都將建立起完善的大資料服務基礎架構及商業化模式，從資料的儲存、挖掘、管理、計算等方面提供一站式服務，將各行各業的資料孤島打通互聯。而且資料應用的生態系統也將變得非常成熟，甚至出現使用者與資料服務商之間的演算法提供商，他們有專業領域內的精英人才，通過資料探勘的方式，尋找事物間的聯絡。使用者只需將其原始資料匯入，提供商很快的就能線上的將分析結果返回，如水和電一樣，即開即用。