運維平臺體系的工作方法和思路

識別運維平臺的邊界在哪兒，才能更好地構建平臺，從而協(xié)助運維的日常工作。

在之前的文章中，談到過“運維的本質——可視化”，在可視化的篇幅中，著重介紹自動化的可視化和數(shù)據(jù)的可視化；在后續(xù)的篇章中又介紹了“互聯(lián)網運維的價值體系”，里面分解了幾個維度：質量、成本、效率、安全等。以上都是為了清楚地梳理運維的內容邊界，基于這個邊界，我們再考慮如何進行平臺支撐?？梢哉f前兩篇文章都是為今天這篇文章作為鋪墊，用理念先行，然后再考慮平臺落地，最后再細化其中每個內容。我更習慣用如下的方式來整體表達運維的工作方法和思路：

首先，價值導向。找到一個價值方向來牽引整個團隊很難，但又必須找到，因這個牽引力就決定了團隊的氣質及后續(xù)的工作方法；之前的文章“運維價值體系”有詳述，在此不細談。

其次，要有一個分而治之的系統(tǒng)，最后面向業(yè)務自底向上的集成，此時便能幫忙實現(xiàn)更好、更快、更省的交付價值。平臺的建設需遵循一些的方法（自底向上、先后順序等），先建設各個運維專業(yè)子系統(tǒng)，通過API的方式對上暴露服務，最后不同的業(yè)務平臺去調用這些服務接口即可。缺少平臺的支持，運維的質量、成本、效率都會直接受到影響。如果要做好服務器精細化成本控制，此時需要一個平臺來處理從服務器資源上采集的資源使用狀態(tài)數(shù)據(jù)，并生成可視化數(shù)據(jù)報表，共享到所有團隊中，在一致理解下，去驅動成本優(yōu)化，越海量的業(yè)務對這個平臺的要求就越高，從采集、處理、模型算法等都有很高的要求。

不要忘了這個平臺還包含面向業(yè)務技術棧構建的平臺。這地方有一個非常好的例子，在2012年左右，我了解到Google有一個非常強大的資源管理平臺Borg（后面叫Omega），它的設計目標是“把數(shù)據(jù)中心看成一個芯片”。Google研發(fā)人員將開發(fā)的服務交給Borg，后續(xù)的服務生命周期（擴容、縮容、調度）都由Borg統(tǒng)一接管，服務被Borg部署到哪個IDC、哪個服務器，研發(fā)人員不用關心。后來Twitter根據(jù)Borg的思想，也開源實現(xiàn)了一個平臺——Mesos，不過Mesos對LongTime的服務調度（如Nginx）支持不是太好，更適合MapReduce的事務調度。這兩個資源管理平臺背后的思想都值得深究，建議看看。

第三，基于平臺，提供透明服務，確保服務提供者和服務交互者之間的交互越少越好。有了整合性的平臺，透明提供服務也成為可能。平臺整合就是避免服務被碎片化，從而讓使用的用戶看到的不是一個一個工具或者孤立系統(tǒng)，而是面向業(yè)務的整合服務。此時成本便可降低、變更的質量也會變成一個穩(wěn)定態(tài)。不同的人、不同的時間執(zhí)行相同的事務流程都能取得一致的執(zhí)行結果。

最后，數(shù)據(jù)驅動。因所有線上業(yè)務服務和線下運維服務都有狀態(tài)，需數(shù)據(jù)平臺提供服務狀態(tài)數(shù)據(jù)的采集、處理、分析處理能力，最后還能讓運維人員自定義分析報表。技術運營數(shù)據(jù)和產品數(shù)據(jù)的一個很大的區(qū)別是，前者在數(shù)據(jù)挖掘方面的能力要求很少。這個地方有個建議，把線上服務的數(shù)據(jù)驅動作為重點（80%），把運維內部服務的數(shù)據(jù)驅動為輔（20%）。因為線上服務的狀態(tài)會反作用于運維內部事務的優(yōu)化。比如說從數(shù)據(jù)中發(fā)現(xiàn)現(xiàn)網的服務有一個故障，需要緊急發(fā)布版本，此時就會直接檢驗運維的變更部署流程、平臺的完備性。

在平臺體系部分，我采用逐級構建的方法，不斷去細化其中的內容，因此會有一級視圖和二級視圖，在這個地方，我不敢到三級的模塊級別，基本上不可看，下圖是參照的是eTOM模型構建方法。

繼續(xù)往下，可以分解出二級視圖。

有了整體的平臺體系視圖，接下來看看每一部分到底是干什么的。

工作流引擎、權限管理。這兩者都是基本的功能，因為其中會涉及流程，所以需要統(tǒng)一的流程引擎平臺。另外需要部門、角色、用戶的權限管理統(tǒng)一管理，不同業(yè)務配置不同系統(tǒng)的使用策略即可，這一塊可以統(tǒng)一實現(xiàn)在單點登陸系統(tǒng)中。

基礎設施物理層。這個視角和傳統(tǒng)模式有些不同，主要是公有云的存在。因此在基礎設施物理層這塊，已經把云端資源當作一個底層基礎設施來看待，后續(xù)的資源獲取完全不同，其他的資源對象依然沒有變化，依然是機房、機柜、網絡、服務器，等等。

配置及服務，把配置當作服務來看待。在ITIL中叫CMDB，Configuration Management Database， CMDB也可以理解成統(tǒng)一的元數(shù)據(jù)庫，比如說機房信息、服務器信息、人員信息、服務信息、業(yè)務信息以及他們之間的物理和業(yè)務拓撲關系等，上層的所有系統(tǒng)都應該關聯(lián)到CMDB，變更后的信息必須實時反饋到CMDB中，確保其他系統(tǒng)能同步這份變化。因此大家都把CMDB系統(tǒng)當作運維的核心系統(tǒng)來對待，便于后續(xù)各個系統(tǒng)之間的互通。

在我的經驗中，CMDB建設還是有非常多的坑。如果你把iTop或者oneCMDB的產品當著標桿（都是開源，沒見過商業(yè)的），那你的CMDB建設就完了。之前在一家傳統(tǒng)企業(yè)，他們把文檔都放到CMDB中管理，不建議這么做，文檔就是SCM的事情。CMDB建設的核心準則：CMDB管理的數(shù)據(jù)一定要為了業(yè)務管理，業(yè)務管理上不需要的東西，就果斷舍棄，比如說文檔，和業(yè)務沒有任何關系，就可以不考慮納入，后續(xù)會有專門的文章介紹。

ITIL服務——基礎、ITIL服務——高級。在早期的文章中把DevOps和ITIL做了對比，ITIL是面向流程的，這個可以在運維平臺建設中不做重點，不要主動去構建流程，會影響運維的敏捷性?；A部分實現(xiàn)一個事件和HelpDesk即可，事件管理在告警轉換成事件之后，可以完整地記錄，便于我們事后的原因分析，能挖掘一些問題，比如說是否某個業(yè)務、某個人、某類機器經常性故障，那就需要重點關注下。高級服務的部分，大家需關注一下，它是可以帶來價值的，比如說可用性管理、能力管理和連續(xù)性管理?？捎眯灾苯拥膶蚓褪菢I(yè)務的質量；能力管理直接的導向就是成本管理；連續(xù)性管理也是和質量戚戚相關，如業(yè)務的容災、備份管理等。但這些管理都不要在流程層面上去看，需要在一個平臺中進行全面的可視化管理。后續(xù)的篇章也會有相應的介紹。

基礎設施及服務。把底層運維資源的管理封裝成一個一個的服務，供業(yè)務自動化平臺使用。我把DNS、LVS（或者F5）甚至OS上的配置管理都看著基礎設施部分，適當?shù)叵蛏涎由炝艘幌隆：唵蔚膭澐衷瓌t是，在業(yè)務架構之外的，都可當著基礎架構部分了。很多運維團隊的建設重點都在這塊。

架構及服務。把業(yè)務架構中的共性需求都剝離出來，抽象成一個一個的服務，最終讓研發(fā)只需要關注自己的業(yè)務代碼即可，比如說統(tǒng)一文件存儲、統(tǒng)一Nosql存儲、統(tǒng)一RDS存儲、統(tǒng)一隊列等。這塊對運維的質量、效率、能力等影響最大，在之前的文章“如何化解研發(fā)和產品之間的矛盾”中重點闡述過服務公共化是唯一的解決之道?，F(xiàn)實中如果有研發(fā)開發(fā)了一個公共組件交給運維，而不提供完整的Webadmin或者API的話，你也就可以認為他是在耍流氓，運維必須有嚴格的完整性交付要求。

數(shù)據(jù)及服務。只要有線上服務在運行，服務數(shù)據(jù)流經過的一切節(jié)點產生的數(shù)據(jù)，你都要采集、存儲和分析起來，供不同的運維場景使用。比如說自動化調度，可以根據(jù)業(yè)務涉及的基礎節(jié)點資源使用情況，制定對應的自動化調度策略；可以在數(shù)據(jù)中直接進行故障定位；可以在數(shù)據(jù)中做安全分析。之前的文章“數(shù)據(jù)驅動運維”中介紹過我做的一個數(shù)據(jù)分層體系。

監(jiān)控及服務，有數(shù)據(jù)的地方才有監(jiān)控。脫離這個原則，你做的都是告警，并且告警的成本會越來越大，不成體系。個人觀點：所有的監(jiān)控視圖都是來源于我們對數(shù)據(jù)的采集以及我們到底有多少經驗來看待數(shù)據(jù)。

持續(xù)集成。這條線是把一個個的程序包交付到各個環(huán)境，在【持續(xù)部署】之上的部分可以通過和持續(xù)集成工具Jenkins或者Go作對接即可。持續(xù)反饋非常重要，一個程序部署到生產環(huán)境之后，需要實時的運行報告反饋回來，確認變更的效果。如果持續(xù)部署平臺化之后，真正的執(zhí)行部署工作會不斷前移，甚至可能直接交付給研發(fā)。此時的狀態(tài)報告，更是有必要，不需要人去登錄主機tail日志看是否正常。這個地方和“數(shù)據(jù)及服務”的能力關聯(lián)很大，沒有前面強大的數(shù)據(jù)服務能力。

面向業(yè)務的運維平臺。不同的業(yè)務會有不同的調度策略和服務使用策略，需要在更上層完成面向業(yè)務的統(tǒng)一調度，這個是全應用的視角，和持續(xù)集成是有一些區(qū)別的。在沒有這個平臺之前，一個完整的業(yè)務上線，需要做很多操作，比如說DNS變更、LVS變更、OS初始化、自動化測試、持續(xù)部署、持續(xù)反饋、監(jiān)控、業(yè)務調用關系配置，等等。面向業(yè)務的調度平臺，就需要有一種調度能力，指揮底層各個平臺為它服務，它本身不實現(xiàn)任何服務接口，是一個服務的集成者。

運維統(tǒng)一門戶。每個運維系統(tǒng)都有任務或者信息與自己相關，如果運維人員每天要去面對那么多的運維系統(tǒng)，會非常痛苦。在統(tǒng)一門戶里面分成兩個部分，一部分是任務中心，把底層所有的事務狀態(tài)都同步到任務中心中，表示我要做什么；信息中心，就是讓運維人平時關注的業(yè)務狀態(tài)Dashboard直接推送到信息中心中，表示我要關注什么。

平臺的目標就是自動化和數(shù)據(jù)化一切，并且最終可視化，從而確保質量、效率和成本幾者之間的平衡。但對于這么一個龐大的復雜體系來說，不可能一蹴而就，可以借鑒一下經驗。

自底向上。一定要把握這個原則，這就相當于我們造車一樣，把各個零件造好了，最后就是組裝。

加強跨團隊之間的合作與溝通。很多事情一旦研發(fā)、測試和運維彼此合作，事半功倍。在合作的過程中，把彼此的需求都統(tǒng)一到平臺中，這樣有利于后續(xù)的推廣和使用。

平臺建設先后有序，優(yōu)先級順序如下：

l P1（最高）：CMDB、基礎架構及服務、數(shù)據(jù)及服務、監(jiān)控及服務、持續(xù)集成；

l P2（次高）：面向業(yè)務的運維平臺；

l P3（低）：ITIL相關、運維統(tǒng)一門戶。