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

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

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

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

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

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

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

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

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

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

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

基礎(chǔ)設(shè)施物理層。這個(gè)視角和傳統(tǒng)模式有些不同，主要是公有云的存在。因此在基礎(chǔ)設(shè)施物理層這塊，已經(jīng)把云端資源當(dāng)作一個(gè)底層基礎(chǔ)設(shè)施來看待，后續(xù)的資源獲取完全不同，其他的資源對(duì)象依然沒有變化，依然是機(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，變更后的信息必須實(shí)時(shí)反饋到CMDB中，確保其他系統(tǒng)能同步這份變化。因此大家都把CMDB系統(tǒng)當(dāng)作運(yùn)維的核心系統(tǒng)來對(duì)待，便于后續(xù)各個(gè)系統(tǒng)之間的互通。

在我的經(jīng)驗(yàn)中，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ù)會(huì)有專門的文章介紹。

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

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

架構(gòu)及服務(wù)。把業(yè)務(wù)架構(gòu)中的共性需求都剝離出來，抽象成一個(gè)一個(gè)的服務(wù)，最終讓研發(fā)只需要關(guān)注自己的業(yè)務(wù)代碼即可，比如說統(tǒng)一文件存儲(chǔ)、統(tǒng)一Nosql存儲(chǔ)、統(tǒng)一RDS存儲(chǔ)、統(tǒng)一隊(duì)列等。這塊對(duì)運(yùn)維的質(zhì)量、效率、能力等影響最大，在之前的文章“如何化解研發(fā)和產(chǎn)品之間的矛盾”中重點(diǎn)闡述過服務(wù)公共化是唯一的解決之道?，F(xiàn)實(shí)中如果有研發(fā)開發(fā)了一個(gè)公共組件交給運(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ù)，你都要采集、存儲(chǔ)和分析起來，供不同的運(yùn)維場(chǎng)景使用。比如說自動(dòng)化調(diào)度，可以根據(jù)業(yè)務(wù)涉及的基礎(chǔ)節(jié)點(diǎn)資源使用情況，制定對(duì)應(yīng)的自動(dòng)化調(diào)度策略；可以在數(shù)據(jù)中直接進(jìn)行故障定位；可以在數(shù)據(jù)中做安全分析。之前的文章“數(shù)據(jù)驅(qū)動(dòng)運(yùn)維”中介紹過我做的一個(gè)數(shù)據(jù)分層體系。

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

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

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

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

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

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

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

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

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

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

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