阿里研究员:缩短软件开发中的反馈弧

阿里研究员:缩短软件开发中的反馈弧

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

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

都说“没有度量就没改进”。但这句话还不完整。度量对于改进的作用是给反馈,但单单有度量还不够,还要度量得足够频繁、度量得足够快,这样才能更有效的进行改进。缩短反馈弧(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是没有这种提示的。如果写了半个小时、一个小时的代码,写了几百行,然后再编译,如果编译有问题,排查起来就比较辛苦(虽然编译错误会告诉我哪行错了,但是真正的问题根源未必就在报错的那一行)。所以,当时大家每写几分钟代码就编译一下,一旦有错就知道了,问题就出在刚才那几分钟写的代码里面。这就是为什么缩短反馈弧能让排查问题变得更方便。

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

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

上一篇:【转】kubernetes 中 deployment 支持哪些键值


下一篇:这个知识点不错,,学习一下先。。。无状态服务(stateless service)(转)