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

本期辩论结果：

共有 119 人参与投票

1.  产品得背：可能是产品考虑不完善；14.29% (17)        

2.  开发得背：可能是开发偷懒；5.88% (7)        

3.  运维得背：可能是运维没配好环境；7.56% (9)        

4.  骑墙： 这口锅，大家一起背！72.27% (86)   

感谢大家的参与！    

本期优秀辩论者如下：

---

三足鼎立时期，曹魏、蜀汉、东吴三分天下，

IT时代，产品、开发、运维三分鼎足；

都说产品与开发是天敌，运维是最大背锅侠，

今天，我们要辩论的话题是：

当项目上线后系统出问题，这锅该由谁来背？

这锅是产品考虑不完善？是开发偷懒？还是运维没配好环境...

---

【本期辩论话题】

（欢迎所有条理清晰，观点充分的言论。精彩发言回复、优秀辩论水平，

令人拜服的论据，甚至是跳出正反方之外独特论点都会获得相应奖励哦～）

---

【主要观点】

观点1: 产品应该背：可能是产品考虑不完善；

观点2: 开发应该背：可能是开发偷懒；

观点3: 运维应该背：可能是运维没配好环境；

观点4: 这锅，大家一起背；

---

【辩论时间】

2018年11月26日 -- 2018年12月01日 23：59

---

【回帖要求】

1、凭心而论，我认为产品应该背，请陈述您的观点：

2、凭心而论，我认为开发应该背，请陈述您的观点：

3、凭心而论，我认为运维应该背，请陈述您的观点：

4、我骑墙：我保持中立，我的观点是________________(请补充论点）！！！

(注：骑墙有风险，中立发言需要更多的语言来证明和表达自己的看法，单独的看法也更容易不被别人支持。)

你可参考以下切入点进行辩论阐述「包括但不限于以下这些，期待更多独特的声音」

1、性能优化谁该背锅：

产品/网站加载慢、闪退是谁的锅？

是代码需要优化？还是架构层面优化？

还是缓存设计优化？是谁该考虑的问题？

2、产品体验谁该背锅？

产品按钮不合理、页面引导缺失是谁的锅？

是产品设计问题？还是开发偷懒？

还是运维上线遗漏了功能？

3、监控部署谁该背锅？

服务器宕机、遭到Web攻击是谁的锅？

是组织架构和权限给的太大？

还是预警系统失效？还是开发代码疏漏？

4、 锅总是有的，看谁来背，是核心人员，还是基层人员？

开发从以前的 “瀑布式流程”到现在“迭代式”敏捷开发，要背哪些锅？该不该背？

背了锅是否让领导注意到，是否给领导解决了烦恼，是否给了自己成长的机会？

---

【奖励惩罚】

1.发表有力论据，做到发言内容丰富、客观的，无论支持何方论点，都会获得相应20s豆奖励，同时将抽取2名幸运用户赠送某公司定制签字笔一支；（字数不少15字）

2.主动反驳他人论据，并冷静客观指出问题的，获得额外的50s豆奖励；

3.无理性攻击性言论，将最低处罚10s豆；

4.灌水、无意义回复，管理员将有权直接删除；

---

【规则说明】

你可以选择当辩手，在一线唇枪舌战，

你也可以是吃瓜群众，为他人点赞助威！

辩论大神与博学文豪们，

接下来就是仁者见仁，智者见智的时候了！

朕把天下交给你们啦！

---

第20期  开怼吧！

（以上图片均来源于网络，侵权立删）

（辩论的本质，不是为了驳倒谁，也不是为了秀自己的正确，辩论的本质意义是通过正反观点的碰撞，凝练出接近事实的真相。对方的观点，自己的观点，互相补充和完善、修正。)

【辩题征集】

如果您有IT行业/云计算/网络安全等其他方面的能引发思考且具有价值的辩论主题，

可以私信sangfor_闪电回_小六进行投稿，一经采用，每个辩题将获得100S豆奖励！

---

【发起投票】

1、请先选择你支持的一方进行投票（最多选择1项）

2、投票后移步评论区陈述个人观点，也可对他人观点进行点赞、评论、反驳哦～；

【热门推荐】
【活动精选】一周热门活动盘点，再不参加就晚了！
>>>点击参与更多精彩活动...

我骑墙中，我认为这锅应该大家一起背，理由是团队协作共同完成的项目，上线时出现问题证明沟通出现的问题，并不能单独排除哪一个环节没有问题应该项目过程组成员一起面对进行风险和整理解决方案；
无论是产品体验，性能优化，监控部署每一个环节都会有沟通的环节，也就是说没有谁可以独善其身完全没有责任；
比如说：产品体验有问题为什么不及时反馈？性能优化不到位为什么准许上线？监控部署有问题为什么不及时解决以至于问题放大？

我骑墙，但并不是一起背锅。
首先说一下这个选项就有点一刀切了。具体问题具体分析，什么样的问题是什么原因导致的，这个原因是由谁来实施的，那么追究责任人就有了方向。而其实绝大多数情况下，我们解决问题的目的并不是为了追责，为了把锅甩给谁，更多的是为了找到客户或者我们自身存在的问题，查漏补缺，使用户无后顾之忧。这才是我们IT人的使命和终极目的。

我骑墙：我保持中立，我的观点是在真相没找到之前还是都客气点好，省的打脸。我是运维，我们经常碰见系统因为一个开发程序不能正常使用，开发程序的说是系统的问题，系统说是软件开发的问题，我们是谁也惹不起，只能一点一点的试试，相互协调。实在解决不了，就搁置争议  找其他东西代替想办法绕过去，实在绕不过去，就只能各方大佬请过来碰头一次性解决。我们出点饭钱大家吃点联络一下感情。真的是难为了我们实际使用的人了。

3、凭心而论，我认为运维应该背，请陈述您的观点
运维属于产品交付用户使用的最后一个节点，用户的满意度和使用的熟练程度，很大一部分都是靠运维来培训解决的。
一个再好的产品，如果用户不会使用或是使用不当，出了问题，但没有人能帮助解决，都会很大程度降低产品在客户心目中的地位。如果有一个好点的运维，很认真负责的帮助用户解决问题和引导用户正确的使用产品，会大大提高客户的工作效率和提升产品的品牌效应。   所以，如果项目上线系统出问题，我认为运维应该背锅。（前提是开发没人问题，不会出现代码错误，否则这个层面的问题不是运维可以解决的）

凭心而论，我认为开发应该背，观点如下：（因为我是运维）
其一、产品的设计是一个不断完善的过程，所以项目上线后系统出问题，肯定不可能让产品大哥背；
其二、所谓的运维是就是修修补补的工作，项目上线后这么大的问题他们基本上沾不上边；
其三、一个产品的开发，核心人员就在于研发大哥，他们一行代码，甚至一个字节的错误都有可能造成系统的严重错误，他们的压力最大，责任也最大，所以这个锅他们要背；
当然，锅有人背，但其它人员不是站着看热闹，而且是积极协助研发大哥尽快把问题找出来，不然哪像 个团队

凭心而论，我认为三人都一起背。
运维为什么要背？
运维是最后对接的那个人，出了故障第一阶段肯定是找运维，运维到系统故障，那你跑步了。
产品为什么要背？
运维有困难了怎么办，肯定需要把锅甩给产品，给自己找点无辜躺枪的感觉，这是本能反应吧。因为大部分稳定正常的系统有故障通常都是本身设备出现问题的几率比较大。
开发为什么要背？
开发是对自己产品最了解的吧？这个系统某一项功能可能有些不足 某些功能使用期间可能会出现一些状况 正常是知道的。能否优化，优化难道大小心里是有点数的，系统出问题，后面要优化要改善还是开发们的事，而且开发正常都是一群，一群人背锅好比运维一个人背锅强。开发们什么锅背不了呢。
这样一轮下来的好处是什么？
怪到产品本身问题 然后如果能找到优化的方法，后面还能少个故障点，把系统出问题转化成变成运维大佬发现了一个BUG。

我骑墙中，我认为这锅应该大家一起背，虽然上线前有实施，有开发，上线后有运维，但是个人感觉，大家都无法及时证明不是自己的锅，所以这个锅应该大家一起来背，除非有很明显的问题，指向某一环节

学习学习

我骑墙中,我认为有福同享，有难同当，一个公司里面不应该出现这种不和谐的声音，有困难大家一起解决才是正道 ，责任推来推去，最后损害的还是公司利益。

我骑墙：我保持中立，我的观点是不管项目出现了什么问题，只要是没有过质保期就是整个项目的问题，推卸责任不会解决问题的，协同起来才能处理好，这个锅得项目实施的产品运维开发一起来背

凭心而论，我认为产品应该背，产品设计方案肯定有问题，在实际项目时候开发有些是完成不了设计的方案，然后匆匆移交给售后，售后呢有些问题还是解决不了。
性能优化谁该背锅-开发，谁让他设计不设计好的。
产品/网站加载慢、闪退是谁的锅-开发，谁让他设计不设计好的。
是代码需要优化？还是架构层面优化？-开发，一个项目好坏要看顶层设计，顶层站位都不好，下面能好的哪去。

我骑墙：我保持中立，我的观点是大家一起背
虽然事情出来了，大家都会推卸责任，跟我们没有关系，其实一个运维需要多方面的配合，多方面的承担，这样才能做的更好

凭心而论，我认为产品应该背，系统出问题应该是产品出问题了，肯定是没有做好周全的考虑，一般实施的都是按照技术文档来做的。

我骑墙：我保持中立，中国人做事始终会有个差不多就好了，不会考虑以后会不会出现什么问题，一旦出问题，所有人第一个想法不是找原因而且把锅甩出去，不甩出去倒霉的可能就是自己，这是大环境造成的，既然问题出来了肯定要先找补救解决的办法，再去分析问题出现的原因，不管谁背锅过最终肯定是领导出面摆平的，