V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
yuhuan66666
V2EX  ›  职场话题

特别好奇 当线上出现个 bug 大家的团队都是怎么对待的?

  •  
  •   yuhuan66666 · 2020-11-28 14:41:18 +08:00 · 4193 次点击
    这是一个创建于 1216 天前的主题,其中的信息可能已经有所发展或是发生改变。

    先说我们的

    不管多严重 如果原因是因为什么校验什么枚举判断错误之类 先数落你 怎么能犯这么低级的错误

    如果是你手下人写的 就数落你 为什么不给手下 review 代码

    如果 是外部业务因素导致的 比如 用户的等级千奇百怪 开发根本完全不了解没有兼容到 就说落你为什么没有想到或者单测覆盖到?

    好奇别的别的团队出现小 bug 和大 bug 团队都是怎么对待的 ?

    是不管问题大小 先数落一遍开发

    还是按不同问题严重性,不同对待的

    还是 谁没写过 bug 宽容对待的

    38 条回复    2020-11-30 20:35:55 +08:00
    wangkun025
        1
    wangkun025  
       2020-11-28 14:46:32 +08:00   ❤️ 5
    我们对待错误比较宽容,可能因为老板很懂,或者老板完全不懂(有敬畏之心)。

    其实这个问题挺简单的。
    首先是需求问题。
    其次是测试问题。
    最后才是开发。

    如果 BUG 是没考虑到的,就是需求的问题。
    如果 BUG 涉及的需求在文档里,测试没测出来,就是测试的问题。
    如果需求提出了功能,但开发实现不了,但别人家的开发能实现,才是开发的问题。

    换个角度看,BUG 其实跟开发一毛线关系都没有。
    HariopaNic
        2
    HariopaNic  
       2020-11-28 14:47:30 +08:00 via iPhone
    遇到 bug 首先解决问题,解决完说一下原因,比较低级的就说下次注意一下。
    hoyixi
        3
    hoyixi  
       2020-11-28 15:03:08 +08:00
    1 楼兄弟,很粗暴啊,是不是从来没写过单元测试
    wangkun025
        4
    wangkun025  
       2020-11-28 15:15:05 +08:00
    @hoyixi 写过。分担责任嘛。只折磨开发,有意思吗?
    yuhuan66666
        5
    yuhuan66666  
    OP
       2020-11-28 15:25:15 +08:00
    @hoyixi #3 说起单元测试 ,我们基本出了 bug 就 数落开发 单元测试没写或者单元测试覆盖度不够
    hoyixi
        6
    hoyixi  
       2020-11-28 15:25:47 +08:00   ❤️ 1
    @wangkun025 #4
    同意,不过,不管谁的问题,最后 bug 都还是开发改啊,哈哈

    bug 一出,先定位打击人群,类似楼主提的”数落一遍开发”,甚至还有扣钱的, 感觉这是中国软件作坊特征之一。

    出 bug 多正常的事,按照流程该干嘛干嘛,迭代就是了。可能很多公司连像样的“流程”都没有,只能让各部门内斗了。
    这现象不光 IT 业有,类似现象本质,感觉就是领导无能,于是为了显得自己永远对,就让下面部门或者人员互斗~
    yuhuan66666
        7
    yuhuan66666  
    OP
       2020-11-28 15:29:23 +08:00
    @wangkun025 #1 我上面 和 上面的上面都是开发干过来,但是我不知道他们是什么心理 都喜欢从自己下属找毛病,出了问题先怪自己下属,外部问题也能怪到自己下属身上,什么 为什么提前没沟通,为什么单元测试没覆盖到,为什么开发阶段没了解过这个问题
    yuhuan66666
        8
    yuhuan66666  
    OP
       2020-11-28 15:32:11 +08:00
    @wangkun025 #4 因为 是团队合作关系 开发团队 测试团队 产品团队 出了 bug 开发领导只能数落手底下开发,QA 和产品团队人家数落不到
    bojackhorseman
        9
    bojackhorseman  
       2020-11-28 15:38:51 +08:00 via iPhone   ❤️ 1
    反正发生什么不都是开发背锅🐴
    XDy0
        10
    XDy0  
       2020-11-28 15:43:56 +08:00
    先解决问题,然后再找问题发生的原因。主要是我好像没出过什么大的 bug,所以也没被骂过,很多问题都是我自己发现自己解决的= =
    yuhuan66666
        11
    yuhuan66666  
    OP
       2020-11-28 15:52:55 +08:00
    @XDy0 #10 上线后 自己发现的吗? 那你观察总结的时间挺多的 我们开发完一个需求 立即下个需求开始 把敏捷开发中的 双周迭代 概念单独拿出来用
    binux
        12
    binux  
       2020-11-28 15:56:44 +08:00
    wangkun025
        13
    wangkun025  
       2020-11-28 15:57:07 +08:00
    @yuhuan66666 关键是数落也没用。
    管理的问题不用管理的手段解决,毛用都没有。
    上面有人说了,就是作坊式的管理水平。
    007yxc
        14
    007yxc  
       2020-11-28 15:57:45 +08:00 via iPhone
    @wangkun025 ....你这逻辑 我很佩服
    yuhuan66666
        15
    yuhuan66666  
    OP
       2020-11-28 16:15:37 +08:00
    @wangkun025 #13 管理的手段就是 当出现一个问题数落完之后 问如何避免下次再出类似的问题, 然后又把问题推到了充分单元测试 提高单元测试覆盖程度 和 review 代码上
    whypool
        16
    whypool  
       2020-11-28 16:32:13 +08:00
    整个组背锅,然后影响年终奖
    zerofancy
        17
    zerofancy  
       2020-11-28 16:39:06 +08:00   ❤️ 2
    拿起手机,发现 iOS 那边也挂了,松了一口气。看来不是客户端的锅。
    yuhuan66666
        18
    yuhuan66666  
    OP
       2020-11-28 16:54:33 +08:00
    @whypool #16 小问题也这样么。。。。
    boris93
        19
    boris93  
       2020-11-28 16:57:48 +08:00 via Android   ❤️ 1
    首先受影响的人会来找我,告诉我出现什么问题了
    确认后,后 JIRA 上开 bug 单
    我按照紧急程度以及当前 sprint 的时间安排,决定是这个 sprint 修好,还是下个 sprint 再做
    修完了,测试,上线

    因为 bug 数落下属,只是发泄情绪而已,没啥实际用途。不如花心思在制定改进方案和落地上面。
    leavic
        20
    leavic  
       2020-11-28 17:02:34 +08:00
    谁写的 bug 拉出去祭天。
    seki
        21
    seki  
       2020-11-28 17:06:29 +08:00   ❤️ 1
    对事不对人,是人都能写出 bug 来
    对于今后的整改措施,是要从手段和方法上去避免和控制,因为人都会犯错,需要通过加静态检查,加测试来避免犯同样的错误
    SjwNo1
        22
    SjwNo1  
       2020-11-28 17:47:51 +08:00 via iPhone   ❤️ 1
    好好反思,耗子尾汁
    musi
        23
    musi  
       2020-11-28 17:57:43 +08:00
    是个开发多多少少都会写 bug 吧。。。真要说没 bug 那就是 no write, no bug
    cheng6563
        24
    cheng6563  
       2020-11-28 20:08:58 +08:00
    反正出事故都是开发的
    赚大钱都是运营的
    beidounanxizi
        25
    beidounanxizi  
       2020-11-28 20:15:51 +08:00
    一楼说的很对啊 不会真的以为单元测试 就能做好吧
    qiaobeier
        26
    qiaobeier  
       2020-11-28 20:17:05 +08:00
    1. 立即解决问题
    2. 会议回顾问题
    3. 扣责任人的奖金
    frankkai
        27
    frankkai  
       2020-11-28 20:43:39 +08:00
    如果是走了一个完整的“开发->测试->验收->发布”的流程 因为是团队,所以理所应当大家一起背锅
    akira
        28
    akira  
       2020-11-28 21:01:24 +08:00
    提交缺陷跟踪
    根据紧急程度安排优先级
    该谁改谁改
    测试
    上线
    cabing
        29
    cabing  
       2020-11-28 22:37:11 +08:00
    先修复 bug,非紧急情况下,再找写出 bug 的人,修复 bug 上线。
    railgun
        30
    railgun  
       2020-11-28 23:00:40 +08:00
    1 、补偿客户损失
    2 、定位问题
    3 、确定修复方案
    4 、临时修复
    5 、正式修复
    6 、事故复盘
    7 、修改发布流程,避免再犯
    8 、确定责任、惩罚措施
    dreamapple
        31
    dreamapple  
       2020-11-28 23:53:38 +08:00 via Android
    运维报故障
    写故障分析报告
    定级
    邮件通报
    还没遇到被领导请喝茶的情况
    nuk
        32
    nuk  
       2020-11-28 23:59:00 +08:00
    1. 写 report
    2. 能修就修
    3. 修不好就甩锅
    raaaaaar
        33
    raaaaaar  
       2020-11-29 09:51:27 +08:00 via Android
    楼上说得很好,我认为第一步应该是定位问题,解决问题,而不是一来就开始追责,那种领导最坑爹了,还有就是领导不会反思,不会开会大家一起思考,总结暴露出来的问题,虽然可能是开发的锅,但是通常都会暴露出开发流程的问题,但是有些领导根本不搞这些,就让你背锅,先把责任让你背着再说
    yjxjn
        34
    yjxjn  
       2020-11-29 11:16:56 +08:00
    1.提 ticket,报告问题
    2.定位错误,调查
    3.修改 BUG,做测试,测试没问题,MR
    wanguorui123
        35
    wanguorui123  
       2020-11-29 21:24:55 +08:00 via iPhone
    上线出现 bug,1 、定位问题和日志; 2 、看能否在线修复; 3 、无法修复立即回滚历史版本; 4 、无法回滚就立刻限制有问题的部分功能与发布公告; 5 、加班修复问题并发版
    ydpro
        36
    ydpro  
       2020-11-30 08:58:00 +08:00
    出问题,改 bug,结束。
    luozejian
        37
    luozejian  
       2020-11-30 09:00:31 +08:00
    忙着甩锅大部分人都是第一时间想到这个
    yuhuan66666
        38
    yuhuan66666  
    OP
       2020-11-30 20:35:55 +08:00
    @raaaaaar #33 更坑爹的是 会反思 但是反思出来都是开发的问题,都是因为开发没做某某控制,导致了 bug 。那解决办法呢,自然也是开发应该想到可能出现的问题,应该更全面的写单元测试。然后如果 开发需要 10 分钟写单测 10 小时,他就会觉得 你不够努力,为什么单测要那么久,既不想让开发占用工时写单测,又要求单测必须要全面。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   937 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 33ms · UTC 20:52 · PVG 04:52 · LAX 13:52 · JFK 16:52
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.