【摘要】

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

正文如下。

運維危機是運維人的危機，你感覺到了么?

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

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

一、云的使用情況

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

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

2、個人也對對國內(nèi)的公有云使用情況做了一次調(diào)研，用戶的使用水平也是相當(dāng)?shù)母?游戲領(lǐng)域)，達到76.19%。因為樣本量不大，應(yīng)該會更高。

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

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

#p#

二、危機在哪兒?

1、云計算平臺對運維的影響

我們都知道云計算平臺有IAAS平臺、PAAS平臺、SAAS平臺之分，不同的部分對運維的角色都有著不同程度的影響。

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

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

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

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

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

2、DevOps對運維的影響

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

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

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

3、開源技術(shù)對運維的影響

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

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

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