你司有没有过运维事故？

一百人不到的游戏公司。以前一位运维手滑导致活动提前结束。后来被开了。
现在做法是禁用 rm，改用 mv 到指定路径下，另有脚本定时清里面的文件。

@mossss21 还好我以前呆的公司比较好 不然已经被开了十几次了

- - 手滑删过库 不过还好操作前备份了一下......

就是删库呗，不过还好是开启日志归档的 db2

曾经有个 bug 跑了起码半年，陆续删掉的数据可能有几千万条。这个事我可以吹好几年哈哈。每次看到大数据我就想到两件搞笑事，一件是这个，另一件就是数字够大就是大数据。哈哈哈哈哈哈哈哈哈。

直接物理接触，格了别人的服务器……

那还是在 2010 年，当时在的小公司，项目上线，跟别人借的服务器。

我们去机房，机房工作人员随手指了两台，说这俩给你们用的。

然后我们开始格盘装系统。装完系统，机房那哥们说，两台中有一台指错了…

@ETiV 然后怎么处理的

@ETiV 悲惨了

手滑删过公司的小项目源码。反编译回来了。

删库，经历过 1,2 次吧

update …… where 1=1
内部系统 web 运行缓慢半小时

我曾经干过，rm -rf / home/...... 多个空格，悲剧了。

我执行过 chmod 777 / -R

测试数据库服务器 rm -rf /
---找监控，甩锅
oracle 生产库业务表 update xxx set dddd=1 where 1=1
---找磁带，恢复 48 小时
生产存储固件挂掉....宕机 2 周
---索赔几百万...吧
mysql 生产库业务表 update xxx set dddd=1 where 1=1
---找到 1 小时前数据，还原掉，并通知业务人员重新操作
生产应用宿主机宕机
----没啥，找人甩锅呗

别的记不得了，反正我觉得自己心脏倍儿好

这么说吧，小心谨慎的运维，都是干过这类问题的，我当年是写 sql 眼花，清空了一个备注列，幸好纯内部系统，丢了就丢了

@ETiV 后续赔钱了吗？

前司到处都是：
1、一觉起来发现数据库因为连接错误过多关闭连接了，所有业务停摆几小时
2、php-fpm 内存泄漏，终于在某天中午占满了所有内存导致业务停摆几小时
3、被当成 ddos 肉鸡，随机时间向外打流量，所有业务停摆 48 小时
4、cron 触发的系统邮件文件占满了所有 inode，无法创建任何新文件，导致所有业务停摆几小时
5、删错数据、删错订单、退错款、付了款订单失败、App 推送点不开、App 推送不到达都是家常便饭，不说了
6、景区保安把手持验票机（ Android 系统）热点打开，3 天耗完 4GB 流量
7、短信通道被 ddos，几百条订单短信发不出去，节假日客服电话被打爆，我的电话被客服打爆
8、工程师把生产库当测试库调整 sql，join 死循环导致 mysql 吃 100%cpu，好在站库分离影响不大
9、推送的 react native 热更新把热更新检查代码注释了，不得不更新原生版本
10、合作方在业务高峰前夜切换接口实现，三天内囤积了 5w 左右的订单无法验证状态（是否使用），老板用从未有过的认真表情问我这 5w 到底会落实成多少损失，好在实际上没多少损失

终于凑够 10 条了，其实 v2 上大佬很多，说话也很好听，技术都很高明，但是实际上大部分的小公司真的只有我这样的一个技术头目带几个兄弟做研发，没有什么精力去做很完善的运维，维持 bug 不比 feature 多就已经竭尽全力了。
希望大家负责的项目都能稳定运行，天长地久。

我老东家遇到过 有一台 build server 上面的同一时间通电的同一批次的三块 SSD 在同一时间一起报废 幸好不是生产服务器 吓出一身冷汗

生产服务器被开发 rm -fr /* ，过了好几分钟发现不对劲取消，除了挽回几十个 G 的日志其他数据全丢了。

RAID1 两块硬盘坏了一块，运维热插拔把正常的拿下来了。。。。。

@Phariel 你这个可以去买彩票了

@xiaoheshang 略 dio，看着黄灯闪然后把绿灯的盘拔下来了？？

两年前小团队只有十几人, 下午上班中查生产数据库第一条执行完执行第二条返回了 'no database selected', 仔细一看 db 不见了.

然后靠 binlog 恢复了, 事故原因是: 不知道怎么了就不见了 (技术副总说的).

还有就是副总深夜没告知手下的人自己就通过 ftp 修改了生产环境的代码, 把数据库连到测试库了, 早上才发现

自己的数据。移动硬盘上有个目录“网站数据”保存着我做过的所有网站源码及数据。一个网站一个目录。有些是自己开发的，有些是用 cms 做的。最早的网站是中学时做的校园论坛，程序是 dvbbs7.0sp2。另外还有两个校内(人人)api 做的 sns 插件。总共二十多个目录。
在对三个硬盘进行数据归类整理时，这个最重要的目录被我弄没了。我也不知道是怎么弄没的，反正是找不到了，用 finadata 对硬盘扫了一遍也没找到。应该是在频繁的大文件拷贝过程中，那片区域被复写过了。
然后赶紧对仍在线上的网站进行备份，重建了一个“网站数据”目录。只剩 5 个了。感觉自己的人生被扣掉了一块。

游戏数据库少执行了一句，然后延长了更新时间。

误删文件肯定事少不了的
最多就是想办法恢复，然后赔偿呗
不过很久之前远程操作某省联通靠近核心的一台防火墙时候脑抽先写了个 deny all
当然后来打电话找机房同事给解决了，最后是半小时左右该省联通用户都没法上网
还被腾讯给投诉了...

@SoulSleep 其他的都能理解，但是为啥会有个索赔几百万呢？让你一个人赔吗？

有，粘贴 update 语句的时候，由于 word 里面折行问题，where 条件没有，执行完发现卧槽，完了！！！ 1000W 数据
但是所幸看到右下角网络感叹号！其实只有一部分被 update 了，其他都还好。。。

携程 5.28 听过吗

我把一个库线上的数据导到测试环境, 结果和其他库信息对不上了, 我这面没什么影响. 后台炸了.
那天感觉后背一直有凉风吹过....

有个小弟迁数据，手动迁出问题丢了 20 分钟数据，让他做成作业自动跑不听，非自己手动做，手动做还不是新建表 rename 表名，居然是傻了吧唧的手动复制数据后再删除原表数据，导致迁移耗时间进来的日志数据不但没迁移走，还被他给删了，帮他擦屁股，擦的恶心死我了

公司一个老姐生产库写 update 没写 where。。。。。
裸奔的数据库
后来靠倒着跑一遍 binlog 回来的，老姐吓得第二天请了病假

有一次 ssh 进去后发现 db 整个没了，花了 n 个小时把备份灌回来，然后检查期间的日志自己一条一条手工补上数据，就这样一个下午过去了。晚上，发现，自己登的是另一台机子，真机好好的。

导出数据库，执行成导入，执行完以为导出成功，删除旧备份。真正实现从删库到跑路。

@jrient 日常删库？

@infun 我现在在凌空 SOHO17 号楼看着这条。。

@e8c47a0d 哈哈哈哈，牛逼

写过一个 bug，因为这个 bug 公司赚了 1 万+，我被罚款 100.

@AllOfMe #28 哈哈，我是甲方，索赔乙方，因为是他们提供服务

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

@supersadmin 能详细说说么

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

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

说个以前的，

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

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

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

……

@SoulSleep 厉害

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

拔掉一个 R6 阵列的 3 个盘......
ESXI 的母机操作系统挂了.....

glibc 还能误删？

看着各位大佬的事故 记笔记记笔记! 看着就怕 哈哈

@chnhyg 简直不要太厉害

@shiny 我遇到过 sentry 被压垮的情况，发进去的内容全在队列里，越来越长

@julyclyde 怎么说呢？可能一些开发人员不熟悉 rpm，被依赖折腾累了，不小心执行 rpm -e --nodeps --force 就把 glibc 卸载了。。这个情况我以前遇到过，唉，头疼

@julyclyde 一般出现在 centos 这种内核 2.6,而且 glibc 又很老的情况下，误删 glibc 还是比较危险的操作

@julyclyde 一般都是安装一些软件，顺带升级导致主服务不兼容挂掉

楼上的都被忽悠了，这是说运维的错，不是疼讯的错，感觉疼讯换产品经理了

@AllOfMe 用了不同大版本的 repo 吧？

rm -rf 多打一个空格；
导数据库之后删除结果发现导出不完整；
不知道哪个手贱的给人演示“ RAID 的安全性”把一个最小规模的 RAID5 0 号盘拔掉换了位置没 rebuild，后来 2 号盘挂了；
热拉伸脚本写错了拉伸出去的都是空镜像直到自动压缩脚本执行的时候删掉正常容器才发现。

然后说一个道听途说的大事故：

因为机房 UPS 设计的太“坚挺”，每次停电全机房能在空调系统离线的情况下工作数小时，长期过热三层磁盘的中间一层磁盘几乎全部报废，存储控制器系统内部报警没人看到，前面板指示灯无异常。

终于在一次未提前通知的停电事件中整个存储挂掉，连带控制器系统也挂掉。

替换了几个批次的硬盘终于找到控制器识别的批次，用借来的控制器（型号老旧经销商和厂家都没有存货）将数据落到最底层，提心吊胆地启动之后惊心动魄地抢救数据，完整克隆到新的存储里面才算完。

@julyclyde 主要也不是版本和 repo 的问题，是一些软件要求 glibc 的版本当前不符合。在使用 rpm 的强制卸载太任性，对 rpm 操作和 glibc 这一重要底层包被卸载危险的认识还不够。如果你卸载了 glibc，会导致只有 cd 和 pwd 能有，所有在运行进程全部不正常。

做过镜像的根盘坏了一块，给厂商报修，当天就换了块新的。可是在自动复制过程中另外一块也挂了，而镜像数据的复制却还没完成，最终系统挂了。。。。（还好是备机，不过这概率也是没谁了，记忆很深）

昨天群里刚发生格错服务器了。把生产库给格了。并且备份还在这台机器上，哈哈。

实习生删表 紧急下线功能 挂维护通知 联系运维还原磁带备份 新数据建表再导 折腾一上午 还好内部系统

@Showfom
@Felldeadbird

没后续了…
机房在宁波，当晚我们就回上海了

责任不在我们，所以我们肯定是没赔钱
不知道机房小哥咋样……

线上服务器删除当前目录的时候少加了个点结果就这样了“ rm -rf /”
一个小目录半天没反映，立刻中止了，吓出一身冷汗
幸好核心文件没有被删除
现在登录线上服务器操作都有点手抖
：（

@neoska 是的，你没看错，就是这么任性。其实 raid 没掉级，只是报警了，最后导致谁也不敢动服务器，把业务紧急迁移了。

@foxni #73 这种几率其实很高的，同批次硬盘的寿命都差不多

运维同学都是有故事的，开发一比弱爆了

@mossss21 这个方法好！！！！

想起前东家的一件事，有个付费接口，好像是银行卡还是身份证的认证，调用一次多少钱的。
结果我们跑测试的同志，把几十万条数据跑起来了。跑了几个小时候才发现。

我一直有一个习惯执行`rm`之前先顿一秒看下命令，不是故意的完全是神经反射，别问我怎么获得的这个技能。

另外最近脑抽把 git 仓库里的 development 远程分支删了，幸好有在操作之前有先把远程 pull 到本地的习惯，这个技能也别问我是怎么获得的。

@AllOfMe 这么重要的东西就应该放内核里，怎么可能让删的呢？

第一份工作的时候, 老大把线上服务器(web)删了.

一不小心把线上游戏服务器给停了几百台，停到一半发现了,赶紧 ctrl+c, 但基本停完了，当时想的是 Python+salt 效率好高，2 秒钟发送了几百次停服指令

@daigouspy 无法完全避免，除非做用户权限管理，但是大多数情况都是 root 直接上的。。。glibc 我这辈子是不会再碰了，有心理障碍

@k9982874 我是习惯性把代码 git 到自己的 visual studio online 上，前几天手一抖在项目现场把写了两个星期的代码全删了，瞬间就觉得血液从脸上退下去了，缓了半分钟才想起来 git update 过了。最后花了一天时间重建了一个丢掉的配置文件

@liuzhedash 啥公司。。。

之前也看过类似不少楼上的运维事故,导致我第一次操作生产数据库的时候,满手是汗(貌似),精神非常紧张,虽然是有事务,可以回滚,也有备份,但是还是忍不住紧张,操作完之后还核对了很多遍.当然现在已经没啥感觉了,但是发现自己错误操作的时候还是会惊出一身冷汗.
嗷,我也干过卸载 yum 这样的事,虽然是在测试的服务器上,但还是被老大嘲讽了一通.

git 切换分支后，git reset --hard。。。

rm -rf ./* 写成了 rm -rf /* 从此之后不在 ./*

别动不动用啥 我司，你司的，用的不对哈，之前看着不爽，去搜了哈，觉得之前是的国企再用司哈

周一数据中心异常断电，部分服务器重启。

那些 rm -rf 日常是是使用 root 登陆服务器操作的么？
曾经手误 kill 的时候带上了-1，至此打死再也不用 root 用户登录，除非不到万不得已的时候…

疲劳时别坚持。
前几天熬夜，连续两次误删文件，第二次快照恢复后立马不再操作休息了。

(生产环境)误删 glibc +1
还不是删了那个 symlink，是把那个 so 文件删了

兼职遇到的垃圾公司

@Hardrain 是你删除的还是兼职公司人员删除的？后续是重装了吗

@AntonChen 其实我一直用的是 rm -fr *