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