公司系统有 bug，领导瞒着上面每天手动修复数据，大家怎么看待这种行为。

[jason2017]

公司属于金融行业，其实是个挺严重的 bug，但是领导找不出原因（他自己之前写的代码，现在不写代码了），加上可能要面子，担心晋升等问题，不上报问题，每天出现异常数据了，让我们手动去修补数据，因为业务的实时要求很高，必须当天搞定，同时还有新的开发任务不断加进来。
搞的很心累，像运维一样，下班后、平时周末也要关注微信群的问题，随时连 vpn 解决问题。

[shoaly]

站你们领导的视角:
1 面临晋升
2 交易量这么大, 不确定修改 bug 会不会引起更大的 bug, 如果真出了更大的 bug, 小弟只会告诉他, 哦 这个确实是 bug, 但是锅是他来背
所以我感觉....他做了一个当下看起来最保险的应对

[cattrace]

为你们好

[LanAiFaZuo]

欺上瞒下的领导不是好领导

[donyee]

你去研究下代码 帮领导修复啊...
今年的绩效就看这个 BUG 啦

[yexm0]

4L +1

[maemual]

所以现在谁在修 bug ？

[CruelMoon]

找不到 bug，可不可以把修复过程自动化呢..

[a7a2]

代码都是他写的 要查 bug 绝对是可以找到的
除非有私心 挟持生产线 我走了你们死定的意思
我也做了一个金融项目，二次期权交易系统，将项目拆分为数据采集服务，交易系统服务，其中后者才不到 3000 行代码，发现及定位问题都很容易。。。
源码是 go 写的。
不过他写了多少万行，但是无论多少都能很好发现及处理

[moshao6]

什么时候到头？ BUG 还是要彻底解决的

[whx20202]

你们领导绩效好了，你们团队绩效怎么样？
面向什么编程呢

[ben1024]

7，10 楼见解深刻

[jason2017]

@donyee 系统很复杂，都是一些核心老代码，平时工作都做不完了，还研究 bug。
@CruelMoon 就是为了不让上面发现，才不做的。

[jmk92]

就假设 lead 确实不写代码了，但是还是能看代码排查问题的，如果 lead 都查不出来的 bug，至少他肯定尽力去查了，而且可能现在也没放弃，晚上加班也在排查中。
那么这个 BUG 应该确实不容易确定或者不那么容易修复，牵扯的东西可能比较多。
所以楼主帮 lead 修复的可能性就更小了，盲目的修复万一牵扯到其他功能就得不偿失了。
所以，建议修复 BUG 的事还是挺 lead 的，至于修复数据的这块，尽可能做一个快速定位问题、自动通知、最好自动可以修复部分代码的工具，类似 7 楼。

[linxl]

不怕手动改出 bug 啊， 到时候程序 bug + 手工 bug 简直没法排查。

[jmk92]

脑补一下，万一盲目的帮领导修复了 BUG，重演了前几天的阿里事件，你，没错就是 you，牛逼喽

[forestyuan]

是不是可以跟领导提一下，这个 BUG 的运维由专人来负责，这样其他人都解脱了，而这个人有了这一块固定的工作，他的其他工作也可以减少一些。

[odirus]

程序员何必难为程序员，我想他也是为了大家好。

要是上面大老板知道了，“这还了得，某某某，马上给我修复！”，你也说了 leader 现在不写代码了，最后还不是大家来修复，但如果大家修复不好或者捅了更大的篓子，估计大家都得兜着走。

我觉得这种事情，可以积极主动和 leader 私下沟通，首先确认对方是否有在排查问题，其次看能不能提出自己的见解，我觉得如果你在这件事情里面能表现出更出众的能力，你的事业应该会更好。

[jason94]

7/8 楼讲的很有理.

[jason2017]

@jmk92

@forestyuan
这么说吧，这个 bug 存在了快半年多了，上一个同事修补了半年多了，实在受不了离职了，然后交接给我了。

[jason2017]

@odirus 我们的领导吧，平时我们出了 bug，基本上就会在群里说你。
然后，自己的 bug 呢，因为他有线上权限，一声不吭，自己偷偷修复了。

[jjx]

@jason2017

哈哈, 我也常常这样干

[dalieba]

应该让领导和公司里面的技术骨干闭门磋商，一块会诊，这样可以发现更多问题，解决的也快。

[ugvf2009]

领导的领导的邮箱电话给我，我来暴他

[amon]

1. 试着沟通让领导安排时间和人力来修复这个 bug
2. 如果领导执意不修复 bug，那就试着自动化修复数量问题呗
3. 有时确实是多一事不如少一事，你能为领导考虑，很好。

[mdnffnd]

@LanAiFaZuo 欺上没有满下

[moshao6]

是不是可以这样理解，如果这个 BUG 一直都无法解决，到后面如果你实在受不了也离职

[opengps]

我跟你说我之前做系统，有那么 2 个极端问题我找了 3 年才找到你信不信？
你们领导估计是实在找不到原因了，另外可能是碍于面子之类的因素不去充电，还着急晋升。

[rocksolid]

选择不上报,估计不是能随便解决的 bug

[Narcissu5]

线上改数据，一旦少些个 WHERE，他的锅就变成你的锅了，到时候也就没人关心什么 BUG 了

[rocky267]

金融公司？还能在线上动数据？分管 DB 的部门看不见？额，如果以上都是 Y，那没什么说的了，如果全部都是违规操作，岂不是你们整个团队都在为他一个人埋单？更何况有 bug 很正常啊，要分锅，当初的测试团队也有责任啊，这锅一大了就不怕分了哈哈哈

[zdnyp]

线下环境不能测试、修复的么...

[yjxjn]

对于古老金融支付系统，手动去修改一些数据，我认为并不是一件丢人的事儿，因为谁敢拍胸脯说这个 bug 修改后，不会引起更大的 bug，因为金融，清算的 IT 系统，一般保证能用则用。
而且我猜这肯定不是你一个人发现这个问题了，你的领导肯定在之前就发现过这个问题，一定也找过人去想着 fixedbug，但是肯定要么钱不够，要么技术难度大，要么可能会影响生产环境上的数据等等之类的原因，所以，我觉得现在就是手动改吧。。

在某 500 强外企，同做支付系统的码农路过，对于出错的数据，我们都采取手动修改的方法，原因就是上面我说的这几种了。

[uvhchina]

我们以前有个非常非常重要的系统，不定时 core dump，大概半小时一次，然后大家就写了个脚本每 30s 检查一次，core dump 了就重新启动。

大家都查了，查了定位不到具体点，确认是一个 7、8 年的老的 lib 有问题，但是...谁也不想动

这种场景其实非常常见的...我还见过有问题大家不肯修正，因为修正了报表数据就会有波动，无论是谁都不肯修，默认 bug 一直在，直到某年业务系统大规模升级割接才顺便修了

[imn1]

如果是从 bug 的错误数据，修正到正确的数据，这样做不算大问题，只是权衡轻重的问题
但如果是数据造假，那就是大问题，严重的可能涉及犯罪

手动修改与上述后者，只是取决于执行人的一念之间，必须杜绝
所以理应以责任重大为由建议查 bug，不过有思想准备这事会落在你头上就是了

[newmlp]

这种重复劳动写个脚本不行

[zartouch]

我比较好奇， 金融系统你们作为开发怎么去生产环境改数据的

[ytmsdy]

搞个脚本自动校验数据，发现差错自动生成修改命令。

[circleee]

纸包不住火，4L+1

[nozer]

你们领导太老实了， 要是我，就直接抓个愣头青限期修正，我管这代码是不是我以前写的， 谁写的代码还没个 BUG，但只要发现问题能及时解决就好。

[469054193]

@LanAiFaZuo 就欺上了 下没有瞒

[nozer]

而且，线上系统出问题，一般都是直接找测试， 测的什么玩意儿。
如果直接责任不摊到测试上，测试效果很难保证。

[l00t]

这种事换我就抱怨几次后直接捅到更上级去了。长痛不如短痛。与其天天做这种破事折磨个一年两年最后受不了走人，还不如彻底把事情摊开了说。

[ExploreWay]

真怕崩盘

[zhangsen1992]

segment fault core dump! 找不到 bug 就写个自动化补数据的程序吧，当然系统被设计越来越冗余

[wenzhoou]

事情应该干。但是必需光明正大的干！
隐藏这样一个问题而且拙劣的表演，不是心坏了就是傻！对，谁拍的板就是说谁。

你，赶紧走人。跟着这样的老大，这样的公司会有什么样的结果。为了自己的将来，选择一个良心老板很重要的。

[P99LrYZVkZkg]

bug 都找不到，这团队太不靠谱了。

实在不行把日志记全了，跟踪看异常数据怎么来的，金融数据还能允许有找不出来 bug 的问题？被人黑了吧？

[superbiger]

老大自己改就算了，哪天忙不过来让别人帮忙改下都是同事也不是不行的。隐藏无所谓，只要锅别随便甩

[shijingshijing]

我比较好奇，你们老大某天生病了躺床上了怎么办。。。。

[liuxu]

源码在手上作者还在居然定位不到 bug

[jeffcott]

@nozer 你们太阴了，我现在就在搞这么个 bug...搞不定怎么办呢

[jerrry]

@jjx 这种小领导真的很讨厌，尤其是当着你的面向大领导转移锅的

[ooooo]

@469054193
@LanAiFaZuo

语文都咋学的...
是
欺下瞒上

苦活留给下属 欺下
不给上面知道 瞒上

[wisdom]

我觉得领导没把锅摔给你们就已经很良心了

[cominghome]

bug 这东西，真不是想找就找得到的，楼上几位说得也太轻巧了。

[rainysia]

最近半年.
做过几件事和主题有关
1, 优先修复 bug 产生的数据, 手动跑数据修复(半天内), 确认不是之前的设计问题的话, 这里就结束了.
2, 修复异常操作产生的数据, 前期是手动跑数据修复, 后期加了脚本自动修复(一天左右), 并且考虑优化业务逻辑整个避免.
3, 设计问题产生的异常数据, 前期手动跑数据修复, 中期优化设计(一周左右), 后期重构设计完全规避(持续好几周加班).

产生的价值对上面来讲, 因为没有实际产出, 所以没有上面认为的业务价值...

总结: 手动修下数据得了. 不行就自动修数据.

[vansl]

没人想笑吗...手动改数据哈哈哈容我笑三分钟

[klren0312]

抱歉我们是自动生成

[WildCat]

@a7a2 go 写的，bug 很好定位吧，说不定楼主的领导用 python 2.x 写的

[chemzqm]

早点上报帮助公司及时止损吧，这种事瞒不住的

[yangqi]

首先你怎么知道领导没有上报问题？你觉得如果上报了，上面会在乎是否修复 bug? 上面只需要你领导的部门每天提供正确的数据就行了，细节问题当然是你领导来决定了。

[changnet]

@jjx 偶尔这么做还可以。经常这么做那肯定是你没吃过苦头。如果按流程走，即使是你的责任也不会太大，毕竟谁的代码都有可能出 bug，公司有对应的风险控制。私自修改线上逻辑，出了问题，那所有责任都归你了。

我最近一次修改线上逻辑，是程序循环发包跑满 cpu，让运维重启两次都没解决问题才不得已线上改

[tesiddddd]

小刘啊，有事干嘛在这儿说，明天来我办公室跟我聊下

[jjx]

@changnet

你想的有点复杂了, 有些理由 造成了看起来 偷偷的改线上 bug

1. 比方说只有一个后端
2. 可能任何时间都在工作, 比方说下班时间

对于已确定的 bug , 这个时候走流程, 太教条了

另外, 改 bug 同改逻辑还真不能想提并论


至于 lz 所说的, 在我们这里是无法容忍的, 我们的规矩是 所有的工作优先级, bug 是第一位的(估计大家都是), 至于造成数据错误的 bug, 更是第一时间公司全体人员动起来解决掉的

[469054193]

@ooooo 人家说的是欺上瞒下 你要挑错的话艾特错人了 应该艾特 3L 那位

[lcy630409]

很多在线 bug 哪来这么简单哟，在线环境，一般是不能进行任何的修改的，
万一 有一点点问题 就是全盘崩，没修改过大型在线祖传程序 bug 的 不要说话了，很刺激的
修好你 你牛 b，修坏了....自己想

[zllovepork]

@shoaly 认同

[jimi2018]

多花时间开代码吧。

[qooweds]

@nozer #41 真是 low 得一 B

[luffysup]

总要解决的 不是长久之计

[flightzz]

就没有比领导更牛逼的大牛了么 总不能永远不解决吧