题图： 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点之前，已全部恢复完成。

虽说未造成重大损失，且又在流量较低时段，但老板还是为了让我长点记性，扣除了我当月全部的工资作为惩罚。事后回想，如果本事件发生在数据库上，并在日活较高时段发生，后果不堪设想。

时间飞逝，转眼间又一个十年过去了。

在常人看来，扒开自己的黑历史是非常丢人的，但毕竟常在江湖走，哪有不挨刀？也许是命运的眷顾，也许是上天的保佑，这些事件不仅有惊无险，还给我的职业生涯增添了不少段子，只是每每说起，多少还有一丝后怕。

跟顺丰事件的主人翁比起来，我算是幸运的，虽然每次都不同程度的受到物质或精神上的惩罚，但还是要谢谢几位老板当年的不 “杀” 之恩，毕竟没有让我瞬间丢了工作，还能继续偿还房贷。

祝所有运维人，好运常伴，万事如意。

 - END -