开发者学堂课程【ALPD 云架构师系列-云原生 DevOps36计：为什么应用发布的成功率会这么低？】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/82/detail/1288
为什么应用发布的成功率会这么低？
一、做到安全可信的发布
C++工程实践基本分为三个部分，不可变基础设施，不可变制品，不可变环境，不可变的发布流水线的过程。本次内容是做到安全可靠的发布，质量是非常重要的一个点，当然安全等因素也很重要。
终态需要提供稳定、可预期的系统。可预期的系统，需要确保环境和软件制品（例:容器镜像）一致性。这是在终态提供服务的角度来看的，有的服务是这样的。但在整个软件协作的过程中，软件的协作是工程师围绕着代码协作的过程，在整个协作的过程中，制品、环境、发布过程都是定义在代码里的。软件交付能力的目标是发得容易，发得频繁。发得频繁属于增量，发得容易是因为每次发布时间比较少。下图的发布成功率达到30.63%，横轴代表时间，纵轴代表每次发布消耗的时长，越往上，发布所需时间越长，越往下就越短，红色的点代表发布失败，绿色的点代表发布成功。
看到这个图之后，能发现什么问题？首先是成功率只有百分之三十左右，发布成功率为什么这么低，有什么问题？
为什么发布的不频繁，也不容易，每次发布都需要那么长时间并且成功率也不高。在实际操作过程中，有很多的理由会导致发布成功率特别低，因为出现bug没有修复，因为有很多冲突，有等待会导致这样的问题。
除了上面这些之外，第一，无法按期交付、挤占需求开发时间。可能无法做到按期交付，不是开发组或测试组不愿意，而是在实际过程中，开发和测试可能占据大量的时间，让维护没有太多的时间，或本身软件质量特别差，有很多缺陷，需要修改相应的缺陷，需要响应一些故障，导致无法在前期做好工作，随着过程的推进，会发现花在维护上的时间特别多，导致没有多长时间做功能上的开发，从而形成恶性循环，会让维护的工作在后期堆得更多。在互联网行业里大家的做法都是操，快，猛，一开始为了响应业务，基本所有的时间都在做开发，但等到业务扩大，再继续开发就很难向前前进，这时绝大多数人都放在维护阶段，但维护的成本是很高的。基本没有太多时间开发新的项目，而且在一个非常脆弱的系统里，增加一个新的东西是很难的。
第二点，问题发现的越晚，修复成本越高。随问题发现时间的延后，修复成本呈指数级上升。在电信行业，一旦问题留到客户那里，成本是非常非常高的。有一年在法国出现电信的故障，电信级别软件的交互与生产环境和开发环境是打不通的。一旦出现问题，要去生产环境中解决这个故障，意味着要派工程师从中国飞到法国，再做相应的调研，出相应的解决方案进行修补。在这个过程当中，对于电信设备来说，是无法提供正常工作的，如果这时出现紧急状况需要拨打电话，电话又打不通，这时就会产生很高的成本。站在商业的角度，运营商很容易提出要求赔偿，一小时赔付多少签，这时成本会越来越高。在互联网行业中，也是这样。上线之后，造成的成本，带来的疑情，带来的故障等导致的成本是很难的，称这个成本为交付质量成本，另外一个成本是在交付过程中产生的成本，也是问题发现的越晚，成本越高，研发团队的角色，职能就会越多，最终形成的道理就是问题发现的越晚，修复成本越高。
基于上面两点，问题对交付效率和结果是有特别大的影响的，只有发布内容的质量得到了保证，才能做到发的容易、发得频繁。发布内容包括制品，发布的策略、环境、配置。可运行的系统就是待发布的内容，所以要保证待发布的系统的质量。要做到这一点会通过全方位的测试质量守护体系，保障交互质量。
