【摘要】

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

正文如下。

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

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

首先帶大家看一組數據，國外著名企業級公有云管理市場領導者rightscale每年都會發布一份云計算市場報告，rightscale應該是云管理里面的鼻祖，2013年他們平臺管理的服務器達到580萬臺，因此他的數據報告還是有一定的權威性，從這個報告中可以讓我們看到一些趨勢。

一、云的使用情況

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

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

2、個人也對對國內的公有云使用情況做了一次調研，用戶的使用水平也是相當的高(游戲領域)，達到76.19%。因為樣本量不大，應該會更高。

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

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

#p#

二、危機在哪兒?

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

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

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

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

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

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

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

2、DevOps對運維的影響

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

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

因此運維最終要變成經驗平臺的建設者，而非簡單的事務執行者。

3、開源技術對運維的影響

現在還有什么開源解決不了的呢?

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

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