题图: from Zoommy
中秋前,圈内一则 “顺丰运维工程师因误删库被开除” 的消息在圈内炸锅了。虽说程序员群体并不八婆,但都纷纷就此事件抛出深藏内心的酸爽感。
有的说,该不该开除删库的运维工程师?有的说,该如何避免误删生产数据库的悲剧发生呢?有的说,权限怎么管理的,运维老大最后的下场如何?而有的则说,运维老大挖的大坑,却让自己小伙伴背锅,太不人道了。
七嘴八舌,也许是抱着看好戏的心态,也许是借机向领导传达 “老板快看,某某公司又出事了吧,还是我们好吧!” 的讯息,无论用意何在,在互联网世界里,哪怕是拍死只苍蝇那样的屁事,只要有人稍加修饰并将其曝光在网上,就会有一堆键盘侠蜂拥而上,你一拳,我一脚,哪管当事人的死与活,毕竟吃瓜群众多,引以为戒的少。
很多时候,我们会习惯性的将问题与用人不当扯上关系,在我看来,在相同体制下,张三会发生,李四也会发生。就好比交通规则,中国有,日本也有,那为什么执行结果却截然不同呢?还有些技术管理者(含运维老大),自己在程序员时期无法做好的事情,比如注释、文档、操作规范流程等,一旦成为管理者后,就不断强调自己当年的遗憾,并要求手下去做到,如做不到就软硬兼施,一手猛灌鸡汤,一手猛炒鱿鱼。
这些现象在技术圈内屡见不鲜,并不稀奇,如碰到,算你倒霉,如没碰到,算你运气爆棚。
说到这有人说,我技术生涯十多年了,就从来没有出过事故,自己能力有问题,别总找客观因素。的确,但有时 “客观因素” 却占据重要位置,即便再好的RP也有爆表一刻,再坚固不摧的技术风控也会遭遇百密一疏。
我的运气还算不错,在近二十年的技术生涯中,虽遭遇过多次“惊悚” 瞬间,但均有惊无险,至少没被老板炒了鱿鱼,也没对公司(或客户)造成太大的直接损失。
接下去,我也来凑个热闹,扒一扒其中两件记忆较为深刻的运维事件:
1、误把生产库当成测试库,删光整张客户表
- 事件影响
2007年某日,某金融企业CRM系统瘫痪将近15分钟。
- 事件缘由
当时我在某乙方软件公司,担任开发,某日接到需求,要求在次日赶赴现场将某系统从V1.0升级至V2.0。
根据公司规定(甲乙方双),生产操作过程须两名以上人员在场(1人操作,1人监督),但由于与甲方技术关系较好,所以在升级过程中并未遵守,不仅如此,还边聊天边操作,注意力分散,最终误将生产库当成测试库,爽快的执行了一连串Truncate操作,完美地干掉了所有客户信息。
- 补救措施
因个人习惯,无论测试还是生产,我会在truncate前先执行create table XXX as select * table,所以有惊无险,百万级的数据量,迅速在分钟级内进行了恢复,产线回复正常。
虽说未造成直接损失,但却给客户留下恶劣影响,我还是被扣除了年度奖金作为惩罚。
2、运维脚本的鲁棒性较差,应用服务器根目录被删除了
- 事件影响
2009年某日凌晨,某游戏电商企业,交易系统瘫痪将近1小时。
- 事件缘由
年初起,大力推广运维自动化,前台写个简单的界面,后台搞个简易脚本,组合起来进行日常运维操作。
我写的其中一个清理日志的脚本,大体代码如下:
...
cd / ${path_rizhi}
rm -rf *
...
粗看没问题,但如果path_rizhi为空,悲剧自然发生,但当时我则认为,path_rizhi不可能为空。
本脚本为每日凌晨3点启动,一般在5分钟内结束,但在上线后的两个月后的某天,由于path_rizhi为空,在30分钟内,整个服务器的根目录被彻底删除。
- 补救措施
好在当时有24小时人工值班,及时发现后,先通过主/备(IOE)切换,后进行操作系统恢复(每日备份),到凌晨5点之前,已全部恢复完成。
虽说未造成重大损失,且又在流量较低时段,但老板还是为了让我长点记性,扣除了我当月全部的工资作为惩罚。事后回想,如果本事件发生在数据库上,并在日活较高时段发生,后果不堪设想。
时间飞逝,转眼间又一个十年过去了。
在常人看来,扒开自己的黑历史是非常丢人的,但毕竟常在江湖走,哪有不挨刀?也许是命运的眷顾,也许是上天的保佑,这些事件不仅有惊无险,还给我的职业生涯增添了不少段子,只是每每说起,多少还有一丝后怕。
跟顺丰事件的主人翁比起来,我算是幸运的,虽然每次都不同程度的受到物质或精神上的惩罚,但还是要谢谢几位老板当年的不 “杀” 之恩,毕竟没有让我瞬间丢了工作,还能继续偿还房贷。
祝所有运维人,好运常伴,万事如意。