顺丰该不该开除运维工程师？

image.png

顺丰运维工程师因误删库被开除的事，现在已经在圈内炸锅了。

本来我是很讨厌蹭热点的，因为这样写出来的内容很可能缺乏长期价值。但是作为极少数既 drop 过生产库，也 rm -rf / 过线上服务器的过来人，我觉得自己很有必要站出来说点什么。

马上要放假了，半夜爬起来码字，仓促之处必有疏漏，还请各位海涵。

事件还原

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

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

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

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

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

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

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

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

声明：以下所述只是我个人的揣测，很可能不是事实！

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

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

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

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

3. 在测试环境 drop （卸载）现有的库

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

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

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

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

问题到底出在哪里？

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

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

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

3. What：现在我们应该做些什么？

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

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

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

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

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

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

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

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

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

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

顺丰到底该不该开除小邓？

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

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

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

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

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

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

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

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

我自己经历的drop事故

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

image image

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

对我 rm rf / 的经历感兴趣的朋友，可以查看我的博客文章：《欲速则不达》http://zhangshenjia.com/it/slow-down/

后话

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

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

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

祝各位朋友中秋节愉快！