儘管雲計算的崛起對於運維行業會帶來很多變化。但是，我們在這其中要看到運維行業的自身發展規律以及其中的不變。
一、背景
作為一項全新的IT革命性技術，雲計算似乎比以往很多新技術的發展速度都要快。在不到十年的時間裡面完成了從誕生、早期實踐、到最終被普遍接受的整個技術發展週期。如今，無論是雲計算中的基礎設施雲（IaaS），平臺雲（PaaS）或者應用雲（SaaS）都已經廣泛進入企業生產環境。
按照IDC最新的報告顯示，未來5年中，在全球IT行業整體年均增長速度不到2%的大環境下，雲計算行業的年均增長速率將超過15%。由此可見，整個雲計算行業的發展速度非常迅猛。在國內，阿里雲作為最早（2008年）跟進這一潮流的巨頭，過去6年裡面取得了非常大的成就，成為國內IaaS領域的絕對領先者。
雲計算的一個重要特徵就是“開箱即用”，由雲供應商提供集中化的運維管理並以服務方式交付給最終用戶。這讓雲用戶可以從很多繁瑣的日常運維工作中解放出來，真正關注自身的業務發展，從而提升整個行業的運營效率。但是正因為如此，這一年來在IT運維圈裡面出現雲計算會革命運維的說法，並引發了運維人員危機的大規模討論。
對於運維人員自身的強烈危機感應該點贊，但在討論運維危機之前，我們不妨先分析一下雲技術給運維行業帶來了什麼樣的改變，而哪些又是仍然保持不變。所以，個人在這裡就雲上運維的變與不變談談一些自己的觀點。
二、雲上運維的不變
如果回顧歷史，除去早期大型企業內部的少部分IT運維人員，中國運維行業的興起應該是隨著互聯網行業上個世紀90年代在中國的發展而來。所以，中國的運維行業以互聯網運維為主。由於互聯網和移動互聯網的快速發展，運維從業人員積累了大量的對於運維行業和運維職業的理解。儘管雲計算的崛起對於運維行業會帶來很多變化。但是，我們在這其中要看到運維行業的自身發展規律以及其中的不變。個人認為這種規律性的不變量至少體現在下面幾點：
1、運維的目標一直未變。
即通過高效運營IT系統來提供高質量的IT服務，並最終幫助實現業務價值。這個目標裡面包括的三要素，即運營的對象仍然是IT系統，運營的目標是提供高質量IT服務，而運營最終的價值是通過業務價值來體現。對照雲上運維場景，可以看出如上三個要素仍然未有任何變化。
2、運維的主流方法論仍然未變。
即通過自動化提升效率，通過數據化實現精細運維。自動化一切的運維方法論無論是在雲下，還是在雲上都是一直有效，而且都是保證高效運維的核心原則。數據化運維是進行精細運維的前提條件。只有通過數據才能回答IT系統的運營是否高效，提供給用戶的IT服務是否高質量，最終的業務價值是否體現出來。
3、運維的主要場景並未變化。
即運維人員面對的日常運維場景仍然是上/下線服務，擴/縮容，批量操作，升級/回滾服務等。而運維人員進行日常運維的主要手段也仍然是監控告警，環境管理和代碼部署等。
4、運維的發展要求也未有變化。
整個運維行業的發展都一直在追求更好的IT系統敏捷性和更優的成本結構。誕生於雲計算普及之前的DevOps運動就是這個發展要求的重要體現，而且在雲上這種新的軟件生產方式不但沒有被改變，反而更容易得到落實。同時，雲平臺提供的彈性伸縮、按需付費模式恰恰更好得滿足了現代互聯網業務對於IT系統敏捷性和彈性成本的要求。
通過上面的分析，可以看出運維的很多根本性要求並未因為雲而發生改變，而這些要求恰恰是運維行業之所以需要存在的根本原因。既然這樣，雲給運維行業到底帶來了哪些變化呢？
三、雲上運維的變化
由於公有云（尤其是公有云IaaS）的普及，整個雲上運維和傳統IDC中的運維還是呈現出比較明顯的不同點，我們可以從下面幾個角度來理解這種不同點。
1、應用運維成為雲上用戶的運維重心
一般來說，很多企業的運維部門主要工作包括基礎運維（針對企業IT基礎設施的運維）、應用運維（針對企業具體業務的運維），較大的運維部門可能還有單獨的運維開發，負責為公司運維部門開發運維工具和平臺。
當用戶決定上雲（尤其是IaaS公有云），就表示用戶已經把基礎運維以及相關的工具平臺開發工作交付給雲供應商，而把應用運維作為整個運維部門的核心。當然，這也符合雲計算希望讓用戶只關注自身業務發展的初衷。如果從宏觀上看，這種變遷可以用下圖描述：
變遷圖
由上圖可以看出，雲上用戶第一個需要做的改變是把整個運維重心轉移到應用運維上。當然，在企業上雲過程中不可能一次性完成如上的切換，必然會有一個很長的時間段內有傳統IT和雲上IT共同存在，共同運維的要求。而且為避免被一家雲供應商鎖定，企業非常有可能同時採購多家雲供應商的服務。
所有這一切都需要企業運維部門擁有統一管理不同來源，不同模式的基礎設施能力。而且由於不同來源基礎設施的自身運維管理能力不同（如公有云IaaS提供的基礎設施就比傳統IDC的基礎設施有更好的自我運維管理能力），這就要求企業運維部門的運維平臺能夠補齊相應短板，磨平不同來源基礎設施的不同。以便能夠統一標準化、自動化日常的運維管理操作。
當然，在這個過程中，企業運維部門仍然要優先關注應用運維工作，並把基礎運維工作儘可能的交給IaaS供應商或者第三方工具。
2、公共組件普遍服務化
在企業內部，不同業務IT系統都會用到很多公共組件（如數據庫，消息隊列等）。由於團隊的技術背景不同，業務要求不同，經常會出現這些公共組件選型的不一致性，導致上線後的運維負擔非常重。所以，企業內部運維部門的一個重要工作就是把這些公共組件標準化並最終服務化，能夠對具體業務部門完全透明。這樣即可以降低運維部門自身的運維成本，又可以提高業務部門的開發效率。
但在雲技術平臺出現之前，很多企業的IT運維部門要想完成公共組件服務化的工作並不容易，所以這個想法很多時候只能在有雄厚資源和有很強運維研發能力的公司才能落地。而云計算平臺（尤其是公有云IaaS平臺）的出現讓公共組件服務化的能力惠及所有云用戶。
例如阿里雲提供了數據庫服務RDS，消息隊列服務MQS，事件通知服務ONS等等。這些服務背後的技術都是經歷阿里電商系統大規模驗證，並且由專門團隊運維。用戶完全可以信任。有了這些服務化的公共組件，企業運維部門在內部推進業務部門使用標準化公共組件會容易很多。
所以，在雲上的IT系統選型時，企業運維部門最好能更早和業務部門合作，力爭使用雲上標準化服務組件，而不是把傳統IT系統系統簡單搬遷到雲主機。如果在企業上雲過程中能把握好這一點，其實就能夠把上雲過程和公共組件標準化和服務化的進程很好統一起來，既能降低運維成本，還能夠保證服務質量，加速軟件開發工作。
3、彈性和自助式成為基礎設施的基本要求
在雲計算平臺中，無論是存儲服務，計算服務還是網絡服務都會提供彈性伸縮，按需付費的功能。絕大多數情況下，你可以認為雲供應商提供的資源是足夠的，把容量管理這個工作交給雲供應商。作為雲上用戶，只需要用時申請，結束時釋放即可。對於企業運維團隊來說，這一點非常重要。在傳統基礎設施中，獲取基礎設施的彈性非常不容易。
為此，很多公司運維團隊都會在基礎設施使用上面制定很多規章制度和流程，以方便進行容量管理和規劃。當管理雲上基礎設施時一定要注意避免這種人為削弱基礎設施彈性的流程。相反，運維團隊需要把雲計算供應商提供的彈性能力充分暴露給業務研發團隊，並鼓勵業務研發團隊為彈性基礎設施做設計（如支持狀態無關和水平擴展），甚至參與到業務架構中的設計，充分使用如阿里雲彈性伸縮服務（ESS）等一系列彈性服務。
這樣一方面可以大幅度降低運維成本（如業務擴容、縮容都能夠自動完成），另外也可以滿足基礎設施成本的彈性需求，降低整個業務的運營成本，提升在市場中的競爭力。
除了彈性，自助式服務成為雲上運維非常基本的一個要求。傳統IT環境中，部分大型企業可以提供自助式IT基礎設施服務，但是對於大部分普通用戶來說，這種服務的成本太高（無法預先提供足夠的資源池），但是雲的出現讓這種方式得以普及，任何用戶都可以在分鐘級別自助獲取一個完整系統架構需要的基礎設施。自助式基礎設施服務在整個IT系統的生產流程中非常重要，因為IT系統的開發、測試、預發和生產都涉及到基礎設施。如果能夠讓這個獲取過程完全自助式，一方面可以大幅度提高整個流程的迭代速度，另外一方面也可以減少運維人員在這些方面的時間開銷。
現在，任何一家企業運維部門在採納雲計算平臺的時候最好都先梳理一下自助式平臺的需求，在上雲的同時把這種自助式基礎設施推廣到軟件研發的每一個環節。或許你會擔心自助式平臺帶來的IT基礎設施濫用問題，這個可以通過成本核算來加以控制。
運維部門也可以在雲平臺上層構建自己的基礎設施自助平臺並嵌入相應成本管控規則。注意，如果需要限制使用，更多的是限制整體成本而不是限制每一項資源的具體使用。只有這樣，才能讓研發團隊充分享受雲帶來的彈性和敏捷。
4、可編程基礎設施融入運維管理體系
無論是傳統的ITIL體系還是ITOM領域，運維管理體系的基礎都是CMDB（配置管理數據庫）。CMDB中保存著整個IT系統的基礎設施元數據，並以此為基礎支持監控場景、部署場景，日常批量運維場景等等。
對於傳統IDC中的基礎設施，由於變化並不頻繁，CMDB的維護更多是通過人工來完成的。但是，在雲平臺上，所有的基礎設施服務都會提供API接口，從而變成了可編程的基礎設施。這就為CMDB中的基礎設施管理完全自動化提供了前提條件。而云上服務對於彈性的強要求又導致基礎設施的變化比傳統IDC中頻繁得多，這就要求運維管理系統自動感知基礎設施變化。
所以，可編程的雲基礎設施必須要融入你的日常運維管理體系中並使用完全自動化的方式進行管理。用戶甚至可以通過感知基礎設施變化的能力進一步集成自動化部署邏輯。例如，一臺雲主機啟動起來後，運維管理體系能夠感知到它的加入，能夠按照預先指定的自動化部署腳本對它進行IT系統部署。在部署完成後主動加入系統的負載均衡器，開始服務用戶。因為基礎設施的可編程，上面整個部署流程完全可以和基礎設施實施一體化自動管理。
當然，如果要把可變成基礎設施融入到運維管理體系中，則需要運維研發部門給自己運維平臺對接各種雲供應商的API，並需要相關的集成開發工作。如果企業不願意投入資源完成這種對接，也可以選擇第三方工具達到同樣的目標。
四、總結
在雲上，運維所追求的目標未變，主要的思路也未變。但是因為雲計算帶來的基礎設施層面變化對於運維的影響也是明確的。在這個過程中，運維需要主動出擊，積極適應雲帶來的各種優勢，並積極向上擴展（例如，更多加入cloud native應用的架構設計中，提供自助式IT服務等等），擴大自己的影響力。
為適應這個轉變，企業運維部門可以考慮重新構建自己的日常運維平臺，也可以通過第三方的工具（如FIT2CLOUD提供的一站式運維管理和持續交付平臺）更快實現運維體系和雲的對接。
來源：互聯網整合，著作權屬作者所有。SAP斯凱普斯本著傳播知識的態度進行整合轉載，如有版權或著作權方提出異議，聯繫立即刪除。
閱讀更多 SAP斯凱普斯 的文章
