2020年是云原生技術(shù)快速發(fā)展的一年，隨著容器技術(shù)的普及，過(guò)去幾年Kubernetes已經(jīng)成為云原生基礎(chǔ)設(shè)施的事實(shí)標(biāo)準(zhǔn)，今年在全球不同地區(qū)開展的線上Kubecon大會(huì)依舊火爆，疫情也阻擋不了大家對(duì)技術(shù)的追求，CNCF社區(qū)同樣發(fā)展迅速，2020年有五個(gè)項(xiàng)目從社區(qū)畢業(yè)，這標(biāo)志著云原生技術(shù)棧越來(lái)越成熟，同時(shí)截止目前共有74個(gè)項(xiàng)目加入社區(qū)，2020年是圍繞Kubernetes的云原生生態(tài)體系建設(shè)快速發(fā)展的一年。云原生技術(shù)的長(zhǎng)足發(fā)展給企業(yè)數(shù)字化轉(zhuǎn)型帶來(lái)了便捷，企業(yè)轉(zhuǎn)型的背后是基礎(chǔ)架構(gòu)人員面臨的對(duì)自身的升級(jí)和轉(zhuǎn)型。
1、傳統(tǒng)運(yùn)維的困局
在我的印象中，每個(gè)傳統(tǒng)運(yùn)維人員都是全能的，要熟悉各種各樣的系統(tǒng)，要熟悉基礎(chǔ)網(wǎng)絡(luò)、操作系統(tǒng)、各種中間件、各種工具，并且熟練掌握能高效解決問(wèn)題的腳本編寫能力，24小時(shí)待命，隨時(shí)準(zhǔn)備去解決生產(chǎn)中的各種問(wèn)題，儼然是業(yè)務(wù)系統(tǒng)的救火員。我們有思考過(guò)是什么造成了這種局面？
過(guò)去我們運(yùn)維人員的職責(zé)很多，是基礎(chǔ)設(shè)施的管理者，承擔(dān)了業(yè)務(wù)應(yīng)用從上線到穩(wěn)定運(yùn)行的所有職責(zé)。所以我們面對(duì)了太多的因素，而要將這些因素沉淀下來(lái)又太不容易，過(guò)去要從無(wú)到有的去建立一套運(yùn)維體系是非常困難的，同樣既有的體系傳承也很困難，一個(gè)新人要想完全熟悉一套運(yùn)維體系要學(xué)的東西非常多，更別指望能將運(yùn)維體系延伸到整個(gè)軟件生產(chǎn)周期，將領(lǐng)域知識(shí)方便的傳輸出去，所以才造成了上下游不通，只有一兩個(gè)核心人員熟練掌握運(yùn)維系統(tǒng)。職責(zé)繁重，運(yùn)維平臺(tái)標(biāo)準(zhǔn)化困難，運(yùn)維體系建設(shè)困難，無(wú)法有效打通上下游，這些都是傳統(tǒng)運(yùn)維的困局，也使運(yùn)維人員成了產(chǎn)品質(zhì)量的背鍋者。
那么云原生時(shí)代的基礎(chǔ)設(shè)施會(huì)有什么變化？運(yùn)維有什么特征，能解決什么樣的問(wèn)題？我們運(yùn)維人員應(yīng)該重點(diǎn)關(guān)注什么？
2、云原生時(shí)代的運(yùn)維特征
從2013年docker開源，到2014年發(fā)布正式版本（1.0），容器技術(shù)因?yàn)槠漭p量方式實(shí)現(xiàn)了系統(tǒng)級(jí)別的隔離特性受到追捧，并且發(fā)展迅速。再后來(lái)Google開源了Kubernetes并且和Linux基金會(huì)合作成立了CNCF，隨著開源社區(qū)的不斷發(fā)展，以Kubernetes為核心建立的云原生生態(tài)逐步完善。云原生時(shí)代的基礎(chǔ)設(shè)施是以容器技術(shù)為基礎(chǔ)，以Kubernetes為平臺(tái)的架構(gòu)。那么云原生平臺(tái)上的運(yùn)維有什么特征呢？
基礎(chǔ)設(shè)施即代碼
容器的出現(xiàn)實(shí)現(xiàn)了一次構(gòu)建處處運(yùn)行的設(shè)想，而Kubernetes則定義了一個(gè)基礎(chǔ)設(shè)施平臺(tái)，并且實(shí)現(xiàn)了通過(guò)配置文件定義資源，讓通過(guò)編寫配置文件實(shí)現(xiàn)資源編排成為現(xiàn)實(shí)。Kubernetes構(gòu)建的基礎(chǔ)設(shè)施平臺(tái)將很多運(yùn)維概念封裝到配置文件中，并且提供了便捷的擴(kuò)展方式給用戶定義自己的資源，這樣使Kubernetes的生態(tài)變得豐富起來(lái)，所以現(xiàn)在如果你想要實(shí)現(xiàn)一項(xiàng)運(yùn)維特性，只需要在基礎(chǔ)設(shè)施平臺(tái)上定義一種類型的資源，并且編寫相應(yīng)的控制器即可實(shí)現(xiàn)，這樣不僅規(guī)范了資源定義的格式，而且也方便了資源的真實(shí)用戶。
運(yùn)維特性下沉、聚焦
得益于基礎(chǔ)設(shè)施平臺(tái)上的資源定義規(guī)范化，面向應(yīng)用的資源編排能力可以很方便的獲得，在云原生體系下，我們只需要定義一些配置文件就可以輕松的編排出來(lái)一套復(fù)雜的應(yīng)用系統(tǒng)，目前通過(guò)各種不同的應(yīng)用定義模型，我們不僅可以定義資源交付的依賴關(guān)系還能屏蔽一些運(yùn)維細(xì)節(jié)，將應(yīng)用研發(fā)和運(yùn)維的關(guān)注點(diǎn)分離開，實(shí)現(xiàn)不同角色的職責(zé)劃分。最終應(yīng)用研發(fā)可能只需要關(guān)心應(yīng)用啟動(dòng)的一些啟動(dòng)參數(shù)配置，應(yīng)用實(shí)例數(shù)量等一些最基礎(chǔ)的應(yīng)用配置，而網(wǎng)絡(luò)、存儲(chǔ)、監(jiān)控日志等復(fù)雜的運(yùn)維特性則會(huì)下沉到基礎(chǔ)設(shè)施層，由運(yùn)維人員負(fù)責(zé)管理。
基礎(chǔ)設(shè)施可靠性和運(yùn)維自動(dòng)化
運(yùn)維特性下層到基礎(chǔ)設(shè)施層之后，運(yùn)維人員可以專注于運(yùn)維特性，并且依托于云原生生態(tài)提供運(yùn)維能力。大家都知道云的最顯著的特性就是彈性，而在云原生架構(gòu)下還有一個(gè)非常重要的特性就是魯棒性。Kubernetes通過(guò)聲明式編程實(shí)現(xiàn)了資源定義和資源實(shí)例的一致性，這基本上就保證了業(yè)務(wù)容器在Kubernetes上的很高的自愈能力，再加上各種監(jiān)控告警、日志、事件告警以及配套的自動(dòng)化運(yùn)維平臺(tái)，基本上可以做到高度的運(yùn)維自動(dòng)化。這僅僅是云原生平臺(tái)的自愈能力，而如果基于業(yè)務(wù)應(yīng)用的監(jiān)控?cái)?shù)據(jù)，配合上人工智能的分析能力，我們可以提前預(yù)測(cè)到即將到來(lái)的事件，并且做出相應(yīng)的措施來(lái)應(yīng)對(duì)，則會(huì)大大增加系統(tǒng)的容錯(cuò)特性。這些都是運(yùn)維平臺(tái)化之后逐步發(fā)展出來(lái)的。
3、如何適應(yīng)云原生時(shí)代的運(yùn)維
傳統(tǒng)運(yùn)維的核心職責(zé)是讓業(yè)務(wù)應(yīng)用穩(wěn)定運(yùn)行，而業(yè)務(wù)則希望能快速試錯(cuò)快速反饋，這兩者目標(biāo)是背離的，這也造就了研發(fā)和運(yùn)維之間的隔閡，也是運(yùn)維人員忙于救火的原因。那么在云原生運(yùn)維體系下，這會(huì)是一個(gè)什么樣的局面呢？因?yàn)檫\(yùn)維特性下沉和基礎(chǔ)設(shè)施平臺(tái)化，運(yùn)維可以立足于云原生平臺(tái)之上，運(yùn)維的職責(zé)也隨之變化，運(yùn)維人員不再聚焦于借助手工或者腳本工具去完成某些自動(dòng)化特性，而應(yīng)該從云原生體系出發(fā)，借助于云原生平臺(tái)的能力提供自動(dòng)化運(yùn)維系統(tǒng)。SRE（Site Reliability Engineer）角色正是在這樣的訴求之下誕生的，是Google率先提出了這個(gè)概念，并且給出了角色職責(zé)定義：保障服務(wù)的可靠性。通過(guò)構(gòu)造標(biāo)準(zhǔn)的運(yùn)維平臺(tái)去保證服務(wù)可靠性，這要求SRE角色具有創(chuàng)造性，能夠運(yùn)用軟件工程思想去完成運(yùn)維特性的自動(dòng)化。
云原生應(yīng)用交付
以CI/CD為例，過(guò)去我們一般使用Jenkins作為CI的流水線工具，而Jenkins本身不具備高可用，實(shí)現(xiàn)方式較重，master-slave的模式嚴(yán)重影響了性能，所以基于Jenkins的流水線系統(tǒng)運(yùn)維起來(lái)成本較高。現(xiàn)在基于容器的流水線，比如云原生流水線工具Tekton，通過(guò)Kubernetes資源定義流水線，并且基于Kubernetes的策略去調(diào)度，由自身的控制器來(lái)管理流水線，整體架構(gòu)非常輕量，因?yàn)樗暮芏喙δ芏家蕾囉谠圃脚_(tái)實(shí)現(xiàn)，無(wú)論是部署還是遷移性都非常好?，F(xiàn)在Jenkins也可以通過(guò)插件的模式去支持容器調(diào)度，升級(jí)版JenkinsX也越來(lái)越向云原生方向發(fā)展。再說(shuō)應(yīng)用交付，如果我需要交付一套應(yīng)用，應(yīng)用包括LB負(fù)載均衡，RDS數(shù)據(jù)庫(kù)，一個(gè)無(wú)狀態(tài)服務(wù)，現(xiàn)在只需要編寫一個(gè)LB資源配置文件，RDS資源配置文件以及應(yīng)用的Deployment文件，并且設(shè)置相互的依賴關(guān)系，然后一鍵發(fā)布，平臺(tái)控制器會(huì)自動(dòng)拉起實(shí)例，不需一會(huì)，你的應(yīng)用就可以訪問(wèn)了。
在網(wǎng)易的輕舟云原生平臺(tái)上，我們基于Tekton和Kubernetes實(shí)現(xiàn)了云原生應(yīng)用交付，充分利用Tekton的資源定義特性，實(shí)現(xiàn)了靈活的流水線模板，讓用戶可以非常方便的定義各種流水線。另外我們?cè)O(shè)計(jì)了網(wǎng)易輕舟應(yīng)用交付模型，將應(yīng)用的研發(fā)和運(yùn)維特性分離，良好的模型定義加上云原生平臺(tái)的特性，可以輕松實(shí)現(xiàn)多云多集群交付，再結(jié)合網(wǎng)易輕舟微服務(wù)平臺(tái)的Service Mesh能力，能實(shí)現(xiàn)灰度發(fā)布、AB測(cè)試、區(qū)域訪問(wèn)等路由策略，幫助業(yè)務(wù)方輕松上云的同時(shí)，還能很好應(yīng)對(duì)各種復(fù)雜的交付場(chǎng)景。云原生日志采集工具和傳統(tǒng)一樣，但是因?yàn)榉?wù)以容器創(chuàng)建出來(lái)，具有漂移特性，所以要求日志采集平臺(tái)能夠自動(dòng)感知業(yè)務(wù)容器的新增和漂移，自動(dòng)管理采集配置文件。一般的實(shí)現(xiàn)是平臺(tái)提供日志采集功能和對(duì)應(yīng)的資源對(duì)象，應(yīng)用交付中增加日志采集資源配置，控制器監(jiān)控指定資源對(duì)象和應(yīng)用Pod，做出相應(yīng)的管理動(dòng)作。
云原生平臺(tái)上的監(jiān)控，同樣以監(jiān)控資源配置的方式對(duì)業(yè)務(wù)暴露，業(yè)務(wù)應(yīng)用在交付時(shí)以Kubernetes資源對(duì)象的方式定義監(jiān)控規(guī)則，由相應(yīng)的控制器去監(jiān)控到并且最終修改監(jiān)控組件的配置文件。
總結(jié)而言，在Kubernetes上，所有的功能都是通過(guò)資源對(duì)象的方式對(duì)外提供。用戶需要什么功能只需要定義對(duì)應(yīng)的資源對(duì)象即可。而資源對(duì)象則通過(guò)Kubernetes的自定義控制器管理，為應(yīng)用適配指定的運(yùn)維能力。
云原生自動(dòng)化運(yùn)維平臺(tái)
應(yīng)用在平臺(tái)內(nèi)會(huì)產(chǎn)生事件、日志、指標(biāo)等數(shù)據(jù)，這些是運(yùn)維自動(dòng)化的基礎(chǔ)。根據(jù)事件告警去設(shè)置對(duì)應(yīng)的處理腳本，并在告警發(fā)生時(shí)能立即執(zhí)行，這是運(yùn)維自動(dòng)化的通用做法。
但是在傳統(tǒng)運(yùn)維框架下，為了保證告警事件能被準(zhǔn)確消費(fèi)，我們可能需要消息隊(duì)列組件。為了保證消息不被重復(fù)消費(fèi)，我們可能需要引入分布式鎖，總之為了保證業(yè)務(wù)穩(wěn)定，實(shí)現(xiàn)運(yùn)維自動(dòng)化，我們需要實(shí)現(xiàn)一套復(fù)雜的運(yùn)維系統(tǒng)，而誰(shuí)又來(lái)保證運(yùn)維平臺(tái)的可靠性？
這些問(wèn)題在云原生框架下可以得到有效的解決，首先是事件，Kubernetes本身就有Event資源用來(lái)標(biāo)識(shí)平臺(tái)內(nèi)發(fā)生的各種事件，另外基于Prometheus的告警，基于日志采集的告警可以方便的在平臺(tái)內(nèi)對(duì)接。在云原生技術(shù)架構(gòu)下，我們同樣可以基于資源對(duì)象和控制器的模式去實(shí)現(xiàn)運(yùn)維的自動(dòng)化。
網(wǎng)易內(nèi)部就實(shí)現(xiàn)了一套云原生故障處理平臺(tái)，我們通過(guò)監(jiān)控平臺(tái)內(nèi)的各種事件，生成異常事件資源，由對(duì)應(yīng)的控制器去監(jiān)控異常事件，并且根據(jù)事件基礎(chǔ)信息去進(jìn)一步采集關(guān)聯(lián)信息。然后分析控制器會(huì)對(duì)異常事件進(jìn)行二次確認(rèn)，確認(rèn)完成之后會(huì)交給恢復(fù)控制器，恢復(fù)控制器執(zhí)行運(yùn)維人員事先定義好的處理方案，執(zhí)行完成之后，異常事件資源的狀態(tài)會(huì)被改寫表示異常處理完成。這是一套標(biāo)準(zhǔn)的云原生的處理流程。
在云原生平臺(tái)上，我們可以充分利用平臺(tái)特性去建設(shè)自動(dòng)化運(yùn)維系統(tǒng)，遵循平臺(tái)的標(biāo)準(zhǔn)，融入平臺(tái)生態(tài)中。從而可以快速建設(shè)出運(yùn)維系統(tǒng)，并且不斷完善。
4、運(yùn)維轉(zhuǎn)型
可以看到云原生時(shí)代的運(yùn)維會(huì)和云原生平臺(tái)緊密結(jié)合，運(yùn)維人員的職責(zé)會(huì)基于云原生平臺(tái)提供軟件的運(yùn)維能力，將運(yùn)維能力平臺(tái)化，體系化，并且不斷的打磨平臺(tái)，實(shí)現(xiàn)高度的自動(dòng)化。那么運(yùn)維人員如何去適應(yīng)云原生時(shí)代？
這里有幾點(diǎn)建議：
容器和Kubernetes是云原生基礎(chǔ)設(shè)施的事實(shí)標(biāo)準(zhǔn)，所以熟練掌握他們是基礎(chǔ)。
至少掌握一門編程語(yǔ)言（最好是Go），學(xué)會(huì)使用軟件工程思想去建設(shè)運(yùn)維系統(tǒng)。
關(guān)注DevOps的發(fā)展，了解系統(tǒng)的瓶頸，學(xué)會(huì)和研發(fā)做互補(bǔ)。
關(guān)注云原生社區(qū)的發(fā)展，學(xué)習(xí)使用各種開源工具去解決遇到的困難。
5、云原生時(shí)代下的運(yùn)維價(jià)值
云原生DevOps快速發(fā)展
容器和Kubernetes開源以來(lái)，從Knative開源，CNCF應(yīng)用交付興趣小組成立，再到今年的Helm成功從CNCF社區(qū)畢業(yè)，云原生工具的發(fā)展推動(dòng)著云原生DevOps的發(fā)展。
另一方面明確的職責(zé)劃分使得研發(fā)和運(yùn)維人員可以更加方便的協(xié)作，傳統(tǒng)的環(huán)境治理需要運(yùn)維人員按照系統(tǒng)清單準(zhǔn)備各種系統(tǒng)設(shè)備，然后按照部署清單將應(yīng)用部署起來(lái)，但是最終往往會(huì)卡在各種問(wèn)題上，環(huán)境不一致，配置變化未同步，制品版本錯(cuò)誤等等各種問(wèn)題使得運(yùn)維人員焦頭爛額，而研發(fā)也是怨聲載道，兩者之間隔閡越來(lái)越大，而當(dāng)應(yīng)用運(yùn)維功能下層到基礎(chǔ)設(shè)施平臺(tái)之后，當(dāng)平臺(tái)以統(tǒng)一的標(biāo)準(zhǔn)去定義各種運(yùn)維資源，環(huán)境治理已經(jīng)變得輕而易舉，而且在新的體系下基本上不會(huì)再出現(xiàn)之前的問(wèn)題。這也是最近幾年DevOps越來(lái)越受關(guān)注的原因之一?；谠圃夹g(shù)體系建設(shè)DevOps變得容易起來(lái)，很多傳統(tǒng)問(wèn)題迎刃而解。
云原生運(yùn)維體系助力業(yè)務(wù)
傳統(tǒng)運(yùn)維體系下，我們要實(shí)現(xiàn)敏態(tài)業(yè)務(wù)的運(yùn)維通常會(huì)非常復(fù)雜，敏態(tài)業(yè)務(wù)要求應(yīng)用能快速迭代，因?yàn)榭焖僭囧e(cuò)快速反饋才能贏得市場(chǎng)，所以對(duì)基礎(chǔ)設(shè)施的自動(dòng)化要求非常高。而在云原生體系下，借助于應(yīng)用交付平臺(tái)、自動(dòng)化運(yùn)維平臺(tái)，雙態(tài)IT運(yùn)維實(shí)現(xiàn)起來(lái)也不再?gòu)?fù)雜，我們可以一鍵快速搭建出一套復(fù)雜應(yīng)用環(huán)境，做各種測(cè)試，并且將結(jié)果反饋給開發(fā)人員，在質(zhì)量卡點(diǎn)通過(guò)之后能快速進(jìn)入預(yù)發(fā)環(huán)境，并通過(guò)完備的監(jiān)控體系將結(jié)果持續(xù)反饋，最終交付上線，運(yùn)維自動(dòng)化能保證線上故障在第一時(shí)間得到處理，通過(guò)不斷的優(yōu)化和打磨，運(yùn)維平臺(tái)越來(lái)越智能，能處理的故障越來(lái)越多，運(yùn)維人力得到釋放，可以更多的投入到平臺(tái)建設(shè)中去，這是一個(gè)良性循環(huán)。這樣體系下的業(yè)務(wù)會(huì)變得更加的敏捷、可靠。
6、為什么說(shuō)運(yùn)維是生產(chǎn)力擔(dān)當(dāng)
過(guò)去運(yùn)維平臺(tái)化程度不高，業(yè)務(wù)一旦變更容易引起線上服務(wù)的不穩(wěn)定，無(wú)論是上線過(guò)程還是新特性帶來(lái)的運(yùn)維不穩(wěn)定，都極大的影響了終端用戶的體驗(yàn)，并且因?yàn)檫\(yùn)維復(fù)雜性高，一些運(yùn)維規(guī)范較難沉淀下來(lái)，造成了研發(fā)和運(yùn)維隔閡重，相互抱怨的狀態(tài)，產(chǎn)品迭代緩慢，用戶滿意度低。
當(dāng)企業(yè)建立起云原生運(yùn)維平臺(tái)的時(shí)候，有了容器、微服務(wù)等技術(shù)的加持，運(yùn)維更具體系，更加規(guī)范，自動(dòng)化程度也更高。業(yè)務(wù)可以更方便的編排應(yīng)用，發(fā)布上線，一天十次交付，線上問(wèn)題能及時(shí)反饋，并且可以自動(dòng)修復(fù)，新的運(yùn)維手段可以快速沉淀，可以說(shuō)是運(yùn)維平臺(tái)推動(dòng)了產(chǎn)品的快速迭代，讓產(chǎn)品保持創(chuàng)新和活力。
我認(rèn)為運(yùn)維平臺(tái)可以從以下幾點(diǎn)提升企業(yè)軟件生產(chǎn)力：
好的基礎(chǔ)設(shè)施利于創(chuàng)造好的產(chǎn)品，好的產(chǎn)品創(chuàng)造更高的價(jià)值。
快速迭代的產(chǎn)品可以增加企業(yè)競(jìng)爭(zhēng)力。
云原生生態(tài)下的技術(shù)更加開放，標(biāo)準(zhǔn)更加統(tǒng)一，問(wèn)題解決的速度更快，這些都能降低生產(chǎn)成本。
中臺(tái)模式也是生長(zhǎng)在運(yùn)維基礎(chǔ)架構(gòu)上的，并且大大提升了生產(chǎn)效率。
創(chuàng)新、快速試錯(cuò)、快速反饋是團(tuán)隊(duì)乃至一個(gè)公司保持活力的根本。
7、未來(lái)展望
當(dāng)運(yùn)維經(jīng)歷了從手工到腳本自動(dòng)化再到基于云原生平臺(tái)的系統(tǒng)化，一路發(fā)展而來(lái)，可以看到非常明顯的特征：自動(dòng)化和系統(tǒng)化。
這里我們也做一些展望：
云原生平臺(tái)已經(jīng)定義了基礎(chǔ)設(shè)施的標(biāo)準(zhǔn)，未來(lái)會(huì)有更多運(yùn)維方面的事實(shí)標(biāo)準(zhǔn)落地，DevOps標(biāo)準(zhǔn)，交付標(biāo)準(zhǔn)，自動(dòng)化運(yùn)維標(biāo)準(zhǔn)等等，只有尺度適合的標(biāo)準(zhǔn)才能更好的促進(jìn)行業(yè)內(nèi)的繁榮。
代碼定義一切，GitOps已經(jīng)非常流行，相信后面可定義的范圍會(huì)更廣。
人工智能快速發(fā)展，AIOps已經(jīng)在各大廠商落地，得益于云原生平臺(tái)，AIOps將能和更多的特性結(jié)合，將來(lái)也會(huì)更加精確通用。
Serverless將徹底屏蔽基礎(chǔ)設(shè)施，運(yùn)維概念對(duì)應(yīng)用研發(fā)透明。
再遠(yuǎn)一些，立足于云原生平臺(tái)，隨著運(yùn)維自動(dòng)化的程度大幅度加強(qiáng)，NoOps不再是奢望，運(yùn)維人力會(huì)得到很大程度釋放。
