您最严重的生产错误是什么?
您最严重的生产错误是什么? 这可能是您在实时系统中参与制作或解决的任何错误。
[将我的回复移至答案]
What was your most serious production bug? This could be any bug you contributed to the making of or solving in a live system.
[moved my response to the answers]
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
我的项目是我毕业后的第一个项目,是一家软件公司的大型销售补偿系统。 我们在最终求和例程中存在一个错误,该错误会尝试从下一次薪水中减去任何自有资金。 在某些情况下,如果追溯计算增加了上个月所欠的金额,则借方将被记录下来,并且永远不会从下一个薪水中减少。 第一个月的价格可能是 3.23 美元,下个月就会增加到 6.46 美元。 你可以看到这是怎么回事。 尽管我们很早就听说过一些用户投诉,但我们将其视为“用户错误”——销售计划很复杂,任何人都很容易误解正确的支付金额。 但几个月后,失踪的资金大得不容忽视——超过 2,000,000 美元的工资支票未支付。 代码修复很简单,只需对数百名员工进行数月的工资计算即可,但并不复杂。
Mine was on my first project out of school, on a large sales compensation system for a software company. We had a bug in the final summation routine which would attempt to subtract any owned money from the next paycheck. In certain situations, where a retroactive computation increased the amount of money owed from a previous month, the debit would be recorded, and then never get reduced from the next paycheck. What might start out as a $3.23 the first month would increase to $6.46 the following month. You can see where this is going. Although we heard of a couple of user complaints early on we dismiss them as "user error" - the sales plans were complex and it was quite easy for anyone to misunderstand what the correct amount was to be paid. But after a few months, the monies that were missing were too large to be ignored - over $2,000,000 in not paid out payroll checks. The code fix was easy, going over months of payroll computations for hundreds of employees, not so much.
我在一个电子商务网站工作,其中客户数据以 CSV 转储形式从旧后端系统提供。 我们只有一个样本数据集可供使用(尽管多次请求完整数据集),因此我们第一次看到完整数据是在实时网站上线的那天早上。 CSV 文件中所有字符串均被引用,但数字未被引用。 我们没有意识到的是,旧系统在数千个较大数字中插入了逗号 - 因此,在我们预期的位置(例如 1099.99),我们得到了 1,099.99。 当然,CSV 解析器看到了逗号,并将值设为 1。想象一下,当大件商品的订单开始出现时,客户会感到惊讶,而这些商品显然以每件 1 英镑的便宜价格出售。 代码很快就被修复了,幸运的是,他们的条款允许他们拒绝订单。 经验教训:永远不要相信示例数据集,并且在使用完整数据负载进行测试之前不要上线。
I worked on an e-commerce website where the client data was supplied as a CSV dump from a legacy back-end system. We only had a sample data set to work with (despite repeated requests for the full data set) so the first time we saw the full data was on the live site the morning it launched. All the strings were quoted in the CSV file but the numbers weren't. What we didn't realise is that the legacy system inserted a comma for the thousands in larger numbers - so where we expected, say, 1099.99, we got 1,099.99. Of course, the CSV parser saw the comma and took the value as 1. Imagine the client's surprise when orders started to come in for big ticket items which were apparently selling at the bargain price of £1 each. The code was fixed quickly and fortunately their terms allowed them to decline the orders. Lesson learned: never trust a sample data set and don't go live until you've tested with a full data load.
我们有一个电子商务系统,当它被转移到生产服务器时(通过我们超级棒的手动复制/粘贴/编辑设置过程),高级开发人员 - 唯一有权访问服务器的人 - 忘记连接系统到支付网关。 销售额达到 18,000 美元后,客户注意到他们的银行账户并不比我们刚开始时大多少。
自那天起流程改进:
没有一个。
我们如何解决问题:
告诉客户根据电子邮件通知联系所有客户
We had an e-commerce system, and when it was moved to the production server (through our super awesome manual copy/paste/edit settings process), the senior developer - the only one with access to the server - forgot to connect the system to the payment gateway. $18,000 worth of sales later, the client notices that their bank account isn't any bigger than when we started.
Process improvements since that day:
Not one.
How we solved the problem:
Told the client to contact all the customers based on their email notifications
在对我构建的系统进行实时更新期间,我丢失了大约 7 个用户的一些用户注册数据。 这听起来并没有那么糟糕,只不过这是 180 亿美元的 IPO 注册。 我们能够通过发送的自动电子邮件追踪信息,但这个小问题让我们流下了几滴汗珠。
I lost some user registration data for about 7 users during a live update to a system I built. That doesn't sounds so bad, except that it was registrations for an $18 billion IPO. We were able to track the information down through the automated emails that got sent out, but there were a few beads of sweat shed over that little hiccup.