DevOps 與云，似乎有種渾然天成的特質：二者都追求“彈性敏捷”、“軟件即服務”、“軟件定義一切”。一個是引領了“持續集成”、“持續交付”的企業文化的變革理念，一個是高并發高可用場景下，事實上的主流應用開發的基礎設施。二者一旦有了同樣的地秉性，就“手拉手”一起大步向前奔赴未來。

技術的變革，好比馬車與火車的變革。如果能及時遷移到新技術上來，新技術所帶來的成長將不日而語。但顯然并不是所有人一上來就能接受這種變化。

正如??《云原生改造到底有多難 | T前線》??一文中，作業幫基礎架構負責人董曉聰所說，“云原生的轉型改造，會對運維的方式產生一定的影響，對于運維崗位而言，中等規模的公司的是很難一下接受的。人肉的工作少了，基礎架構的能力更得到重視，不再局限于一些重復的、機械式的工作。”

傳統的運維，更多的是指網絡運維、數據庫運維等。而現在我們在招聘軟件上再搜索“運維”，呈現給求職者的，更多是“云原生運維”、“ DevOps 工程師”、“SRE工程師”、“云原生架構師”、“ Kubernetes 運維”等字眼。 當傳統時代讓渡給“云”，與之相關的運維工作的內容和職責都產生很大的不同，短短幾年間，傳統 Linux 操作系統的運維方式的聚光燈移開，取而代之的是云原生時代的 Kubernetes 的運維。

云上的 DevOps 工作內容因各家企業的實際業務不同而不同，但 Kubernetes 運維作為事實上的云運維標準，這里作為一個典型來進行介紹：

熟悉 DevOps、CI/CD，負責應用產品的持續交付和持續運維的工具體系的建設，支撐業務的快速迭代與穩定性工具建設； 完善 Kubernetes 集群的監控體系、日志分析和全方位數據運營（包括可用性指標、歷史事故、資源利用率等），提高監控有效性及時發現故障，保障業務可用； 優化 Kubernetes 集群運維體系，對底層基礎組件的部署持續調優，提升各線的運維能力和問題處理效率； 負責 Kubernetes 集群運維平臺的建設，打造自動化運維和管控體系；負責Kubernetes集群管理、部署發布、可觀測體系等系統的設計和實現。

云上的 DevOps 遠遠不限于這些。

云上的DevOps是如何崩潰的

然而，鮮花與荊棘同在，彈性、可觀測、韌性、可持續等一系列高檔的詞匯都會出現在它的上下文。但回歸到落地層面，猶如一種“云泥”之別。 許多在做數字化轉型的公司，往往急于改造，卻忽略了實際業務情況，強行把“DevOps”塞到云中，結果往往適得其反，崩潰得的一塌糊涂。比如：遠程會議中

首先是顯而易見的問題：人才。 要在云中進行 DevOps，云運維工程師需要對于懂得非常專業的基于云的工具以及并構建工具鏈相關內容非常專業。如果做不到，一切都是泡影。 公司要在傳統運維人員中找到具備這項能力的員工，并不容易。更糟糕的是，有的公司甚至將 DevOps 撤回到傳統平臺，宣告失敗。 其次，大多數 DevOops 工具鏈所需的工具，云很少擁有。雖然現在云上已經擁有不少 DevOps 工具，它們要么由公共云供應商銷售，要么由 DevOops 云服務的主要合作伙伴銷售，但研發人員往往會發現一個問題：你所需要的大約 10% 到 20% 的工具，并不存在于你的公共云平臺上。這時你就將不得不合并另一個提供商的平臺，這會導致多云的復雜性。當然，對那些缺少的工具的需求取決于當時正在構建的應用程序的類型。  當然，DevOops 工具提供商看到了云計算的成功，并迅速填補了這項“工具短缺”的空白。但是，通常不可能在首選提供商上找到本地運行所需的一切。Devops 工程師通常會選擇混搭的方法，采取“云優先”策略： 如果可以找到，他們會選擇在云上本地運行的工具，但在其他云提供商或那些可怕的本地系統上則配有后備選項。  再加上代碼和數據，在云和其他遠程系統之間來回傳輸，這種由工具鏈帶來的復雜性，將會放大到相當棘手的難度。 這時，次生的問題產生了：如果你沒有了解云安全部署的員工，安全性和可靠性又成了一個挑戰。 總之，自制應用程序和基礎設施與基于云的 SaaS 之間的差距，比想象中的要大。在沒有找到合適的人才之前，決策者不能頭腦一熱，就把 DevOps 搬到云上。

傳統IT運維的弊端

最近幾年，疫情對企業的數字化轉型具有明顯推動作用。不同行業都反映出一個事實：越早進行數字化轉型越有利于在業務中領先。而在此這種背景下，傳統的IT運維就顯得力不從心了。

首先，隨著企業數字化轉型的發展節奏提速，IT系統數量快速增長，同時云原生架構的應用導致系統復雜度越來越高，傳統運維方式已經無法滿足業務發展的需求。提高運維效率和運維質量，成為IT運維的必然趨勢。 其次，傳統運維依賴于人的經驗，這使得業務的穩定性、安全性難以得到保障，阻礙了數字化轉型的進程。 最后，傳統運維不能從業務服務的視角去看待整體整個的數據變化，很難第一時間判定問題根因。所以必須改善傳統運維的效能，才能滿足數字化轉型的要求。

云端的DevOps人現狀

那么，云中的DevOps人怎么樣呢？

他們就是或者說，在大小長假和“購物節”期間，保障全民線上狂歡的幕后工作者——云運維工程師及各重保團隊的工程師，。是怎樣的狀態呢？

云計算時代對運維提出了新的要求，云運維將在本地工作轉移到云服務器端，從基礎架構到上層業務，管理對象增多，包括了存儲、虛擬機、網絡安全、防火墻、備份、緩存、負載均衡、數據庫等等......

與此同時，架構云化和智能化提高了運維的門檻，要求運維還需具備縱向的管理能力，對此進行統一監控，快速定位問題所在。因此，運維需要一個強大的平臺作為支撐，通過自動化部署進行生命周期階段的操作，按需配置與更新云端資源，對現有的維護模式進行延伸，解決云運維維護的困境，保障業務持續發展。

具體到職位，云運維工程師 15k 起步，專家和架構師的薪資則在 25k 到 40k 不等。 不管是傳統的運維還是云運維，工程師們的“隨時待命”狀態還是一樣的。“除夕家人在家吃年夜飯。工程師一邊看春晚，一邊守在電腦旁看監控系統”成為了新的運維工作常態。而疫情的影響，人可以下班回家，但往往也需要“遠程值班”。 如果你正在云廠商任職，上云全過程進行管理和技術支持工作、定期與重大客戶深入交流也成為了一項十分重要的工作。

企業青睞什么樣的云運維人員

首先，需要熟悉 IaaS、PaaS、SaaS各層的架構及典型應用。 其次，基礎功扎實的人員。熟悉安全、Linux系統、數據庫、云服務、大數據等，熟悉基礎組件（Nignx、Kubernetes、Redis、消息隊列、MySql等） 再者，拔尖的高分項。經歷過大中型企業業務場景，良好的協作和推動能力，比如針對客戶現有IT架構進行梳理與分析，推動售前架構師所提供的設計方案的落地、設施和交付工作等。 再比如，對AWS、騰訊云、阿里云等不同品牌的云服務區別，形成了不錯的認知。 最后，實戰經驗。如果你具備豐富的企業級應用架構設計或云服務集成實施經驗，那在談薪階段，主動權往往掌握在你手中。

寫在最后

去年，阿里云發布了“云上自動化運維白皮書”，其中寫到： 65%的企業已經在公共云中 使用DevOps，卻只有 20% 的企業認為自己充分用到了 DevOps 的全部能力。 云和DevOps的結合，發揮雙重價值的同時，也帶來了很多諸如“統一簡單的可觀測”、“分布式應用的復雜性非常高”、“鏈路復雜度高”、“缺乏自助服務”等挑戰。 新需求是點亮技術演進樹的觸發點，開發者從來不擔心會有新更趁手的工具的產生，他們更多需要的是——在轉型決策之前，從容不迫地理解各種“云事物”，不止工具，還有文化與理念的變化。

參考鏈接：

??https://www.zdnet.com/article/cloudify-devops-6-4-arrives-heres-whats-new?? ??https://www.infoworld.com/article/3674690/how-devops-in-the-cloud-breaks-down.html?? ??https://www.zhihu.com/question/430000480/answer/2627883101?? ??https://zhuanlan.zhihu.com/p/469897872?? ??https://zhuanlan.zhihu.com/p/339177612??