开发运维
首发于开发运维

Bug引发事故,该不该追究责任?

今天看到美团支付故障,想想美团工程师可能对bug引起的故障和和要承担责任进行纠结过程中,严重推荐这篇文章,“人非圣贤,孰能无过?”技术人员也是人,因此编程过程中难免出 Bug,出了 Bug 系统就会出问题,出了问题系统就会宕机。那么,Bug 引发的一连串事故,该不该追究责任,又如何去追责呢?

记得有一次,和朋友聊天。在交流的过程中,朋友问:“在你们的工作中,工程师的 Bug 或者失误引发的问题,会不会被追究责任,会不会扣工资,会不会被开除?”

当时我很诚实地按照实际情况回答说:“不会。”

这个人又继续问:“那出了事故没有任何惩罚,不会有问题吗?”当时,我围绕着员工的素质、自觉性和责任心进行了回答。后来再次思考这个问题,我越想越觉得有意思。

俗话说 “常在河边走,哪有不湿鞋”,各种因为代码问题引起的麻烦也是屡见不鲜。那么,在 Bug 引发问题的情况下,怎样处理才能最大程度上保持团队的主动性、责任感和执行力呢?

我们先来假想两种极端的情况:如果每个错误都会受到惩罚,会怎样;如果所有的错误都没有任何追究和跟进,又会怎样?

假如每个错误都会受到惩罚,不难想象,以下情况一定难以避免。

  1. 大家都怕闯祸,所以风险高的事没人做,或者总是那几个靠谱的“老司机”做。没有机会处理这种复杂情况的人,永远得不到锻炼,也无法积累这样的经验。
  2. 如果有人搞砸了什么事情,会因为担心承担后果而推卸责任,从而尽可能掩盖错误的坏影响,不让人知道。
  3. 如果别人犯了错,会觉得不关自己的事。
  4. 指出别人的错误就会导致别人被追究责任,因此看到有问题也会犹豫要不要指出。

反之,如果无论发生什么错误,都不需要承担后果或进行反省,没有任何担当,那可能又会出现以下情况。

  1. 同样的错误可能会一再发生。
  2. 小错没有被及时制止,或者没有引起足够重视,最终导致酿成大错。
  3. 做事仔细的人会觉得不公平。自己为了安全起见,每次代码改动都写很多单元测试,每个项目都反复测试和预防问题;但是别人的草草而就导致错误百出,却因为显得进度更快,反而被认为更有效率。

那么,对于工作中的错误,尤其是 Bug 导致的错误,我们应该采取什么态度和措施呢?

第一,追究责任,但不是惩罚。“知其然,并知其所以然”,搞清楚在什么场景下,什么样的 Bug 引发了什么样的错误。相关人员应该尽最大的可能去做好善后工作,并思考如何避免下次犯同样的错误。

第二,对事儿不对人。在这个追究的过程中,重点在于怎么改善流程、改进制度,来避免同样的错误,而不是指责员工不应该怎么样。如果相关人员已经那么做了,为什么这个错误仍然没有及时被发现和制止?

第三,反复问“为什么”,从根本上发现问题。错误为什么会发生?有些 Bug 可能只是显露出来的冰山一角。

举一个假设的例子,因为小王的代码改动影响了小李的代码,让小李之前实现的功能不对了。在这种情况下,我们首先要问:

  • 为什么小李代码功能不对没有立马被发现?

答:因为小李当时的测试用例没有覆盖这种情况。

  • 为什么小李的测试例不完整?

答:因为这个地方的测试需要 mock 一个服务的返回值,但是这个 mock 的值并不是真的服务器端的返回值,所以测也测不出来。

  • 为什么要去 mock?

答:因为我们的测试系统框架不够完善。

这样反复问,反复想,就能找出根本上值得改进的问题,而这样的结果和受益,比惩罚犯错儿的人要好得多。

第四,员工关系的建立也很关键。需要培养的是大家相互信任、互帮互助,为了共同的目标努力的氛围,而不是一种不安全感。这种不安全感可能是自己不够自信,害怕犯错;也可能是对他人漫不关心,或是对其代码质量有怀疑。只有大家都相信,找出问题的根本目的是解决问题,避免问题再发生,才能建立一个不断反思、不断学习、不断进步的良性循环。

最后给你留一个思考题, 这也是现实生活中我多次听说的事故。如果你是一家公司的技术主管,团队里的一位工程师因为误操作删除了线上的用户数据,这时候你又发现,上个月数据的自动备份因为某些故障停止了,现在你该怎么办呢?

文章被以下专栏收录

    微信公众号同名,欢迎投稿。全平台约20万开发者关注,会员来自全球十多个国家和地区,拥有十多个线上线下技术社群,向本专栏投稿即默认发布到Python中文社区全平台。GitHub:github.com/pycn