編者按：從今天起，我們將開啟一個新的專欄：《研發(fā)效能提升36計_持續(xù)交付篇》。專欄將通過10-20篇文章，系統(tǒng)分享云原生時代，企業(yè)如何落地持續(xù)交付，本文是該專欄的開篇。

策劃&編輯｜雅純

Dora在2018年DevOps年度報告中對軟件交付效能提出了一組度量指標，以衡量一個企業(yè)的軟件交付水平。

• 部署頻率。指應用將變更部署到生產(chǎn)環(huán)境的頻率。如每天都有部署，一天能部署十次，還是一天部署一次，或者一個月才部署一次。
• 變更前置時長。指從代碼提交到部署上線并在生產(chǎn)環(huán)境運行起來的時長。
• 服務恢復時間。是服務中斷之后到下一次服務能夠恢復以繼續(xù)服務的時長。
• 變更失敗率。是指對生產(chǎn)環(huán)境的變更失敗的比率，總共變更了多少次，其中有多少次是失敗的。

可以看到，“精英”團隊的部署頻率基本上是按需——只要想發(fā)布，就可以隨時發(fā)布上去。我們將“低效能”和“精英”之間一比較，再對照一下自己的團隊，就可以看到自己是屬于哪一個象限里，是屬于精英、低效能、高效能，還是中等效能。

當然，對于變更失敗率一項，有些同學會說：“我每次發(fā)布都成功了，我是百分百的?！逼鋵嵅蝗?，一次完成發(fā)布過程，且中間沒有任何的干預，也沒有事后的修復、回滾是很難的。

在跟很多業(yè)務團隊、包括外面公司的同學交流時，我們發(fā)現(xiàn)，無論是CTO、CIO、還是一線的研發(fā)人員，大家都面臨一個問題：“我想改變”、“我想做得好”、“我想成為精英”，但是實際做到卻很難。為什么？

因為：

1.管理成本越來越高。 人越來越多，管理成本越來越大，協(xié)作復雜度也越來越高，開會的時間比干活的時間還多。

2.技術債務也越來越高。 實際生產(chǎn)中，業(yè)務往往不會給你很多時間去在一開始就做得很好。于是便有了“我不管怎么樣先把業(yè)務它跑起來?！钡强赡苓^了一年或者兩年之后，你會發(fā)現(xiàn)它跑不動了。這種情形在互聯(lián)網(wǎng)創(chuàng)業(yè)里頭叫糙快猛。技術債務越來越高之后，要再去做一些事情，就要連本帶息要一起還了。

3.新技術引入非常困難。 有一些比較好的技術因為人員的成本的問題，找不到非常優(yōu)秀的人。另外，有一些技術的門檻較高，需要的技能也紛繁復雜。

不僅如此，軟件交付形態(tài)的變化也對軟件交付效能提出了挑戰(zhàn)。

1.持續(xù)的產(chǎn)品交付對軟件研發(fā)模式要求更高

以前的軟件交付是有里程碑的，但是現(xiàn)在不一樣了，我們希望每天都有新的東西出來，而不是去完成幾個里程碑、或者是三個月、一兩年后再出一個東西。我們希望軟件的交付是持續(xù)地、增量發(fā)生的。

以電信設備為例，電信設備的交付，開發(fā)環(huán)境和生產(chǎn)環(huán)境網(wǎng)絡是不通的，換而言之，去做一次發(fā)布和實施的成本特別高。

這時候，持續(xù)的交付就對軟件的研發(fā)模式提出了更高的要求。不可能再有很長時間的plan，然后等到半年后或者兩年后做一個集成來交付實施。它要求你每個迭代都有東西出來。

2.持續(xù)升級的服務對可用性提出了更高的要求

當軟件可以做到持續(xù)發(fā)布、升級了，軟件的可用性也會相應地被提出更高的要求，不能動不動就斷了。對客戶來講，他看到的就是你的一個服務，他對你提供的服務是有感的，因此你的服務需要非常高的可用性。

3.持續(xù)的交付需要能高效保證產(chǎn)品質(zhì)量

質(zhì)量對持續(xù)交付是非常重要的。當產(chǎn)品發(fā)布上線，如果有質(zhì)量問題就很容易導致故障，甚至導致需要公司出面來去做公關。近幾年也有很多這樣的例子。

俗話說，有挑戰(zhàn)就一定有機遇。具體來看，云原生時代，我們面臨著2大機遇，可以幫助我們提升軟件交付效能。

機遇1：技術發(fā)展推動應用架構(gòu)及部署架構(gòu)的演進

（1）應用架構(gòu)的演進

我們會發(fā)現(xiàn)，技術的發(fā)展實際上在推動我們的應用架構(gòu)和部署架構(gòu)的演進。從資源的角度來說，以前我們應用云托管，而后發(fā)展為云優(yōu)化，再到現(xiàn)在的云原生。我們會發(fā)現(xiàn)資源發(fā)生了一些變化，而應用架構(gòu)的也同樣發(fā)生了變化——從單體應用逐漸發(fā)展為了Severless。也就是說從原來挨得越來越近，到慢慢地分得越來越開、拆得越來越小。

（2）部署架構(gòu)的演進

從部署架構(gòu)的角度來說，我們也可以看到一些變化，從原來的物理機到現(xiàn)在的BaaS/FaaS。

這樣的演進也讓我們的整個交付變得更靈活、更解耦，可以做到想發(fā)就發(fā)，甚至讓工程師更多的關注在業(yè)務邏輯上。

機遇2：云基礎設施和云原生技術的興起

（1）云基礎設施的層次越來越高

現(xiàn)在云基礎設施的抽象層次越來越高了。其實在13年的時候，我們當時對于云基礎設施的理解都是“infrastructure”。但隨著容器的興起，我們逐漸看到了容器平臺，而后我們又有了PaaS，我們不需要再去關心消息隊列、存儲、監(jiān)控等。而今，我們擁有了Serverless，幾乎是可以不用寫后端，整個的應用后端全部在云上。要做的就是寫業(yè)務邏輯，而且?guī)缀跏乔岸说臉I(yè)務邏輯。后端服務我只需要按照使用量付費就可以了。

（2）K8S成為事實標準，云原生成為趨勢

從K8S到現(xiàn)在的CNCF，我們會發(fā)現(xiàn)目前K8S已經(jīng)是一個事實上的標準。大家不會再去討論要不要去做云原生，現(xiàn)在的問題是怎么做。

（3）微服務化背景下，服務治理的訴求越來越大

大家都在談微服務，但微服務會帶來很多之前沒有的問題。其中一個比較典型的問題就是服務治理。服務太多，怎么進行服務治理、服務發(fā)現(xiàn)怎么做、負載均衡、容量調(diào)度等等，各種問題都來了。所以大家對服務治理的訴求就變得越來越大。

與此同時，服務的數(shù)量越多，復雜性就越高。比如，若一個服務的可用性是99.9%，10個9服務累加便是99.9%的10次方。另外，它本身的復雜性也會越來越高。好比說兩個人之間交流很簡單的，但三個人交流的時候，我的鏈路就多了一些。再加上分布式服務間的網(wǎng)絡通信，各種各樣的異常情況都會出現(xiàn)。這些都是非常現(xiàn)實的問題，也會給我們帶來很大的成本。

總結(jié)來看，如今我們的軟件交付與以前有了非常大的不同。

云原生時代，我們需要持續(xù)交付的模式，以實現(xiàn)更快、更高質(zhì)量的軟件交付。

然而，大多數(shù)時候概念十分美好，落地卻有各種各樣的痛苦。

云原生時代，我們該如何落地持續(xù)交付？接下來，我們將通過系列文章，與大家一起梳理云原生時代持續(xù)交付的系列實踐，敬請期待。

也歡迎在評論區(qū)留言，與云效專家互動，說出你想聽到的內(nèi)容～

歡迎大家使用云效，云原生時代新DevOps平臺，通過云原生新技術和研發(fā)新模式，大幅提升研發(fā)效率。現(xiàn)云效公共云基礎版不限人數(shù)0元使用。