开发者学堂课程【ALPD 云架构师系列：云原生 DevOps 36计-阿里云云效出品：度量及改进】学习笔记，与课程紧密连接，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/772/detail/13527
度量及改进
内容介绍：
一、课前启示
二、持续交付
三、衡量度量标准
四、计算逻辑
五、两个维度的改进
六、爱上问题，改进的机会
七、影响问题的持续发布要素
八、路径
九、团队工程能力矩阵
一、课前启示
在爱丽丝梦游仙境中一幅漫画，树上趴的猫叫做才俊猫，里面爱丽丝走到岔路口，看到树上的才俊猫，爱丽丝问他我该走那条路呢？猫反问道你要去哪？答：我也不知道，猫说那就无所谓了。这段话反映出你要走的路是对是错取决于你的目标，符合目标的选择通常是好的选择，而违背目标的选择往往都是坏的，度量也是如此，是一种手段你要选择那条路，但是本身往哪条走取决于本身的选择，给出的答案是因为改进而度量。
二、持续交付
持续交付，就是持续地交付（Continuous Delivery is Deliver Continuously）
●持续-分散均匀的，而不是批量的
●快速-过程快速即时的
●可靠-过程要有质量保证
●度量-帮助看见，发现问题和改进点
持续交付能力，一直是说持续的交付将其既解开为持续的交互，是分散均匀的，而不是批量的，不是矛刺状的发布是均匀的，另外要快速的发布而且是过程有质量保证的，此外需要度量进行发现问题和改进点。
三、衡量度量标准
质量：持续快速、高质量、低成本地交付业务价值
业内存在标准衡量如何度量，从四个标准，分别为 部署频率、变更前置时间，变更失败率、线上服务恢复时长。
部署频率更多是变更与快速，变更前置时间更多是快速，变更前置时间时间要短，服务恢复时长即出现问题时要快速回复，即质量做到快速的响应，稳定性，整个服务的可容性好，变更失败率也是质量水平，其中反馈出来，持续，快速，可靠几个角度，可以看到变更前置时间和失败率会影响部署，同样变更失败率和服务稳定性也会影响到线上服务时长，给出相对完整的工程能力的度量。
四、计算逻辑
变更前置时长，一般作为各道工序的求和，加上等待时间，等待后执行，有时执行出错，需要回滚加上工序反复次数的时间，此时的等待为等待反应的时间。
此外，具体到每一步工序的时间为准备时间和实际的恢复时间，为简单计算逻辑执行时间+准备时间和实际执行的时间。
影响成功率的因素；前序质量、基础设施及环境稳定性。
五、两个维度的改进
基于整体的流程计算出的数据，基于这些因素对这些数据进行相应的改进，而改进从两个角度，流程角度和工序角度，有本质的不同，流程改进确定是一种价值流的改进，最大化价值，是价值最大化的向下流动，而工序改进是每一道具体的工序应该做到什么样，在工序中如何做的更好，在工序中消除浪费，符合金逸的思想，rest 所以上面管理的实践偏向流程改进，而相对工程偏向于工序的改进。
举例，一家客户的企业现状，将企业进行交互的过程用便利贴，贴出，每一张大的便利贴为一个阶段，具体活动用黄的小的表示，红色的表示问题，问题很多，蓝色表示期望，从流程的价值角度表示期望，从源头，具体想要走到什么样上去。
而在第二部分针对每一道工序，具体存在那些问题，完成后形成下图，是根据具体的需求设计，比如说有具体的迭代计划，和另外一个迭代结束，即固定的结束时间，在迭代结束进行批量计算，导致代码的变更流是什么样的情况，如图展示，每一步具体的衔接时间，每一步的具体批量多大，所形成。
通过价值流的具体分析，找出问题，针对相应的问题做出象限，如下图，比如说从影响的范围和改进难度，此时会发现，需要对难度大得到地方做出改进的选择，为什么要改进容易?为了增强信心增加改进的效益，并且是在拿到所有问题的时候，所有人内心很担忧甚至是害怕，这么多问题是会影响成本和本身的工作的效率，所以很多时候人们惧怕出现很多问题的情况。
六、爱上问题，改进的机会
如同小孩子一样，出错后不告诉他如何改进会很怕错，此时出错会更多，所以此时针对问题的本身，去改变思维的方式，应该爱上问题，问题是现状，其实就是问题，是改进的机会，问题是一种反馈。
识别问题是一种反馈，最怕看不到问题，如同理发，看不出问题的存在，此时我们仅看到现象而找不到根因，所以此时不要被现象蒙蔽，要找到根因，标题长不是问题，是现象，缺陷多不是问题，是现象，需要去找到根因，比如说此时的问题进行发布的批量特别大或者是进行单量的工程比较弱，服务架构的水平差，这些是问题，是对于那些现象，造成的结果，此时进行分析，找到杠杆点，最容易撬动问题的点，如同手里五百快钱送领导礼物，是买钢笔和劣质皮鞋呢？显然答案显而易见。用非常小的投入，达到非常好的结果，但是要找到特别准的根因。
七、影响问题的持续发布要素
●返工：批量的集成，容易造成整个版本的失败，每次失败，需要整个版本中，所有变更一起返工
●阻塞：手工工序过多，形成等待；依赖过多，等待其他的部署
●落后的技术手段：手工测试，流水线手工串接及触发，信息同步靠手工文档
●债务：自动化测试，没有有效的代码扫描手段，无单元测试；应用间耦合高
导致返工、阻塞、落后的技术、以及债务常见技术上的债务，为后续造成影响，在一篇文章，看到失败的总结，其中第一点不敢留下技术债，第二点没有及时去还债，在业务快速发展，可能要留技术债，此时是没问题的，但是不能及时不还债，一旦时间久了以后会膨胀，会出现还不动的情况，还债的难度越来越大。
所以针对流程、结果的优化改进来达成目标状态，比如刚才首先从频率上，提供愿景目标希望每周一次，质量上来说每天均可发布，从时间上来说每天不超过一个小时，当然此时为愿景目标，基于当前的状态需要做出调整的目标，也就是绿色的便利贴，希望所作出的，最后形成面向需求的做出来的成品，目前来说针对较差的产品，可以通过好的技术手段来改变。
八、路径
比如原来的发布通过脚本通过原来的编排的方式进行分批的发布，然后通过手动的测试来进行手段的改进，原来可能是运维、开发完全分离的方式。现在可以通过一站式形成完整的整体，在这个过程中可以找寻目标的状态，此时整个过程是存在路径的不可能说运动时，这个月就要搞定这个事，你会发现运动是做不到的，需要找到路径，来进行这个运动。
针对路径，通过真实的案例第一部分可进行能力的补齐，若没有静态扫描，可以通过增加静态扫描的方式进行静态的扫描，你的部署能力也会从人工的部署能力变成动画的部署能力，从而进行了成本的降低
在此过程中如何做到持续的发布，做到批量小一点。
第三步做到信息的协调，通过信息的透明化，和构建信息的追溯，进行信息的协调，有时的响应慢，便是由于信息的协同不全，此时通过信息的透明化来完成。
第四点通过管理抓手，通过相应的度量，有一些相应的机械找到改进的行为，此时为推荐找到相应的路径，此时找到相应的加速，根据经验，此方式较为通用。
此外在能力补齐时建议从后向前做，先解决部署问题再向前解决相对应的问题，往往会带有相关要求，进行前期的改变会在结果上得到反馈机会，而如果没有采用从后向前，则没有相关结果的反馈。
所以通过这种方式会很容易的得到落地的实施。
九、团队工程能力矩阵
从团队的工程能力也存在相应的矩阵，团队负责方向是可以对基础模块、指令还是产品的实施，由于团队水平不一，有时仅能负责一块指令，对开发系统很难，这是对于业务能力的理解范围，而横向对应角度更多是技术能力，从能力角度看团队是能做到计算基础需求还是到完整的发布上线等，此时目标是最右上面的点，可以根据这张表，对自身团队进行检测，并对未来的预期进行路径的设定。
