同事 A 写了个方法,同事 B 调用了 A 的方法 导致线上直接宕机 这个锅该谁背。。
yasumoto · 2021-01-11 10:28:06 +08:00 · 32562 次点击这是一个创建于 1446 天前的主题，其中的信息可能已经有所发展或是发生改变。
公司服务器连续几次宕机，导致有很多业务数据没进来，我们投放是花了钱的 后面找问题发现
是同事 A 写了个 sql 在 mybatis 里面用的<where><if xxx != null> xxx=xxx<if>....</where>类似这样的
同事 B 调用了这个方法，但是他的业务有的时候值没有 导致查询全表 1000 万的数据 机器直接卡死了
在阿里云显示慢 sql 执行了 500 多秒 - -
今天业务找过来说让员工负责一部分损失 ，问问大家 这个损失应该谁背呢
是同事 A 写了个 sql 在 mybatis 里面用的<where><if xxx != null> xxx=xxx<if>....</where>类似这样的
同事 B 调用了这个方法，但是他的业务有的时候值没有 导致查询全表 1000 万的数据 机器直接卡死了
在阿里云显示慢 sql 执行了 500 多秒 - -
今天业务找过来说让员工负责一部分损失 ，问问大家 这个损失应该谁背呢
第 1 条附言 · 2021-01-11 14:23:44 +08:00
总结了大家提供的宝贵意见
1.测试的锅--->这个跟测试没关系 因为是小需求半天工作量 年底测试也正在其他项目中就没参与
2.A 的锅--->写的方法没有加参数拦截 导致别人调用全表查询
3.B 的锅--->自测不全 调用别人的方法没有仔细 review 导致系统宕机
4.领导的锅--->上线合并代码没有仔细检查 埋下了隐患
这两天我们研发和测试会在开一个集体会讨论下以后怎么避免类似问题 和这次问题的后续处理
哎头疼，年终奖还没发 希望公司不要拿这事给我们做文章
1.测试的锅--->这个跟测试没关系 因为是小需求半天工作量 年底测试也正在其他项目中就没参与
2.A 的锅--->写的方法没有加参数拦截 导致别人调用全表查询
3.B 的锅--->自测不全 调用别人的方法没有仔细 review 导致系统宕机
4.领导的锅--->上线合并代码没有仔细检查 埋下了隐患
这两天我们研发和测试会在开一个集体会讨论下以后怎么避免类似问题 和这次问题的后续处理
哎头疼，年终奖还没发 希望公司不要拿这事给我们做文章
 |
201
suyuyu 2021-01-11 18:12:15 +08:00  8
ali 的锅，机器不行导致 100w 数据就 GG
|
 |
202
mushishi 2021-01-11 18:26:59 +08:00
规范需求整个生命周期流程，责任就很好划分了。这样不是自己的锅不会扔到你头上
|
 |
203
bianqurenfm 2021-01-11 18:42:24 +08:00
只有当公司个个都能独当一面的时候才能谈责任和背锅，小团队还是以解决问题为主，否则产品不专业，测试不专业，写代码的不专业，那么这公司基本上天天都在找背锅侠：）
|
 |
204
Cloudia 2021-01-11 19:28:23 +08:00 via Android 6
槽点太多不知道从何吐起
1 、权责不对等。让员工负责的前提是员工有调配相应人财物的权力，目前来看 AB 都没有让测试配合的人员调配权力。 2 、项目管理人员 /技术领导缺失。按权责对等来看，项目管理人员和技术领导才有权力给安排测试或者进行总体代码 review，在上线前应该确认功能通过测试。 3 、相应编程规范缺失。大概是技术领导缺位导致的，事后才说 A 该拦截 B 该怎样怎样没有意义，应该事前就由技术领导约定接口规范。 出现这种事情先想谁来背锅的话，未来你们的技术问题会慢慢变成奇葩的办公室政治问题，别问我是怎么知道的 |
 |
205
lj2016 2021-01-11 19:31:27 +08:00 3
真是笑了,员工负责损失? 员工是大股东吗?
|
 |
206
tomjiangg 2021-01-11 19:38:26 +08:00
几年以前在数据库中间价加过一个功能，如果 sql 没有 where 条件，或者 where 条件恒为真，直接返回错误
|
 |
207
mlsnatalie 2021-01-11 19:40:17 +08:00 via Android 2
@yasumoto 好神奇啊，那要是广告效果不好，导致钱也浪费了，那这个损失是产品背还是运营背？
|
 |
208
vinceall 2021-01-11 19:57:00 +08:00 via Android
测试>B>A
|
 |
209
jiangzm 2021-01-11 20:11:45 +08:00
责任要划分，但是损失应该是公司承担，不然以后谁还敢放手做事情。
|
 |
210
zzzzzzggggggg 2021-01-11 20:15:46 +08:00 1
主要责任在于 B，次要责任在于 A
|
 |
211
pjntt 2021-01-11 20:17:45 +08:00
算部门领导的锅
|
 |
212
sampeng 2021-01-11 20:20:06 +08:00 via iPhone
A 和 B 都没责任。违反了工作条例哪一条？但要查不出来为什么，那就是这两个都有责任。
|
 |
213
wangbenjun5 2021-01-11 20:40:33 +08:00 1
这个真火，首先得喷这种垃圾公司
其次真要抓人背锅，我觉得都有锅，没有测试也能上生产？？？ 另外直接开发人员的锅比较大，至于写这个方法的人没有锅，项目里面烂代码多了去，谁知道当初写出来是干啥的，你如果要用肯定要做好自测啊 最后，如果项目有负责人，应该是负责人承担，比较位高则重，工资又高还不干活，负点责任咋啦 |
 |
214
soulmt 2021-01-11 20:48:48 +08:00
所以开发不应该相信自己的代码 还是得交给测试
|
 |
215
ditel 2021-01-11 20:55:09 +08:00 via Android
@mlsnatalie 这个广告了预见的和不可预见的难道不是运营该在前期就考虑到的吗？照这样的流程来看，员工还是放弃更新线上的吧，让公司的 ceo 什么来更新线上，不然担不起这么大的责任
|
 |
216
flowercoder 2021-01-11 21:31:53 +08:00
再忙也要测，尤其是产品交付这种，只能说不要再有下次了，否则商务那边很难做了
|
 |
217
akira 2021-01-11 21:54:05 +08:00
流程规范好 比什么都好
|
 |
218
isnullstring 2021-01-11 22:44:30 +08:00
什么鬼公司，正经公司一般都只会罚部门管理级的人，这还具体到做事的人？
|
 |
219
fakeshadow 2021-01-11 22:46:43 +08:00 1
呵呵，让员工承担损失。
|
 |
220
hugo54 2021-01-11 22:57:22 +08:00
测试完全没参与，甩锅给测试？疯了吧？
|
 |
221
danhahaha 2021-01-11 23:09:36 +08:00 1
希望以后部分代码由 ai 去做，哪怕一小部分，然后大家就可以甩锅给 ai，这才是 ai 的最佳使用场景。
|
 |
222
cubecube 2021-01-11 23:18:16 +08:00
谁提出来的让研发承担损失，下次代码就由 ta 来写
|
 |
223
doun 2021-01-11 23:19:23 +08:00 via Android
你们领导应该去怼一下，出问题了该承担部分损失，没出问题就该有一部分收益吧
|
 |
224
FS1P7dJz 2021-01-11 23:37:46 +08:00
2333333333
损失员工背,利润老板拿??? 开公司本来就是风险的 这个风险并不仅仅是指市场和外部竞争的风险,当然也包括了自己团队失误产生额外的经济损失风险 你非要员工赔偿也可以 首先你必须要举证自己的损失是多少 你做活动花了多少钱,并不代表就一定有多少钱的收益 又不是固定财产或者生产资料损失,比如砸坏电脑等 这种纯粹的营销数据是很难界定实际价值 |
 |
225
polyang 2021-01-12 00:13:37 +08:00
@lancelee01 你的看法我有点不赞同，这责任怎么都轮不到 A 吧，A 只是写了个方法给 B 调用而已，我怎么知道 B 的业务场景是怎么样的？照这样子说，我对接了第三方开放出来的接口，然后因为我们业务不严谨导致接口调用出错了或者时间太长了，这个时候我还可以去追究第三方的责任吗？
|
 |
226
xy90321 2021-01-12 00:39:20 +08:00
说谁会自测准备 1000w 数据的那条 xswl
谁要你准备 1000w 数据了... 最起码执行计划看看问题吧 然后线上数据什么规模都不知道，性能观点都没有就贸然开始 coding 的，在我们这儿也就是一直零绩效的命了 |
|
227
xy90321 2021-01-12 00:42:40 +08:00
然后回到正题，既然是业务上可能为空，那就是设计的锅
谁设计的谁背，但最多也就是有限责任 在我们这儿也就是当月绩效扣光外加请全组下午茶一周到一月不等（或者按照其他事前约定行事） 项目成功不分红，出事了要赔偿的都是耍流氓，风险收益严重不对等那就是强制剥削 |
 |
228
kimgo110 2021-01-12 02:22:56 +08:00 via Android
肯定 B 啊…不然他工资是白领的？
|
 |
229
icorgi 2021-01-12 08:16:09 +08:00
这什么公司，发出来避个雷
|
 |
230
rapperx2 2021-01-12 09:07:08 +08:00
要我说就是连带关系，所有都背
|
 |
231
v2eros 2021-01-12 09:10:06 +08:00
至少 A 没问题
|
 |
232
lei2j 2021-01-12 09:10:34 +08:00 via Android
现在出个 bug 都要赔偿了？
|
 |
233
tairan2006 2021-01-12 09:13:26 +08:00
没做慢查询日志告警吧。。
|
 |
234
kergee 2021-01-12 09:14:43 +08:00
有没有人说说最佳实践，因为如果我是同事 B，也很有可能忘记
|
 |
235
weizhen199 2021-01-12 09:16:57 +08:00
全都有锅啊
领导的锅是逃不掉的，员工有啥事上级都有责任是逃不掉的。 A 和 B 的锅就要具体砍了。这个 A 写的方法是公用的还是私用的。 |
 |
236
hyqCrystal 2021-01-12 09:22:07 +08:00
领导就是用来背锅的 不然要领导干嘛？形象大使吗
|
 |
237
jinhan13789991 2021-01-12 09:22:45 +08:00
知道保险公司是干什么的吗？知道大额保单的保险金是多少吗？不买保险还想理赔，想得美啊。
|
|
238
polyang 2021-01-12 09:22:48 +08:00
讲真，出了 BUG 让员工背损失的，我是头一次见（可以扣绩效啥的，但是直接背损失就说不过去了）。老板赚钱的时候怎么不想着员工呢？
|
 |
239
SunnyCoffee 2021-01-12 09:24:16 +08:00 1
如果这个功能没问题的话谁受益，谁受益谁承担。不可能光受益不担风险
|
 |
240
g0thic 2021-01-12 09:27:53 +08:00
相关人员年终考核绩效不达标 年终少发一点
|
 |
241
notejava 2021-01-12 09:45:41 +08:00
同样的问题曾经出现在我的身上，调用了老大的方法，以为没值的时候返回 Null，谁知道返回空字符 ""，导致损失了很多投放的广告预算，其实是我的锅，最后老大帮我背了[捂脸]。
|
 |
242
wolfie 2021-01-12 09:49:36 +08:00
A 100% 无责任。
|
 |
243
adsltsee 2021-01-12 09:50:37 +08:00
测试>B>A
|
 |
245
xmx12138 2021-01-12 10:16:03 +08:00
这让员工背锅真的是过分了啊，首先测试没介入就上线的需求就根本找不到开发的锅，跟测试也没关系，人家根本没参与啊，这是内部管理流程的问题。
|
 |
246
freelancher 2021-01-12 10:32:27 +08:00
做得好了。业绩是领导的。做得差了，锅是员工的。奇葩思维。
首先肯定是领导的锅。 然后是 B 的锅。A 的锅，我觉得不应该。写的时候就想不到有人这么智障。 |
 |
247
Vegetable 2021-01-12 10:38:35 +08:00
出了问题扣绩效，可以。
承担损失，跑路。 |
 |
248
48555247 2021-01-12 10:47:35 +08:00
如果是 A 告诉 B 可以调用这个 SQL，那 A 有一部分责任，没说清楚自己的使用场景加告诉限制。
如果 B 只是看到有这个查询的 SQL 就拿来用，B 的锅没跑了。 |
 |
249
atonku 2021-01-12 10:50:34 +08:00
啥破数据库啊，一千万都能这么慢，设计数据库的要担责；
测试人手不足就直接上正式，谁允许的谁担责，比如开发部领导； 可以对员工提出问题，但是真要罚钱，那就真的是愚蠢了。 建议楼主不是领导的话，趁早跑路。 |
 |
250
BZxiansen 2021-01-12 10:52:39 +08:00
这种事情，分不清楚，就按实际操作来呗。
首先损失公司承担，然后公司找 boss，boss 找负责人，负责人找职位领导，领导再找动手的。 一层一层下来，风险承担也越来越小，一开始就找最下面的背锅，人家能不能背的起都是个问题。 |
 |
251
mz02005 2021-01-12 11:09:08 +08:00 via iPhone
让我想起了电影《 a 计划》中，成龙指着元彪说的那几句话
|
 |
252
free1978 2021-01-12 11:16:54 +08:00
让业务去死。程序员写错代码还要负责损失？那写对了挣钱公司是不是给提成 50%？
|
 |
254
ns20 2021-01-12 11:31:50 +08:00 1
这个问题为何要把 A 拉进来，无论如何追责，肯定不会追到 A 头上。
|
 |
255
ohhe 2021-01-12 11:39:59 +08:00
构架有问题。就算出现这样的问题也不应该连续几次宕机吧
|
 |
256
nowto 2021-01-12 11:42:21 +08:00
[要看 A 写的方法有没有完善的文档（比如 javadoc ）注释]
应该按照文档约定调用方法；文档上应该说明不合理调用产生的风险。 1. 如果 B 完全按照文档说明调用方法，发生了意料之外的 bug，那么应该 A 背锅。 2. 如果 B 没有按照 A 的文档说明调用了方法（比如没有仔细阅读文档，便调用了方法），或者干脆就没有文档，B 背锅。 这时，B 应该找 A，让其首先完善文档。 最好的做法，A 的方法应该做防御性编程，检测不合理调用并抛出合适异常，同时文档上也应该做说明。 |
|
258
nowto 2021-01-12 11:55:14 +08:00
我只是从 A 和 B 两个人来说，哪个应该担责更多，不同意应该让员工赔偿损失。
一个团队，出现问题不会只是一个人的责任，我同意“不管什么错，leader 都应该有责任”。 |
 |
259
shyling 2021-01-12 12:05:30 +08:00
dba 的锅，这么慢的查询都不管的吗^_^
|
 |
260
noparking188 2021-01-12 12:56:35 +08:00
反正不是基层员工的锅
|
 |
261
yinxianwei 2021-01-12 13:25:34 +08:00
话说代码没人审核吗？
|
 |
262
guokeke 2021-01-12 14:38:57 +08:00
@yasumoto 如果以后赚的钱也给员工承担一部分那就没问题，如果只是拿工资干活，那上线流程也没走，只是程序做完了就上线，那还要其他人干什么？所以说还要看这员工是给自己打工还是只是单纯打工人。
|
 |
263
zzzmh 2021-01-12 14:48:08 +08:00
我的经验是负责人背锅，一般一个项目要有个负责人，分派任务，审核代码，看测试报告，上线以后还要跟进数据和运行健康情况。如果员工每个人都自己写自己的，也没人统筹负责，那废了。
|
 |
264
imkerberos 2021-01-12 14:50:51 +08:00
还好不是 free API 接口，否则 GNU 和微软有的赔了。
|
 |
265
nolynfeng 2021-01-12 16:22:46 +08:00
如果非要背锅，B 和技术负责人，B>技术负责人，既然在调用别人的方法，那肯定需要考虑到调用会产生的情况，这属于考虑全吧，技术负责人没有对代码进行审核就上线，或者说审核没有发现问题，也需要承担一定责任，没测试也就不说什么了，并不是所有公司都有测试。。。
|
 |
266
JiafuYuan 2021-01-12 16:40:05 +08:00
首先是公司责任,其次是领导责任,按收入比例依次承担,责任员工可以处罚,但不需要为错误承担损失.
|
 |
267
stevenkang 2021-01-12 17:47:55 +08:00
修的房子跨了，责任算在码砖的工人上？
修的桥塌了，也算在修桥的工人上？ |
 |
268
jimmyismagic 2021-01-12 19:07:59 +08:00
测试不会测出这么大数据量来的，所以还是开发 b 背锅，自己用别人的代码前当然得学习怎么用
|
 |
269
dorothyREN 2021-01-12 19:34:28 +08:00
A 的错，错在不该让 B 用这个接口
|
|
270
polyang 2021-01-12 19:53:44 +08:00
@imkerberos 哈哈，怕是要直接赔破产了
|
 |
271
elintwenty 2021-01-13 10:53:44 +08:00
这个锅要么是测试的，要么就是你们领导的。从正文里补充的“测试不背这个锅”来看，就是你们公司 /领导有问题。因为没有一个完整且有效的流程覆盖实际情况，更不用说各种监测、预警机制以发现、感知故障。出错难以避免，预防出错的制度才是解决错误的最好方法，仅仅靠单个人的主观意识不可能分毫无虞。如果靠研发在开发过程中为这种事情做最后的保障，也可以说质量毫无保障了。
|
 |
272
Habyss 2021-01-13 13:12:35 +08:00
我的第一关注点是, 承担的损失是多少...
少的话,几百块,大家平摊,当个教训,然后一起总结怎样避免类似的问题. 多的话,直接离职,爱咋咋滴. |
Select Language