作者 | 郑子颖
来源 | 阿里技术公众号

一 为什么缩短反馈弧是关键

都说“没有度量就没改进”。但这句话还不完整。度量对于改进的作用是给反馈，但单单有度量还不够，还要度量得足够频繁、度量得足够快，这样才能更有效的进行改进。缩短反馈弧（feedback loop）的价值在生活中有很多例子：

• 减肥。如果每天称体重，就有助于减肥、有助于控制体重。吃多了，看着体重一天天上去，心里就有压力了，就会控制。如果不是每天称体重，就容易放纵自己，一发而不可收拾。每天称体重，和每半年称一次体重，对减（gai）肥（jin）的作用是完全不一样的。
• 吃饭，如果吃太快，就容易吃太多。原因也是反馈弧太长。人的饱腹感是有delay的，从肚子已经吃饱了，到大脑感受到饱腹感，有一个delay。在这个delay这段时间里，如果继续吃，就会吃多了。
• 育儿，是反馈弧的另一个很好的例子。家里有小孩的人，都对育儿很焦虑。因为：不知道现在做的这些事情，对小孩将来的上学、就业会产生什么影响。在育儿这件事情上面，反馈弧的长度是论年记的。

工作中也有很多例子：

• 线上变更，我们强调“可监控”。做了一个变更，如果能马上得到高质量的反馈（高质量的反馈 = 监控覆盖率高、噪音低、阈值设定合理），就非常有助于判断我做的这个变更是好的还是不好的。资损核对，从T+1，到T+H，到TM，也是反馈弧不断缩短的过程。反馈弧缩短是非常有助于及时发现问题、及时采取对策的。
• 系统设计分析的评估遗漏，仍然是反馈的问题。我的这个系分，对不对，有没有遗漏。我系分的时候做了一个判断：这个链路可以复用。那么这个判断对不对？有没有遗漏、判断对不对，这些都是反馈。
• 我们平时说 “业务试错”，也是反馈。“试错”的意思就是：试一下，看看错不错，如果错了就掉头，如果对了就可以继续投入。“快速试错”就是业务效果的反馈弧要缩短。没有“快速试错”能力，就是反馈弧长，就不好。我们要有快速试错能力。
• 晋升，也是很痛苦。因为晋升的反馈弧也很长。辛辛苦苦干两三年，还要准备晋升述职，也不知道最后评委会怎么评价。为了解决这个问题，如果能在过程中增加了一些非正式的述职，提供反馈，效果就很好。

二 怎么算反馈弧短？

反馈弧短不短，有两个方面：

1. 反馈的前置等待时间。理想状态是：反馈不需要等，任何时候想要反馈都可以。
2. 反馈本身的耗时。理想状态是：反馈本身的耗时很短，结果立等可取。

打个比方，二三十年前，那时候量血压（量血压就是一种反馈）是要去医院量的，只有等早上医院开门了、挂个号、排队等，轮到你了医生给你量血压。所以不是任何时候想量血压就能量血压的，量血压的前置等待时间很长。但量血压这个事情本身，耗时很短，一分钟就知道结果了。后来，有了家用血压计，量血压就不用等了，也不需要求助于医生，自己在家里任何时候都可以量，可以每天早中晚量三次，甚至可以每小时都量一下。有了家用血压计，虽然量血压这个反馈动作本身的耗时并没有缩短很多，但提高了频次，任何时候想要反馈就可以给反馈，前置等待时间缩短到几乎为零。这个变化就大大的有助于病人控制自己的血压。类似的，控制血糖也是类似的道理。以前要知道血糖是要去医院验血的，现在有一些新技术，可以让病人自己就可以测量血糖，手指尖夹一下就可以了。这个变化就大大的有助于控制自己的血糖。

软件开发活动中的反馈也是类似的。我是一个开发，我改了一行代码，我想知道这行代码有没有问题。这就是给我反馈。我是一个开发，我写了大半天代码，把某个功能需要的代码写好了，我现在想知道这个功能是不是能work了、我的代码还要不要再改。这也是反馈。今天，在有些团队，一个开发要得到这些反馈，反馈弧还很长，长在两个方面：1）要等，不是任何时候想要反馈都可以。2）反馈本身的耗时长、成本高，结果也不是立等可取的。反馈弧一长，开发效率就降低了。在一些团队里，反馈弧长，在他们的开发联调中的体现就是：

• 反馈不是随时随地的，要等。因为不是随时随地都可以发起一笔的。也不是每个人都知道怎么发起一笔的，只有特定的同学才知道怎么发起一笔。
• 反馈不是立等可取的。就算发起了一笔交易，还要找一个个域的同学check数据。同时，反馈的质量也不高，反馈不consistent，因为check是人做的，不同人的做的check不一样。

持续集成就是要缩短反馈弧。我们平时一直在做各种事情，比如改代码、数据库加字段、修改DRM值、数据库里插入数据。持续集成就是每件事情做了以后、每个动作发生以后，都要尽可能快的给我反馈，告诉我各种场景是不是通的、代码是不是work。“持续”了，反馈要随时随地都可以给。自动化是缩短反馈弧的必要条件（但不是充要条件，因为自动化了以后，还有覆盖率、充分性、有效性等要素）。如果还有人工步骤，就不肯能做到反馈弧很短，因为人是不可能随时随地都available的，人的动作也是很慢的。

三 缩短反馈弧的成本和投入产出比

要缩短反馈弧、建设持续集成，的确是需要投入成本的。要花人花时间去写自动化、去维护整个基建、去维护持续集成的良好运行。但是，在缩短反馈弧上投入的成本，是能从其他地方收回来的。很多人只看到了建设持续集成需要的投入，但是他们没有算另一笔账：这个做好了，能节省多少时间。

例如，对每个项目来说，把每个联（ji）调（cheng）用例和check都自动化了，这个前期投入，在项目进行的过程中会收到回报。比如，人肉做一次check，算上找人的功夫，加起来每次人肉check可能要15分钟。而把这个check自动化，需要2小时的工作量（包括自动化、以及后面的维护）。那么，如果整个项目过程中要做的check次数超过8次，这个自动化就是一笔划算的买卖。事实上，一个check在一个项目里面何止跑8次。现在，可能一个check在一个项目里面只跑几次，但这是因为实在没法再多跑了，因为每次check都非常累。但如果自动化了，check就可以跑很多次很多次。我们是希望check跑很多次很多次的。因为：我们希望我们任何时候改了代码，都能随时随地的得到反馈。

另外，随时随地跑一下check、随时随地的得到反馈，还有一个很大的好处，就是：能使得排查问题变得很方便。九十年代的时候，IDE还没有今天这么好，比如那时候在Turbo C 2.0里面写代码，当时很多程序员的习惯是每写几分钟代码就编译一下。因为当时的IDE比较“简陋”，不像今天的IDE，哪个地方如果有typo，比如变量名打错了、关键字打错了，都会马上有波浪线提示。当时的IDE是没有这种提示的。如果写了半个小时、一个小时的代码，写了几百行，然后再编译，如果编译有问题，排查起来就比较辛苦（虽然编译错误会告诉我哪行错了，但是真正的问题根源未必就在报错的那一行）。所以，当时大家每写几分钟代码就编译一下，一旦有错就知道了，问题就出在刚才那几分钟写的代码里面。这就是为什么缩短反馈弧能让排查问题变得更方便。

投入在建设持续集成上的成本，不能孤立的看。如果只从单个开发同学的视角看，我的投入产出比未必很高，也许在某些情况下，用原来的方式反而对个人更方便。但在很多情况下，个体受益，往往会导致群体受损，进而导致每个个体都受损。个体做一些小的付出，会导致整个群体受益，进而让每个个体受益。

这样的例子在生活中也很多。如果每个人开车都不遵守秩序，都乱变道、乱加塞，那么整体的道路秩序就会很混乱，进而导致整个高速上面的车速都降下来，进而导致每个人都更晚回家。疫情防控也是这个道理。局部的一些隔离措施对个体来说是一个付出。但这些个体的付出，换来的是群体的受益，我们整个社会的疫情防控就做好了，整个社会的经济恢复了，进而让每个个体都受益。