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