开发者学堂课程【ALPD 云架构师系列-云原生 DevOps36计：持续反馈和持续改进】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/82/detail/1298
持续反馈和持续改进
内容介绍：
一、终态：提供稳定、可预期的系统
二、检视和适应
三、提升软件研发的可见性
最后一次课程更多关注注意反馈和注意改进，最后会做针对这一系列课程的快速回顾。回到最终的终态，就是作为软件交付的终态，是提供稳定、可预期的系统。
一、终态：提供稳定、可预期的系统
一个可预期的系统要确保环境和软件制品的一致性。要做到这一点，在整个软件交付过程中要去做到这个，因为是持续交付价值的，可预期运行的系统是软件的增量，所有在这个过程当中，真的在做工程的能力是持续、快速、高质量地交付软件增量的能力。持续交付能力要做到两点，一个是容易发布（Release Easy），还有一个是频繁发布(Release Often)。
二、检视和适应
具体怎么去落地，怎么去达到这个目标，也就是出于现在的水平，怎么可以达到持续、快速、高质量地交付软件增量。
在整个 PDCA 里，有比较简单的两个，一个叫检视，一个叫适应，这里只是用了 Inspect、 Adapt、Plan 和 Action。简单一点就是 PDCA，只是 action 就是 do， Check，再相应的一些 Adapt，就是个无限的循环。要做到这一点，其实目标是提升持续交互的能力，要做到持续交互的能力需要去建立反馈的闭环，也就是要作为要去改进的反馈循环。
比如区分两种提升的能力，一种是提升特别快的，一种是提升特别慢的。比如在平时开发过程当中，有很多现实生活的例子，比如理头发，如果理发是让家人理，头发可能两个月或者一个月理一次，每理一次的感觉一样，没有特别好，但是理发店的理发师傅，可能学一个月、两个月下来，手艺明显增加很快。
因为在理发店里面理发师每天可以理很多次，每次理完之后师傅会告诉他这个地方有问题，那个地方有问题，然后就知道怎么去改，改完之后就理下一个，很快就可以理下一个，慢慢就能把头发理很好。但如果是家人理，可能就这一个实验对象，两个月就理一次，也提不了什么反馈意见，理完了再下个月又很长时间没理了，又一样。
所以实际的提升或者改进的速度取决于反馈的频率，做这件事情做得是否足够频繁，反馈的周期是不是足够的短。比如学开车，学开车每打一次方向盘，汽车会立刻告诉打多了还是打少了，从一名不会开汽车的人到成为一个优秀的驾驶员，时间其实是特别短的，提到新车之后过完两三个月，会认为自己已经具备去 f1赛场开汽车的能力。但与此同时可以看到，在开远洋货轮这件事情上，打一次舵，船身的转动，它的反馈周期是特别长的，所以反馈相对就会比较久，感觉就会比较慢，而且平时在路上打汽车方向盘的机会多于在海上打舵的机会，显然两个的频率也是不一样。在这个过程当中，需要做频繁的持续改进，首先要获得持续反馈，但反馈的本质是让人看得见。
三、提升软件研发的可见性
在整个软件研发过程当中，在整个工程上，第一要看得见制品的质量，必须对交付质量很清楚，现在看的质量是处在什么样的水平上；第二要看得见加工的活动，针对做这件事情的效率和效果是情况是怎么样的；第三要看得见交付的全貌，活动的整体的过程全部串联起来是什么样的，所以又提供了从工程效目上来交付的全貌是什么。但是前面三者只是让看见，看见给了相应的反馈，有了相应的反馈应该带来具体的响应行动，也就是要去做任何相应的改进行动，比如质量有问题，要立刻去修复这个问题，如果某个加工的活动里的效率特别低，要想办法怎么提升上去；如果整个工程能力很弱，没办法做到持续快速的响应业务的诉求，要想办法怎么提升工程能力。
1、交付的质量
这里有几张图表很清晰的告诉了交付的质量水平是怎么样的，每个红色的点表示是一次缺陷，可以看到它的缺陷的数量是越来越密，而且缺陷修复的周期时间越来越高，纵轴表示提交一个缺陷 Open 一个缺陷到修复的时间的窗口大概是多少。
可以看到缺陷越来越多，而且缺陷的累积也越来越多，虽然改得很快，绿色的部分改得很快，但红色的部分累积得很快，且越来越大，在最右边的图的上边里可以看到整个缺陷累积是越来越多，可以以此对应到整个发布过程，可以看到发布的成功率很低，绝大多数都是红色的部分，回滚的次数也很多，从整体上看，告诉交付质量是处在什么样的水平。
2、看得见加工的活动
在整个发布过程当中，也要看得见加工的活动，加工的活动里每次从代码提交到最后发布到生产环境里的每个阶段都会有相应的一道道工序去确保软件制品质量是符合预期的。这个过程当中一旦不符合预期，会直接给一个反馈，所以这里提到的 no news is good news，就是没有消息就是好消息，反馈就是有问题了才反馈，需要去做一些处理，做相应的一些 action。
这里能够看见整体的加工活动，每个活动里加工的结果是怎样，还要快速的反馈，在右边这张图里，也就在整个 CICD 的流水线上，每个过程最后都到反馈到 dashboard 上，然后给到开发者，也就是作为一名程序员，这次代码的提交在整个交付过程当中的结果应该第一时间反馈到屏幕上，能看得见整体加工的活动。
3、需要看得见交付的全貌
看这两张图，特别是第二张图在之前反复的出现过。上面这张是发布的日历图，就是哪一天有发布就会有一个绿色的色块，如果发布次数多颜色会深一点，可以看到每周能够发布多少次，总共发布了多少次，连续有多少天一次发布都没有，中间有一块从六月份有一段时间一个发布都没有，有多少天是能够连续发布的或者是哪一天发布的次数特别多，都能看出来。
能够看到整个交付的情况是什么样子，按天，哪个地方经常出现问题，比如阻塞了一个星期没发布，可能就是有问题。下面这张图是一张散点图，能看出发布成功率是什么样子，绿的点多还是红的点多，发布时长分布在什么地方，就是18个小时左右还是3天左右，发布集，每个点都是有大小的，大的点发布集会更大，小的点发布集会更小，说明如果这个发布集越大说明这次发布内容越多。同时看到数据的趋势，比如成功率是在增加的还是减少的，发布频率是在增加的还是减少的，能够通过这个图看出来。在整体上来说，这样简单的一个图是从外往内去看，第一个发布的结果是怎么样，用下面这张图，在发布过程当中每个地方情况是怎么样，看到整体之后才可以往下转，看到它坎坷的“一生”。
看某一次发布到底发生了什么，如果再往下转，发现这是非常典型的。因为它分成了三个阶段，开发阶段、集成阶段和发布阶段，会发现开发阶段显然是没有做到测试的，就是它的问题频繁的失败，但是没有人去修复，就一直在失败，到了最后它也是失败的，没有结果。整个开发阶段的反馈周期特别长，会发现一个流水线比集成和发布的都长，集成阶段没有经过验证，就前面阶段都没有走完就进入集成了，基线都是不对的、不成功的，然后它的返工特别多，会看到中间每一次一个虚线框出的就是一次验证，会发现它重复了很多次，所以一直都失败，一直在返工。
到发布阶段，会发现发布阶段同样是经过集成验证就进入发布了，它的返工也很多，发布阶段返工了四到五次，中间那些空白的，就是没有绿色也没有红色的地方是在人工等待，就是要等到一个人工确定的响应，人工等待占比很多。整体来看，开发集成发布并不是创新的，它用不同的机械，所以最后放上去是非常坎坷的。
在整体上从外面看到完整的结果，再深入到里面去可以看到非常完整的一些细节。在整个过程反馈回来会告诉全貌，有了这些东西，无论是从资本的质量来看，还是活动的情况来看，还是整个全貌来看，它只是让看见。看见并不是主要的目的，看见只是一种手段，最终带来的结果是能够带来具体的改进行动，目标就是为了改进而做的。
4、带来具体的改进行动
在这个过程当中可以看到，无论是发布到生产环境上，线上带来的故障、告警、缺陷和疑情，这里是外部的质量告诉相应的一些反馈还是内部里在研发交付发布的过程当中带来的一些过程质量，里面包含了行为，包含了制品的质量，包括工程能力的水平，通通把它叫做过程质量，因为表示过程做得好还是不好。
有了外部质量、过程质量这两块数据的反馈，才得以有机会去做相应的分析，产生出改进行动。
改进行动也逃不出这五点，环境/工具、流程、代码/设计、测试守护和员工技能，有了改进行动之后做完相应改进行动，最终体现出来的结果就是外部质量和过程质量得到了有效的改进，所以整个看见和反馈的目标最终要带来改进行动或者相应的一些具体的一些 action，后续的一些响应的一些 action，有了这些东西分别知道了反馈首先是从制品质量、活动、全貌和具体改变行动。
