共计 2507 个字符，预计需要花费 7 分钟才能阅读完成。
简介：从今天起，咱们将开启一个新的专栏：《研发效力晋升 36 计_继续交付篇》。专栏将通过 10-20 篇文章，零碎分享云原生时代，企业如何落地继续交付。
编者按：从今天起，咱们将开启一个新的专栏：《研发效力晋升 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 次方。另外，它自身的复杂性也会越来越高。好比说两个人之间交换很简略的，但三个人交换的时候，我的链路就多了一些。再加上分布式服务间的网络通信，各种各样的异常情况都会呈现。这些都是十分事实的问题，也会给咱们带来很大的老本。
总结来看，现在咱们的软件交付与以前有了十分大的不同。
云原生时代，咱们须要继续交付的模式，以实现更快、更高质量的软件交付。
然而，大多数时候概念非常美妙，落地却有各种各样的苦楚。
云原生时代，咱们该如何落地继续交付？接下来，咱们将通过系列文章，与大家一起梳理云原生时代继续交付的系列实际，敬请期待。
原文链接
本文为阿里云原创内容，未经容许不得转载。
