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

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/

后话

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

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

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

祝各位朋友中秋节愉快!

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 201,468评论 5 473
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 84,620评论 2 377
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 148,427评论 0 334
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,160评论 1 272
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,197评论 5 363
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,334评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,775评论 3 393
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,444评论 0 256
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,628评论 1 295
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,459评论 2 317
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,508评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,210评论 3 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,767评论 3 303
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,850评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,076评论 1 258
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,627评论 2 348
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,196评论 2 341

推荐阅读更多精彩内容