开发者学堂课程【ALPD 云架构师系列：云原生 DevOps 36计-阿里云云效出品：为什么应用发布的成功率会这么低】学习笔记，与课程紧密连接，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/772/detail/13531
为什么应用发布的成功率会这么低
内容介绍：
一、云原生 DevOps 36计的问题叙述
二、无法预期交付，挤占需求开发时间
三、问题发现的越晚，修复成本越高
一、云原生 DevOps 36计的问题叙述
欢迎来到 LPD，最佳工程实践，今天讲DevOps 36，这是从零开始的，其实整个交通实现基本上是分成三块来讲，一个是不可变，基础设施分别讲到了不可变的制品，而不可变的像环境，然后再讲一个在发布流水线，不可变的一个过程，今天跳到另外一个主题，就是比如质量这一块，也就是要注意安全可信的发布，要做到安全可行的发布，其实质量是一个非常重要的一个点，当然其他的一些点也有像安全向合规，今天更多是从质量的角度来去了解一下可信发布的一个目标。
再回顾一下之前讲的状态。其实需要提供一个稳定然后可以使系统需要确保环境和软件制品一致性，这是站在最终中泰提供的服务的角度来去看，服务是这样但是整个在软件写作的过程当中，软件的协作是工程师围绕着代码的一个协作的一个。因为在整个写作过程当中，无论是制品、环境、发布过程，所以在过程中，对于发布来讲，认为发布的目标是什么提高软件交互能力的一个目标，就是要发的容易，要发的频繁，说明增量精致比较多，发的容易，因为每次发的时间比较少，看一下如图：
图上的例子就是统计了一下发布成功率是30.63%，从图上的点，可能看得出来是红的，其实都比较密，如图就是其实之前应该也见过几次，横轴就是一个时间从4月1号到现在的时间，然后纵轴是一个时时长，就是每次发布所耗的时长是一个对数的，所以看到就是下面可能是秒，上面得到了天，所以越往上就发布的时间所用的时间越长，越往下就越短，里面一个红的点表明是一次失败的发布，一个绿的点表明是一次成功的发布。看到图之后，能够有什么一个联想呢？
从图上，能够发现什么问题，首先就是成功率只有30%左右，发布成功率为什么这么低，有什么问题，为什么发布的不频繁，发布的也不容易，每次发布都要很长的时间，并且成功率又不高，接着往下认为的几个观点，其实不用的具体也明白，在过程当中实际的工作当中，有很多的理由会导致发布成功率会特别。比如有的人bug不去修复。是因为有很多冲突，也讲过分支管理，包括研发模式里，有冲突，有等待，会导致这样的一个问题，刚好也取了下面的那张图：
二、无法预期交付，挤占需求开发时间
除了前面所讲之外还有哪些原因呢？看一下第一个很重要的一个原因，就是有的时候，举个开发约定什么时候测试，之间约定一个什么样的时候来去测试，或者什么时候发布了上线，但是大家的时间没办法做到安全交互，这里没办法，不是开发主观上不愿意，可能由于其他的一些原因，也不是测试主观上不愿意保证质量很好，然后往下游走，但是在实际过程当中开发和测试可能记在上游做了好多事情维护，没有太多时间，或者本身软件质量特别差，有很多缺陷，需要修改相应一些缺陷，要去响应线上的一些故障，导致没有办法的时间在前期就把工作做好，会发现，随着过程，越到后来花在维护上的时间就越来越多，然后就没有多少时间去做功能的开发，然后就形成一个恶性循环，因为想发的更快，就会减弱一些，就是原来本来应该在维护阶段做到的事情，那就会让维护的工作，在后期堆的更多。
就是这里头是一个很典型的，我觉得在互联网行业里头尤为突出。所以在互联网行业里，大家做法都是说，超快，猛，一开始正常业务，所以说很快堆了很多东西，所以基本上所有的时间都在做开发，但是等到后面的时候，业务真的起来了。这时要在上面再继续开发的时候，发现很难往前走，走不动了，这时绝大多数人都是放在维护阶段，其实曾经我跟张宇也曾经工作了在一个比较老的一个系统上面，是一个电信的一个系统，记得当时，在改代码的时候我翻到了一个八几年的代码，所以当时，绝大多数整个团队，很多人绝大多数都是在维护那一套的系统，这时会发现维护的成本是很高的。当在2000零几年要去看一段80年代的代码的时候，大家就可想而知啊，这时维护成本有多高，要去开发新的特性，基本上没有太多时间，所以这是一个，而且在一个非常脆弱的系统里，在心中所有的东西也是会很难的，这是第一点。
三、问题发现的越晚，修复成本越高
第二点，就是问题发现越晚修复成本越高就是随着问题，暴露的点越往后走，可以看到就是整个的成本是呈指数级的上升的。其实应该在电信行业工作都有这种经验，一旦问题留到客户那里你的成本是非常非常高的。这里也可以举个例子，记得有一年在法国，然后出现过一个电梯的一个故障，这时因为电信级别的，软件的交互，适合生产环境和开发环境是打不通的，这时一旦出现问题，要去生产环境里去解决故障，那也意味着要派工程师从中国飞到那边去，飞到那边去之后，再去做相应的一些修订、调研，然后再去出相应的一些配置，然后再去修复它。而在过程当中，对于电信设备来说，它是没办法提供正常工作的。
那时如果发生地震了，有其他的人，比如有人生病了要打电话，如果电话又打不通怎么办？
所以这里会导致很高的这种成本，站在商业的角度来讲，运营商当然是很容易向设备上提出要求赔偿，比如一个小时你不能恢复要多少钱，然后折合一下赔付可能就是好几百万欧元了，这时成本是越来越高，其实在互联网行业里比如上线之后这时造成的成本带来的疫情带来的这些故障所导致的这些成本其实是很难的，把这种成本叫做交付的一个质量的一个成本。
交付出去之后，由于缺陷导致的这种成本。那另外一个成本，就是在交互的过程当中里产生成本。越到后面，渠道的研发团队的人的角色、职能它就会越多，这时很简单一个道理，问题发现得越晚，修复成本越高。那在这里相信比较多人都会有类似的这种恶同感，所以基于前面两个其实发现其实是问题其实交互的一个效率和交互的一个结果来提出是有特别大的影响。
所以今天要去做了保证待发布内容的质量，因为只有发布的质量的发布的内容的质量得到了保证的话，才能做的发的容易，发的频繁，而发布内容的质量有什么比较制品。
包括环境，像一些配置，之前说过股份制，包括制品，包括发布的一些策略，包括环境，包括配置，都是在这里面，也就是一套可运行的系统，就是在发布的一个内容，需要保证在发布的这套系统是可以运行的，要做到这一点，很容易，那要做到这一点，其实现成的办法是什么呢？
冒出来的第一印象其实就是通过全方位的测试，来保障一个角度质量。
