私募股权基金网站建设,劳务公司名称大全,简洁大方的网站,企业网站建设找哪家简介#xff1a;从今天起#xff0c;我们将开启一个新的专栏#xff1a;《研发效能提升36计_持续交付篇》。专栏将通过10-20篇文章#xff0c;系统分享云原生时代#xff0c;企业如何落地持续交付。
编者按#xff1a;从今天起#xff0c;我们将开启一个新的专栏#…简介从今天起我们将开启一个新的专栏《研发效能提升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几乎是可以不用写后端整个的应用后端全部在云上。要做的就是写业务逻辑而且几乎是前端的业务逻辑。后端服务我只需要按照使用量付费就可以了。
2K8S成为事实标准云原生成为趋势
从K8S到现在的CNCF我们会发现目前K8S已经是一个事实上的标准。大家不会再去讨论要不要去做云原生现在的问题是怎么做。
3微服务化背景下服务治理的诉求越来越大
大家都在谈微服务但微服务会带来很多之前没有的问题。其中一个比较典型的问题就是服务治理。服务太多怎么进行服务治理、服务发现怎么做、负载均衡、容量调度等等各种问题都来了。所以大家对服务治理的诉求就变得越来越大。
与此同时服务的数量越多复杂性就越高。比如若一个服务的可用性是99.9%10个9服务累加便是99.9%的10次方。另外它本身的复杂性也会越来越高。好比说两个人之间交流很简单的但三个人交流的时候我的链路就多了一些。再加上分布式服务间的网络通信各种各样的异常情况都会出现。这些都是非常现实的问题也会给我们带来很大的成本。
总结来看如今我们的软件交付与以前有了非常大的不同。 云原生时代我们需要持续交付的模式以实现更快、更高质量的软件交付。
然而大多数时候概念十分美好落地却有各种各样的痛苦。
云原生时代我们该如何落地持续交付接下来我们将通过系列文章与大家一起梳理云原生时代持续交付的系列实践敬请期待。
原文链接
本文为阿里云原创内容未经允许不得转载。
