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

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

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

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

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

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

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

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

繼續往下，可以分解出二級視圖。

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

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

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

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

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

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

基礎設施及服務。把底層運維資源的管理封裝成一個一個的服務，供業務自動化平臺使用。我把DNS、LVS（或者F5）甚至OS上的配置管理都看著基礎設施部分，適當地向上延伸了一下。簡單的劃分原則是，在業務架構之外的，都可當著基礎架構部分了。很多運維團隊的建設重點都在這塊。

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

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

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

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

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

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

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

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

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

平臺建設先后有序，優先級順序如下：

l P1（最高）：CMDB、基礎架構及服務、數據及服務、監控及服務、持續集成；

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

l P3（低）：ITIL相關、運維統一門戶。