關(guān)鍵詞：
大數(shù)據(jù)
服務(wù)器
摘要：騰訊公司從2012年開始，通過對服務(wù)器運營流程、工具系統(tǒng)的建設(shè)，服務(wù)器從一線到三線的運營基本轉(zhuǎn)入線上自動化。在服務(wù)器靜態(tài)配置、動態(tài)的運行狀態(tài)和生命周期各個節(jié)點的運營這幾個方面，產(chǎn)生了大量的運營數(shù)據(jù)，這些信息像滾雪球一樣，以幾何量級快速增長。數(shù)據(jù)越來越多，該如何著手處理呢？這就像剛?cè)腴T的廚子一樣，在農(nóng)貿(mào)市場里面對堆積如小山般的食材，無從下手。到2013年，建立網(wǎng)平的大數(shù)據(jù)平臺，把所有的基礎(chǔ)架構(gòu)運營數(shù)據(jù)統(tǒng)一接入和管理，從此，我們開始了在數(shù)據(jù)礦山中挖掘金礦的歷程。
大數(shù)據(jù)的處理
經(jīng)過長時間的實踐和總結(jié)，我們發(fā)現(xiàn)服務(wù)器運營的大數(shù)據(jù)有以下四個特點，由淺入深，分別是：1）Volume 數(shù)據(jù)體量巨大，特別是騰訊有海量的服務(wù)器，綜合起來，數(shù)據(jù)量可以到PB級別，需要大容量、高性能的存儲技術(shù)，分析的算法也需要最優(yōu)化；2）Variety 數(shù)據(jù)類型眾多，涉及大量的運行日志、部件狀態(tài)、生產(chǎn)鏈運營、環(huán)境變量等，經(jīng)常要抽絲剝繭，才能找到有用的數(shù)據(jù)；3）Value 價值巨大，但并不是每個數(shù)據(jù)都有價值，需要經(jīng)過清洗和加工處理后，其產(chǎn)生的效果才能顯現(xiàn)，以機房環(huán)境溫度告警為例，數(shù)百萬條溫度的信息，經(jīng)過分析對比后，才有可能發(fā)現(xiàn)溫度異常；4）Velocity 數(shù)據(jù)需要快速處理，特別是告警類的應(yīng)用，時效性是非常重要的。
下面講講我們是怎么收集和存儲服務(wù)器運營數(shù)據(jù)的，給我三分鐘，給你一個帥氣又有營養(yǎng)的答案！
運營系統(tǒng)架構(gòu)
對于海量服務(wù)器的管理，我們建立了一套功能強大的運營分析系統(tǒng)，從服務(wù)器的帶內(nèi)和帶外收集了全面的靜態(tài)屬性和動態(tài)運行數(shù)據(jù)，對服務(wù)器的每個關(guān)節(jié)進行的全方位的數(shù)據(jù)采集和監(jiān)控。猶如我們平時體檢，把心、肝、脾、肺、腎，甚至每個毛孔，都進行了檢查。系統(tǒng)架構(gòu)如下圖所示。
存儲和分析
數(shù)據(jù)收集起來后，除了一部分實時的數(shù)據(jù)存在本地數(shù)據(jù)庫，幾乎全部的歷史數(shù)據(jù)都會存儲在公司級的數(shù)據(jù)平臺中。這個數(shù)據(jù)平臺提供了豐富的工具系統(tǒng)，功能全面，涵蓋了數(shù)據(jù)存儲、分析、實時計算等。例如，TPG是基于postgreSQL的數(shù)據(jù)庫，用于存放TDW（Tencent distributed Data Warehouse騰訊分布式數(shù)據(jù)倉庫）離線分析后的結(jié)果數(shù)據(jù)，便于系統(tǒng)調(diào)用（如服務(wù)器利用率分析，故障分析、服務(wù)器生命周期等生產(chǎn)數(shù)據(jù)）；Hbase基于No SQL，萬億級的分布式、有序數(shù)據(jù)存儲，用于存放分析后的結(jié)果數(shù)據(jù)（如溫度功耗分析結(jié)果數(shù)據(jù)）。整體的架構(gòu)如下圖所示。
大數(shù)據(jù)的四個實踐
大數(shù)據(jù)的規(guī)劃分析，決策者和開發(fā)者首先要從業(yè)務(wù)驅(qū)動的角度，選擇數(shù)據(jù)生產(chǎn)的業(yè)務(wù)場景，即要預(yù)計數(shù)據(jù)分析得到的結(jié)果能帶來哪些效益。根據(jù)公司服務(wù)器運營的特點，我們在以下四個場景做了大數(shù)據(jù)的分析和應(yīng)用，給實際的運營帶來的實實在在的好處。
硬盤故障預(yù)測
硬盤是服務(wù)器硬件故障率最高的一個部件，如果能提前預(yù)測到硬盤故障，對業(yè)務(wù)體驗、完善備件管理都有莫大的收益。這也是基礎(chǔ)架構(gòu)運營在經(jīng)歷自動化、流程化后，需要進一步提升運營效率、降低運營成本的天然要求。
涉及硬盤的運營數(shù)據(jù)包括業(yè)務(wù)IO數(shù)據(jù)、硬盤內(nèi)部的SMART和硬盤運行的環(huán)境變量數(shù)據(jù)(溫度和濕度)。目前，運營系統(tǒng)對IO數(shù)據(jù)是每小時采集一次，SMART數(shù)據(jù)每三小時采集一次，溫度和濕度每半小時采集一次，這些數(shù)據(jù)合計起來每天的記錄數(shù)上億條。硬盤故障預(yù)測，適合使用分類算法，我們使用了目前較為流行的SVM分類算法，輔以合適的核函數(shù)來加快學習計算的效率。
經(jīng)過了一年多時間的實踐，走了不少彎路，也碰到了很多坑，在硬盤故障標準確定、業(yè)務(wù)IO分類定義等方面吃了不少的虧，我們在基于SMART數(shù)據(jù)做的故障預(yù)測，達到了令人滿意的效果。在實際運營環(huán)境中驗證的結(jié)果如下：準確率precision達到98%，預(yù)測時間leadtime的整體偏差不超過2天。
需要重點指出的是，我們做的預(yù)測結(jié)果，除了training階段用歷史數(shù)據(jù)外，驗證的過程是用現(xiàn)網(wǎng)的實時數(shù)據(jù)來進行的。就是說，經(jīng)過SVM算法得到的預(yù)測模型后，我們是用最新采集的實時數(shù)據(jù)輸入到模型中，得到的ok和fail兩種預(yù)測結(jié)果，在3天、7天、14天后再對預(yù)測的結(jié)果進行驗證。這個比傳統(tǒng)的預(yù)測方式（訓練和驗證都是使用歷史數(shù)據(jù)），對現(xiàn)網(wǎng)應(yīng)用的價值大大提高了。目前在現(xiàn)網(wǎng)環(huán)境中，主要的落地場景包括：1）預(yù)測出來的結(jié)果，經(jīng)過運營流程，對BG業(yè)務(wù)提前發(fā)出預(yù)警，以提高業(yè)務(wù)運維效率； 2）根據(jù)預(yù)測出來的大規(guī)模硬盤故障，對備件進行有效管理。
服務(wù)器利用率分析
騰訊的業(yè)務(wù)類型和機型都相當多，機器分配給業(yè)務(wù)后，使用的情況如何？我們需要跟蹤服務(wù)器的利用率情況，下圖是某業(yè)務(wù)某機型磁盤IO的利用率統(tǒng)計分析圖。分析過程如下：存儲類機型，看到一段時間統(tǒng)計出來的IO的利用率并不高，并且是寫少讀多的應(yīng)用，是否可以考慮使用IOPS相對不高的廉價硬盤？還是業(yè)務(wù)的架構(gòu)存在優(yōu)化的空間？
服務(wù)器利用率分析給運營帶來的好處在于：1）結(jié)合業(yè)務(wù)模型，發(fā)現(xiàn)業(yè)務(wù)應(yīng)用服務(wù)器的短板，在發(fā)現(xiàn)并修復系統(tǒng)架構(gòu)缺陷的同時，提高整體利用率；2）對機型選型的優(yōu)化，例如對于磁盤容量使用率不高的機型，在后續(xù)的機型定制中減少硬盤的數(shù)量。
故障率分析
服務(wù)器故障分析對服務(wù)器的各個部件的故障率都做了分析和監(jiān)控，包括1）生成月度故障率報表；2）故障率異常的實時監(jiān)控和自動告警；3）分析外部條件與故障率的關(guān)系；4）與OS的軟件告警信息聯(lián)動起來，及時發(fā)現(xiàn)服務(wù)器的亞健康狀態(tài)。
上圖是某服務(wù)器硬件最近幾周的故障率統(tǒng)計信息。按部件給出各個機型的故障率情況，及時發(fā)現(xiàn)批次性故障并給出告警
環(huán)境監(jiān)控
2013年8月，華東地區(qū)遭遇罕見的高溫天氣，很多機房空調(diào)制冷扛不住了，頻繁發(fā)生服務(wù)器高溫重啟的事件。如果能把機房環(huán)境溫度有效的監(jiān)控起來，我們就能在發(fā)現(xiàn)異常時發(fā)出高溫告警，提前采取措施。對服務(wù)器入風口溫度進行采集和監(jiān)控是一個較為有效的方案。
上圖顯示服務(wù)器入風口溫度變化的異常情況，經(jīng)過數(shù)據(jù)的規(guī)整和誤差修正，產(chǎn)生了高溫告警。通過自動化流程，及時知會到機房現(xiàn)場負責人。
一些思考
不要被數(shù)據(jù)誤導
人們很容易被大數(shù)據(jù)忽悠。在很多場合我們都談了大數(shù)據(jù)強大的功能和美好的未來，認為可以解決許多社會問題，甚至預(yù)測未來。無論大數(shù)據(jù)如何神奇，若試圖用大數(shù)據(jù)引領(lǐng)未來只會誤入歧途，因為大數(shù)據(jù)背后本就存在著“先天不足”：從本質(zhì)上看，大數(shù)據(jù)最大的缺陷就在于試圖以確定去“顛覆”混沌與不確定性。之前我們做硬盤故障預(yù)測，直觀的認為硬盤的讀寫壓力對硬盤老化和故障是有直接關(guān)系的，但經(jīng)過分析，發(fā)現(xiàn)業(yè)務(wù)使用硬盤的隨機性太大了，硬盤響應(yīng)IO的模式也很多變，對于業(yè)務(wù)的IO讀寫比例、塊大小等，有太多的不確定性，就是前面說的混沌，導致前面基于IO做的預(yù)測結(jié)果非常糟糕。其實這里要說的就是，目前這個階段，依靠大數(shù)據(jù)來指導服務(wù)器運營，不靠譜，服務(wù)器運營智能化遠遠沒有達到。這里還是要靠運營和開發(fā)人員的思維和頭腦，把自動化運營先做好。
數(shù)據(jù)質(zhì)量的把控
數(shù)據(jù)的質(zhì)量和字段規(guī)范性對后面分析效果的影響很大。但業(yè)務(wù)開發(fā)所設(shè)計的數(shù)據(jù)不是為了運營分析而服務(wù)的，很多情況下都是為了功能開發(fā)而存在，如果可以在系統(tǒng)構(gòu)建初期進行介入，其實可用避免很多清洗工作，數(shù)據(jù)可直接投入分析使用。這里開發(fā)人員和數(shù)據(jù)分析的人員存在一個gap，如果對數(shù)據(jù)在系統(tǒng)設(shè)計中遇上各種約束的話，開發(fā)人員會覺得很痛苦，開發(fā)效率非常低；而數(shù)據(jù)分析人員卻覺得如果數(shù)據(jù)能做到工具級定制，就是連數(shù)據(jù)的表字段的名稱，注釋，連內(nèi)部關(guān)系，都是由系統(tǒng)統(tǒng)一生成，這樣采集完美的。
后來，我們內(nèi)部經(jīng)過一段時間的討論和磨合，形成的共識。我們做的是運營系統(tǒng)，歸根到底是為運營服務(wù)的，而數(shù)據(jù)分析是運營的一個重要功能。所以沒有辦法，這個問題還是需要開發(fā)階段來解決，開發(fā)人員只能克服了。
對大數(shù)據(jù)未來的設(shè)想
精細化的傳感器
對于服務(wù)器上傳感器的設(shè)計，互聯(lián)網(wǎng)企業(yè)有特殊的需求，對上游硬件廠商的依賴是比較高的。騰訊有大量的服務(wù)器運營數(shù)據(jù)，非常希望可以跟業(yè)界一起在數(shù)據(jù)、資源、算法等各個維度可以共享，尋求更多提高運營效率的途徑。這里的傳感器也可以從廣義上來展開，除了服務(wù)器物理上的sensor越來越多，在服務(wù)器各個運營環(huán)節(jié)都可以在流程中加入各種采集代碼，把服務(wù)器部署、搬遷、退役等每個細小的步驟都如實的記錄下來。運營系統(tǒng)的不斷優(yōu)化將使“傳感器”體積微型化，它將出現(xiàn)在生產(chǎn)的每一個角落，為運營決策提供更科學的數(shù)據(jù)支撐。
數(shù)據(jù)服務(wù)即開即用
隨著數(shù)據(jù)的逐步完善和開放，互聯(lián)網(wǎng)和企業(yè)都將建立起完善的大數(shù)據(jù)服務(wù)基礎(chǔ)架構(gòu)及商業(yè)化模式，從數(shù)據(jù)的存儲、挖掘、管理、計算等方面提供一站式服務(wù)，將各行各業(yè)的數(shù)據(jù)孤島打通互聯(lián)。而且數(shù)據(jù)應(yīng)用的生態(tài)系統(tǒng)也將變得非常成熟，甚至出現(xiàn)用戶與數(shù)據(jù)服務(wù)商之間的算法提供商，他們有專業(yè)領(lǐng)域內(nèi)的精英人才，通過數(shù)據(jù)挖掘的方式，尋找事物間的聯(lián)系。用戶只需將其原始數(shù)據(jù)導入，提供商很快的就能在線的將分析結(jié)果返回，如水和電一樣，即開即用。
