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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

基礎(chǔ)設(shè)施及服務(wù)。把底層運(yùn)維資源的管理封裝成一個一個的服務(wù)，供業(yè)務(wù)自動化平臺使用。我把DNS、LVS（或者F5）甚至OS上的配置管理都看著基礎(chǔ)設(shè)施部分，適當(dāng)?shù)叵蛏涎由炝艘幌?。簡單的劃分原則是，在業(yè)務(wù)架構(gòu)之外的，都可當(dāng)著基礎(chǔ)架構(gòu)部分了。很多運(yùn)維團(tuán)隊的建設(shè)重點(diǎn)都在這塊。

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

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

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

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

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

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

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

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

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

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

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

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

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