研发出了生产事故，到底要罚钱不？

关注

原创最新推荐文章于 2026-07-23 16:26:29 发布 1.3k 阅读 AI 写同款· GEO 优化 ›

解读乔新亮的《看透本质：研发出了生产事故，到底要不要罚钱？》我喜欢阅读，看到让我拍案叫绝的文章，内心就会特别汹涌澎湃，但是我知道这种碰撞是肤浅的，因为学习金字塔原理告诉我们，收听只不过吸收5%，我非得写点什么不可，好让自己更好的领会和消化，也是对每一个让我激动不已的作者致敬。乔新亮简介：彩食鲜副总裁兼CTO、前苏宁科技集团副总裁、TGO鲲鹏会荣誉导师导引　　这篇文章给我最大的触动是切入点很小，但是通过逻辑矛盾处，启动思考，层层深入，不断反思和推... 阅读详情

蓝色关注，回复“9”获取个人如何快速成长、架构、程序员或产品经理能力模型、技术管理等资料。

见字如面，我是军哥。

最近有一位读者跟我抱怨，他最近弄一个线上事故，造成系统宕机 20 分钟，并造成公司损失 10 万左右人民币，公司直接罚了他 2000 元并降薪一档，他觉得平常加班就多，一个人干两人的活，公司也一年多没涨薪来，这还罚款非常不好受，询问我这公司制度合理么？

我觉得这个问题很不错，决定就此写上一篇，各位请跟我来！

— 1 —

罚钱真的有用么？

据我所知，大部分的 IT 公司都会对一定级别事故的当事人直接罚钱，但这真的合理么？这样真的可以让员工少犯错么？

为此，我和多位设置惩罚制度的 CTO 聊了聊，他们认为，研发出事故的本质原因是缺乏责任心或能力问题，与其搞那么多复盘、整改，还不如直接罚钱，这样犯错的人下次就会小心了。

但是责任心或能力问题，真的是事故的本质么？

老实说，罚钱确实可以在一定程度上解决问题，但是会带来诸多副作用，比如会导致员工工作消极，多个部门之间互相推诿责任。

最后也请管理者换位思考一下，你自己能保证系统一定不出事故么？我觉得技术再牛逼的人也不敢打保票吧。我们能做的是降低事故的频率和事故快速恢复的能力。

我们进一步思考，出事故的原因，我觉得如下两种可能性居多，第一种是核心系统，因为业务复杂牵涉的上下游系统多，第二种是团队核心人员离职，新人老人交替期。

对于第一种，核心系统需求多负责度高，迭代速度也快，出问题就多，这就变成了多干多错，而对于一些边缘系统，出问题就少，就算出现了问题也没几个人关心，核心系统因为出事故就扣钱，这本质上就不是责任心或能力问题。

对于第二种，我认为是人员流失，工作没有做好交接导致，新人接替老人工作，会没有责任心么？这显然也不是问题的本质。

找不到事故的本质，还用罚钱这种暴力的方式，根本无法彻底解决问题，事故依然还会光临。

果不其然，上文说的多位设置惩罚制度的 CTO 坦言，公司事故一直有，偶尔还很多，但是感觉除了罚钱也没什么有效办法，于是我把压箱子的干货拿了出来，请看下文。

— 2 —

我亲身经历的事故系统化方案

我记得 2016 年饿了么线上事故频发，比如高峰时间不能下单，没多会就有一些大V 微博或朋友圈投诉，业务部门也会抱怨系统太烂，还拿那么高的工资，竞争对手也会因此大肆做文章，这对于我们技术部门是脸上无光的，CTO 因此被 CEO diss 也是家常便饭。

我当时是多位技术总监之一，在 CTO 的周会上，我要承诺把部门稳定性搞好，还要思考提什么建议，可以提升公司其他系统的稳定性。

我还记得，当时技术团队近千人，几百个系统，一天上线百余次，公司里有核心系统也有边缘系统，按前文所说，有的核心系统故障频发，有的系统故障少一些，但这些故障在 CEO 眼里都是技术部门的问题，都是 CTO 要搞定的。

后来经过技术和产品核心团队沟通达成一致，关于事故处理，我们不用大多数公司罚钱这种形式，我们系统化（事故前、中、后）的思路如下：

1、对公司任何员工，不管是基层还是总监都不要直接罚钱，但是纳入部门负责人绩效考核之中，对于基层员工事故只作为绩效参考作用。这里有一个先决条件，每个部门的系统稳定性会提前三个月收集数据，比如 A 部门三个月内有 1 个P0，那么对于 A 部门未来三个月最多只能有 1 个 P0 事故，这种考核的好处就是每个部门跟自己比，部门之间有了公平性。

2、每个部门根据自己的开发语言特性情况，整理出系统架构、数据库设计、安全等军规，我部门当时军规，请公众号后台回复 “111” 获取。

3、犯错的人必须带头复盘事故，部门负责人必须参与，复盘需要只对事不对人，一经发现对人攻击直接警告处分，犯错人分享失败的教训，其他部门或者核心骨干必须参与学习。

4、一个事故需要有彻底的解决方案而不是临时方案，必须有整改的截止时间，并且有专人来检查是否如期修改，还要保证同样的问题不能再犯错，最后对于复盘的事故要留存好文档，让不在场的同事或者新人都可以学习这些宝贵的经验。

5、容许大家犯错，但是比如新技术或新业务特性的上线，需要先小规模灰度再放量然后全量的过程，大家都必须遵守这个 SOP。

6、根据事故定期统计，给各个技术部门颁发“坚若磐石奖”和“不堪一击奖”，这些奖还会公示并邮件发送技术产品部门所有人。

通过以上六条，每个部门的事故降低了，稳定性提升了，所以 CTO 的日子就好过多了，大家的日子也就好过了。

写在最后

以上，是今天文章的全部。

回到读者开始的问题，我相信读者（你）心中已经有了答案。

如果你是公司的技术负责人，那么恭喜你，你可以按我的办法实施起来了，如果你不是技术负责人，给公司技术老大提提建议，顺便把这篇文章转给他。

关于我：军哥，前饿了么、贝壳技术总监，乐于结交朋友，也欢迎加我微信与我做朋友（公号输入框回复“w”即可），朋友圈做个点头之交！

另外军哥写了一些，关于个人如何快速成长、深度思考、程序员或产品经理能力模型、架构，OKR干货，技术管理等电子书资料，公号后台回复 “9”获取，不谢。