ios15|云原生时代，软件交付有何不同 | 研发效能提升36计苹果

文章图片

文章图片

文章图片

编者按：从今天起，我们将开启一个新的专栏：《研发效能提升36计_持续交付篇》。专栏将通过10-20篇文章，系统分享云原生时代，企业如何落地持续交付，本文是该专栏的开篇。
Dora在2018年DevOps年度报告中对软件交付效能提出了一组度量指标，以衡量一个企业的软件交付水平。

部署频率。指应用将变更部署到生产环境的频率。如每天都有部署，一天能部署十次，还是一天部署一次，或者一个月才部署一次。变更前置时长。指从代码提交到部署上线并在生产环境运行起来的时长。服务恢复时间。是服务中断之后到下一次服务能够恢复以继续服务的时长。变更失败率。是指对生产环境的变更失败的比率，总共变更了多少次，其中有多少次是失败的。可以看到， “精英”团队的部署频率基本上是按需——只要想发布，就可以随时发布上去。我们将“低效能”和“精英”之间一比较，再对照一下自己的团队，就可以看到自己是属于哪一个象限里，是属于精英、低效能、高效能，还是中等效能。
当然，对于变更失败率一项，有些同学会说：“我每次发布都成功了，我是百分百的。 ”其实不然，一次完成发布过程，且中间没有任何的干预，也没有事后的修复、回滚是很难的。
在跟很多业务团队、包括外面公司的同学交流时，我们发现，无论是CTO、CIO、还是一线的研发人员，大家都面临一个问题：“我想改变”、“我想做得好”、“我想成为精英” ，但是实际做到却很难。为什么？
因为：
1.管理成本越来越高。人越来越多，管理成本越来越大，协作复杂度也越来越高，开会的时间比干活的时间还多。
2.技术债务也越来越高。实际生产中，业务往往不会给你很多时间去在一开始就做得很好。于是便有了“我不管怎么样先把业务它跑起来。 ”但是可能过了一年或者两年之后，你会发现它跑不动了。这种情形在互联网创业里头叫糙快猛。技术债务越来越高之后，要再去做一些事情，就要连本带息要一起还了。
3.新技术引入非常困难。有一些比较好的技术因为人员的成本的问题，找不到非常优秀的人。另外，有一些技术的门槛较高，需要的技能也纷繁复杂。
不仅如此，软件交付形态的变化也对软件交付效能提出了挑战。

1.持续的产品交付对软件研发模式要求更高以前的软件交付是有里程碑的，但是现在不一样了，我们希望每天都有新的东西出来，而不是去完成几个里程碑、或者是三个月、一两年后再出一个东西。我们希望软件的交付是持续地、增量发生的。
以电信设备为例，电信设备的交付，开发环境和生产环境网络是不通的，换而言之，去做一次发布和实施的成本特别高。
这时候，持续的交付就对软件的研发模式提出了更高的要求。不可能再有很长时间的plan ，然后等到半年后或者两年后做一个集成来交付实施。它要求你每个迭代都有东西出来。
2.持续升级的服务对可用性提出了更高的要求当软件可以做到持续发布、升级了，软件的可用性也会相应地被提出更高的要求，不能动不动就断了。对客户来讲，他看到的就是你的一个服务，他对你提供的服务是有感的，因此你的服务需要非常高的可用性。
3.持续的交付需要能高效保证产品质量质量对持续交付是非常重要的。当产品发布上线，如果有质量问题就很容易导致故障，甚至导致需要公司出面来去做公关。近几年也有很多这样的例子。
俗话说，有挑战就一定有机遇。具体来看，云原生时代，我们面临着2大机遇，可以帮助我们提升软件交付效能。
机遇1：技术发展推动应用架构及部署架构的演进

（1）应用架构的演进
我们会发现，技术的发展实际上在推动我们的应用架构和部署架构的演进。从资源的角度来说，以前我们应用云托管，而后发展为云优化，再到现在的云原生。我们会发现资源发生了一些变化，而应用架构的也同样发生了变化——从单体应用逐渐发展为了Severless 。也就是说从原来挨得越来越近，到慢慢地分得越来越开、拆得越来越小。