DevOps 與云，似乎有種渾然天成的特質(zhì)：二者都追求“彈性敏捷”、“軟件即服務(wù)”、“軟件定義一切”。一個是引領(lǐng)了“持續(xù)集成”、“持續(xù)交付”的企業(yè)文化的變革理念，一個是高并發(fā)高可用場景下，事實上的主流應(yīng)用開發(fā)的基礎(chǔ)設(shè)施。二者一旦有了同樣的地秉性，就“手拉手”一起大步向前奔赴未來。
技術(shù)的變革，好比馬車與火車的變革。如果能及時遷移到新技術(shù)上來，新技術(shù)所帶來的成長將不日而語。但顯然并不是所有人一上來就能接受這種變化。
正如??《云原生改造到底有多難 | T前線》??一文中，作業(yè)幫基礎(chǔ)架構(gòu)負責人董曉聰所說，“云原生的轉(zhuǎn)型改造，會對運維的方式產(chǎn)生一定的影響，對于運維崗位而言，中等規(guī)模的公司的是很難一下接受的。人肉的工作少了，基礎(chǔ)架構(gòu)的能力更得到重視，不再局限于一些重復的、機械式的工作。”
傳統(tǒng)的運維，更多的是指網(wǎng)絡(luò)運維、數(shù)據(jù)庫運維等。而現(xiàn)在我們在招聘軟件上再搜索“運維”，呈現(xiàn)給求職者的，更多是“云原生運維”、“ DevOps 工程師”、“SRE工程師”、“云原生架構(gòu)師”、“ Kubernetes 運維”等字眼。 當傳統(tǒng)時代讓渡給“云”，與之相關(guān)的運維工作的內(nèi)容和職責都產(chǎn)生很大的不同，短短幾年間，傳統(tǒng) Linux 操作系統(tǒng)的運維方式的聚光燈移開，取而代之的是云原生時代的 Kubernetes 的運維。
云上的 DevOps 工作內(nèi)容因各家企業(yè)的實際業(yè)務(wù)不同而不同，但 Kubernetes 運維作為事實上的云運維標準，這里作為一個典型來進行介紹：
熟悉 DevOps、CI/CD，負責應(yīng)用產(chǎn)品的持續(xù)交付和持續(xù)運維的工具體系的建設(shè)，支撐業(yè)務(wù)的快速迭代與穩(wěn)定性工具建設(shè)； 完善 Kubernetes 集群的監(jiān)控體系、日志分析和全方位數(shù)據(jù)運營（包括可用性指標、歷史事故、資源利用率等），提高監(jiān)控有效性及時發(fā)現(xiàn)故障，保障業(yè)務(wù)可用； 優(yōu)化 Kubernetes 集群運維體系，對底層基礎(chǔ)組件的部署持續(xù)調(diào)優(yōu)，提升各線的運維能力和問題處理效率； 負責 Kubernetes 集群運維平臺的建設(shè)，打造自動化運維和管控體系；負責Kubernetes集群管理、部署發(fā)布、可觀測體系等系統(tǒng)的設(shè)計和實現(xiàn)。
云上的 DevOps 遠遠不限于這些。
云上的DevOps是如何崩潰的
然而，鮮花與荊棘同在，彈性、可觀測、韌性、可持續(xù)等一系列高檔的詞匯都會出現(xiàn)在它的上下文。但回歸到落地層面，猶如一種“云泥”之別。 許多在做數(shù)字化轉(zhuǎn)型的公司，往往急于改造，卻忽略了實際業(yè)務(wù)情況，強行把“DevOps”塞到云中，結(jié)果往往適得其反，崩潰得的一塌糊涂。比如：遠程會議中
首先是顯而易見的問題：人才。 要在云中進行 DevOps，云運維工程師需要對于懂得非常專業(yè)的基于云的工具以及并構(gòu)建工具鏈相關(guān)內(nèi)容非常專業(yè)。如果做不到，一切都是泡影。 公司要在傳統(tǒng)運維人員中找到具備這項能力的員工，并不容易。更糟糕的是，有的公司甚至將 DevOps 撤回到傳統(tǒng)平臺，宣告失敗。 其次，大多數(shù) DevOops 工具鏈所需的工具，云很少擁有。雖然現(xiàn)在云上已經(jīng)擁有不少 DevOps 工具，它們要么由公共云供應(yīng)商銷售，要么由 DevOops 云服務(wù)的主要合作伙伴銷售，但研發(fā)人員往往會發(fā)現(xiàn)一個問題：你所需要的大約 10% 到 20% 的工具，并不存在于你的公共云平臺上。這時你就將不得不合并另一個提供商的平臺，這會導致多云的復雜性。當然，對那些缺少的工具的需求取決于當時正在構(gòu)建的應(yīng)用程序的類型。 當然，DevOops 工具提供商看到了云計算的成功，并迅速填補了這項“工具短缺”的空白。但是，通常不可能在首選提供商上找到本地運行所需的一切。Devops 工程師通常會選擇混搭的方法，采取“云優(yōu)先”策略： 如果可以找到，他們會選擇在云上本地運行的工具，但在其他云提供商或那些可怕的本地系統(tǒng)上則配有后備選項。 再加上代碼和數(shù)據(jù)，在云和其他遠程系統(tǒng)之間來回傳輸，這種由工具鏈帶來的復雜性，將會放大到相當棘手的難度。 這時，次生的問題產(chǎn)生了：如果你沒有了解云安全部署的員工，安全性和可靠性又成了一個挑戰(zhàn)。 總之，自制應(yīng)用程序和基礎(chǔ)設(shè)施與基于云的 SaaS 之間的差距，比想象中的要大。在沒有找到合適的人才之前，決策者不能頭腦一熱，就把 DevOps 搬到云上。
傳統(tǒng)IT運維的弊端
最近幾年，疫情對企業(yè)的數(shù)字化轉(zhuǎn)型具有明顯推動作用。不同行業(yè)都反映出一個事實：越早進行數(shù)字化轉(zhuǎn)型越有利于在業(yè)務(wù)中領(lǐng)先。而在此這種背景下，傳統(tǒng)的IT運維就顯得力不從心了。
首先，隨著企業(yè)數(shù)字化轉(zhuǎn)型的發(fā)展節(jié)奏提速，IT系統(tǒng)數(shù)量快速增長，同時云原生架構(gòu)的應(yīng)用導致系統(tǒng)復雜度越來越高，傳統(tǒng)運維方式已經(jīng)無法滿足業(yè)務(wù)發(fā)展的需求。提高運維效率和運維質(zhì)量，成為IT運維的必然趨勢。 其次，傳統(tǒng)運維依賴于人的經(jīng)驗，這使得業(yè)務(wù)的穩(wěn)定性、安全性難以得到保障，阻礙了數(shù)字化轉(zhuǎn)型的進程。 最后，傳統(tǒng)運維不能從業(yè)務(wù)服務(wù)的視角去看待整體整個的數(shù)據(jù)變化，很難第一時間判定問題根因。所以必須改善傳統(tǒng)運維的效能，才能滿足數(shù)字化轉(zhuǎn)型的要求。
云端的DevOps人現(xiàn)狀
那么，云中的DevOps人怎么樣呢？
他們就是或者說，在大小長假和“購物節(jié)”期間，保障全民線上狂歡的幕后工作者——云運維工程師及各重保團隊的工程師，。是怎樣的狀態(tài)呢？
云計算時代對運維提出了新的要求，云運維將在本地工作轉(zhuǎn)移到云服務(wù)器端，從基礎(chǔ)架構(gòu)到上層業(yè)務(wù)，管理對象增多，包括了存儲、虛擬機、網(wǎng)絡(luò)安全、防火墻、備份、緩存、負載均衡、數(shù)據(jù)庫等等......
與此同時，架構(gòu)云化和智能化提高了運維的門檻，要求運維還需具備縱向的管理能力，對此進行統(tǒng)一監(jiān)控，快速定位問題所在。因此，運維需要一個強大的平臺作為支撐，通過自動化部署進行生命周期階段的操作，按需配置與更新云端資源，對現(xiàn)有的維護模式進行延伸，解決云運維維護的困境，保障業(yè)務(wù)持續(xù)發(fā)展。
具體到職位，云運維工程師 15k 起步，專家和架構(gòu)師的薪資則在 25k 到 40k 不等。 不管是傳統(tǒng)的運維還是云運維，工程師們的“隨時待命”狀態(tài)還是一樣的。“除夕家人在家吃年夜飯。工程師一邊看春晚，一邊守在電腦旁看監(jiān)控系統(tǒng)”成為了新的運維工作常態(tài)。而疫情的影響，人可以下班回家，但往往也需要“遠程值班”。 如果你正在云廠商任職，上云全過程進行管理和技術(shù)支持工作、定期與重大客戶深入交流也成為了一項十分重要的工作。
企業(yè)青睞什么樣的云運維人員
首先，需要熟悉 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)進行梳理與分析，推動售前架構(gòu)師所提供的設(shè)計方案的落地、設(shè)施和交付工作等。 再比如，對AWS、騰訊云、阿里云等不同品牌的云服務(wù)區(qū)別，形成了不錯的認知。 最后，實戰(zhàn)經(jīng)驗。如果你具備豐富的企業(yè)級應(yīng)用架構(gòu)設(shè)計或云服務(wù)集成實施經(jīng)驗，那在談薪階段，主動權(quán)往往掌握在你手中。
寫在最后
去年，阿里云發(fā)布了“云上自動化運維白皮書”，其中寫到： 65%的企業(yè)已經(jīng)在公共云中 使用DevOps，卻只有 20% 的企業(yè)認為自己充分用到了 DevOps 的全部能力。 云和DevOps的結(jié)合，發(fā)揮雙重價值的同時，也帶來了很多諸如“統(tǒng)一簡單的可觀測”、“分布式應(yīng)用的復雜性非常高”、“鏈路復雜度高”、“缺乏自助服務(wù)”等挑戰(zhàn)。 新需求是點亮技術(shù)演進樹的觸發(fā)點，開發(fā)者從來不擔心會有新更趁手的工具的產(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??
