开发者学堂课程【ALPD 云架构师系列-云原生 DevOps36计：度量及改进（二）
】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/82/detail/1300
度量及改进（二）
内容介绍
一、持续交付
二、计算逻辑
三、改进
四、愿景目标
五、路径
四、愿景目标
需要针对结果的目标，通过流程上的优化，再进行每道工序的改进，最终就可以达到目标状态。例如下图就是愿景目标。
频率上希望每周发一次;质量上希望每天发新的 build;时间上希望一次发布时长不多于一个小时。
这个愿景目标可以显示理想的状态，如此才可以基于当前的状态，找到问题并做出相应的改进。上文提到的便利贴是针对问题做了相应调整的，绿色便利贴是指愿景目标，之后产生出下面的面向需求的持续，即有需求后需求的开发，测试和发布，与代码变更流建立起相应关系。需求可以自己开发，并直接发布，然后达到相应水平。目前在中间阶段中有练习阻塞点或较差的工序，就可以通过较好的技术手段来改变。
例如之前发布时，通过脚本机子进行，可以通过开发S编排方式分批发布，大多通过手动测试，但其实可以采用自动化测试手段来做。之前开发、测试、运维都是分开独立的系统，但之后可以利用完整的一站式平台来解决，将其串起来形成一个整体。在这个过程中，就能够找到目标状态并分析原因，找到原因后即可进行改进。
五、路径
就像运动，一旦开始就做不到把业务停下来，就算能够停下来，可能运动过去不到半年就回去了。所以需要找到一个路径，每做一件事情，都能获得到相应的结果，如此比较有信心，每一次有微小的改进即可。
1、简单路径
路径很重要，这里有一个简单的路径，可见、可控、可度量、加速。
例如这个真实案例。
（1）第一部分，做相应能力的补齐。在代码质量管理方面，静态扫描可以加进来，其成本很低，但结果明显。部署能力方面，可以将人工部署改成动画部署。这些相对成本很低，原来无法将所有东西打通了，现在可以先打通。
（2）完成后，需要考虑在这个过程中怎样做到持续发布，将批量做小一点，发布窗口多一点，以便将其及时发出去。
（3）更好促进角色之间的协同，通过信息的透明化建立信息的可追溯性，做好更好的协同并加快响应速度。
响应慢大多是在等待，而等待是由于信息延迟无法同步造成的，通过信息的透明化追溯可以优化。
通过管理的抓手，例如度量、性能的基线等找到改变的机会
2、团队能力
在很多团队里做这件事情百试百灵。
（1）在做能力补齐这件事时，采用从后往前的方式。如果原来的部署有问题，先去把部署解决完毕。解决部署的问题后再解决验证问题，再到集成问题，如此逐步往前。
后续问题慢慢解决时，会给前期的工具带来要求，如此就带来了前期的改进机会，并且前期改进可以在结果上得到呈现。若先做前面，由于没有达到最后的结果，所以没有相应反馈。
通过这种方式，很容易做出相应落地。但是对于一个团队来说，一张图、一成账、一颗心，做所有的事都必须胸中有丘壑，有大图。
（1）关于团队的工程能力也有相应的简单矩阵，这里是以前的产品设计的矩阵。
①从纵轴的角度看，团队是能负责技术模块还是技术组件，还是产品或是系统，因为团队的水平不同，可能只能负责某一块组件，很难负责整个系统。所以需要从业务领域的角度来理解范围。
②对于横向角度来说，更多的是注重技术能力，是只能负责一块模块或组件的开发工作还是开发和测试都可以胜任，或是能做到集成或发布，或是可以负责整个流程等。
③目标是右上方的点，可以检视团队处于哪个方块，计划下一个方块是什么。
这个过程中可以把未来定义成目标，当下就是现状。再找到一个改进机会，这时再去定义相应的路径。
