你司有没有过运维事故？

[AllOfMe]

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

[mossss21]

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

[jrient]

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

[virus94]

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

[caaat]

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

[funcman]

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

[ETiV]

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

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

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

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

[Showfom]

@ETiV 然后怎么处理的

[chenhonzhou]

@ETiV 悲惨了

[lingo]

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

[shadownet]

删库，经历过 1,2 次吧

[7654]

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

[imaning]

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

[niuoh]

我执行过 chmod 777 / -R

[SoulSleep]

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

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

[opengps]

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

[Felldeadbird]

@ETiV 后续赔钱了吗？

[liuzhedash]

前司到处都是：
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 多就已经竭尽全力了。
希望大家负责的项目都能稳定运行，天长地久。

[Phariel]

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

[xiaoheshang]

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

[xiaoheshang]

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