簡介：從今天起，我們將開啓一個新的專欄：《研發效能提升36計_持續交付篇》。專欄將通過10-20篇文章，系統分享雲原生時代，企業如何落地持續交付。
編者按：從今天起，我們將開啓一個新的專欄：《研發效能提升36計_持續交付篇》。專欄將通過10-20篇文章，系統分享雲原生時代，企業如何落地持續交付，本文是該專欄的開篇。
- 部署頻率。指應用將變更部署到生產環境的頻率。如每天都有部署，一天能部署十次，還是一天部署一次，或者一個月才部署一次。
- 變更前置時長。指從代碼提交到部署上線並在生產環境運行起來的時長。
- 服務恢復時間。是服務中斷之後到下一次服務能夠恢復以繼續服務的時長。
- 變更失敗率。是指對生產環境的變更失敗的比率，總共變更了多少次，其中有多少次是失敗的。
可以看到，“精英”團隊的部署頻率基本上是按需——只要想發佈，就可以隨時發佈上去。我們將“低效能”和“精英”之間一比較，再對照一下自己的團隊，就可以看到自己是屬於哪一個象限裏，是屬於精英、低效能、高效能，還是中等效能。
當然，對於變更失敗率一項，有些同學會說：“我每次發佈都成功了，我是百分百的。”其實不然，一次完成發佈過程，且中間沒有任何的干預，也沒有事後的修復、回滾是很難的。
在跟很多業務團隊、包括外面公司的同學交流時，我們發現，無論是CTO、CIO、還是一線的研發人員，大家都面臨一個問題：“我想改變”、“我想做得好”、“我想成爲精英”，但是實際做到卻很難。爲什麼？
因爲：
1.管理成本越來越高。 人越來越多，管理成本越來越大，協作複雜度也越來越高，開會的時間比干活的時間還多。
2.技術債務也越來越高。 實際生產中，業務往往不會給你很多時間去在一開始就做得很好。於是便有了“我不管怎麼樣先把業務它跑起來。”但是可能過了一年或者兩年之後，你會發現它跑不動了。這種情形在互聯網創業裏頭叫糙快猛。技術債務越來越高之後，要再去做一些事情，就要連本帶息要一起還了。
3.新技術引入非常困難。 有一些比較好的技術因爲人員的成本的問題，找不到非常優秀的人。另外，有一些技術的門檻較高，需要的技能也紛繁複雜。
不僅如此，軟件交付形態的變化也對軟件交付效能提出了挑戰。
1.持續的產品交付對軟件研發模式要求更高
以前的軟件交付是有里程碑的，但是現在不一樣了，我們希望每天都有新的東西出來，而不是去完成幾個里程碑、或者是三個月、一兩年後再出一個東西。我們希望軟件的交付是持續地、增量發生的。
以電信設備爲例，電信設備的交付，開發環境和生產環境網絡是不通的，換而言之，去做一次發佈和實施的成本特別高。
這時候，持續的交付就對軟件的研發模式提出了更高的要求。不可能再有很長時間的plan，然後等到半年後或者兩年後做一個集成來交付實施。它要求你每個迭代都有東西出來。
2.持續升級的服務對可用性提出了更高的要求
當軟件可以做到持續發佈、升級了，軟件的可用性也會相應地被提出更高的要求，不能動不動就斷了。對客戶來講，他看到的就是你的一個服務，他對你提供的服務是有感的，因此你的服務需要非常高的可用性。
3.持續的交付需要能高效保證產品質量
質量對持續交付是非常重要的。當產品發佈上線，如果有質量問題就很容易導致故障，甚至導致需要公司出面來去做公關。近幾年也有很多這樣的例子。
俗話說，有挑戰就一定有機遇。具體來看，雲原生時代，我們面臨着2大機遇，可以幫助我們提升軟件交付效能。
機遇1：技術發展推動應用架構及部署架構的演進
我們會發現，技術的發展實際上在推動我們的應用架構和部署架構的演進。從資源的角度來說，以前我們應用雲託管，而後發展爲雲優化，再到現在的雲原生。我們會發現資源發生了一些變化，而應用架構的也同樣發生了變化——從單體應用逐漸發展爲了Severless。也就是說從原來捱得越來越近，到慢慢地分得越來越開、拆得越來越小。
（2）部署架構的演進
從部署架構的角度來說，我們也可以看到一些變化，從原來的物理機到現在的BaaS/FaaS。
這樣的演進也讓我們的整個交付變得更靈活、更解耦，可以做到想發就發，甚至讓工程師更多的關注在業務邏輯上。
機遇2：雲基礎設施和雲原生技術的興起
（1）雲基礎設施的層次越來越高
現在雲基礎設施的抽象層次越來越高了。其實在13年的時候，我們當時對於雲基礎設施的理解都是“infrastructure”。但隨着容器的興起，我們逐漸看到了容器平臺，而後我們又有了PaaS，我們不需要再去關心消息隊列、存儲、監控等。而今，我們擁有了Serverless，幾乎是可以不用寫後端，整個的應用後端全部在雲上。要做的就是寫業務邏輯，而且幾乎是前端的業務邏輯。後端服務我只需要按照使用量付費就可以了。
（2）K8S成爲事實標準，雲原生成爲趨勢
從K8S到現在的CNCF，我們會發現目前K8S已經是一個事實上的標準。大家不會再去討論要不要去做雲原生，現在的問題是怎麼做。
（3）微服務化背景下，服務治理的訴求越來越大
大家都在談微服務，但微服務會帶來很多之前沒有的問題。其中一個比較典型的問題就是服務治理。服務太多，怎麼進行服務治理、服務發現怎麼做、負載均衡、容量調度等等，各種問題都來了。所以大家對服務治理的訴求就變得越來越大。
與此同時，服務的數量越多，複雜性就越高。比如，若一個服務的可用性是99.9%，10個9服務累加便是99.9%的10次方。另外，它本身的複雜性也會越來越高。好比說兩個人之間交流很簡單的，但三個人交流的時候，我的鏈路就多了一些。再加上分佈式服務間的網絡通信，各種各樣的異常情況都會出現。這些都是非常現實的問題，也會給我們帶來很大的成本。
總結來看，如今我們的軟件交付與以前有了非常大的不同。
然而，大多數時候概念十分美好，落地卻有各種各樣的痛苦。
雲原生時代，我們該如何落地持續交付？接下來，我們將通過系列文章，與大家一起梳理雲原生時代持續交付的系列實踐，敬請期待。
本文爲阿里雲原創內容，未經允許不得轉載。