V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
jason2017
V2EX  ›  程序员

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

  •  4
     
  •   jason2017 · 2018-07-03 13:13:40 +08:00 · 12393 次点击
    这是一个创建于 2095 天前的主题,其中的信息可能已经有所发展或是发生改变。
    公司属于金融行业,其实是个挺严重的 bug,但是领导找不出原因(他自己之前写的代码,现在不写代码了),加上可能要面子,担心晋升等问题,不上报问题,每天出现异常数据了,让我们手动去修补数据,因为业务的实时要求很高,必须当天搞定,同时还有新的开发任务不断加进来。
    搞的很心累,像运维一样,下班后、平时周末也要关注微信群的问题,随时连 vpn 解决问题。
    70 条回复    2018-07-04 16:53:31 +08:00
    shoaly
        1
    shoaly  
       2018-07-03 13:26:30 +08:00
    站你们领导的视角:
    1 面临晋升
    2 交易量这么大, 不确定修改 bug 会不会引起更大的 bug, 如果真出了更大的 bug, 小弟只会告诉他, 哦 这个确实是 bug, 但是锅是他来背
    所以我感觉....他做了一个当下看起来最保险的应对
    cattrace
        2
    cattrace  
       2018-07-03 13:40:54 +08:00
    为你们好
    LanAiFaZuo
        3
    LanAiFaZuo  
       2018-07-03 13:42:44 +08:00
    欺上瞒下的领导不是好领导
    donyee
        4
    donyee  
       2018-07-03 13:43:57 +08:00   ❤️ 7
    你去研究下代码 帮领导修复啊...
    今年的绩效就看这个 BUG 啦
    yexm0
        5
    yexm0  
       2018-07-03 13:44:42 +08:00 via iPhone
    4L +1
    maemual
        6
    maemual  
       2018-07-03 13:45:58 +08:00
    所以现在谁在修 bug ?
    CruelMoon
        7
    CruelMoon  
       2018-07-03 13:47:05 +08:00   ❤️ 21
    找不到 bug,可不可以把修复过程自动化呢..
    a7a2
        8
    a7a2  
       2018-07-03 13:48:01 +08:00   ❤️ 2
    代码都是他写的 要查 bug 绝对是可以找到的
    除非有私心 挟持生产线 我走了你们死定的意思
    我也做了一个金融项目,二次期权交易系统,将项目拆分为数据采集服务,交易系统服务,其中后者才不到 3000 行代码,发现及定位问题都很容易。。。
    源码是 go 写的。
    不过他写了多少万行,但是无论多少都能很好发现及处理
    moshao6
        9
    moshao6  
       2018-07-03 13:48:56 +08:00
    什么时候到头? BUG 还是要彻底解决的
    whx20202
        10
    whx20202  
       2018-07-03 13:49:29 +08:00   ❤️ 3
    你们领导绩效好了,你们团队绩效怎么样?
    面向什么编程呢
    ben1024
        11
    ben1024  
       2018-07-03 13:57:58 +08:00
    7,10 楼见解深刻
    jason2017
        12
    jason2017  
    OP
       2018-07-03 13:58:57 +08:00
    @donyee 系统很复杂,都是一些核心老代码,平时工作都做不完了,还研究 bug。
    @CruelMoon 就是为了不让上面发现,才不做的。
    jmk92
        13
    jmk92  
       2018-07-03 14:00:26 +08:00
    就假设 lead 确实不写代码了,但是还是能看代码排查问题的,如果 lead 都查不出来的 bug,至少他肯定尽力去查了,而且可能现在也没放弃,晚上加班也在排查中。
    那么这个 BUG 应该确实不容易确定或者不那么容易修复,牵扯的东西可能比较多。
    所以楼主帮 lead 修复的可能性就更小了,盲目的修复万一牵扯到其他功能就得不偿失了。
    所以,建议修复 BUG 的事还是挺 lead 的,至于修复数据的这块,尽可能做一个快速定位问题、自动通知、最好自动可以修复部分代码的工具,类似 7 楼。
    linxl
        14
    linxl  
       2018-07-03 14:01:42 +08:00
    不怕手动改出 bug 啊, 到时候程序 bug + 手工 bug 简直没法排查。
    jmk92
        15
    jmk92  
       2018-07-03 14:03:00 +08:00
    脑补一下,万一盲目的帮领导修复了 BUG,重演了前几天的阿里事件,你,没错就是 you,牛逼喽
    forestyuan
        16
    forestyuan  
       2018-07-03 14:03:41 +08:00
    是不是可以跟领导提一下,这个 BUG 的运维由专人来负责,这样其他人都解脱了,而这个人有了这一块固定的工作,他的其他工作也可以减少一些。
    odirus
        17
    odirus  
       2018-07-03 14:06:29 +08:00
    程序员何必难为程序员,我想他也是为了大家好。

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

    我觉得这种事情,可以积极主动和 leader 私下沟通,首先确认对方是否有在排查问题,其次看能不能提出自己的见解,我觉得如果你在这件事情里面能表现出更出众的能力,你的事业应该会更好。
    jason94
        18
    jason94  
       2018-07-03 14:07:09 +08:00
    7/8 楼讲的很有理.
    jason2017
        19
    jason2017  
    OP
       2018-07-03 14:08:51 +08:00
    @jmk92

    @forestyuan
    这么说吧,这个 bug 存在了快半年多了,上一个同事修补了半年多了,实在受不了离职了,然后交接给我了。
    jason2017
        20
    jason2017  
    OP
       2018-07-03 14:14:14 +08:00
    @odirus 我们的领导吧,平时我们出了 bug,基本上就会在群里说你。
    然后,自己的 bug 呢,因为他有线上权限,一声不吭,自己偷偷修复了。
    jjx
        21
    jjx  
       2018-07-03 14:33:46 +08:00
    @jason2017

    哈哈, 我也常常这样干
    dalieba
        22
    dalieba  
       2018-07-03 14:41:16 +08:00 via Android
    应该让领导和公司里面的技术骨干闭门磋商,一块会诊,这样可以发现更多问题,解决的也快。
    ugvf2009
        23
    ugvf2009  
       2018-07-03 14:44:04 +08:00 via Android
    领导的领导的邮箱电话给我,我来暴他
    amon
        24
    amon  
       2018-07-03 14:44:13 +08:00
    1. 试着沟通让领导安排时间和人力来修复这个 bug
    2. 如果领导执意不修复 bug,那就试着自动化修复数量问题呗
    3. 有时确实是多一事不如少一事,你能为领导考虑,很好。
    mdnffnd
        25
    mdnffnd  
       2018-07-03 14:54:43 +08:00 via Android
    @LanAiFaZuo 欺上没有满下
    moshao6
        26
    moshao6  
       2018-07-03 15:02:41 +08:00
    是不是可以这样理解,如果这个 BUG 一直都无法解决,到后面如果你实在受不了也离职
    opengps
        27
    opengps  
       2018-07-03 15:08:51 +08:00
    我跟你说我之前做系统,有那么 2 个极端问题我找了 3 年才找到你信不信?
    你们领导估计是实在找不到原因了,另外可能是碍于面子之类的因素不去充电,还着急晋升。
    rocksolid
        28
    rocksolid  
       2018-07-03 15:15:08 +08:00
    选择不上报,估计不是能随便解决的 bug
    Narcissu5
        29
    Narcissu5  
       2018-07-03 15:37:07 +08:00
    线上改数据,一旦少些个 WHERE,他的锅就变成你的锅了,到时候也就没人关心什么 BUG 了
    rocky267
        30
    rocky267  
       2018-07-03 15:45:03 +08:00
    金融公司?还能在线上动数据?分管 DB 的部门看不见?额,如果以上都是 Y,那没什么说的了,如果全部都是违规操作,岂不是你们整个团队都在为他一个人埋单?更何况有 bug 很正常啊,要分锅,当初的测试团队也有责任啊,这锅一大了就不怕分了哈哈哈
    zdnyp
        31
    zdnyp  
       2018-07-03 15:47:46 +08:00
    线下环境不能测试、修复的么...
    yjxjn
        32
    yjxjn  
       2018-07-03 15:50:01 +08:00   ❤️ 2
    对于古老金融支付系统,手动去修改一些数据,我认为并不是一件丢人的事儿,因为谁敢拍胸脯说这个 bug 修改后,不会引起更大的 bug,因为金融,清算的 IT 系统,一般保证能用则用。
    而且我猜这肯定不是你一个人发现这个问题了,你的领导肯定在之前就发现过这个问题,一定也找过人去想着 fixedbug,但是肯定要么钱不够,要么技术难度大,要么可能会影响生产环境上的数据等等之类的原因,所以,我觉得现在就是手动改吧。。

    在某 500 强外企,同做支付系统的码农路过,对于出错的数据,我们都采取手动修改的方法,原因就是上面我说的这几种了。
    uvhchina
        33
    uvhchina  
       2018-07-03 15:54:36 +08:00
    我们以前有个非常非常重要的系统,不定时 core dump,大概半小时一次,然后大家就写了个脚本每 30s 检查一次,core dump 了就重新启动。

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

    这种场景其实非常常见的...我还见过有问题大家不肯修正,因为修正了报表数据就会有波动,无论是谁都不肯修,默认 bug 一直在,直到某年业务系统大规模升级割接才顺便修了
    imn1
        34
    imn1  
       2018-07-03 15:56:33 +08:00
    如果是从 bug 的错误数据,修正到正确的数据,这样做不算大问题,只是权衡轻重的问题
    但如果是数据造假,那就是大问题,严重的可能涉及犯罪

    手动修改与上述后者,只是取决于执行人的一念之间,必须杜绝
    所以理应以责任重大为由建议查 bug,不过有思想准备这事会落在你头上就是了
    newmlp
        35
    newmlp  
       2018-07-03 16:03:27 +08:00
    这种重复劳动写个脚本不行
    zartouch
        36
    zartouch  
       2018-07-03 16:10:09 +08:00 via iPhone
    我比较好奇, 金融系统你们作为开发怎么去生产环境改数据的
    ytmsdy
        37
    ytmsdy  
       2018-07-03 16:13:47 +08:00
    搞个脚本自动校验数据,发现差错自动生成修改命令。
    circleee
        38
    circleee  
       2018-07-03 17:15:15 +08:00
    纸包不住火,4L+1
    nozer
        39
    nozer  
       2018-07-03 17:20:46 +08:00   ❤️ 1
    你们领导太老实了, 要是我,就直接抓个愣头青限期修正,我管这代码是不是我以前写的, 谁写的代码还没个 BUG,但只要发现问题能及时解决就好。
    469054193
        40
    469054193  
       2018-07-03 17:22:47 +08:00
    @LanAiFaZuo 就欺上了 下没有瞒
    nozer
        41
    nozer  
       2018-07-03 17:23:53 +08:00
    而且,线上系统出问题,一般都是直接找测试, 测的什么玩意儿。
    如果直接责任不摊到测试上,测试效果很难保证。
    l00t
        42
    l00t  
       2018-07-03 17:36:52 +08:00
    这种事换我就抱怨几次后直接捅到更上级去了。长痛不如短痛。与其天天做这种破事折磨个一年两年最后受不了走人,还不如彻底把事情摊开了说。
    ExploreWay
        43
    ExploreWay  
       2018-07-03 18:02:36 +08:00
    真怕崩盘
    zhangsen1992
        44
    zhangsen1992  
       2018-07-03 18:23:53 +08:00
    segment fault core dump! 找不到 bug 就写个自动化补数据的程序吧,当然系统被设计越来越冗余
    wenzhoou
        45
    wenzhoou  
       2018-07-03 18:37:37 +08:00 via Android
    事情应该干。但是必需光明正大的干!
    隐藏这样一个问题而且拙劣的表演,不是心坏了就是傻!对,谁拍的板就是说谁。

    你,赶紧走人。跟着这样的老大,这样的公司会有什么样的结果。为了自己的将来,选择一个良心老板很重要的。
    P99LrYZVkZkg
        46
    P99LrYZVkZkg  
       2018-07-03 18:44:08 +08:00
    bug 都找不到,这团队太不靠谱了。

    实在不行把日志记全了,跟踪看异常数据怎么来的,金融数据还能允许有找不出来 bug 的问题?被人黑了吧?
    superbiger
        47
    superbiger  
       2018-07-03 19:42:52 +08:00
    老大自己改就算了,哪天忙不过来让别人帮忙改下都是同事也不是不行的。隐藏无所谓,只要锅别随便甩
    shijingshijing
        48
    shijingshijing  
       2018-07-03 19:51:40 +08:00
    我比较好奇,你们老大某天生病了躺床上了怎么办。。。。
    liuxu
        49
    liuxu  
       2018-07-03 19:52:15 +08:00
    源码在手上作者还在居然定位不到 bug
    jeffcott
        50
    jeffcott  
       2018-07-03 19:58:01 +08:00
    @nozer 你们太阴了,我现在就在搞这么个 bug...搞不定怎么办呢
    jerrry
        51
    jerrry  
       2018-07-03 20:07:52 +08:00 via Android
    @jjx 这种小领导真的很讨厌,尤其是当着你的面向大领导转移锅的
    ooooo
        52
    ooooo  
       2018-07-03 20:08:19 +08:00
    @469054193
    @LanAiFaZuo

    语文都咋学的...

    欺下瞒上

    苦活留给下属 欺下
    不给上面知道 瞒上
    wisdom
        53
    wisdom  
       2018-07-03 20:13:07 +08:00
    我觉得领导没把锅摔给你们就已经很良心了
    cominghome
        54
    cominghome  
       2018-07-03 22:52:14 +08:00
    bug 这东西,真不是想找就找得到的,楼上几位说得也太轻巧了。
    rainysia
        55
    rainysia  
       2018-07-03 23:21:44 +08:00
    最近半年.
    做过几件事和主题有关
    1, 优先修复 bug 产生的数据, 手动跑数据修复(半天内), 确认不是之前的设计问题的话, 这里就结束了.
    2, 修复异常操作产生的数据, 前期是手动跑数据修复, 后期加了脚本自动修复(一天左右), 并且考虑优化业务逻辑整个避免.
    3, 设计问题产生的异常数据, 前期手动跑数据修复, 中期优化设计(一周左右), 后期重构设计完全规避(持续好几周加班).

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

    总结: 手动修下数据得了. 不行就自动修数据.
    vansl
        56
    vansl  
       2018-07-04 00:20:40 +08:00 via iPhone
    没人想笑吗...手动改数据哈哈哈容我笑三分钟
    klren0312
        57
    klren0312  
       2018-07-04 00:25:22 +08:00
    抱歉我们是自动生成
    WildCat
        58
    WildCat  
       2018-07-04 00:29:29 +08:00
    @a7a2 go 写的,bug 很好定位吧,说不定楼主的领导用 python 2.x 写的
    chemzqm
        59
    chemzqm  
       2018-07-04 00:36:34 +08:00
    早点上报帮助公司及时止损吧,这种事瞒不住的
    yangqi
        60
    yangqi  
       2018-07-04 00:45:21 +08:00
    首先你怎么知道领导没有上报问题?你觉得如果上报了,上面会在乎是否修复 bug? 上面只需要你领导的部门每天提供正确的数据就行了,细节问题当然是你领导来决定了。
    changnet
        61
    changnet  
       2018-07-04 00:49:18 +08:00 via Android
    @jjx 偶尔这么做还可以。经常这么做那肯定是你没吃过苦头。如果按流程走,即使是你的责任也不会太大,毕竟谁的代码都有可能出 bug,公司有对应的风险控制。私自修改线上逻辑,出了问题,那所有责任都归你了。

    我最近一次修改线上逻辑,是程序循环发包跑满 cpu,让运维重启两次都没解决问题才不得已线上改
    tesiddddd
        62
    tesiddddd  
       2018-07-04 01:03:12 +08:00 via iPhone
    小刘啊,有事干嘛在这儿说,明天来我办公室跟我聊下
    jjx
        63
    jjx  
       2018-07-04 06:59:20 +08:00
    @changnet

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

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

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

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


    至于 lz 所说的, 在我们这里是无法容忍的, 我们的规矩是 所有的工作优先级, bug 是第一位的(估计大家都是), 至于造成数据错误的 bug, 更是第一时间公司全体人员动起来解决掉的
    469054193
        64
    469054193  
       2018-07-04 08:25:09 +08:00
    @ooooo 人家说的是欺上瞒下 你要挑错的话艾特错人了 应该艾特 3L 那位
    lcy630409
        65
    lcy630409  
       2018-07-04 09:05:34 +08:00
    很多在线 bug 哪来这么简单哟,在线环境,一般是不能进行任何的修改的,
    万一 有一点点问题 就是全盘崩,没修改过大型在线祖传程序 bug 的 不要说话了,很刺激的
    修好你 你牛 b,修坏了....自己想
    zllovepork
        66
    zllovepork  
       2018-07-04 09:36:43 +08:00
    @shoaly 认同
    jimi2018
        67
    jimi2018  
       2018-07-04 10:03:43 +08:00
    多花时间开代码吧。
    qooweds
        68
    qooweds  
       2018-07-04 11:28:00 +08:00
    @nozer #41 真是 low 得一 B
    luffysup
        69
    luffysup  
       2018-07-04 14:57:36 +08:00
    总要解决的 不是长久之计
    flightzz
        70
    flightzz  
       2018-07-04 16:53:31 +08:00
    就没有比领导更牛逼的大牛了么 总不能永远不解决吧
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   1237 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 30ms · UTC 17:58 · PVG 01:58 · LAX 10:58 · JFK 13:58
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.