Bug引发事故，该不该追究责任？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 为什么要去 mock？

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

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

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

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