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

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

正如??《云原生改造到底有多難 | T前線》??一文中，作業(yè)幫基礎(chǔ)架構(gòu)負(fù)責(zé)人董曉聰所說，“云原生的轉(zhuǎn)型改造，會對運(yùn)維的方式產(chǎn)生一定的影響，對于運(yùn)維崗位而言，中等規(guī)模的公司的是很難一下接受的。人肉的工作少了，基礎(chǔ)架構(gòu)的能力更得到重視，不再局限于一些重復(fù)的、機(jī)械式的工作?！?/p>

傳統(tǒng)的運(yùn)維，更多的是指網(wǎng)絡(luò)運(yùn)維、數(shù)據(jù)庫運(yùn)維等。而現(xiàn)在我們在招聘軟件上再搜索“運(yùn)維”，呈現(xiàn)給求職者的，更多是“云原生運(yùn)維”、“ DevOps 工程師”、“SRE工程師”、“云原生架構(gòu)師”、“ Kubernetes 運(yùn)維”等字眼。 當(dāng)傳統(tǒng)時代讓渡給“云”，與之相關(guān)的運(yùn)維工作的內(nèi)容和職責(zé)都產(chǎn)生很大的不同，短短幾年間，傳統(tǒng) Linux 操作系統(tǒng)的運(yùn)維方式的聚光燈移開，取而代之的是云原生時代的 Kubernetes 的運(yùn)維。

云上的 DevOps 工作內(nèi)容因各家企業(yè)的實際業(yè)務(wù)不同而不同，但 Kubernetes 運(yùn)維作為事實上的云運(yùn)維標(biāo)準(zhǔn)，這里作為一個典型來進(jìn)行介紹：

熟悉 DevOps、CI/CD，負(fù)責(zé)應(yīng)用產(chǎn)品的持續(xù)交付和持續(xù)運(yùn)維的工具體系的建設(shè)，支撐業(yè)務(wù)的快速迭代與穩(wěn)定性工具建設(shè)； 完善 Kubernetes 集群的監(jiān)控體系、日志分析和全方位數(shù)據(jù)運(yùn)營（包括可用性指標(biāo)、歷史事故、資源利用率等），提高監(jiān)控有效性及時發(fā)現(xiàn)故障，保障業(yè)務(wù)可用； 優(yōu)化 Kubernetes 集群運(yùn)維體系，對底層基礎(chǔ)組件的部署持續(xù)調(diào)優(yōu)，提升各線的運(yùn)維能力和問題處理效率； 負(fù)責(zé) Kubernetes 集群運(yùn)維平臺的建設(shè)，打造自動化運(yùn)維和管控體系；負(fù)責(zé)Kubernetes集群管理、部署發(fā)布、可觀測體系等系統(tǒng)的設(shè)計和實現(xiàn)。

云上的 DevOps 遠(yuǎn)遠(yuǎn)不限于這些。

云上的DevOps是如何崩潰的

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

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

傳統(tǒng)IT運(yùn)維的弊端

最近幾年，疫情對企業(yè)的數(shù)字化轉(zhuǎn)型具有明顯推動作用。不同行業(yè)都反映出一個事實：越早進(jìn)行數(shù)字化轉(zhuǎn)型越有利于在業(yè)務(wù)中領(lǐng)先。而在此這種背景下，傳統(tǒng)的IT運(yùn)維就顯得力不從心了。

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

云端的DevOps人現(xiàn)狀

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

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

云計算時代對運(yùn)維提出了新的要求，云運(yùn)維將在本地工作轉(zhuǎn)移到云服務(wù)器端，從基礎(chǔ)架構(gòu)到上層業(yè)務(wù)，管理對象增多，包括了存儲、虛擬機(jī)、網(wǎng)絡(luò)安全、防火墻、備份、緩存、負(fù)載均衡、數(shù)據(jù)庫等等......

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

具體到職位，云運(yùn)維工程師 15k 起步，專家和架構(gòu)師的薪資則在 25k 到 40k 不等。 不管是傳統(tǒng)的運(yùn)維還是云運(yùn)維，工程師們的“隨時待命”狀態(tài)還是一樣的?！俺胰嗽诩页阅暌癸垺９こ處熞贿吙创和?，一邊守在電腦旁看監(jiān)控系統(tǒng)”成為了新的運(yùn)維工作常態(tài)。而疫情的影響，人可以下班回家，但往往也需要“遠(yuǎn)程值班”。 如果你正在云廠商任職，上云全過程進(jìn)行管理和技術(shù)支持工作、定期與重大客戶深入交流也成為了一項十分重要的工作。

企業(yè)青睞什么樣的云運(yùn)維人員

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

寫在最后

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

參考鏈接：

??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??