你司有没有过运维事故？

[AllOfMe]

删库，update 没加 where，rm rf /，误删 glibc 等等运维事故，小至两三人的创业公司，大至如最近的腾讯云磁盘事故，都有可能发生。
你们公司有没有过类似的事故？这些犯错的员工下场一般是怎么样的？

[dingjssc]

@lucifer9 手动点赞，我也干过同样的事情。

[whileFalse]

@supersadmin 能详细说说么

[tonzeng]

楼上大部分甲方大爷干过的事情，我都擦屁股。

[lucifer9]

@dingjssc #41 还听同事说过一个某外派大厂的，不知真假。说是当年西非某国用的该厂设备，全套的那种。某天派驻过去维护的工程师脑抽，把国防部的网络搞断了大半天。当时该国还在内战中，也就是当时反政府军没啥行动，要不这哥们儿估计就成当地民族英雄了。

[chnhyg]

说个以前的，

我们的数据库有多重备份，备份系统挂了近一年，也是需要恢复数据库的时候才发现的这个事，所以最近一次的有效备份文件是一年前的。

当天不小心误删了数据库，后果是什么呢？一家即将上市的集团公司近一年的生产数据全没了。

万幸的是，最后发现一个离职的同事很久很久以前写的一个备份系统还在默默地运行着，最近一次的有效备份文件是一天前的。

……

[AllOfMe]

@SoulSleep 厉害

[artandlol]

@chnhyg 你们一定要去感谢下那位前同事

[colorfulberry]

1. rm -rf 搞过一次，文件恢复了一天，小公司，只恢复了 80%。 其他的也不了了之
2. update 不带 where，最近出现过一次，其实也就影响了 10 几个人。

[xderam]

@liuzhedash 2 3 4 7 都遇到过，其实大厂子也有这些问题。（逃

[houzhimeng]

现在就担心阿里也搞这么一出就完蛋了，买他那个灾备也不安全啊。

[artandlol]

前几天在 k8s 集群里面执行了下，一个 pod 挂掉了就自动重建了，有其他 pod 在访问没任何影响

[Hucai]

@chnhyg #45 不给那个离职的同事来一笔奖金说不过去吧

[shiny]

印象比较深有两条：
1. 32 位系统上 ip2long 的结果去存字段类型为 int，SQL 失败后数据都没存下来。因为比较隐蔽，大半年后才发现。代价：每条记录都价值上千元。
表面原因：不要用 32 位系统。
深入原因：生产环境上应该要捕获并认真对待每一条错误。后来上了 sentry 此类问题就可以规避了。

2. 凌晨迁移服务器时候备份的 sql 被错误 echo 清空了，然后没有任何备份。
表面原因：备份应该是定期且能够验证的。现在用好云服务的自带功能（比如快照和自动快照策略）规避绝大多数的风险了，当年没这玩意儿。
深入原因：疲乏的时候谨慎操作生产环境服务器，想好每一条操作，认真评估风险，防范后再去操作，可参考航空界的飞行检查单。

[shiny]

补充上面第一条：32 位系统下 ip2long 出现负值，但数据库字段类型为 unsigned

[Hucai]

innode 类型数据表，启动报错，删了 ibdata1 启动正常，后来数据就丢了，再后来就知道了 innode 和 myisam 的区别

[boris1993]

机房没上 UPS，终于某次园区停电之后烧了 3 块服务器主板
后续是公司买了俩 UPS 扔机房里面。因为定期备份失效，工作进度回滚 3 个月。
我？我是开发部门，负责看戏的。

[dongisking]

数据库里面有个字段叫 deleted_at，如果不为空就是软删除了，有一天我把测试数据都硬删了，然后同事说登陆不到了。我看了下代码是用的 is_del 字段，被坑死了。

[cstj0505]

某天晚上生产数据库突然被内核杀掉了三次，算吗

[shiny]

遇到问题不可怕，可怕的是不去分析问题，日后规避。
遇到问题要问五个为什么 https://zh.wikipedia.org/wiki/%E4%BA%94%E4%B8%AA%E4%B8%BA%E4%BB%80%E4%B9%88
找到深层次原因才能更好规避问题，也是技术人员真正宝贵的实践经验，而不仅仅是会何种语言，CRUD 工作经验几年。

[pyufftj]

@niuoh 我以前在黑苹果上执行了和你一模一样的命令，后来就重装了系统。。