“人非圣贤，孰能无过？”技术人员也是人，因此编程过程中难免出 Bug，出了 Bug 系统就会出问题，出了问题系统就会宕机。那么，Bug 引发的一连串事故，该不该追究责任，又如何去追责呢？
今天我就和你聊聊 Bug 和责任的问题。
记得有一次，一个国内的访问团来公司参观。在交流的过程中，有人问：“在你们的工作中，工程师的 Bug 或者失误引发的问题，会不会被追究责任，会不会扣工资，会不会被开除？”
当时我很诚实地按照实际情况回答说：“不会。”
这个人又继续问：“那出了事故没有任何惩罚，不会有问题吗？”当时，我围绕着员工的素质、自觉性和责任心进行了回答。后来再次思考这个问题，我越想越觉得有意思。
我在 Airbnb 负责支付和交易业务，这意味着大部分的错误都等价于真金白银。无论是从用户那少收钱，导致公司亏损，还是从用户那多收钱引起法律或者合约的纠纷，只要跟钱沾了边，都不是小事情。
俗话说 “常在河边走，哪有不湿鞋”，各种因为代码问题引起的麻烦也是屡见不鲜。那么，在Bug引发问题的情况下，怎样处理才能最大程度上保持团队的主动性、责任感和执行力呢？
我们先来假想两种极端的情况：如果每个错误都会受到惩罚，会怎样；如果所有的错误都没有任何追究和跟进，又会怎样？
假如每个错误都会受到惩罚，不难想象，以下情况一定难以避免。
- 大家都怕闯祸，所以风险高的事没人做，或者总是那几个靠谱的“老司机”做。没有机会处理这种复杂情况的人，永远得不到锻炼，也无法积累这样的经验。
- 如果有人搞砸了什么事情，会因为担心承担后果而推卸责任，从而尽可能掩盖错误的坏影响，不让人知道。
- 如果别人犯了错，会觉得不关自己的事。
- 指出别人的错误就会导致别人被追究责任，因此看到有问题也会犹豫要不要指出。
反之，如果无论发生什么错误，都不需要承担后果或进行反省，没有任何担当，那可能又会出现以下情况。
- 同样的错误可能会一再发生。
- 小错没有被及时制止，或者没有引起足够重视，最终导致酿成大错。
- 做事仔细的人会觉得不公平。自己为了安全起见，每次代码改动都写很多单元测试，每个项目都反复测试和预防问题；但是别人的草草而就导致错误百出，却因为显得进度更快，反而被认为更有效率。
那么，对于工作中的错误，尤其是 Bug 导致的错误，我们应该采取什么态度和措施呢？
第一，追究责任，但不是惩罚。“知其然，并知其所以然”，搞清楚在什么场景下，什么样的 Bug 引发了什么样的错误。相关人员应该尽最大的可能去做好善后工作，并思考如何避免下次犯同样的错误。
第二，对事儿不对人。在这个追究的过程中，重点在于怎么改善流程、改进制度，来避免同样的错误，而不是指责员工不应该怎么样。如果相关人员已经那么做了，为什么这个错误仍然没有及时被发现和制止？
第三，反复问“为什么”，从根本上发现问题。错误为什么会发生？有些 Bug 可能只是显露出来的冰山一角。
举一个假设的例子，因为小王的代码改动影响了小李的代码，让小李之前实现的功能不对了。在这种情况下，我们首先要问：
- 为什么小李代码功能不对没有立马被发现？
答：因为小李当时的测试用例没有覆盖这种情况。 - 为什么小李的测试例不完整？
答：因为这个地方的测试需要 mock 一个服务的返回值，但是这个 mock 的值并不是真的服务器端的返回值，所以测也测不出来。 - 为什么要去 mock？
答：因为我们的测试系统框架不够完善。
这样反复问，反复想，就能找出根本上值得改进的问题，而这样的结果和受益，比惩罚犯错儿的人要好得多。
第四，员工关系的建立也很关键。我们需要培养的是大家相互信任、互帮互助，为了共同的目标努力的氛围，而不是一种不安全感。这种不安全感可能是自己不够自信，害怕犯错；也可能是对他人漫不关心，或是对其代码质量有怀疑。只有大家都相信，找出问题的根本目的是解决问题，避免问题再发生，才能建立一个不断反思、不断学习、不断进步的良性循环。
最后给你留一个思考题， 这也是现实生活中我多次听说的事故。如果你是一家公司的技术主管，团队里的一位工程师因为误操作删除了线上的用户数据，这时候你又发现，上个月数据的自动备份因为某些故障停止了，现在你该怎么办呢？
精选留言
2017-11-16 19:38:20
2017-11-15 09:16:22
首先，解决问题。
对外的事情永远应该放在首位解决，首先要考虑的是用户数据没有了怎么做补救。如果实在没有办法挽回数据了，考虑如何将损失降到最低。或者以某种方式补偿用户。用户的利益永远是第一位的。
其次，追究责任。
误操作也好，没有自动备份也罢，肯定需要有人来承担责任。没有责任人的事故很难挖掘到深层次的原因。错了就是错了，就是需要承担起这份错误带来的事故责任。
最后，流程优化。
人和机器最大的不同是人是具有主管能懂性的。机器可以严格按照程序执行，没有喜怒哀乐，但是人不行。谁都会有心情沮丧的阶段，也会有狂喜的时候，这种情况往往就容易犯错。所以如何规避，是不是可以从流程上去杜绝错误出现就是事后需要思考的。那前面的例子，如果删除操作是高危操作，是不是可以制定需要授权，是不是可以规定同时需要多人确定。自动备份是不是可以制定一些预警机制？
个人一些想法，抛个砖，引玉。
2017-11-15 17:34:34
2018-04-27 11:32:19
首先，先想办法把损失降到最低，是否有其它备份，是否有其它途径重新生成数据等。
其次，作为技术主管，对外主动承担首要责任，不要把责任推给下属。
第三，用why-why法去找深层次原因，就是不断的问为什么，找出根本原因。
第四，针对上述的原因，一个个找解决方案，每个解决方案都要有责任人和时间点，避免重复再犯。
第五，针对事故进行复盘总结，对事不对人，重点不在于惩罚，而是在于吸取经验，总结教训。
2018-02-27 11:33:44
我有两个疑问:
1，例子中最后推敲到是测试系统不完善，可是如果要完善测试系统需要大量的资源，公司目前资源紧张，协调资源很难，是不是应该在这种情况下顶着压力申请资源改进测试系统呢，是不是每次代码合并都进行一次review更简单有效一点
2，留的题目中，我们继续使用上面例子中追问自己的思路，数据为什么没有备份，没有备份，为什么没有发告警信息呢，因为运维系统不完善。假设运维系统完善了，发告警了，可是运维同事忽略了呢。
所以我觉得有时候人与系统或者流程之间有个均衡，资源充足的公司不断完善系统，让每个人都成为螺丝钉，资源不充足的公司，要培养人的习惯，管理者要把更多的精力放在人身上。
2017-11-15 19:06:53
以前创业碰到很多这种问题，重大事故大都是有流程，不执行，偷懒所致，因为越是不确定的东西反而自己更重视，反而熟悉的问题总错，所以还是要细心。个人非常不容易罚款，当时CEO逼着订下罚款的细节，我说👌，权责利要匹配，也一并订下奖赏的条款，不说话了……
2017-11-16 23:26:50
2017-11-16 17:44:38
1.自身角度，这种问题不会同步出现。首先能够操作正式服务器后台数据的都是经验丰富的主程级别，出现概率极低。就算出现了，我们通过数据库日志也可以恢复数据，把损失降到最小。如果日志损坏了我们还可以通过最多24小时自动备份数据恢复。我相信不会同时都出问题。
还有就是需要及时上报让运营考虑应急预案，让客服做好疏导和安抚工作。必要时候给予出现问题用户一定补偿。
2.如果是很不规范创业公司，开发人员误删了用户数据（我们按最坏的考虑数据清空了），又没有备份，立刻停止任何操作，及时上报问题，立刻切断外网用户的访问，如果数据价值非常大可以请专业数据恢复公司恢复数据，运营、客服都要协调动起来，讨论出善后方案并高效执行。
对于第一种造成损失较少，但需要误删者解释清楚操作细节和原因，这种一般是操作规范的问题，以后严格按规范操作数据，然后需要向公司公开道歉，特别是增加了运营和客服工作量
对于第二种造成损失很大，是操作的问题，也是数据库冗灾没有做好，更是管理上的问题。需要深刻反思反省，加强冗灾能力同时让公司加人手和资源吧。通过这件事老板也不会不舍得投入了（曾见到过创业公司不重视服务器资源投入的问题，还有就是找靠谱的开发人员和技术主管）。
2017-11-15 08:49:32
2017-11-15 12:36:08
2017-11-15 09:12:04
不过针对丢失用户数据这件事，很有可能数据追不回来了，这时候给用户相应的补偿很重要（包括但不限于发优惠券，送套餐，营销召回等方式），一方面达到挽救损失，另一方面直面问题，让用户降低对平台的不信任。当然，最重要的是，得解决数据丢失的问题，定期检查，灾备演练，防止这数据丢失的事情再次发生。
2017-11-15 12:01:56
2017-11-15 09:18:37
做完这些，就要开始“追责”了，为什么发生，怎么发生的。比如，是不是权限管理有疏漏，是不是生产安全操作原则没有普及，技术人员是否疲劳工作等。
2017-11-30 16:02:27
其次，组织复盘。从组织结构、工具、流程规范等方面思考，找到根本原因进行解决。另外，如果出现人员方面的责任心问题，需要追求责任，给予惩罚。
2017-11-15 10:41:12
朱赟可否每周做一次复盘？回答一些大家的问题，另外也让大家知道你看问题的视角，强化记忆和学习。帮助一起提升。
当然，如果直播就更赞。（色）（色）
2020-03-13 23:11:06
首先分析定位故障后，想办法恢复对外服务，含技术修复及业务应急，通过双活系统、灾难备份系统、最近一次可用的数据备份、其他关联系统的数据、大数据平台（或数据仓库等二线数据）、本系统的日志等方式、业务操作打印流水等想办法恢复数据。如果造成了数据丢失，需要配合业务方面协商业务应急处置办法，出具公告。在再次对外服务前，对当前的数据副本做好完整的备份；当恢复后的数据从业务逻辑、数据逻辑等方面进行充分检验，避免脏数据造成二次事故。
其次关注修复数据的实际运行，抢修期间即便采取了很多防范二次事故的措施，但由于时间非常紧急，很可能万中漏一，发生抢修数据不完整，或者约束关系检查不完整，或者其他各种问题，需要及时关注系统运行尤其是数据一致性等问题。
再次，系统性分析事故原因分析，例如为何会发生误删数据，是否没有严格执行权限控制和双人会同要求？ 相关维护方案是否没有经过审批？删除数据的高危操作是否没有被有效拦截？变更操作之前是否没有按规定执行备份？数据备份失效为何没有告警？是否缺失必要的异构备份机制？
最后充分吸取教训，围绕生产运行、变更维护、数据备份等工作的流程机制、系统配置等进行优化，通过测试环境实战模拟演练检验有效性，从机制上保障生产，尤其是数据的安全性。
2018-02-26 10:15:02
2017-11-15 18:45:57
然后完善自动备份程序和操作流程，杜绝类似问题的发生。
最后问题追责。技术主管是第一责任人，操作数据之前未进行数据备份，未定时检查数据备份是否正常。运维人员是第二责任人，未定时检查自动备份程序的稳定性。工程师是第三责任人。
2022-03-18 21:35:36
1、不做就不会错。大家都怕处罚，每次处罚都是涉及钱，很多人不敢去做改动，能轻微处理就轻微处理，有事情就要各种管理升级，没人愿意去主导事情，都在等着上面领导决策，没有人主动推动流程优化，一有问题就把“领导说的”抬出来。标准铁饭碗模式。领导做错了，就没多少影响，如果员工做错了，一定会被大范围当作典型案例批斗，并且扣钱。
2、问题追溯并改进。我曾服务过一个做Linux下软件开发的公司，遇到某个软件bug，就会根据影响的优先级，决定是分配多少人参与问题排查和处理，处理后会反过来思考优化团队内的平台和工具，优化团队内流程方案，让流程规范落地到代码工具，减少人的错误。比较可惜，他们公司销售人员太少，已有的很强的销售人员也被大企业挖走了，在我们本地没能活下去，现在被外包公司打包收购了。
3、员工关系。互相帮扶的我见到的挺少，为了绩效考核，为了个人不被替代，为了让自己的技术看起来更强，有的同事会把经验留存在自己的脑子里，不做分享，也不愿帮同事，还能找出各种看起来很合适的理由。团队看似是团队，实际是各自为营，互相是传递数据的黑盒子，离职率也是没低过。
2019-08-12 18:13:24
事后：复盘，输出后续优化改进，避免下次类似问题