【摘要】

運(yùn)維工作多而繁雜，如何設(shè)定一個(gè)標(biāo)準(zhǔn)來(lái)牽引運(yùn)維工作，至關(guān)重要。本文作者王津銀，互聯(lián)網(wǎng)價(jià)值運(yùn)維倡導(dǎo)者。本文從“可視化”的角度進(jìn)行探討，把可視化落到自動(dòng)化平臺(tái)的可視化和數(shù)據(jù)的可視化兩個(gè)維度上，同時(shí)對(duì)這兩個(gè)維度進(jìn)行了深入的闡述，也給出了具體的平臺(tái)示例，目的是為了提供一個(gè)更清晰的借鑒思路。

正文如下。

運(yùn)維危機(jī)是運(yùn)維人的危機(jī)，你感覺(jué)到了么?

其實(shí)這個(gè)時(shí)候談運(yùn)維危機(jī)有點(diǎn)像在當(dāng)下討論股市危機(jī)一樣，因此寫這篇文章時(shí)，內(nèi)心很糾結(jié)，特別是這個(gè)互聯(lián)網(wǎng)運(yùn)維才產(chǎn)生沒(méi)多少年(10年)的行業(yè)，怎么你就來(lái)談危機(jī)了?沒(méi)辦法，都因技術(shù)發(fā)展太快。

首先帶大家看一組數(shù)據(jù)，國(guó)外著名企業(yè)級(jí)公有云管理市場(chǎng)領(lǐng)導(dǎo)者rightscale每年都會(huì)發(fā)布一份云計(jì)算市場(chǎng)報(bào)告，rightscale應(yīng)該是云管理里面的鼻祖，2013年他們平臺(tái)管理的服務(wù)器達(dá)到580萬(wàn)臺(tái)，因此他的數(shù)據(jù)報(bào)告還是有一定的權(quán)威性，從這個(gè)報(bào)告中可以讓我們看到一些趨勢(shì)。

一、云的使用情況

云的使用度已經(jīng)達(dá)到93%的水平，而在具體的云使用策略上，可以看到未來(lái)多云(82%)和混合云(55%)是未來(lái)的趨勢(shì)。

其實(shí)這兩組數(shù)據(jù)給我們展現(xiàn)都是云的趨勢(shì)越來(lái)越明顯，用戶的接受度越來(lái)越高。而云計(jì)算到底對(duì)運(yùn)維有著什么樣的顛覆力?

2、個(gè)人也對(duì)對(duì)國(guó)內(nèi)的公有云使用情況做了一次調(diào)研，用戶的使用水平也是相當(dāng)?shù)母?游戲領(lǐng)域)，達(dá)到76.19%。因?yàn)闃颖玖坎淮螅瑧?yīng)該會(huì)更高。

3、Rightscale報(bào)告中，也對(duì)DevOps的使用情況做了統(tǒng)計(jì)。用戶應(yīng)用DevOps的理念或者工具很廣泛，達(dá)到66%的水平，相比去年有一定的增長(zhǎng)，并且在IT更復(fù)雜、敏捷性要求更高的大企業(yè)中，DevOps的應(yīng)用比例更高。在DevOps工具的使用上主要是puppet、salt、chef、docker幾類。調(diào)查報(bào)告中用了“DevOps rises，Docker soars”來(lái)總結(jié)DevOps和Docker。

4、為了進(jìn)一步去驗(yàn)證DevOps理念的應(yīng)用情況，我把PuppetLabs的DevOps的報(bào)告又找出來(lái)了，總結(jié)了DevOps的核心理念及實(shí)踐。報(bào)告反復(fù)強(qiáng)調(diào)自動(dòng)化、強(qiáng)調(diào)DevOps文化價(jià)值、強(qiáng)調(diào)數(shù)據(jù)驅(qū)動(dòng)等等，這些對(duì)運(yùn)維又有著什么樣的影響呢?

#p#

二、危機(jī)在哪兒?

1、云計(jì)算平臺(tái)對(duì)運(yùn)維的影響

我們都知道云計(jì)算平臺(tái)有IAAS平臺(tái)、PAAS平臺(tái)、SAAS平臺(tái)之分，不同的部分對(duì)運(yùn)維的角色都有著不同程度的影響。

IAAS把基礎(chǔ)架構(gòu)做成一個(gè)服務(wù)，資源即需即得，這也正式創(chuàng)業(yè)公司都愿意使用公有云平臺(tái)的一個(gè)原因。按照傳統(tǒng)的模式，創(chuàng)業(yè)公司自己需要聯(lián)系機(jī)房、購(gòu)買服務(wù)器、電信機(jī)房放置調(diào)試服務(wù)器/網(wǎng)絡(luò)等等一堆基礎(chǔ)設(shè)施的工程，影響項(xiàng)目周期不說(shuō)，還需要一定的專業(yè)技能，而IAAS把創(chuàng)業(yè)公司都從這些需求中解放出來(lái)。再進(jìn)入到IAAS內(nèi)部幾大部分，軟件定義計(jì)算、軟件定義存儲(chǔ)、軟件定義網(wǎng)絡(luò)，進(jìn)一步降低對(duì)運(yùn)維人的依賴，確保一個(gè)大資源池的整體服務(wù)能力。讓軟件代替人，是IAAS層基本思想，都知道對(duì)于一個(gè)海量的服務(wù)架構(gòu)，同時(shí)要面向不同的業(yè)務(wù)形態(tài)，IAAS只能依賴這樣的軟件定義能力，靠人是跟不上的。剛剛paypal分享他們遷移到openstack經(jīng)驗(yàn)，其中一個(gè)數(shù)據(jù)很有意思，以前paypal對(duì)服務(wù)器故障的容忍度是1%，而遷移云平臺(tái)之后容忍度是3%到5%。要知道這個(gè)比率提高意味著什么，對(duì)運(yùn)維的實(shí)時(shí)事務(wù)處理要求進(jìn)一步降低，也就是對(duì)人的需求減少了。結(jié)論：不需要那么多基礎(chǔ)運(yùn)維人員了。

PAAS部分，進(jìn)一步對(duì)服務(wù)進(jìn)行抽象，變成一個(gè)公共的服務(wù)架構(gòu)，研發(fā)程序只需要遵從一定的開(kāi)發(fā)和配置約束，最后服務(wù)的運(yùn)行、發(fā)布等都由PAAS平臺(tái)統(tǒng)一接管，進(jìn)一步釋放對(duì)運(yùn)維的依賴，且此時(shí)根本就沒(méi)有IAAS層維護(hù)成本;結(jié)論：不需要那么多應(yīng)用運(yùn)維人員了。

最后到SAAS部分，這塊目前在國(guó)外非常活躍，國(guó)外從運(yùn)維領(lǐng)域的監(jiān)控、自動(dòng)化部署、數(shù)據(jù)分析、資源管理等領(lǐng)域都有多家公司在提供服務(wù)。之前依賴運(yùn)維從無(wú)到有的構(gòu)建，現(xiàn)在也不需要了。在傳統(tǒng)的模式下，運(yùn)維都是自己搭建監(jiān)控平臺(tái)，自己構(gòu)建部署系統(tǒng)。當(dāng)前情況下，對(duì)于小的企業(yè)來(lái)說(shuō)，可以直接使用云平臺(tái)自帶的服務(wù)，足夠應(yīng)付。對(duì)于更大規(guī)模的企業(yè)環(huán)境來(lái)說(shuō)，你可以選擇其他云服務(wù)，只要你許可他們的agent安裝在你的服務(wù)器上，采集數(shù)據(jù)/部署都可以完成。再回過(guò)頭看看IAAS云中提供的RDS服務(wù)(類似SAAS服務(wù))，里面把一切對(duì)Mysql的管理都封裝成webUI;對(duì)于系統(tǒng)中慢查詢，在給出報(bào)告的同時(shí)，還能給出相應(yīng)的優(yōu)化建議，備份、遷移管理都一應(yīng)俱全。不過(guò)幸運(yùn)的是，國(guó)內(nèi)目前這塊的產(chǎn)品還不多。結(jié)論：不需要那么多應(yīng)用運(yùn)維人員和DBA了。

隨著在云計(jì)算不同層次的云服務(wù)水平的不斷提升，對(duì)傳統(tǒng)的運(yùn)維模式(流程性、功能性、技能型)逐漸形成顛覆力。可能還是會(huì)有很多人有疑問(wèn)?從公有云獲取到服務(wù)器資源之后，總還需要做一些一些人去做系統(tǒng)管理的工作吧?不需要，你是否想過(guò)未來(lái)假設(shè)有人基于puppet或者salt封裝一個(gè)appstore的模式供用戶使用，里面所有的SA管理方案都可以通過(guò)下載的方式應(yīng)用到自己的OS環(huán)境;PAAS現(xiàn)在很難應(yīng)用起來(lái)，部署工作總還需要運(yùn)維吧?我認(rèn)為即使PAAS應(yīng)用不起來(lái)，通過(guò)其他的持續(xù)部署方案和更上的自動(dòng)化編排方案都可以解決自動(dòng)化的問(wèn)題，因?yàn)楸举|(zhì)上就是發(fā)布文件和執(zhí)行命令;應(yīng)用需要經(jīng)常變更、擴(kuò)容、故障定位總需要運(yùn)維吧?我也不這么看，你所會(huì)的技能很多都隱藏在數(shù)據(jù)之中，通過(guò)容量數(shù)據(jù)可以驅(qū)動(dòng)應(yīng)用變更和擴(kuò)容，并且容器docker的出現(xiàn)可以讓這個(gè)工作變得更簡(jiǎn)單，關(guān)于故障定位，很多時(shí)候都是依賴一些故障定位技巧，而這些技巧都是可以通過(guò)數(shù)據(jù)來(lái)做root cause分析的，只需要把資深的一些運(yùn)維人經(jīng)驗(yàn)提煉成產(chǎn)品。

因此我更愿意相信在不久的將來(lái)會(huì)有一個(gè)完整的運(yùn)維產(chǎn)品存在(類似ERP)，該運(yùn)維產(chǎn)品能夠解決自動(dòng)化運(yùn)維的問(wèn)題，能夠把一切技術(shù)數(shù)據(jù)收集起來(lái)，按照運(yùn)維人的經(jīng)驗(yàn)來(lái)提煉數(shù)據(jù)的價(jià)值，應(yīng)用到各個(gè)運(yùn)維場(chǎng)景中去，比如說(shuō)容量、故障定位、擴(kuò)容、變更等等。

2、DevOps對(duì)運(yùn)維的影響

在前面給了一些關(guān)于DevOps的數(shù)據(jù)，首先可以看出DevOps的理念已經(jīng)開(kāi)始逐漸被更多的企業(yè)所接受，其次DevOps關(guān)注的焦點(diǎn)也和過(guò)去的流程ITIL有著本質(zhì)的區(qū)別，他就是需要通過(guò)自動(dòng)化不斷的降低浪費(fèi)、驅(qū)動(dòng)敏捷、打破團(tuán)隊(duì)邊界等等。在前不久，我參加了今年puppetlabs的一個(gè)在線調(diào)查，里面可以看到國(guó)外已經(jīng)有專門的DevOps部門存在，且有專門的DevOps工程師。我是如何看DevOps?就是把后端的Ops服務(wù)不斷的推到前面Dev，讓前面的Dev具備Ops能力，這就是DevOps。當(dāng)然背后是靠平臺(tái)和工具支持的，流程肯定是不行，這是傳統(tǒng)運(yùn)維急需要改變的地方。把這種對(duì)人的依賴和運(yùn)維的經(jīng)驗(yàn)都轉(zhuǎn)換到平臺(tái)中。在早期，所有的發(fā)布變更都依賴運(yùn)維來(lái)完成，后來(lái)我們搭建發(fā)布平臺(tái)，可以讓測(cè)試來(lái)做發(fā)布，再往后發(fā)布平臺(tái)和自動(dòng)化測(cè)試平臺(tái)進(jìn)一步對(duì)接，這個(gè)發(fā)布工作再進(jìn)一步交付給研發(fā)，運(yùn)維從過(guò)去的執(zhí)行者變成了審核者，自動(dòng)化驅(qū)動(dòng)一切，質(zhì)量、敏捷驅(qū)動(dòng)一切。

再去到數(shù)據(jù)化運(yùn)維部分。由于研發(fā)、運(yùn)維都是技術(shù)人員，所以大家很容易對(duì)技術(shù)數(shù)據(jù)達(dá)成一致的認(rèn)識(shí)，甚至有時(shí)是研發(fā)會(huì)更敏感，因?yàn)樗私庾约旱姆?wù)該如何衡量。過(guò)去我們都有錯(cuò)誤的認(rèn)知，把數(shù)據(jù)當(dāng)著運(yùn)維團(tuán)隊(duì)的核心資產(chǎn)且保密，只有運(yùn)維團(tuán)隊(duì)使用，而其他的團(tuán)隊(duì)只能關(guān)注到一些運(yùn)維給到的結(jié)果，其實(shí)這是違背DevOps原則的。而我的建議是，運(yùn)維提供采集一切數(shù)據(jù)的能力，把上層的分析和展現(xiàn)能力開(kāi)放給所有技術(shù)人員，運(yùn)維人員只是數(shù)據(jù)使用的一個(gè)角色，可以按照自己的價(jià)值維度和場(chǎng)景抽象幾個(gè)數(shù)據(jù)產(chǎn)品出來(lái)，比如說(shuō)監(jiān)控、容量、質(zhì)量、可用性等等。研發(fā)人員也是數(shù)據(jù)使用的一個(gè)角色，它可以按照自己對(duì)服務(wù)的理解，去任意的加工數(shù)據(jù)，這個(gè)有點(diǎn)回歸到以前BI的那套思路了。

因此運(yùn)維最終要變成經(jīng)驗(yàn)平臺(tái)的建設(shè)者，而非簡(jiǎn)單的事務(wù)執(zhí)行者。

3、開(kāi)源技術(shù)對(duì)運(yùn)維的影響

現(xiàn)在還有什么開(kāi)源解決不了的呢?

而我想說(shuō)，在運(yùn)維的每個(gè)部分都有相應(yīng)的開(kāi)源解決方案存在，難道我們還說(shuō)對(duì)運(yùn)維的依賴很重么?在任何一個(gè)運(yùn)維開(kāi)源技術(shù)面前，運(yùn)維能表現(xiàn)出比研發(fā)更強(qiáng)的把握能力么?說(shuō)實(shí)話，開(kāi)源技術(shù)把之前運(yùn)維的技能墻打破了，都可以獲取技術(shù)的能力。不過(guò)這個(gè)地方有運(yùn)維的一個(gè)存在價(jià)值，也就是國(guó)外DevOps部門的存在價(jià)值，我的思考是DevOps部門提供的是運(yùn)維平臺(tái)統(tǒng)一規(guī)劃和建設(shè)能力，否則對(duì)于一個(gè)企業(yè)來(lái)說(shuō)，技術(shù)和目標(biāo)的協(xié)調(diào)無(wú)法完成。開(kāi)源技術(shù)降低了獲取門檻，但也提高了被濫用的可能，而運(yùn)維部門可以避免這種濫用。

一方面我們要注意到當(dāng)下的云端技術(shù)變化趨勢(shì)以及對(duì)運(yùn)維的影響，另一方面要清楚的知道單純的流程性/功能性/技能型運(yùn)維，已不是時(shí)下需要，危機(jī)正在悄悄走進(jìn)你。當(dāng)前運(yùn)維的存在空間，還有部分是因?yàn)殚_(kāi)發(fā)不懂什么是運(yùn)維，他們連配置管理都不知道。當(dāng)有一天運(yùn)維也像開(kāi)發(fā)、測(cè)試一樣變成云端服務(wù)，運(yùn)維就不需要依賴某個(gè)運(yùn)維人和某個(gè)運(yùn)維團(tuán)隊(duì)了。因此請(qǐng)盡快擁抱自動(dòng)化運(yùn)維、數(shù)據(jù)化運(yùn)維，并往運(yùn)維產(chǎn)品化、規(guī)劃方向提升，一起做好運(yùn)維轉(zhuǎn)型準(zhǔn)備吧。