开发者学堂课程【ALPD 云架构师系列-云原生 DevOps36计：度量及改进（一）】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/82/detail/1300
度量及改进（一）
内容介绍
一、持续交付
二、计算逻辑
三、改进
四、愿景目标
五、路径
这是爱丽丝梦游仙境里的一幅漫画。
爱丽丝走到岔路口，看见树上趴着一只柴郡猫，爱丽丝问它，我该走哪条路呢？柴郡猫反问道，你要去哪？爱丽丝说：我也不知道，柴郡猫说，那就无所谓了，走哪条路都行。这段话告诉我们，要走的路是对是错取决于目标，符合目标的选择就是好的选择，违背目标的选择就是坏的选择。度量这件事也是。度量只是一个手段，往哪方面走，也取决于为了什么而度量。在这里有明确的答案：为了改进而度量。
一、持续交付
1、做到持续分散均匀，而不是批量的。也就是说，不是突增似的一个一个毛刺状的发布，而是非常均匀的 。
2、快速。要做到持续，过程能够快速及时。
3、要符合预期，要可靠，过程要有质量保证。
4、持续、快速、可靠需要有相应的度量方式帮助看见、发现问题和改进点。这是做工程里相应做度量改进里较为简单的。
（1）怎样体现持续，快速，可靠和度量。在工程能力方面，业界有一些标准，是Dora state of Devops 2018给出的。这里从四个方面提到软件交互效能的度量。
①一个是附属频率跟前置时间，服务恢复时间还有变更失败率。变更前置时间即快速，变更时间短，服务出现问题时能够快速恢复，稳定性和服务的可用性比较好。变更失败率即质量水平。其他几个指标反映出了持续，快速，可靠的几个角度。
②变更前置时间和变更的失败率最终会影响到部署，同样变更失败率和服务的稳定性也会影响线上服务的亏损市场，这里给出来的是相对来说比较完整的工程能力的度量和结果指标。
二、计算逻辑
1、变更前置时长一般是各大工序各种活动的发布过程的所有的时间的求和，加上等待的时间，等待完成后再去执行，那么这里就是时间，但是有时执行可能会出错，所以还需要有反复的时长，比如前面那个图样测试了十次，每次一个小时可能一共需要二十多小时。这个等待指的是阻塞等待。
2、另外一个指的是每一道工序的时间有最终执行时间，又包含了准备时间和实际的执行时间。如此容易出现问题，需要进行排查定位，再加上恢复时长。
只要给出一个简单的计算逻辑，这些因素最终就会影响计算的结果指标。
三、改进
1、改进维度
得到数据之后才可以做相应的改进，而改进是从两个维度执行，一个是从流程改进的角度，另一个是工序改进的角度，这两个有本质的不同。
在流程改进中，更多是一种管理实践，是价值流的改进，即最大化价值，让其能够向下流动。
工序的改进就是要了解过程中每一道工序应该做到什么程度并做得更好，然后消除工序中的相对浪费，使其符合精益思想。所以说管理实践更多是偏向流程改进的，而工程实践或是相应的技术偏向工序的改进，也就是消除浪费方面。
举个例子，这是我们一个客户的现状，把整个发布的过程或者说是软件交互过程用便利贴贴出来，其中每一张比较大的便利贴，是一个阶段，每个阶段里具体的活动用方的、黄色的便利贴贴出来。产生的问题用红色的便利贴贴出来。
由于一些便利贴已经贴在另外的地方，红色便利贴看起来很少，其实很多。蓝色的是期望做成什么样子。
（1）首先我们会从整个流程上去看具体的情况，价值怎样从源头顺利走到尾巴上。
（2）第二部分就是要针对每一道工序里的任务或活动，将其问题标示出来。
完成之后就可以形成一张图。
图中是针对需求迭代时间设计的，比如迭代计划需要有固定的起止时间。也就是说在迭代结束时做批量的提测发布。这时就造成了代码的变更流情况，可以分析出来了，基本上与便利贴相同，每一步具体的活动、中间的衔接台花费时间、衔接过程中的批量多大，以此形成一张图。
2、通过对价值流的分析，就可以分析出具体的问题出在哪里。
例如，将相应问题做成象限，从影响的范围，改进难度等角度考虑。选择改进时，要选择影响范围较大，但相对来说改进容易一点的，容易建立信心，能够更快地能够完成改进。很难的话，可能会长时间看不到效果。
在遇到问题时，大家内心都很担忧，有些时候甚至是害怕的，因为这么多问题意味着需要花很多时间和成本来解决相应的事情，可能影响到现在的工作。
3、问题即改进机会
改变思维范式，问题就是改进的机会，应该爱上问题。现状无法达到目标状态，这就是问题，而这个问题就是改进机会。问题可以给予反馈，最怕的不是有很多问题，而是看不到问题。
4、找到根因
没有接受过专业训练的人有时无法分辨是问题还是现象，或是由现象所造成的影响。这时不能被现象蒙蔽，要找到根本原因，例如交付周期长不是问题而是现象。
如缺陷很多，也不是问题而是现象，这时应该通过根因分析找到具体的问题，例如具体的问题可能是排期需求批量很大，或是集成分布的批量很大，还有集成发布的工程能力问题、服务价格的设计水平很差等这些才是问题，由于问题才造成了现象，以至于带来对业务响应能力变弱的影响。这时就要做相应的分析才能知道问题所在。需要找到最容易改进的杠杆点，即投入最小的成本，获得最大的收益。用一个小投入培训，达到比较好的结果。但是一定要找准根因，才有机会去做这件事。
5、影响持续发布的要素
从问题的角度来说最终会影响的要素有导致返工、阻塞、或是有些落后的技术，有比较好的手段去做，却依然选择落后的技术，以前没有意识到这个地方可以调整。
还有可能有遗留的债务，常见的就是技术上的债务，以前欠下来但没来得及还，就会在后续的问题中产生出来。
在业务快速发展的过程中，肯定会存在必须要留技术债的情况，有时为了业务的快速发展，一定要留技术债，这是没问题的，要敢于留技术债。但不能说以业务为借口不还债，技术债要及时还，一旦时间久了，债就会膨胀，还的难度越来越大。
