工程师应该如何对待自己的错误

继上次讲的管理者如何对待工程师团队犯错误之后，我再说说工程师怎么对待自己的错误。

RCA报告制度是我的研发四板斧之一，也是我最为重视的环节，我会和涉及到的所有人一一确认BUG和故障的所有细节，直到我能完全理解并建立因果链为止，RCA报告由我编写或至少由我修改一直改到我满意为止。

但很多工程师刚到我的团队，遇到这种场合，都会有点腼腆，有点扭捏，有点不好意思。还有工程师不愿自曝其丑，总觉得我改都改了，领导这是生气了吗，领导你问这么细干啥呀，总想对推理过程一带而过。

 

在我这里，允许失败，允许犯错。做IT不可能一帆风顺，不可能没有意外，就算内部没发布没更新没问题，外部也会给你当胸一拳，所以我常说“灾难随时会到来”。

“有一种愚蠢的观点认为，在NASA不允许失败。”埃隆·马斯克说，“但在这里（注：指SpaceX），失败是可以选择的。如果你没有把事情搞砸过，说明你的创新能力不够强。”——Ozan Varol

按这种说法，也不是什么失败都可以被接受。我对高级别错误见猎心喜，反对愚蠢的低级错误，尤其是反复犯同一类低级错误。

工程师死于什么？

工程师死于听天由命和漫不经心。

 

有研究人员对71名外科医生在10年时间里做过的6500台心脏手术做了调查分析，他们发现，那些把手术搞砸了的外科医生会在随后的手术中表现更差，结果表明这些外科医生不仅没有从他们的错误中吸取教训，反而还强化了坏习惯。——Ozan Varol

所以工程师应该有意识地用清晰易懂的证据链，论述清楚根本原因，撰写RCA报告，并广而告之，让其他工程师一起从这个错误中吸取教训，把不好的习惯提前消灭。

 

第一个例子：

曾有产品经理反馈，她多次发现我们的一款App在苹果手机上会出现打开后首页菜单消失的现象，再次打开后则菜单显示。此问题复现时机不确定。

工程师分析后发现，首页菜单的动态显示用了一个临时性方案：由H5资源中的JSON文件配置。

菜单项之所以消失，是因为从网络下载的存储于沙盒文件目录 Library/Cache 中的新H5资源文件夹丢失了，所以不显示首页菜单。

网上大多数文章中对这个 Library/Cache 目录的描述是：程序重启后并不会丢失数据，只是不会被iCloud同步。而实际上苹果的文档中给出的说明是，当设备存储空间不足时，系统可能会自动删除此目录中的文件。

本地H5文件夹丢失后，解压出来的是App包里的老H5资源，所以下一次打开的时候能显示首页菜单（只不过是上一个版本的）。

工程师找到根本原因之后，明白了两个道理：

第一条，尽量不要使用临时方案，迫不得已采用了临时方案，也要尽早改造为通用方案，别给自己埋雷。

第二条，使用官方相关API时，一定要亲自查阅通读官方原版API DOC，不要道听途说，不要嚼别人嚼过的馍。

所以他将H5资源从 Library/Cache 目录，转移到 Documents 目录，确保H5资源相关的文件不会丢失。同时首屏菜单，从H5中的JSON控制，改为由服务器统一下发。

 

我们积攒了数百份翔实的RCA报告，每攒一批RCA就会全员发布。

为了提升从失败中吸取教训的能力，NASA在一份名为“飞行规则”的文件中罗列了人类在航天飞行中犯过的错误。这份记录过去的规则可以为未来提供指导，它汇集了几十年来的航天失误和错误判断，让人们以史为鉴。该文件记载了自20世纪60年代以来载人航天飞行中出现的数千种异常情况及解决方案，描绘了每次事故的前因后果，并在更宏大的背景下赋予它们意义，为子孙后代保留了这种制度化的知识。有了这本手册，NASA的员工只要关注新的问题即可，无须做不必要的重复工作。

——Ozan Varol

虽然我不知道一代代工程师有多少人认认真真读过一遍RCA，但我对每一个案例都印象深刻，每当发生BUG或故障，我都能联想起历史上一宗宗相似的案例，为团队提供思路。

工程师不要觉得那些都是过时的册子，都是别人犯的错，我不会犯这些错误。但你连是什么错误都不知道，你凭什么不会重复犯错？

 

第二个例子。

一天业务方反馈说数据大屏里有一个学生的消费趋势和他的消费明细对不上。

工程师进一步分析其他学生消费信息发现并不是一个学生数据问题，而是共通性问题。这才发现Kafka集群的目标topic有五个分区，但消费端只消费了其中三个分区的数据。这是为什么呢？

原来前不久大数据服务“移山”里的实时订阅监控告警某topic的消费延迟较大，于是就扩了两个分区，但是下游消费者并未感知到分区的变化，依旧只消费旧的三个分区数据，造成计算结果偏小。那这又是为什么呢？

工程师探究之后发现，FlinkKafkaConsumer配有动态感知分区变化的开关（flink.partition-discovery.interval-millis），打开开关后，便可以动态感知分区变化，就不用重启消费端了。由于实时计算动态感知有性能损耗，所以官方默认是关闭的。从性能和资源利用率及我们实际情况综合考虑，也不需要开启动态感知参数。以后如果分区调整变多，会打开这个开关的，就不用统一重启所有消费者了。工程师得到的教训是，对于商业产品涉及的集群，任何与其相关变化调整要做方案评估再操作，不可太随意。

 

当我与一些企业高管谈论失败时，他们中的一些人认为：如果失败是可以容忍的，那么失败的次数就会成倍增加。失败意味着犯错，而犯错是需要追责的。这些高管认为，如果不对责任方做出处罚，最终就会培养出一种“失败也无所谓”的企业文化，允许失败的存在。这些想法与几十年来的研究结果格格不入。——Ozan Varol

这也就是我上一篇文章所抨击的企业高管。

你完全可以创造一种环境，允许聪明人失败，且让他们不自鸣得意。你可以允许人们承担高质量的风险，但你也可以设定高标准。你用不着容忍那些草率的失败——所谓草率的失败，指的是因为心不在焉而反复犯同样的错误或反复失败。你可以奖励那些“聪明人的失败”行为，惩罚表现不佳的人。当你正在打造那些可能会失败的东西时，必须要接受一些无法避免的错误。人们不应该为聪明的失败承担责任，而应该为没有从中学到经验承担责任。——Ozan Varol

在这种环境下，那些仍然不愿意公开谈论失败的工程师，那些仍然对“总结经验教训”敷衍潦草的工程师，注定将一事无成。

 

这其中的奥秘，是一种叫“心理安全”的东西：

1995年的一项研究发现，每一位住院病人的用药错误次数达到了1.4次。在这些错误中，大概有1%的病人得了并发症，身体受到伤害。哈佛商学院教授埃德蒙森决定深入挖掘原因，她派一名助理研究员去医院实地观察医疗团队的做法。该助理发现，较好的医疗团队并没有犯更多的错误；相反，他们只是上报了更多的错误。

这些团队拥有开放的氛围，员工认为探讨错误的做法是安全的，他们更愿意与他人分享失败的经验，并积极努力减少失败，所以他们的表现更为优秀。

埃德蒙森把这种氛围称为心理安全。用埃德蒙森的话来说，心理安全是指“在实现雄心勃勃的绩效目标过程中，没有人会因为犯错、提问或求助而受到惩罚或羞辱”。

研究表明，心理安全能促进创新。当人们可以畅所欲言，提出挑衅性的问题和半成型的想法时，挑战现状就变得更容易了。心理安全也提升了团队学习能力。在心理安全的环境中，若上司提出可疑要求，雇员就会提出质疑，而不是一味地服从命令。在埃德蒙森的研究中，表现最好的医院团队是由一位身先士卒、极其平易近人的护士长领导的，她积极地促进开放式环境的形成。在接受采访时，护士长说她的团队允许在“一定程度上犯错”，而“非惩罚性的环境”对发现和解决错误至关重要。在该团队工作的护士们证实了护士长的话。一位护士指出，“这里的员工更愿意承认错误，因为护士长会帮助你”。在这个团队中，护士们勇于为自己的错误承担责任。正如护士长所说的那样，“护士们往往会因为犯错而自责，她们对自己的要求比我任何时候对她们的要求都严格得多”。

表现最差的两个医疗团队则有着截然不同的氛围。在这两个团队中，犯错意味着受惩罚。一位护士称，她曾卷入一起医疗事故中。在给一名病人抽血时，她不小心伤到了病人，护士长立刻对她进行“审判”。护士回忆说：“简直太丢脸了，仿佛我是两岁大的孩子似的。”另一位护士说“医生们喜欢摆架子”，如果你犯了错，“他们恨不得把你的脑袋拧掉”。还有一位护士称，犯错后的感觉就像是“被叫进校长办公室”。结果，如果发生用药错误，护士们会故意掩盖消息，免受短期的尴尬和痛苦。然而这种做法忽略了保持沉默的长期后果，即病人因为用错药而受伤或死亡。反过来，这种环境会形成恶性循环。那些表现最差、最需要改进的团队也最不可能上报错误；而如果错误没有上报，团队便无法改进。

我相信每一位对职场高度和人生高度有所追求的工程师都不会愿意置身于那种没有心理安全的团队环境，一旦你偶然间加入了一个愿意明确承诺支持“聪明人的失败”和善意的风险承担行为的团队，请珍惜它，因为真的不多见。

-END-