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