ITPub博客

首页 > IT职业 > IT职场 > 顺丰该不该开除删库的运维工程师?

顺丰该不该开除删库的运维工程师?

IT职场 编辑:胡孟依 时间:2018-09-29 14:35:41 1 删除 编辑

作为极少数既 drop 过生产库,也 rm -rf / 过线上服务器的过来人,我觉得自己很有必要站出来说点什么。


1、事件还原


undefined


本次事件流出的是一封顺丰内部通报邮件,大概描述了一位邓姓工程师因操作不当而导致数据丢失、业务停摆的事故,邮件内容如下:


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


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


…… 此次故障导致业务产生了严重的负面影响。


……根据《奖励与处罚管理规定3.0》……对直接责任人邓XXX予以解除劳动合同处罚,并予以顺丰科技全网通报批评。


以上描述得有些专业了,非技术人员理解起来可能有点困难,我来给大家用白话翻译一下:


小邓是一名年轻的程序员,干起活来手特别快,平时敲打键盘如狂风暴雨一般,一般人的眼睛根本跟不上他的操作。然而跑得越快、摔得越惨,终于有一天,他在做危险操作的时候因为手快发生了失误,删除了重要的工作数据,让公司的系统瘫痪了十个小时。结果他被开除了,还被全公司通报批评。


好了,事情的经过就是这样。接下来我再从技术角度分析一下。从“导致RUSS 生产数据库被删掉”这句话来看,小邓应该做的是 drop (卸载库) 操作,而不是 delete (删除数据) 操作。根据我的经验和理解,事情大概率是这样的:


声明:以下所述只是我个人的揣测,很可能不是事实!


很明显,小邓想把生产环境的数据库的数据搬到测试环境里。定期将生产数据同步到测试环境,这是一个非常常见且高频的需求。如果数据结构不同,代码就跑不起来;如果数据不新不真,产品经理也不好评估新产品的效果。


做数据同步和迁移有很多种方法,其中最方便快捷、简单粗暴的方法就是:


  1. 把线上的数据库 dump(打包) 成一个文件

  2. 把这个文件下载到测试环境的机器上

  3. 在测试环境 drop (卸载)现有的库

  4. 用文件中的数据重建新的库


很明显,事故发生在第三步,也就是:本应在测试环境执行的 drop 操作,在生产环境被执行了。


如果是第一次做这样的操作,我相信任何有基本职业操守的人都会非常小心的。从小邓“忽略了弹窗提醒,直接回车”来看,他对整个操作流程是非常熟练的,当天他一定是已经做了很多次这样的操作。


我大胆地猜测:小邓同学是在 熬夜加班 / 临近饭点 / 老婆催回家 / …… 之类的状态下,无心犯下这个错误的。



2、问题到底出在哪里?


既然问题出现了,我们就得搞清楚以下三个问题:


  1. Why:导致问题的根本原因究竟是什么?

  2. How: 怎么避免以后再发生类似的问题?

  3. What:现在我们应该做些什么?


我们先来研究一下,导致本起事故的根本原因到底是什么?真的是小邓 粗心大意、一味求快么?


对任何已有结论的问题,都应该进行自己的独立思考,这样才不会人云亦云,掉入思维陷阱里。


在未看清所选内容的情况下,便通过 delete 执行删除……
同时邓某忽略了弹窗提醒,直接回车


这一部分没得说,100%是小邓的问题。不看提醒直接默认选择,这是一个非常不好的习惯。应该有很多人在Windows里删除文件时因为懒得再去清回收站,就直接Shift+Delete然后回车的吧?肯定还有嫌每次弹个对话框麻烦,干脆设置成“不提醒确认”的吧?那一旦删错了,就能去求助Rstudio之类的数据恢复软件,至于能不能找回来,就只能听天由命了。


做开发和运维的人理应知道数据的重要性,在对数据做 drop、delete 等无法撤销的危险操作时要慎之又慎,一定要反复检查,最好找人结对和review。


邓某错选了 RUSS 数据库,打算执行删除的 SQL。
在选定删除时,因其操作不严谨,光标回跳到 RUSS 库的实例……


顺丰有 DBA 吗?运维同学为什么竟然有权限操作生产数据库?生产环境和测试环境为什么不进行严格的隔离? 执行线上危险操作时,为什么不安排双人结对或者review?同步数据这种高频操作为什么没有做成脚本或服务,而是靠容易出错的人工来执行?


当然,顺丰体量虽大,但毕竟并不是一家互联网公司,可能工程师数量还不及业内一家小型创业公司。在这种情况下,一人多用、权限混乱也是可以理解的常态。但对于数据十分重要、服务绝对不能停的业务,CTO和项目leader,应该对员工可能出现的操作失误设计预先防范的措施和制度,否则就是失职。当你的业务有可能因为员工一个小失误就瘫痪,甚至数据无法找回导致公司关门时,你怎么还睡得着觉?


在照顾孩子的时候,我学到的最重要的道理就是:如果有样东西不能让孩子玩,那就不能放在孩子够得着的地方。 如果你是一名销售,刚签完一个大客户,兴高采烈地回到家里,把合同扔到茶几上,然后冲进洗手间上了个厕所回来,就发现合同被你家熊孩子用笔涂得一塌糊涂,你觉得是该怪孩子调皮呢,还是该怪你自己不小心?


综上所述,我认为虽然小邓的误操作是本次事故的直接原因,但顺丰公司对明显的安全隐患视而不见,在权限管理、风险控制、流程设计上存在重大缺陷,才是本次事故的根本原因。


3、顺丰到底该不该开除小邓?


如果找不到问题的根本原因,在错误的方向上再怎么努力,也不可能找到解决方案。相反,只要找到了正确的原因,解决方案也就自动呈现。所以,我们就不浪费时间来讨论如何避免再发生类似事故了。


现在最有争议的话题就是: 顺丰到底怎么处理本次事件才是合理的?


小邓因工作失误,给公司带来了巨大的损失,这是客观事实。而小邓作为个人是无力赔偿公司损失的,顺丰公司作为非国家单位,能动用最高级别的惩罚就只有开除。我相信,顺丰这么大的公司,作出开除并通报批评这个决定,应该是经过激烈的讨论的。最终决策者还是决定杀鸡儆猴,以儆效尤。从法律的角度上讲,顺丰有权这么做;从道德的角度上讲,顺丰的立场也没有问题。


可是,为什么业内对这个处理结果会出现如此大的反应呢?因为顺丰在处理的过程中呈现了一副冷冰冰的姿态,在事故原因分析中把所有责任推卸到员工头上,对公司制度的缺失及领导者的失职只字不提,实在让人心寒。


定义为人的问题,那就只能解决人,却解决不了问题。 开除了一个小邓,却不在权限设计、流程管控上下功夫,那还一定还会有小王、小张们前仆后继地继续出同样的问题。也许现在风声紧,大家都会对安全格外注意,但不会持续多久。


定义为程序和制度的问题,才能从根本上解决问题。 顺丰本来可以保留一个忠心耿耿、加薪欲望低的好员工,同时呈现出包容错误的正能量企业文化,收买大片人心。但是现在顺丰的员工们会怎么想呢?原来公司没有把我们当人看,我们只是随时可以更换的螺丝钉,出了问题就走人,就算是机器出了问题,我们也得当背锅侠。


对小邓来说,被开除反而是一个好消息。 有过这么一次惨痛的经验教训,估计小邓一辈子都不会再犯删除线上库这种错误了。我们都知道人的价值是由稀缺性决定的,拥有小邓这样有经验的人可谓是少之又少。小邓现在出了名,一定会有N多公司给他抛出橄榄枝,会有更好的机会等待着他。相反,如果顺丰没有开除小邓,他一定会因为内疚而对工作更加尽职尽责,短期也不会选择跳槽。交了这么高学费的人,怎么能放他走,便宜别的公司呢?


开除了一个大有前途的员工,顺便伤了全公司的人的心,还引发业界口诛笔伐,带动股价下跌。顺丰这次真是赔到姥姥家了。


4、我自己经历的drop事故


我2011-2013年在微拍工作期间,既犯过 drop 线上库的错误,也犯过 rm rf / 线上服务器的错误。其中drop线上库的经过,跟小邓基本上是一模样的。我后来写了一篇博客来反思,直接上图吧:


undefined

undefined

感谢当时的boss胡震生不仅给了我足够的包容,还为我开导排解,帮我学习和成长。痛定思痛细查原因,通过技术手段根治,从此再没有犯过这两个错误。


对我 rm rf / 的经历感兴趣的朋友,可以查看我的博客文章:《欲速则不达》



5、后话


人是靠不住的,因为人会变、会离开。只让员工成长,却不让系统成长,结果就是经验都沉淀到了员工自己身上,当员工离职时就带走了所有,公司一无所获。


系统才是唯一能永远留在公司内部的资源。真正优秀的员工,会想方设法来迭代系统,即便自己离开也能高效运转。而那种让自己变得不可或缺,离开之后系统便不可持续运转的员工,其实是最大的隐患。


我又要说我的口头禅了:一个人的价值,不在于他得到过什么;而在于他给这个世界留下了什么。


祝各位朋友中秋节愉快!


【作者介绍】


张砷镓:一名具有独立思考能力和代码洁癖,且兴趣爱好广泛的程序猿,曾任赶集黄页事业部技术经理,现从事编程教育工作。骨灰级游戏玩家,曾在魔方、扫雷、俄罗斯方块等领域取得国内第一,多次打破全国记录,扫雷网(saolei.net)创始人。


来自 “ 镓话 ”, 原文作者:张砷镓;原文链接:https://mp.weixin.qq.com/s/mRhz5Py3_DY1lVw53GMeYQ,如有侵权,请联系管理员删除。

请登录后发表评论 登录
全部评论
公众号

注册时间:2018-07-26

  • 博文量
    29
  • 访问量
    45258