在一個新的環境中工作了兩個多月，從業務模式、平臺建設、工作方法和團隊工作風格各個方面都有了一些認識。有了這些認識，更能讓你體會到工作的發力點在哪里，這次自己的工作方法做了很大的調整，沒有去平移過去的工作經驗，因為當前的很多預設條件和過去不同（具體就不一一列舉）。其實運維工作很多時候都聚焦在兩個方面，一個是工具建設；一個是數據建設。在工具平臺建設層面上，進一步突破的阻力很大，一則缺乏標準化的基礎；其次還在于大家意識的改變。因此這次想從數據分析體系入手，用數據說話，用數據評價運維服務。簡而言之，就是數據驅動運維（Data-Driven Ops）。
 　　我把數據運維驅動定義為一種方法，它是通過我們對運維目標的識別，借助全量的數據體系來評價運維過程，以確認和目標的達成程度。此時看到了幾個問題，數據驅動運維的目標是什么？全量的數據體系是什么樣子的？如何建設？最終又如何反作用于運維過程？
 　　數據驅動了運維什么？
 　　運維的日常場景很多，看似繁雜，其實最終都會有對應的目標導向，比如說對產品質量的首要負責；對效率提升有著狂熱的癡迷；對成本有著近乎苛刻的要求，這一切源于生產集群都是有運維管理的。生產集群提供的是面向用戶的服務，服務的質量的好與壞首先必須傳遞到運維側，通過數據的方式進行評測。維護一個(超)大規模的生產集群，又必須促使運維在繁雜的工作中，找到提升效率和人力解放的方法。在很多時候，我們為了提供更好的服務質量，服務提供方不一定需要付出更多的資源成本，也許當前的資源就能夠支撐未來的容量，而不是無數據支撐下，我們就給出了對應的擴容變更方。
 　　什么樣數據可以驅動運維？
 　　面對核心的運維價值和目標，我們需要說明樣的數據來說明我們當前的狀態，此時需要運維采集"大"的數據來分析。一開始不要設定哪些數據是我們需要的，哪些不是我們需要的，但是需要有一個數據歸類的方法，找到數據之間的關系。一個方法，就是跟著用戶訪問流，看請求經過了那些資源和服務，然后統一采集這些資源和服務對象的數據。初步歸類如下：
 　　A）面向用戶
 　　端對于我們來說是非常重要的數據采集點，端采集的數據需要更直接的反應用戶對我們產品的感知。從用戶側來說，我們一般可以看到兩類數據，一類是面向產品運營人員的；一類是面向技術人員。在數據驅動運維的價值中，我們可以采集面向技術人員的數據指標作重點，而少量的采集產品側的數據。
少量的產品側數據，比如說IP、用戶數、PV。這樣的產品數據，可以讓運維在某些場景下，能夠找到事件的相關性。比如說當前的資源容量和業務之間的關系等等。
 　　技術指標，則包含很多，而不同的產品有不同的特征。比如說現在游戲的九游客戶端，我們可以重點收集如下指標，崩潰率、啟動速度、首屏加載時間、下載速度、用戶界面點擊情況、頁面功能返回值、重點元素的加載時間、DNS請求的時間等等。還有一個非常重要的數據，雖然它和產品無關，但是在有端的情況下，能夠幫忙快速測試獲取的，就是我們的機房出口質量數據，可以通過客戶端hook測試點的方法達到。網頁端要采集的數據和方法基本上也和端類似，不一一列舉。
 　　B）面向資源
 　　我們向用戶提供產品和服務的時候，其實是i有很多的資源在支撐，人力資源、帶寬資源、服務器資源、IDC資源、機柜資源等等，我們可以看出資源的對象非常多。如何識別這些資源對象，還是有方法可循的。在我們建設CMDB的時候，我們通過業務導向的方法，已經對我們的資源做了一次識別和入庫，此時在cmdb中都建立了要管理的資源對象及其屬性。對資源狀態數據的收集，是為了評估它的容量，以確保對業務未來的支撐。可以轉移一些指標來看一下如何和業務關聯？
 　　帶寬、服務器、IDC、機柜、CPU、內存、網卡、磁盤IO，這些資源決定著服務的支撐能力?？梢越藴实娜萘磕Ｐ?，來計算資源的使用率。同時設定資源的容量模型，確保業務的突發情況。在面向用戶的數據采集中，我們采集了部分的業務數據，此時可以根據業務的趨勢，進一步去看未來的資源容量變更情況。
 　　C）面向公共服務
 　　公共服務是指我們常見的存儲服務、cache服務、負載均衡服務、名字服務等等，比如說分布式存儲、DNS。是在之前資源基礎上，一個面向應用的能力封裝。在CMDB中，其實把服務也當作一種資源，但個人還是喜歡把它剝離出來看，因它的特征表現和數據采集的方法都和傳統資源采集方法截然不同。
 　　不同的服務需要關注的指標都非常不同，比如說DNS服務，你會關注的解析成功率和解析時間，你還要關注各地LDNS的解析次數，甚至還要關注某次變更之后LDNS的解析異常情況等等。Mysql、memcache、分布式文件存儲等各類服務，所需要關注的指標都截然不同。
 　　D）面向接口
 　　我們知道用戶的請求在頁面或者客戶端產生之后，一定會轉換到內部分布式系統之間大量的調用。分布式系統典型特征，不是函數式的編程模型，更多的是RPC事件調用的方式，因此此時對這類數據的采集顯得尤為重要。接口數據有很多和其他數據采集表現不同的特征。第一、數據量非常大，因此一般采用抽樣模型。不過這個地方一定要接口調用量，在很少的情況下，建議全量模式；第二、實施難度大。不同的語言，不同的RPC調用模型，采集的方式都有不同，需要開發深度的配合；第三、采集的數據分析成本高。因為量大，使用傳統的技術方法和分析模型難以應對；第四、數據價值最大。在故障發現和運維優化層面，這個數據最有說服力，隨用戶服務好壞的最直接表現；第五、采集數據模型最容易統一。關注的都是服務訪問的延時和失敗情況，在加上服務實例之間的描述就可以了。
 　　E）面向整合
 　　當我們采集了以上四類數據之后，我們會發現這些數據是一個離散狀態，而非關聯。用關聯的視角，更多是從業務拓撲、物理拓撲及用戶訪問流三個角度去看，整合之后的數據更能體現數據的價值。關聯的數據也給提煉核心數據價值帶來很大的困擾，因多樣化的數據帶來的干擾，此時需要回到運維價值驅動的角度。還有一種整合的數據，直接是在用戶的實際訪問流中通過染色的機制來實現數據采集，這個數據對故障定位的意義非常大，能夠快速發現問題，通過染色機制，看用戶請求在內部服務之間穿越，尋找故障根源點。
 　　什么方法可以幫助構建數據體系？
 　　上節我們已經詳細敘述了需要收集的數據，那么有哪些方法來指導我們完成這樣的數據收集、分析呢？
 　　第一個方法：目標價值驅動法。數據的意義都是最終未來到導向運維的幾個價值（質量、效率、成本），有了這些價值，我們再回到我們評估的對象，無論是產品功能、資源、服務還是接口等等，我們都有了評價的指標體系?；谶@個評價體系，我們不斷深入挖掘數據的構成。
 　　第二個方法：運維場景分析法。在我們日常的運維場景中，我們可以提煉一些核心場景，比如故障定位、服務優化、自動化調度、服務管理等等。有了這些核心場景，我們就需要相應的數據支撐，此時也可以挖掘一些有價值的數據。對于故障定位來說，我們需要降低故障定位的成本，提高故障定位的效率，此時必然需要全面的數據體現，從而能夠快速發現故障源；服務優化，有了業務運營數據的積累，我們才知道我們服務的瓶頸在哪里，甚至一次版本變更后的服務質量變好和變壞都可以通過數據來直接評估；自動化調度，我們需要實時的知道服務器資源、帶寬的資源使用情況，從而確定準確的調度策略；服務管理，服務的生命周期的管理，需要在服務的每一個階段，給出數據運營的狀態，比如說服務部署、服務變更等等。
 　　第三個方法：遺留系統整合法。在我們日常的運維系統中，業務規模是從小到大的，開始我們肯定使用了大量的開源系統，比如說監控cacti、nagios等等，這些數據在長期的運行過程中，必然積累了很多有意義的數據，運維日常的活動也沉淀其中，此時我們可以把整合和替換遺留系統為目標。面對遺留系統，一定有很多需求而放棄了的。我想有了這個數據改造基礎之后，讓用戶需求來持續滾動數據的分析體系，方法快速有效。
 　　什么方法可以構建驅動體系?
 　　前面介紹了，我們需要整理什么樣的數據及數據怎么收集。那如何讓數據產生價值呢？數據運營如果不遵循一套方法，最終變成毫無價值的數據。
 　　第一、堅持數據運維的文化。在日常的運維活動中，我們需要堅持數據說話，堅持數據共享，堅持避免以定性的方法對運維過程、運維故障、運維事件的描述。甚至在有KPI的運維團隊中，建議把這類的數據驅動的運維價值反應到KPI中，確保團隊成員對運維數據是足夠重視的。
 　　第二、適當考慮數據的實時性。一個不能實時反應運維狀態的數據是沒有價值的，此時數據分析人員和運維人員需要把握一個邊界，不能所有的數據都以實時的形式給出，過多實時的數據一則成本很高，其次數據干擾很大。此時可以區分不同角色的數據需求，一線運維告警人員更多的是看服務狀態，因此告警的需求多一些；更上層的運維管理人員希望看到的是服務某個周期（天、周、月）的運行狀態（趨勢、對比、多維）；研發人員的數據需求和一線運維人員差不多；產品人員更多的是關注產品的趨勢和用戶體驗等等。
 　　第三、業務元數據需要沉淀在cmdb，建立底層數據關聯。使用這樣一套公共的基準元數據規則，可以更好的整合數據，比如說業務分類。以業務的角度大家容易統一理解數據，讓數據反向作用于我們維護的業務，非常直觀。
第四、持續滾動反饋的數據體系。讓數據持續滾動起來，方法很簡單，就是和運維目標關聯，通過目標驅動，自上而下的重視這些目標價值。在持續滾動的過程，不斷完善數據源及數據分析和展現方法等等。
 　　其實當前階段，最看重的數據價值是數據驅動了思維和意識的達成。這段時間和我的運維研發團隊在這個方向上達成了一致，在六月份我們會討論具體的行動計劃。先寫這么多，給自己思路做個記錄。