1.程序员并非刻意制造麻烦
2.本地测试无法达到线上的量级,发现不了问题
3.程序技术正常,并非因为技术欠缺导致低级的 bug
4.上线一段时间后,偶发的 bug
5.但是损失重大
6.测试组进行了常规测试
请问这个责任应该属于谁 1.程序员-技术不精 2.测试组-测试不利 3.项目经理-项目管理不善 4.老板-项目开发中必然的损失,归于公司
顺便延伸一个问题,如果线上发现了一个问题,用户莫名的流失(可能原因 1.系统有问题,导致用户使用不便 2.导入的这批用户有问题,不喜欢公司产品 3.内容推广有问题,没有吸引力等等),程序试用了各种方法,查找了各种日志,一无所获,是否可以说明程序无用,在摸鱼。
![]() | 1 cmdOptionKana 2020-12-22 11:40:22 +08:00 具体问题具体分析,没有具体细节,谁知道问题出在哪里? |
2 guisheng 2020-12-22 11:41:27 +08:00 通病就是:无论你是怎么做出这个系统的,有无 BUG 。没有达到预期的收入并还降低了收入,影响收益。 就算是创世神都会被谴责。 |
3 zengzizhao 2020-12-22 11:41:53 +08:00 ![]() 2.本地测试无法达到线上的量级,发现不了问题 3.程序技术正常,并非因为技术欠缺导致低级的 bug 这里看来可以说是某种程度上的技术欠缺,因为高并发经验不足,所以其实还是存在技术上的问题的,对吗 |
4 Jooooooooo 2020-12-22 11:46:14 +08:00 看你描述没说清楚是量级大了之后触发了很难触发的场景(比如极端情况的并发)还是量级大了之后容量导致了问题 如果是前者, RD/QA 一起背锅, RD 没有考虑到存在并发问题, QA 没有设计出对应的测试用例. 如果是后者, 负责压测的人背锅. |
![]() | 5 jr55475f112iz2tu 2020-12-22 11:48:56 +08:00 ![]() 楼主用 “程序员” 这个称呼,感觉就不是研发在问这个问题吧? 第一个问题:4 第二个问题:理论上这不是研发该回答的问题,是运营要回答的问题 |
![]() | 6 ligiggy 2020-12-22 11:49:49 +08:00 ![]() 找个几把责任人,出了问题,大家都有责任,赶紧把问题解决,下次开研讨会总结经验。 |
7 across 2020-12-22 11:51:40 +08:00 程序和测试(看具体 bug )领导主责,下属次责。 |
![]() | 8 bk201 2020-12-22 11:55:51 +08:00 找到让后让他背锅,然后下次谁都不想接这任务? |
![]() | 9 xuanbg 2020-12-22 11:55:55 +08:00 ![]() 肯定是领导担责任啊。 |
![]() | 10 3dwelcome 2020-12-22 12:01:30 +08:00 程序员光"尽心尽力"没用,出了问题必须要去解决,而且平时要重视技术积累,关键时候要有能力解决。 不能一边拿着高薪,一边说我尽力了,然后任由潜在 BUG 把用户劝退。 当年网游后端开发没完备的技术参考,全凭手写,只要服务器多崩了几次,游戏就凉了。这种案例比比皆是,所以招聘核心码农,要天赋+努力+写代码的热情,缺一不可。 |
![]() | 11 boris93 2020-12-22 12:03:32 +08:00 via Android ![]() 这不是一个人的责任,而是一个整体的责任 而且出了线上问题,先想办法解决 然后开复盘会,分析每个环节有什么缺漏 然后讨论如何避免 重点在修复流程和执行上的漏洞 如果光是抓人痛骂扣工资,毛用没有 |
13 tesguest123 2020-12-22 12:05:02 +08:00 via iPhone 找个外包让他背锅,doge 。我是外包,我为自己带盐 |
![]() | 14 redtea 2020-12-22 12:09:13 +08:00 架构师应该负大部分的责任。 |
![]() | 15 hoyixi 2020-12-22 12:13:25 +08:00 当然是领导的责任~ 但是,我国的特色是领导永远不会错~ 下面背锅~ |
16 lifetimeporn 2020-12-22 12:14:34 +08:00 当然是测试的错 |
17 sampeng 2020-12-22 12:15:07 +08:00 ![]() 这难道不是对于一个团队最值得庆祝的时刻吗?宝贵的经验是在一次一次问题中增加的。不会平白无故多出经验来。 假设这次事故损失 10 万。也就一个高级研发工程师 2 个月工资。但一个团队的经验值上涨,完全抵得过这个经济上的损失。 |
![]() | 18 tabris17 2020-12-22 12:22:02 +08:00 惨开《瑞穗证券的乌龙指事件》 |
![]() | 19 Vegetable 2020-12-22 12:23:19 +08:00 系统性问题 |
20 icew4y 2020-12-22 12:24:50 +08:00 via iPhone ![]() 请问系统盈利的能分钱吗?为什么出 bug 就要负责? |
![]() | 21 dawn009 2020-12-22 12:35:55 +08:00 没人有责任。接受现实。 3 楼说“这里看来可以说是某种程度上的技术欠缺,因为高并发经验不足,所以其实还是存在技术上的问题的,对吗” 不对 一个人只要没死没残,他始终能从任何成功和失败中获得经验,因此永远可以说他“经验不足”。只要“经验不足”是任何条件下的永真式,它就会失去用来分类的作用。 只有加上一个评价的基点:对此人能力的预期 才能评价他的经验足不足 |
![]() | 22 whypool 2020-12-22 12:37:00 +08:00 via Android 公司背锅 是教训,也是财富 |
![]() | 23 kop1989 2020-12-22 12:40:11 +08:00 1 、软件开发没有尽力一说。只有程序满足需求和不满足需求。 2 、软件出现问题一般有这么几种可能:( 1 )业务调研不成功,没有完全涵盖业务需求( 2 )产品设计不合理( 3 )开发人员没有 100%的实现需求内容( 4 )软件质量差、健壮性不足,有违软件开发常识。 其中( 1 )和( 2 )是产品 /项目管理的问题。根据原因会涉及到产品经理、项目经理、技术主管等决策层人员。 ( 3 )和( 4 )可以再继续解剖,因为程序不会无缘无故的质量差和未覆盖需求。 依照不同的原因,责任有可能归咎到项目的任何人身上。比如项目经理对于进度把控不到位,比如开发人员技术不到位,比如项目组人力短缺,技术选型出现失误等等。 3 、至于说延申的问题,你括号中的描述都是“产品”和“运营”的范畴。跟程序员扯不上关系。 |
24 djs 2020-12-22 12:41:53 +08:00 谷歌都能宕机呢 |
![]() | 25 westoy 2020-12-22 12:49:14 +08:00 这种事工程以外也蛮多的, 比如财务为了控制风险让采购控制采购量, 结果公关营销开了波大, 一堆订单压着但是没货了........ 预估到了就问责项目经理和架构, 没有预估产品和老板自己扛, 码农对得起自己工资就行了, 给多少钱干多少活儿 |
26 liuy1994g 2020-12-22 13:12:52 +08:00 我肯定没有责任,多半是领导的责任 |
27 fuxiuyin 2020-12-22 13:13:57 +08:00 权责统一,谁能从这个产品中获得收益谁有有责任去先办法把这个产品做好,不管是自己做好还是想办法让别人做好。不能做好了收益都是管理层的(组长 /总监...),出事了都是实际做事的人的。 |
![]() | 29 sagaxu 2020-12-22 13:16:09 +08:00 via Android ![]() 线上事故,个人认为至少有一半是超负荷工作和压工期引发的 |
30 ruokw 2020-12-22 13:18:04 +08:00 via Android 扔来扔去就会到程序员头上 别想了 跑不掉的 |
![]() | 31 Leonard 2020-12-22 13:18:12 +08:00 谁都不能保证程序没有 bug,Google,微软也不能。如果大家工作流程都没有问题,这里就不该追责,想怎么改进才是正事 |
32 helloworldgo 2020-12-22 13:21:06 +08:00 我不管测试测没测出来,出了 bug 就是程序员的问题,错了就是错了 |
33 dilu 2020-12-22 13:31:28 +08:00 你好,一般这种没有界限的失误,都是领导的责任,或者可以粗略的认为:谁拿的多就是谁的责任。 |
![]() | 34 yangguangxia 2020-12-22 14:15:54 +08:00 需求不明确的锅 |
35 forgottencoast 2020-12-22 14:18:56 +08:00 @dilu 并不是谁拿的钱多就是谁的责任。 我以前老板就很清醒,他说,人都是我招进来的,或者是我招进来的人招进来的,所以最终责任肯定在我身上。 |
![]() | 36 loryyang 2020-12-22 14:20:55 +08:00 ![]() 这种问题不属于技术问题,属于管理问题,怎么定责影响到各团队后续的做事方式和战斗力 按照你的描述,个人觉得最好的办法,还是公司层面把损失吃了,底层员工就事论事,提升后续的保障能力,包括灰度能力和实时监控+可应急 |
![]() | 37 otakustay 2020-12-22 14:27:12 +08:00 实现 BUG 的情况下,团队经理 35%,技术 Leader 35%,测试 15%,开发 15% |
![]() | 38 binux 2020-12-22 14:29:06 +08:00 via Android ![]() 如果让程序员背锅,下次能给你整个更大的你信不信? |
![]() | 39 locoz 2020-12-22 14:50:13 +08:00 via Android 前面的情况显然是流程的问题,代码质量保障只做了基本的事情导致的,锅是 CTO 或代码质量保障部门的,和开发、测试、项目经理都没关系。 但损失已经造成了,纠结这些没有意义,抓紧补漏并在事后完善流程才是关键。 结论就是责任给谁都不合适,且老板应有项目出现损失的预期,把这损失硬吃下就好了。 后面的情况怪开发干嘛?用户莫名流失这种问题的分析本来就不应该是开发一个人来做,而是应该运营、产品和开发一起做,整个操作流程都过一遍才能分析出具体问题在哪、应该怎么优化,单开发查日志、试方法有啥卵用? |
40 chenyu0532 2020-12-22 14:52:01 +08:00 1. 楼主估计不是程序猿 2. 我内心自私的认为想让程序背锅 3. 出了问题是团队的责任,只要不是故意为之就不能单纯的指责某一个人 4. 程序员没 NB 到不出错误,如果有这样的人,你们老板是雇不起 /舍不得雇的,所以要有自己赔这个损失的心理准备 5. 谷歌都能宕机,何况你们。。。 |
![]() | 41 reus 2020-12-22 14:57:56 +08:00 ![]() https://sre.google/sre-book/postmortem-culture/ Best Practice: Avoid Blame and Keep It Constructive An atmosphere of blame risks creating a culture in which incidents and issues are swept under the rug, leading to greater risk for the organization 谷歌这篇说得挺好的。损失既然已经造成,再找人背锅也挽回不了损失,何必呢。背锅文化只会让人以后倾向于掩盖问题,反而搞出更大的事故。 |
42 Lemeng 2020-12-22 15:04:25 +08:00 凡事无绝对,原因出来了,该谁就是谁。测试也是根据需求来。 |
![]() | 43 feiandxs 2020-12-22 15:06:21 +08:00 ![]() 我的责任,行了吧。 我就很看不惯这种,遇事后不是第一时间想着解决问题,而是找责任人。不是一起复盘总结宝贵的经验,各部门一起坐下来好好看看今后有什么可以改善的地方,当前的问题有哪些合理的解决办法,而是来找『谁的问题』。 真要找人的问题,应该是每个人都冲上去说是我的问题。 如果是找别人的问题,这个找问题的人就是最大的问题。 |
44 frankkai 2020-12-22 15:13:50 +08:00 团队的责任。 |
45 ahill 2020-12-22 15:27:23 +08:00 谁有权利能避免或解决这个问题是谁的责任。 从这个角度看测试,开发,总监,老板都有责任 测试在压测及场景覆盖度不足, 开发细节并发经验 review, 总监 release 流程,尽早保留问题发现问题减少损失的机制 有责不一定就要有惩。如果要有惩,谁获利最大惩谁 |
![]() | 46 linoder 2020-12-22 15:29:14 +08:00 所以需要流程规范 …… 你需求评审 技术评审 代码 REVIEW 都搞了 那么大家帮你背锅 如果你跳过了某一步 那就得你自己背锅了 |
![]() | 47 suyongfu 2020-12-22 15:30:42 +08:00 定位问题,分析问题,解决题。 以上三个步骤走完之后基本上就知道是谁的锅了。 |
48 charlie21 2020-12-22 15:39:22 +08:00 评估组 |
49 zhuweiyou 2020-12-22 15:39:47 +08:00 是软件就有 bug, 不应追责, 应想办法解决 /优化 |
![]() | 50 hahiru 2020-12-22 15:45:53 +08:00 快,程序员,甩锅给他,稳准狠。谁叫他不能预测所有 bug 。 不能因为损失重大就一定要找个人背锅。 一定要背锅的话来找我吧。 我,秦始皇,有钱。 |
![]() | 51 murmur 2020-12-22 15:47:18 +08:00 大家一起背锅,如果隐瞒不报肯定你全责,如果发现问题提前提出,然后有意外再一起分锅 |
![]() | 52 DelayNoMay 2020-12-22 15:51:53 +08:00 @ligiggy 你这不是废话吗,人家说问责,你扯处理问题。你怎么知道楼主公司没有先解决了问题?解决问题之后难道不应该事后问责,以防再次发生类似的事故吗? |
![]() | 53 imdong 2020-12-22 15:54:24 +08:00 via iPhone ![]() 这话说的,谁还不是尽心尽力了?你们程序员尽心尽力了,我们产品,测试,运营等都没尽心尽力? 谁背锅还不简单,没话语权的,最不会甩锅的背锅呗。 出问题还不赶紧解决,找人背锅有用么? 有这功夫不如想想以后怎么避免这种事情的发生。 |
54 iceneet 2020-12-22 15:54:37 +08:00 我觉得都有责任 不过比起追责 最重要的是事故后的处理和总结 避免下次事故 毕竟已经损失的已经追不回来了 |
![]() | 55 ligiggy 2020-12-22 15:55:26 +08:00 @DelayNoMay 除了问题,就一定要问责?你想咋的,避免下次问题的关键是分析问题点,总结经验,避免下次犯错,而不是问责,问责就能避免下次犯错? |
![]() | 56 DelayNoMay 2020-12-22 15:56:03 +08:00 @feiandxs 随便扣帽子你最行,要是没第一时间去解决问题,楼主还有闲情来发帖? |
![]() | 57 mamahaha 2020-12-22 16:07:56 +08:00 知道为啥没人敢动屎山了吧,出了问题你试试。 |
58 hejw19970413 2020-12-22 16:09:23 +08:00 我认为还是对事不对人。如果你按照公司的规章制度和正常的流程走出了问题,修复就可以了,如果你比如开发完了不按公司规定走或者是自测没有测试之类的,只能自己交点学费了。 |
![]() | 59 DelayNoMay 2020-12-22 16:10:59 +08:00 @ligiggy 难道问责和分析问题,总结经验冲突?二者只能取其一?总结完教训,然后对造成事故的责任人进行适当的问责,以作警醒是很合情合理的,小问题问责确实说不过去,但楼主都说了,这个损失是巨大的。我真的觉得你的逻辑很搞笑,问责这个词自始至终贯穿中国整个社会,从家庭学校到企业 zf,出了重大事故,无一不问责。适当的问责还可以提高整个团队的责任心氛围。按你的逻辑,很多违法犯罪的人也是总结下经验,避免下次再犯,然后就逃过民事或者刑事的处罚? |
![]() | 60 ligiggy 2020-12-22 16:12:20 +08:00 @DelayNoMay 你继续发挥,哈哈 |
61 lsl233 2020-12-22 16:12:32 +08:00 我觉得这个问题和 `尽心尽力实现的功能` 没有关系,问题应该是 `上线出了问题,责任是谁的。` |
![]() | 62 Oleg 2020-12-22 16:17:57 +08:00 线上锅一起背啊,整条链路都要反思 |
![]() | 63 shm7 2020-12-22 16:23:17 +08:00 via iPhone leader 和该员工一起扛 |
![]() | 64 ElmerZhang 2020-12-22 16:29:43 +08:00 ![]() 肯定是公司承担呀 打个比方:按 8 级地震标准建的房子,结果发生 9 级地震塌了,责任是谁的? |
![]() | 65 stormysky 2020-12-22 16:38:07 +08:00 不做就永远不会有问题 |
66 kx5d62Jn1J9MjoXP 2020-12-22 16:41:32 +08:00 还是技术问题 偶发 bug 也是 bug |
![]() | 67 cking 2020-12-22 16:45:43 +08:00 我们公司因为开发的问题损失了 100 多万 然后 只是开会商讨了怎么把损失降低到最低 没有追责.但是项目负责人奖金没了 |
![]() | 68 xianxiaobo 2020-12-22 16:47:04 +08:00 第一个问题我选择 4,第二个问题我觉得不能说明。 第一个问题可以靠请有经验的技术大牛来解决。 第二个问题可以靠请运营来解决。 单纯搞责任制,怪某个人,并不能解决问题。 |
![]() | 69 justsosososo 2020-12-22 16:47:26 +08:00 运维先背,运维背完测试背,测试背完你在背 |
![]() | 70 yousabuk 2020-12-22 16:49:08 +08:00 via iPhone 无责 |
![]() | 71 intmax2147483647 2020-12-22 16:58:09 +08:00 ![]() 所有把这种问题责任归于个人的公司都是傻逼公司,傻逼老板。 |
![]() | 72 wupher 2020-12-22 16:58:30 +08:00 架构师, 如果没有架构师,那就讨论一下没有架构师算谁的责任。 互联网项目,我觉得架构还是挺重要的。 非功能性需求可能不能保证项目会火,但确实会影响项目会不会灭。 |
![]() | 73 VictorJing94 2020-12-22 17:03:32 +08:00 测试问题啊,测试要是免责那必然要提前申明做不了某种测试,肯定要项目点头,项目经理没做好风险管理,要是项目也想免责,那就要提前给老板做过风险汇报吧....那责任往上传导了...程序员就是个施工的.....按图纸做,被动等着检查的,有啥责任 |
![]() | 74 opengps 2020-12-22 17:05:34 +08:00 遇到问题,什么都不做的才是应该担责任的 |
75 fengpan567 2020-12-22 17:15:01 +08:00 ![]() 一看就是想着压缩工期上线,结果线上出 bug 了,又想让开发背锅 |
76 calpes 2020-12-22 17:16:55 +08:00 ![]() 这个情况,定责完全看你们给了程序员多少钱。 给到了大厂平均水平的数目,那完全是程序员的责任,作为值这个数的程序员应该考虑到高并发或者大用户量的情况下应该出现什么样的场景,这是应当应分得事情。 只给了小破厂平均水平的数目,那程序员没责任,你出这点钱就想要个大厂高工架构师,是不是想太多了? |
77 zzl93 2020-12-22 17:24:59 +08:00 ![]() 整个流程都走下来了,没发现问题,是之后才发现的 bug,那只能怪你们公司对项目上线后的监控不到位吧。没有对用户数据很敏感或者专门研究数据这块的相关人员吧。 还有,发现问题导致的用户流失,这个问题是 bug 还是功能上的问题,如果是 bug,是否改好很明显吧,改不好肯定就是程序员当前能力处理不了这个问题了。改好了至于用户是否回来和开发无关吧。 或者说你们想查是不是因为这个问题导致用户流失,我认为这要记录用户的操作习惯的数据吧,例如你们程序用户操作访问某个模块的数量一直在 800-1000 之间徘徊,某天突然降到了 700,这肯定就要排查这个模块是否有问题。 还有用户调研啊,调查问卷的设计等等。 没有数据,没有一定的分析报告,谁也不想背锅哈。而有数据,有分析,那可能早就发现这个问题并解决了吧。 。。。。。。。。 突然又想到了,有了数据分析师,他如果摸鱼去了怎么办。。。。/手动捂脸 |
![]() | 78 liion 2020-12-22 17:34:16 +08:00 出现线上问题,应该考虑流程上减少问题出现的概率或者减少损失的方法,因为下次还会新问题的。硬要找个人被的话,就找个想炒的人吧 dog : ) |
![]() | 79 xFrye 2020-12-22 18:02:02 +08:00 比较反感的是一上来就找背锅的。正常来说不是解决问题然后检讨么,保证不要再次犯同样错就好 |
![]() | 80 clxtmdb 2020-12-22 18:11:56 +08:00 赞同楼上一些观点,取决于工资 |
81 liian2019 2020-12-22 18:14:17 +08:00 有事一起扛呗,老大们冲在最前面 |
82 seanxx 2020-12-22 18:14:20 +08:00 责任是大家的,如果责任是某个单一的人的话,那其他人是来做什么的? 吃干饭的? |
84 Still4 2020-12-22 18:27:56 +08:00 这种事情为什么非要追责,明显就是整个组一起扛啊,高并发环境下偶发 bug 很可能因为架构原因导致的,大家一起想办法解决问题才是关键,责不责的没什么用,你给他定责他就能解决了吗 |
85 charlie21 2020-12-22 18:35:38 +08:00 扛是不可能扛的,你爱扛你自己扛 。肯定是个人责任,定责不清建议不要开公司 |
![]() | 86 jsjgjbzhang 2020-12-22 18:39:21 +08:00 一般是 qa 承担责任,老板承担损失,程序员看情况是开还是不开 |
87 leewi9coder 2020-12-22 18:41:10 +08:00 是自己的, 为什么要当程序员 |
![]() | 88 morizawatt 2020-12-22 18:52:25 +08:00 肯定要权责分明的,lz 也没说题外的,这么多人猜想题外 /怼问责的人干什么?不问责的 ls 几位你们公司都没有绩效奖 /季度奖 /xx 奖这些?优秀员工应该有吧?人员优化 /内部调整没有依据乱来吗? |
89 Still4 2020-12-22 19:02:21 +08:00 @morizawatt 先解决问题,问题解决不了光问责有什么用,线上继续出问题,每个月继续追责逼人离职吗?再说问题都不知道在哪你定谁的责,要我说服务器性能不够,运维的责,你问问运维服不服 |
90 hsuvee 2020-12-22 19:12:42 +08:00 讨论这么激烈,都想啥呢,造成重大损失,定责肯定是开发 |
![]() | 91 3dwelcome 2020-12-22 19:35:32 +08:00 @calpes 也不完全是钱的问题。钱多钱少能决定开发出来的软件,是上中下里某一个等级。但这种能把用户劝退,导致大量流失的 BUG,就是关系到及格线的问题了。 码农写出的代码,始终和美术不一样,有底线在,不是钱少画丑一点也能接受的。后台恶性崩溃 BUG 能让所有团队成员的付出,付之东流。 |
![]() | 92 beidounanxizi 2020-12-22 19:43:54 +08:00 一般来说 这种问题 很难界定 , 别自己背锅 或者被迫背锅 一定要甩锅出去 更要记住 接需求的时候 如何甩锅 这种甩锅是合理性的 |
93 ryanlid 2020-12-22 19:54:28 +08:00 谁拿的钱多,谁担责 |
![]() | 94 xiangbohua 2020-12-22 19:58:17 +08:00 按照国内一半公司的做法,开发居多吧。 |
![]() | 95 cutlove 2020-12-22 19:58:30 +08:00 |
![]() | 96 Leigg 2020-12-22 20:10:03 +08:00 via iPhone 楼主你这话说的就有毛病了,你说你尽力了,那你言下之意就是其他人没尽力了。那你的说法就应该是流程的问题,不应该来追究某个人的责任。如果上面硬要追究某个人来承担责任,如果真的追究到你的头上,那你就提桶跑路吧,没没得救了。 |
97 yeqizhang 2020-12-22 20:33:40 +08:00 via Android 如果有测试用例,测试测漏了,测试的锅。 如果线上的非常隐蔽的 bug 真要开发负责,建议,代码 review 的人也要负责,连带这个开发的领导也要负责,顺便让招这个开发的 hr 也负责吧,谁让他招聘进来的呢[dog] |
![]() | 98 tiedan 2020-12-22 20:42:50 +08:00 对于延伸的问题 有没有人解答 |
![]() | 99 tiedan 2020-12-22 20:45:01 +08:00 海恩法则: 每一起严重事故的背后,必然有 29 次轻微事故和 300 起未遂先兆以及 1000 起事故隐患。 |
![]() | 100 A3 2020-12-22 20:57:24 +08:00 via Android 你尽全力了吗 |