如何对待工程师团队犯错误

如果针对工程师团队犯的每一个错误都锱铢必究，以罚代管，那也就不需要这种管理团队了。罚，谁不会罚？！管，你会吗？！

一.犯错误是什么状态？

干活的才会犯错，不干活当然不会犯错。

2002年我刚做技术总监，依托于微软的COM+服务做分布式服务治理，面向全国提供一项移动数据企业级服务，每天就像坐在火山口，如履薄冰如临深渊。

你说我有没有责任心？肯定是有的。每天都在上下班路上闭着眼复盘代码和架构（那时候C++程序是基于COM+和MSMQ服务的松散耦合多服务多节点协同模式），脑海中就像《后翼弃兵》里一样打开了一屏屏代码和日志的视图上下翻动，绞尽脑汁想有什么可以优化的地方，还有哪些地方可能会引发内存泄漏或线程安全。

你说我有没有压力？当然有啊。恐惧和焦虑伴随着我，让我惧怕听到短信告警声和电话铃声。手机里常备一条上行短信指令，随时随地准备上行短信，远程重启核心服务。

你说我态度端不端正？非常端正。服务有隐患，我特别愿意承认，特别愿意改。我曾经说过，实事求是，是工程师团队的最低道德要求。但在没有更先进的架构级解决方案出现之前（比如十年后出现的Redis、Dubbo、Docker等史诗级解压作品），我只能在原有方案基础上修修补补。

有此亲身体会， 我遇事都是相信除了极个别人之外绝大多数工程师都是荣誉感很强的，也是非常不愿意看到事故发生的，更会在第一时间开动脑筋定位和解决问题，用不着领导催。

二.如果换成是我，我会犯这个错误吗？

有一次线上严重漏测造成了比较大的影响，我该责怪谁呢，产品、研发、测试？

我把这个项目的测试用例拿出来仔细看了一遍，把测试用例评审会议纪要又都翻出来看了一遍。最后我的结论是， 如果把最后的看门人换成是我 ，我编写的测试用例，还与产品和研发都评审了几轮测试用例，在这种情况下也没有能查缺补漏提前发现，那说明只能亡羊补牢，补上测试用例，用测试用例来确保每次更新迭代都能复核这个路径。还能怎么办？

态度有问题吗？

态度有问题，可以处罚。

态度如果没有问题，那就是能力有问题。

能力有问题，那也是领导的管理问题。

板子应该打到领导的屁股上，要么是领导没有预见性，要么是领导没有输出工具，要么是领导没有培训到位。

领导没有预见性怎么办？换领导啊。预见性这种东西，真的是天赋。

没有输出工具怎么办？亡羊补牢为时未晚，赶紧总结方法论，全面自动化。

没有培训到位怎么办？从这一刻开始，认认真真逐字逐句地死磕RCA报告制度，让每一次错误变成有意义的共同记忆。

如果这些都做了，那追究责任的话，也只能“压实”分管领导的“主体责任”了。

三.技术归零 管理归零

出了事故，处罚谁？

罚基层员工？

罚部门主管？

罚分管高管？

罚之前先搞清楚目的。

罚是为了不再发生，对吧？

可在IT生产上，往往是你要是知道这么会死你就不会死，往往是死了才知道原来还有这种死法～

面对错误，有两种领导。

第一种，成功领导。成功领导会问你还需要什么资源支持，喜欢从错误中吸取教训，举一反三，构筑内功，绝不再犯。

第二种，普通领导。而普通领导则既不能技术归零“定位准确、机理清楚、问题复现、措施有效、举一反三”，也不能管理归零“过程清楚、责任明确、措施落实、严肃处理、完善规章”，反正就是员工你不对，你错了，你疏忽大意，你搞砸了，你要对此负全部责任。

有一年在一个重要节日的晚高峰，我们的验券核心服务突然出现严重超时问题，不仅仅是我，连业务方都派了代表蹲守在排查人的旁边，大眼瞪小眼，你看我我看你，但是经过了两个多小时的排查，各种服务重启无效，代码看了一个遍，始终找不到问题原因。在排除了所有的不可能之后，无论剩下的多么难以置信，那就是真相。终于发现是偶然间把测试环境的 MySQL 数据库端口号配置带上了线。因为测试环境的服务器资源紧张，所以验券的核心数据库 MySQL 端口号不是默认的 3306，但两三年来他们一直如此，测试环境和生产环境就是不一样，从未因此出错。这回把错误的端口带上去之后，生产环境的验券组件连接数据库超时之后进入了另一个业务逻辑（这段逻辑还包在一个C++库里，多年都未动过，所以第一时间没有怀疑到这里），倒是也能验券，但损失了等待超时的时间，从而让商家无法容忍。

怎么办？

后来我要求研发协作平台必须实现一个特性： 上线的时候必须做到一包（注：打包的包）到底，一镜 （注：镜像的镜） 到底 。具体指的是，一个代码分支对应的一个包（或镜像），可以流经测试环境，直接上生产环境，一路穿行，全程无需手工干预，无需手工改配置文件，无需重新打包。 一镜到底，就要求配置与代码分离，与环境有关的配置不能存储在工程的配置文件里。

我再也不相信测试通过后的二次打包。一次两次上线可能不出错。一千次一万次上线呢？一镜到底是保证我们不再次死于非命的保命良方。而且系统即流程，要把这个最佳实践做实到系统里。

四.小结

言而总之，总而言之一句话，压实分管领导的主体责任，同时让灾难成为团队的宝贵财富而不仅仅是罚款和心理负担。