最具影响力的数字化技术在线社区

168大数据

 找回密码
 立即注册

QQ登录

只需一步,快速开始

1 2 3 4 5
打印 上一主题 下一主题
开启左侧

误删数据库的顺丰工程师,真的应该被开除么?

[复制链接]
跳转到指定楼层
楼主
发表于 2018-9-21 16:48:47 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式

马上注册,结交更多数据大咖,获取更多知识干货,轻松玩转大数据

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
本帖最后由 168主编 于 2018-9-21 17:03 编辑

昨天晚上,据微博网友大佬坊间八卦爆料,顺丰科技数据中心的一位高级工程师(邓XX)误删生产数据库,导致某项服务无法使用并持续 590 分钟。最终公司决定辞退工程师邓某,并在顺丰内网通报。

据内部通报:

邓某错选了 RUSS 数据库,打算删除执行的 SQL。在选定删除时,因其操作不严谨,光标回跳到 RUSS 库的实例,在未看清所选内容的情况下,便通过 delete 执行删除,同时邓某忽略了弹窗提醒,直接回车,导致 RUSS 生产数据库被删掉。

因运维工作人员不严谨的操作,导致 OMCS 运营监控管控系统发生故障,该系统上临时线上发车功能无法使用并持续了 590 分钟。

网友爆料的内部通报邮件截图:


下面是部分网友的讨论:







一直以来,「删库」就是 IT 人口中的热点话题,每次的讨论都离不开一张神图:


对于「从删库到跑路」这个半调侃半心酸的观点,知乎上有一位朋友的回复,可能反映了这个行业的一些现状:

正如这位朋友所说的,在一家公司,你真的搞得线上数据无法恢复的话,那么可能真的只好跑路了。

但发生误操作从而「删库」的工程师,真的一定要被开除么?

以上是网友们的观点,而我的观点是:犯了错误,就要承担相应的后果,但不一定非要开除。原因有三:


1. 如果一定要开除,那么他的直属主管也应该一并被开除。以顺丰事件为例,当事人的责任在所难免,但「删库」应该是运维主管才有的权限,所以部门的老大应该承担更大的责任;

2. 一般来说,对于线上的数据库操作,提交的 SQL 语句都会进行审核、数据备份,然后才是入库。正如网友所说的那样,顺丰运维平台在数据库操作权限、操作流程控制以及灾备应急这三方面做得确实太不到位了...
跟开除一名员工相比,借由这次的事情解决自身平台的运维问题才是关键,而一名内部的高级工程师在这项工作中肯定能提供很大的帮助;

3. 如果这个人平时是个很负责、很忠诚、技术能力很强的人,今天确实是脑子一热做的误操作。为此就开除一个培养了多年的精英,实在是便宜了别的公司,开除不如采用一些别的形式的惩罚措施。

这点国外技术公司的做法值得我们借鉴,在核实情况后,他们大部分是会保护“误操作”的员工。说的好听点是对工程师友好尊重,说的更直白点是,我花这么大代价培养的人,怎么可以轻易便宜了其他公司呢?
21世纪什么最贵?人才啊!

*部分素材整理自网络,如侵删

网上有一个观点:任何运维问题,可以分成三类:政治问题、管理问题、技术问题。

如果是政治问题,那有相应的解决方案;但这次事故,显然更像是一个管理问题,把责任粗暴安在一个技术人员头上,是最差的做法,哪怕只是做到亡羊补牢,也为时未晚。

顺丰前一阵儿先是数据库被暗网售卖,现在又是高级工程师“从删库到跑路”...辞退一名员工很容易,但真的有利于顺丰解决技术问题么?

你觉得这个员工应该被开除么?

本文转载自【51CTO官微】
楼主热帖
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏 转播转播 分享分享 分享淘帖 赞 踩

168大数据 - 论坛版权1.本主题所有言论和图片纯属网友个人见解,与本站立场无关
2.本站所有主题由网友自行投稿发布。若为首发或独家,该帖子作者与168大数据享有帖子相关版权。
3.其他单位或个人使用、转载或引用本文时必须同时征得该帖子作者和168大数据的同意,并添加本文出处。
4.本站所收集的部分公开资料来源于网络,转载目的在于传递价值及用于交流学习,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。
5.任何通过此网页连接而得到的资讯、产品及服务,本站概不负责,亦不负任何法律责任。
6.本站遵循行业规范,任何转载的稿件都会明确标注作者和来源,若标注有误或遗漏而侵犯到任何版权问题,请尽快告知,本站将及时删除。
7.168大数据管理员和版主有权不事先通知发贴者而删除本文。

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关闭

站长推荐上一条 /1 下一条

关于我们|小黑屋|Archiver|168大数据 ( 京ICP备14035423号|申请友情链接

GMT+8, 2024-5-6 22:16

Powered by BI168大数据社区

© 2012-2014 168大数据

快速回复 返回顶部 返回列表