下厨房 6 月 26 日数据丢失事故总结

[eric]

1. 备份节点因故下线长达两个月，一直没有重新启用；
2. 使用 rm -f 删除备份节点文件，5 分钟后才发现进错了机器……

全文在这里： http://tech.xiachufang.com/?p=18

[lichao]

我不止一次 shutdown -h 0 然后发现是在服务器上

[eric]

@lichao 我也试过。后来我给所有生产环境上机器的 PS1 都换了个颜色

[wang2191195]

那个员工怎么样了=_=

[thinkxen]

我了个去啊~

[Ricepig]

有人发现吗？在这个案例里，信息产业部下属公司数据恢复能力强于阿里巴巴dba团队出来创业的沃趣科技

[skydiver]

@Ricepig 他们两个公司干的不是一个事情。

[kennedy32]

每个这种事故，都有因故没有备份数据库的事件出现
相似的错误造成一次又一次事故

[master]

虽然说操作失误千不该万不该，但最后暴露出来的还是对运维的不重视
所以这大概是国内很普遍的情况吧，技术团队兼作运维，
所以因为还有研发的工作在，所以运维的方面即使明知有疏忽，
还是被一再拖延，直到操作失误才发现没有后悔药

[master]

@Ricepig
觉得对于这个问题讨论公司人员背景好像意义不太大，
毕竟是误删磁盘数据的恢复工作，这个肯定还是以做数据恢复为主业的公司更擅长一些
沃趣的关注点毕竟还是放在运维，虽然说删磁盘这种事也算是运维故障

[TonyLiu2ca]

测试环境很重要吧，生产环境的改变之前要有测试计划吧，测试之后要有升级脚本吧。

[jason52]

看看那个数据恢复公司成功恢复的案例，令人大吃一惊啊，什么医院，银行等单位运维都是蛮重要的啊

[Ricepig]

@skydiver 哪不同了？

[breeswish]

@Ricepig 做的事情是一样的，但是后面一个毕竟是专业做数据恢复的，这跟阿里那个以运维为主的不能比的嘛= =

[sykp241095]

这次下厨房发生了这个事故后，我特意注册了一个 shutdown.sh 域名，请问各位这个域名可以用来做什么。。

[firsthym]

深刻的教训

[julyclyde]

@master 我觉得就是人员背景问题。你说的对，初创企业对运维不够重视

[skydiver]

@Ricepig 一个是硬盘数据恢复公司，一个是数据库专业服务公司。

[laogui]

那个员工怎么样了?有没有被杀害？

[laogui]

看了这个过程感觉技术好牛X，从硬盘修复中、从内存中、从memcache中、从binlog中、从搜索引擎的快照中。从这几种东西里提取了一堆不完整的数据你们竟然最后可以搞一块去。太佩服你们的技术了。

[apptao]

@lichao 我也是, 后来我把服务器上的shutdown都改名了.