程序员背锅？这6个产品经理的“低级错误”，正在让公司损失千万！

在IT行业，事故是每个从业者都可能遇到的挑战。这些事故不仅会给企业带来直接的经济损失，还会对团队士气和项目进度产生深远影响。本文通过作者亲身经历的六个真实IT事故案例，详细剖析了事故发生的背景、原因、处理方式以及最终的损失，希望能帮到大家。

———— / BEGIN / ————

正所谓吃一堑长一智，IT事故会让企业蒙受巨大的损失，给开发团队沉重的打击。

从另一方面看，也是产研深刻学习的绝佳时机——抛开打击，反思问题，我们会明白有些看似无用的规范、流程的价值。

产品经理虽然不写代码，不直接搞技术，但事故反映出的对于项目管理、流程管理、人员管理和技术规范的要求值得我们思考、借鉴。

我例举了6个经历过的生产事故，我会从事故、损失、原因、处理方式4个方面来阐述。

事故一

我第一次亲身经历IT事故，是在大客户现场，该大客户是一家精品酒店，坐落在5A级景区边上，房价每晚要1000元。

当时这家酒店正好要做系统升级，我就随着运维同事一起前去调研学习，没想到升级当晚系统宕机了一段时间，导致部分订单丢失。

第二天早上，酒店总经理来到我们客房里，我（一个产品新人）、运维小哥、酒店总经理，三人面面相觑。

酒店总经理在旁督促，希望想尽一切办法找回订单，运维小哥满眼愁容地想办法，我立在边上啥忙也帮不上。

损失：酒店损失约5000元收入（约5个订单）

问题原因：系统初次升级不稳定。

处理方式：

• 系统重新启动后正常运行。

• 丢失的订单大约20个，补救措施则是酒店人员通过历史订单记录和员工的回忆，回补了十几个订单，最后丢失的订单约5个。

这个问题在IT事故里只能算“小问题”，可给我却留下了深刻的印象，尤其是当事情发生时那种我无能为力的感受，令我暗暗下决心要提升个人能力，以便在关键时刻能有所帮助。

随着时光流逝，我碰到的IT事故也越来越多，五花八门；有些事故难以避免，更多的都是“人祸”造成的，事故经常出现在系统发版、老代码维护、技术人员不规范操作的情况下。

事故二

一个常规的CRM系统版本功能发布后，当晚风平浪静，第二天上午9:30分左右，系统部的电话突然炸锅，IT报修的电话都被业务部打爆了。

业务经理很着急：“开工30分钟了，CRM一条客户名单都没下发，几百人的电销团队干坐在职场”。

当时，昨晚熬夜发版的IT开发还在家补觉，上午开工过了3小时才修复问题。

损失：公司损失约2000万的贷款业绩（业务部平均每天5000万贷款业绩，当天上午没有业绩产生）

问题原因：此次发版功能中，有一个“上线新渠道”的需求，这个新渠道并不是新的，而是原渠道的客户通过“新渠道”来标记，使同一个渠道来源的客户可以在系统上区分开来，走不同的销售流程。

然而，技术人员理解成了“上线新渠道，替换原渠道”，因此，系统上线后就把“原渠道”干掉了；而上线当晚的生产验收时，产品、业务同事只验证了“新渠道”，客户名单下发自然正常的，可第二天渠道过来的客户名单实际都还是“原渠道”的，CRM系统匹配不上，就导致了客户名单无法下发。

处理方案：

1. 立即回滚代码，先让业务团队作业。

2. 紧急修复渠道规则，通过临时版本补上需求。

3. 问题定责，产品和技术各承担50%的责任，被领导记在小本本上。实际情况是：产品说技术理解错了，技术说产品没讲清楚——沟通理解差异造成的老套剧情。

事故三

年底了，财务同事熬夜对账，发现公司账务少了60万，于是拉出全量账单核对；半宿过去，细查后发现有一个账户没有实际的充值记录，却提现了60万。

于是，立即找技术经理核对问题发生原因。

震惊的是：同样有问题的账户还有好几个，总共被异常提取的金额达到300万；公司立即报警，连夜召开高层管理层紧急会议，公司进入预警状态。

敏锐的同事立马猜到始作俑者是谁了——清结算系统的技术负责人H。

H沉迷氪金游戏，以前还常向同事借钱，但不知从何时开始，H忽然手头阔绰起来，手机、手表都换成了最高配的苹果设备，不坐地铁还买了奔驰E300，每天游戏氪金好几千。很多人以为他家拆迁了。

很快警方就带走了H，对自己所作所为供认不讳。

损失：300万

问题原因：H手法也并不高明，他利用了两个漏洞：一是他可以直接修改数据库中的用户账户余额，二是他发现提现有个免审核白名单（在白名单的账户提现无需经过财务审批），而他也有修改白名单的权限。

H为了掩人耳目，他先用母亲的身份信息注册了一个账户，每个礼拜“提款”几万到他母亲银行卡。

偷的钱越多，开销越大，H开始不满足每个礼拜几万块，再联合了几个朋友故技重施，而“提款”金额大了很多，最多一次性60万。

以前，H老鼠偷米式的盗取，财务没有发现，最终因为他的贪婪，东窗事发，现在锒铛入狱。

处理方案：

1. 报警把人带走

2. 加强数据库权限管理，废除提款白名单

3. 技术领导管理失职，扣一个月绩效

事故四

一个深夜，几百个大货车被卡在高速收费站出口，原因是ETC被拉黑，无法扣款。

深夜赶路的货车司机又急又气，骂骂咧咧的打电话找公司、找ETC服务商解决问题，但当晚无法解决ETC被拉黑的问题。

最后，司机只能自掏腰包支付通行费，不仅无法享受ETC通行便利和优惠，还造成了交通拥堵。

损失：约20万（2万多张ETC通行卡被拉黑，外部影响极为恶劣；商务部倾巢出动，给予客户赔偿）

原因：技术人员D为了处理一个小问题，私自修改代码，未经测试、验收，私自发布上线。

D原先是想偷偷修复这个小问题，可他盲目自信，以为自己的代码逻辑没问题，违反代码发布规范，上线后触发了“拉黑”代码逻辑，导致系统误将2万多张ETC卡拉黑。

处理方案：

1. 立即回滚代码，并将误拉黑的ETC卡解黑；

2. 商务对大客户一个个登门道歉，赔偿损失，产品让利；

3. 技术部加强代码发布流程规范；

4. 公司原本打算让D“走人”，后念在其为公司工作多年，降职降薪处理；其上级领导管理失职，扣一个月绩效。

事故五

某集团的报修电话炸了，门店纷纷表示客人无法下单，系统里没有订单进来。

技术负责人一看报错，数据库里的订单表被“锁”了（无法新增、修改订单，意味着客人无法下单，公司收入中断）！

原因：前一天晚上，新上了一个统计订单的数据汇总报表。然而，开发的技术方案是“直接查生产订单表”，每天凌晨去查。

这块功能代码是晚上8点发布的，发布完开发人员也没有试跑一遍就“下班”了。

此前测试环境没有发现该问题，因为测试环境的数据量跟生产完全不是同一个级别，测试环境只有几万条人造的数据，生产环境是上亿条真实数据。

此外，公司的测试人员能力有限，无法模拟生产造出这么多的数据。

设计该技术方案并负责开发的是一位刚入职两个月的外包工程师。

损失：约50万收入（2个小时无法下单）

处理方案：

1. 数据库解锁，新报表功能下线

2. 连夜开除外包人员

3. 规定所有报表类需求不能直接访问生产数据库

事故六

一个周四早上，我迈着轻松的步伐来到办公室，总监问我的企业微信怎么样？我说“正常的呀，咋了？”

然后，总监告诉我他“被离职了”——原来，前一天晚上企业员工同步出了问题，导致大约2000员工在系统上“被离职”，导致下游企业微信、SSO、业务管理系统均无法使用。

这其中最严重的是企业微信无法登录，员工日常所有的同事沟通、聊天记录、内部材料都在企业微信上，企微没了意味着大部分事情都做不了。

原因：公司为了降低成本，采购了新的人事系统替换老的人事系统。

事发前一天，新人事系统有发版升级，事发当晚，公司的员工数据同步服务（该服务将人事系统的员工数据同步给企业内部各个系统，包含企业微信）升级。

夜间凌晨，员工同步服务的代码判断2000人“已离职”，并同步企微，随即企微执行了员工离职操作。

员工同步服务的离职代码本是数据梳理迁移时用的“一次性代码”，本应注释，负责的开发人员Z用完后一直放在生产环境。

可是怎么触发的离职规则呢？

技术负责人查了一天的代码逻辑，发现并不会主动触发该规则，只能是上游人事系统触发的；可开发人员Z又没有记详细日志，因此，无法得知具体上游同步了什么数据。

新人事系统那边，则声明前一天上线不可能导致员工离职，其提供的日志也查不出个原由。

因此，此案至今悬而未决。

负责员工同步服务的开发人员Z的是外包。

损失：60万，找腾讯恢复企业微信的数据25万，2000人半天无法正常办公的损失约35万

处理方案：

1. 找腾讯企业微信数据，包括“被离职”员工、聊天记录、文件

2. 一次性的“离职代码”注释

3. 企业扣除外包公司合同费用5万（外包公司便给其下两位驻场的外包人员停发工资，其中之一的当事人被辞退，另一个因被停薪便主动离职）；此外，两位IT负责人当月绩效为0，再罚5000

总结

跟历史一样，哪怕经历了这么多问题，系统也永远无法保证不会出问题。

在信息技术、大数据、AI日益贴近普罗大众的今天，对于技术人员来说，应学会与系统问题相处。

这不是说面对复杂的系统问题只求心理安慰，躺平应对，而是要转变思路：不追求完美的结果，去追求完美的流程，尽量避免问题反复发生，以及有问题发生也可以及时响应处理。

• 功能开发前做好技术方案评审，要由高级的技术经理决定的技术开发方案，而不是普通开发人员

• 标准的上线发版流程，开发提交、测试通过报告、技术经理审核、上线生产验收这几个步骤一个都不能少

• 凡发版，必要有回退方案

• 凡涉及系统切换、数据迁移，必做相关数据的前后备份

• 技术人员的权限管控，数据库修改权限、代码发布权限要按人品和资历分配，严禁账密共享

• 如企业用外包开发人员，不建议开放过高权限，其编写的代码逻辑要检查

最后，作为产品经理，应与技术充分沟通，对技术表示理解；有些问题技术本来不会犯，但是产品、业务催的太死了，技术被赶鸭子上架，那做出来的东西就会丢三落四。

假如以上这些都做到位了，还是发生了生产事故，那也只能听天由命、尽力找补。

毕竟只要有IT系统，就必然会有IT事故。