深信服社区»版块 综合类 畅所欲言 【开怼吧】20期:当项目上线后系统出问题,这锅该由谁来 ...

【开怼吧】20期:当项目上线后系统出问题,这锅该由谁来背?

查看数: 5482 | 评论数: 44 | 收藏 0
关灯 | 提示:支持键盘翻页<-左 右->
    组图打开中,请稍候......
发布时间: 2018-11-25 21:54

正文摘要:

本期辩论结果:共有 119 人参与投票 1.  产品得背:可能是产品考虑不完善;14.29% (17)        2.  开发得背:可能是开发偷懒;5.88% (7)     &n ...

回复

tj_zero 发表于 2018-11-26 10:19
我骑墙中,我认为这锅应该大家一起背,理由是团队协作共同完成的项目,上线时出现问题证明沟通出现的问题,并不能单独排除哪一个环节没有问题应该项目过程组成员一起面对进行风险和整理解决方案;
无论是产品体验,性能优化,监控部署每一个环节都会有沟通的环节,也就是说没有谁可以独善其身完全没有责任;
比如说:产品体验有问题为什么不及时反馈?性能优化不到位为什么准许上线?监控部署有问题为什么不及时解决以至于问题放大?
凝網_蟲爺 发表于 2018-11-27 15:28
我骑墙,但并不是一起背锅。
首先说一下这个选项就有点一刀切了。具体问题具体分析,什么样的问题是什么原因导致的,这个原因是由谁来实施的,那么追究责任人就有了方向。而其实绝大多数情况下,我们解决问题的目的并不是为了追责,为了把锅甩给谁,更多的是为了找到客户或者我们自身存在的问题,查漏补缺,使用户无后顾之忧。这才是我们IT人的使命和终极目的。
熙瑞 发表于 2018-11-27 20:44
我骑墙:我保持中立,我的观点是在真相没找到之前还是都客气点好,省的打脸。我是运维,我们经常碰见系统因为一个开发程序不能正常使用,开发程序的说是系统的问题,系统说是软件开发的问题,我们是谁也惹不起,只能一点一点的试试,相互协调。实在解决不了,就搁置争议  找其他东西代替想办法绕过去,实在绕不过去,就只能各方大佬请过来碰头一次性解决。我们出点饭钱大家吃点联络一下感情。真的是难为了我们实际使用的人了。
新手796028 发表于 2018-11-28 10:19
3、凭心而论,我认为运维应该背,请陈述您的观点
运维属于产品交付用户使用的最后一个节点,用户的满意度和使用的熟练程度,很大一部分都是靠运维来培训解决的。
一个再好的产品,如果用户不会使用或是使用不当,出了问题,但没有人能帮助解决,都会很大程度降低产品在客户心目中的地位。如果有一个好点的运维,很认真负责的帮助用户解决问题和引导用户正确的使用产品,会大大提高客户的工作效率和提升产品的品牌效应。   所以,如果项目上线系统出问题,我认为运维应该背锅。(前提是开发没人问题,不会出现代码错误,否则这个层面的问题不是运维可以解决的)
13638095227 发表于 2018-11-29 19:10
凭心而论,我认为开发应该背,观点如下:(因为我是运维
其一、产品的设计是一个不断完善的过程,所以项目上线后系统出问题,肯定不可能让产品大哥背;
其二、所谓的运维是就是修修补补的工作,项目上线后这么大的问题他们基本上沾不上边;
其三、一个产品的开发,核心人员就在于研发大哥,他们一行代码,甚至一个字节的错误都有可能造成系统的严重错误,他们的压力最大,责任也最大,所以这个锅他们要背;
当然,锅有人背,但其它人员不是站着看热闹,而且是积极协助研发大哥尽快把问题找出来,不然哪像 个团队
小泉 发表于 2018-11-30 09:01

凭心而论,我认为三人都一起背。
运维为什么要背?
运维是最后对接的那个人,出了故障第一阶段肯定是找运维,运维到系统故障,那你跑步了。
产品为什么要背?
运维有困难了怎么办,肯定需要把锅甩给产品,给自己找点无辜躺枪的感觉,这是本能反应吧。因为大部分稳定正常的系统有故障通常都是本身设备出现问题的几率比较大。
开发为什么要背?
开发是对自己产品最了解的吧?这个系统某一项功能可能有些不足 某些功能使用期间可能会出现一些状况 正常是知道的。能否优化,优化难道大小心里是有点数的,系统出问题,后面要优化要改善还是开发们的事,而且开发正常都是一群,一群人背锅好比运维一个人背锅强。开发们什么锅背不了呢。
这样一轮下来的好处是什么?
怪到产品本身问题 然后如果能找到优化的方法,后面还能少个故障点,把系统出问题转化成变成运维大佬发现了一个BUG。
yl2352 发表于 2018-12-1 07:24
我觉得应该是开发来背锅。产品到使用过程中,一定要适合单位的现实状况,而目前很多产品的开发工作呢,开发工程师都急于去了结这个项目,没有充分的调研,怎么样契合单位的实际运营状况,也没有考虑足够的配合实际工作,所以应该开发来背这个锅。很多成熟产品看起来很美,但是具体到一个单位,它有它固定的工作模式,不能完全按照产品的流程,所以要有一个融合过程,这个融合过程本来应该是开发工程师来完成的也是应该他所擅长的,可事实上很少有那种优秀的开发工程师能够承担起来这种融合工作,来的开发都太年轻了他们不是很了解耶,并不想去了解。我是运维
凡鸟末世 发表于 2018-11-30 10:16
凭心而论,在没有找出问题出在哪的情况下,这个问题应该大家一起先找出解决问题的办法,最后谁解决的不就知道锅是谁的了吗,所以说前期先一起背锅被
YiYunchen 发表于 2018-11-30 08:54

我骑墙:我保持中立
智能伙伴 发表于 2018-11-29 18:09
骑墙中立:观点
能非常明确责任的自然是相应出错的人背,难以分清即大家都不想背的,只能大家一起背了,界限可以说是很模糊的,但是也是有人可以明确界限然后做出背锅之人
vito 发表于 2018-11-29 14:37
我骑墙中,项目上线后出现问题,得看是哪方面的问题,是产品本身有缺陷,产品经理首当其冲,要是程式开发的问题,这开发也甩不开,最后是运维部署,如果是OS,硬件或者基础环境没部署好,这个锅就是运维的了,要是一个人就是开发有时运维,也就是俗说的Devops,这样开发运维就统一了,责任分明,谁也不用甩锅,也就没人背锅。
新手669092 发表于 2018-11-29 10:23
凭心而论,我认为运维应该背,请陈述您的观点:
开发多牛气,开发出来的产品肯定没问题,即使有问题,也是运维技术不到位,没有提前/及时发现问题,反馈问题,解决问题。运维是万能的接锅侠哦,亲!一脸懵逼的运维
gzlitao 发表于 2018-11-28 16:35
我骑墙:我保持中立 ,大家一起出来,谁独立背,谁都不高兴。