这是一个创建于 2724 天前的主题，其中的信息可能已经有所发展或是发生改变。
公司属于金融行业，其实是个挺严重的 bug，但是领导找不出原因（他自己之前写的代码，现在不写代码了），加上可能要面子，担心晋升等问题，不上报问题，每天出现异常数据了，让我们手动去修补数据，因为业务的实时要求很高，必须当天搞定，同时还有新的开发任务不断加进来。
搞的很心累，像运维一样，下班后、平时周末也要关注微信群的问题，随时连 vpn 解决问题。
搞的很心累，像运维一样，下班后、平时周末也要关注微信群的问题，随时连 vpn 解决问题。
 | 1 shoaly 2018-07-03 13:26:30 +08:00 站你们领导的视角: 1 面临晋升 2 交易量这么大, 不确定修改 bug 会不会引起更大的 bug, 如果真出了更大的 bug, 小弟只会告诉他, 哦 这个确实是 bug, 但是锅是他来背 所以我感觉....他做了一个当下看起来最保险的应对 |
 | 2 cattrace 2018-07-03 13:40:54 +08:00 为你们好 |
 | 3 LanAiFaZuo 2018-07-03 13:42:44 +08:00 欺上瞒下的领导不是好领导 |
 | 4 donyee 2018-07-03 13:43:57 +08:00  7 你去研究下代码 帮领导修复啊... 今年的绩效就看这个 BUG 啦 |
 | 5 yexm0 2018-07-03 13:44:42 +08:00 via iPhone 4L +1 |
 | 6 maemual 2018-07-03 13:45:58 +08:00 所以现在谁在修 bug ？ |
 | 7 CruelMoon 2018-07-03 13:47:05 +08:00 21 找不到 bug，可不可以把修复过程自动化呢.. |
 | 8 a7a2 2018-07-03 13:48:01 +08:00 2 代码都是他写的 要查 bug 绝对是可以找到的 除非有私心 挟持生产线 我走了你们死定的意思 我也做了一个金融项目，二次期权交易系统，将项目拆分为数据采集服务，交易系统服务，其中后者才不到 3000 行代码，发现及定位问题都很容易。。。 源码是 go 写的。 不过他写了多少万行，但是无论多少都能很好发现及处理 |
 | 9 moshao6 2018-07-03 13:48:56 +08:00 什么时候到头？ BUG 还是要彻底解决的 |
 | 10 whx20202 2018-07-03 13:49:29 +08:00 3 你们领导绩效好了，你们团队绩效怎么样？ 面向什么编程呢 |
 | 11 ben1024 2018-07-03 13:57:58 +08:00 7，10 楼见解深刻 |
 | 12 jason2017 OP |
 | 13 jmk92 2018-07-03 14:00:26 +08:00 就假设 lead 确实不写代码了，但是还是能看代码排查问题的，如果 lead 都查不出来的 bug，至少他肯定尽力去查了，而且可能现在也没放弃，晚上加班也在排查中。 那么这个 BUG 应该确实不容易确定或者不那么容易修复，牵扯的东西可能比较多。 所以楼主帮 lead 修复的可能性就更小了，盲目的修复万一牵扯到其他功能就得不偿失了。 所以，建议修复 BUG 的事还是挺 lead 的，至于修复数据的这块，尽可能做一个快速定位问题、自动通知、最好自动可以修复部分代码的工具，类似 7 楼。 |
 | 14 linxl 2018-07-03 14:01:42 +08:00 不怕手动改出 bug 啊， 到时候程序 bug + 手工 bug 简直没法排查。 |
| 15 jmk92 2018-07-03 14:03:00 +08:00 脑补一下，万一盲目的帮领导修复了 BUG，重演了前几天的阿里事件，你，没错就是 you，牛逼喽 |
 | 16 forestyuan 2018-07-03 14:03:41 +08:00 是不是可以跟领导提一下，这个 BUG 的运维由专人来负责，这样其他人都解脱了，而这个人有了这一块固定的工作，他的其他工作也可以减少一些。 |
 | 17 odirus 2018-07-03 14:06:29 +08:00 程序员何必难为程序员，我想他也是为了大家好。 要是上面大老板知道了，“这还了得，某某某，马上给我修复！”，你也说了 leader 现在不写代码了，最后还不是大家来修复，但如果大家修复不好或者捅了更大的篓子，估计大家都得兜着走。 我觉得这种事情，可以积极主动和 leader 私下沟通，首先确认对方是否有在排查问题，其次看能不能提出自己的见解，我觉得如果你在这件事情里面能表现出更出众的能力，你的事业应该会更好。 |
 | 18 jason94 2018-07-03 14:07:09 +08:00 7/8 楼讲的很有理. |
| 19 jason2017 OP |
| 20 jason2017 OP @odirus 我们的领导吧，平时我们出了 bug，基本上就会在群里说你。 然后，自己的 bug 呢，因为他有线上权限，一声不吭，自己偷偷修复了。 |
 | 22 dalieba 2018-07-03 14:41:16 +08:00 via Android 应该让领导和公司里面的技术骨干闭门磋商，一块会诊，这样可以发现更多问题，解决的也快。 |
 | 23 ugvf2009 2018-07-03 14:44:04 +08:00 via Android 领导的领导的邮箱电话给我，我来暴他 |
 | 24 amon 2018-07-03 14:44:13 +08:00 1. 试着沟通让领导安排时间和人力来修复这个 bug 2. 如果领导执意不修复 bug，那就试着自动化修复数量问题呗 3. 有时确实是多一事不如少一事，你能为领导考虑，很好。 |
 | 25 mdnffnd 2018-07-03 14:54:43 +08:00 via Android @LanAiFaZuo 欺上没有满下 |
| 26 moshao6 2018-07-03 15:02:41 +08:00 是不是可以这样理解，如果这个 BUG 一直都无法解决，到后面如果你实在受不了也离职 |
 | 27 opengps 2018-07-03 15:08:51 +08:00 我跟你说我之前做系统，有那么 2 个极端问题我找了 3 年才找到你信不信？ 你们领导估计是实在找不到原因了，另外可能是碍于面子之类的因素不去充电，还着急晋升。 |
 | 28 rocksolid 2018-07-03 15:15:08 +08:00 选择不上报,估计不是能随便解决的 bug |
 | 29 Narcissu5 2018-07-03 15:37:07 +08:00 线上改数据，一旦少些个 WHERE，他的锅就变成你的锅了，到时候也就没人关心什么 BUG 了 |
 | 30 rocky267 2018-07-03 15:45:03 +08:00 金融公司？还能在线上动数据？分管 DB 的部门看不见？额，如果以上都是 Y，那没什么说的了，如果全部都是违规操作，岂不是你们整个团队都在为他一个人埋单？更何况有 bug 很正常啊，要分锅，当初的测试团队也有责任啊，这锅一大了就不怕分了哈哈哈 |
 | 31 zdnyp 2018-07-03 15:47:46 +08:00 线下环境不能测试、修复的么... |
 | 32 yjxjn 2018-07-03 15:50:01 +08:00 2 对于古老金融支付系统，手动去修改一些数据，我认为并不是一件丢人的事儿，因为谁敢拍胸脯说这个 bug 修改后，不会引起更大的 bug，因为金融，清算的 IT 系统，一般保证能用则用。 而且我猜这肯定不是你一个人发现这个问题了，你的领导肯定在之前就发现过这个问题，一定也找过人去想着 fixedbug，但是肯定要么钱不够，要么技术难度大，要么可能会影响生产环境上的数据等等之类的原因，所以，我觉得现在就是手动改吧。。 在某 500 强外企，同做支付系统的码农路过，对于出错的数据，我们都采取手动修改的方法，原因就是上面我说的这几种了。 |
 | 33 uvhchina 2018-07-03 15:54:36 +08:00 我们以前有个非常非常重要的系统，不定时 core dump，大概半小时一次，然后大家就写了个脚本每 30s 检查一次，core dump 了就重新启动。 大家都查了，查了定位不到具体点，确认是一个 7、8 年的老的 lib 有问题，但是...谁也不想动 这种场景其实非常常见的...我还见过有问题大家不肯修正，因为修正了报表数据就会有波动，无论是谁都不肯修，默认 bug 一直在，直到某年业务系统大规模升级割接才顺便修了 |
 | 34 imn1 2018-07-03 15:56:33 +08:00 如果是从 bug 的错误数据，修正到正确的数据，这样做不算大问题，只是权衡轻重的问题 但如果是数据造假，那就是大问题，严重的可能涉及犯罪 手动修改与上述后者，只是取决于执行人的一念之间，必须杜绝 所以理应以责任重大为由建议查 bug，不过有思想准备这事会落在你头上就是了 |
 | 35 newmlp 2018-07-03 16:03:27 +08:00 这种重复劳动写个脚本不行 |
 | 36 zartouch 2018-07-03 16:10:09 +08:00 via iPhone |
 | 37 ytmsdy 2018-07-03 16:13:47 +08:00 搞个脚本自动校验数据，发现差错自动生成修改命令。 |
 | 38 circleee 2018-07-03 17:15:15 +08:00 纸包不住火，4L+1 |
 | 39 nozer 2018-07-03 17:20:46 +08:00 1 你们领导太老实了， 要是我，就直接抓个愣头青限期修正，我管这代码是不是我以前写的， 谁写的代码还没个 BUG，但只要发现问题能及时解决就好。 |
 | 40 469054193 2018-07-03 17:22:47 +08:00 @LanAiFaZuo 就欺上了 下没有瞒 |
| 41 nozer 2018-07-03 17:23:53 +08:00 而且，线上系统出问题，一般都是直接找测试， 测的什么玩意儿。 如果直接责任不摊到测试上，测试效果很难保证。 |
 | 42 l00t 2018-07-03 17:36:52 +08:00 这种事换我就抱怨几次后直接捅到更上级去了。长痛不如短痛。与其天天做这种破事折磨个一年两年最后受不了走人，还不如彻底把事情摊开了说。 |
 | 43 ExploreWay 2018-07-03 18:02:36 +08:00 真怕崩盘 |
 | 44 segment fault core dump! 找不到 bug 就写个自动化补数据的程序吧，当然系统被设计越来越冗余 |
 | 45 wenzhoou 2018-07-03 18:37:37 +08:00 via Android 事情应该干。但是必需光明正大的干！ 隐藏这样一个问题而且拙劣的表演，不是心坏了就是傻！对，谁拍的板就是说谁。 你，赶紧走人。跟着这样的老大，这样的公司会有什么样的结果。为了自己的将来，选择一个良心老板很重要的。 |
 | 46 P99LrYZVkZkg 2018-07-03 18:44:08 +08:00 bug 都找不到，这团队太不靠谱了。 实在不行把日志记全了，跟踪看异常数据怎么来的，金融数据还能允许有找不出来 bug 的问题？被人黑了吧？ |
 | 47 superbiger 2018-07-03 19:42:52 +08:00 老大自己改就算了，哪天忙不过来让别人帮忙改下都是同事也不是不行的。隐藏无所谓，只要锅别随便甩 |
 | 48 shijingshijing 2018-07-03 19:51:40 +08:00 我比较好奇，你们老大某天生病了躺床上了怎么办。。。。 |
 | 49 liuxu 2018-07-03 19:52:15 +08:00 源码在手上作者还在居然定位不到 bug |
 | 52 ooooo 2018-07-03 20:08:19 +08:00 |
 | 53 gpg 2018-07-03 20:13:07 +08:00 我觉得领导没把锅摔给你们就已经很良心了 |
 | 54 cominghome 2018-07-03 22:52:14 +08:00 bug 这东西，真不是想找就找得到的，楼上几位说得也太轻巧了。 |
 | 55 rainysia 2018-07-03 23:21:44 +08:00 最近半年. 做过几件事和主题有关 1, 优先修复 bug 产生的数据, 手动跑数据修复(半天内), 确认不是之前的设计问题的话, 这里就结束了. 2, 修复异常操作产生的数据, 前期是手动跑数据修复, 后期加了脚本自动修复(一天左右), 并且考虑优化业务逻辑整个避免. 3, 设计问题产生的异常数据, 前期手动跑数据修复, 中期优化设计(一周左右), 后期重构设计完全规避(持续好几周加班). 产生的价值对上面来讲, 因为没有实际产出, 所以没有上面认为的业务价值... 总结: 手动修下数据得了. 不行就自动修数据. |
 | 56 vansl 2018-07-04 00:20:40 +08:00 via iPhone 没人想笑吗...手动改数据哈哈哈容我笑三分钟 |
 | 57 klren0312 2018-07-04 00:25:22 +08:00 抱歉我们是自动生成 |
 | 59 chemzqm 2018-07-04 00:36:34 +08:00 早点上报帮助公司及时止损吧，这种事瞒不住的 |
 | 60 yangqi 2018-07-04 00:45:21 +08:00 首先你怎么知道领导没有上报问题？你觉得如果上报了，上面会在乎是否修复 bug? 上面只需要你领导的部门每天提供正确的数据就行了，细节问题当然是你领导来决定了。 |
 | 61 changnet 2018-07-04 00:49:18 +08:00 via Android @jjx 偶尔这么做还可以。经常这么做那肯定是你没吃过苦头。如果按流程走，即使是你的责任也不会太大，毕竟谁的代码都有可能出 bug，公司有对应的风险控制。私自修改线上逻辑，出了问题，那所有责任都归你了。 我最近一次修改线上逻辑，是程序循环发包跑满 cpu，让运维重启两次都没解决问题才不得已线上改 |
 | 62 tesiddddd 2018-07-04 01:03:12 +08:00 via iPhone 小刘啊，有事干嘛在这儿说，明天来我办公室跟我聊下 |
 | 63 jjx 2018-07-04 06:59:20 +08:00 @changnet 你想的有点复杂了, 有些理由 造成了看起来 偷偷的改线上 bug 1. 比方说只有一个后端 2. 可能任何时间都在工作, 比方说下班时间 对于已确定的 bug , 这个时候走流程, 太教条了 另外, 改 bug 同改逻辑还真不能想提并论 至于 lz 所说的, 在我们这里是无法容忍的, 我们的规矩是 所有的工作优先级, bug 是第一位的(估计大家都是), 至于造成数据错误的 bug, 更是第一时间公司全体人员动起来解决掉的 |
 | 65 lcy630409 2018-07-04 09:05:34 +08:00 很多在线 bug 哪来这么简单哟，在线环境，一般是不能进行任何的修改的， 万一 有一点点问题 就是全盘崩，没修改过大型在线祖传程序 bug 的 不要说话了，很刺激的 修好你 你牛 b，修坏了....自己想 |
 | 66 zllovepork 2018-07-04 09:36:43 +08:00 @shoaly 认同 |
 | 67 jimi2018 2018-07-04 10:03:43 +08:00 多花时间开代码吧。 |
 | 69 luffysup 2018-07-04 14:57:36 +08:00 总要解决的 不是长久之计 |
 | 70 flightzz 2018-07-04 16:53:31 +08:00 就没有比领导更牛逼的大牛了么 总不能永远不解决吧 |
Select Language