瞎扯淡 总结教训
这次论坛帖子的损失很大，大家痛心不必说，责怪谁也没意义，不如讨论一下如何总结教训吧。
事情背景参考这个： http://ruby-china.org/topics/7748
当然我们可以制定制度来解决问题，比如禁止在线进行 rspec 操作，但是好的办法应该是尽量用技术和框架来搞定而不是给人定一堆条条框框。
个人观点，这次的问题是由于线上机器部署了与产品无关的配置和代码信息导致的，如果线上根本没有 rspec（以及其它用于开发、测试的环境），那么这个问题就可以很容易避免了
另外一个角度，最近在考虑这样一件事，软件框架通常都提供 production/test/development 三个不同的配置环境，初看挺不错，但有两个缺陷：
- 实施的时候容易把环境配置文件和源代码放在同一个版本控制系统中，而真实的场景中，环境的配管信息其实是和代码有不同的维护方式和生命周期的，这是导致线上可以做 rspec 操作的一个重要原因
- 所谓 开发/测试/线上 其实只是一个很粗略的环境分类，在真实的情况下，会有小集成（若干应用联调），大集成（系统测试）以及很多临时性的环境配置，这些都是工作中的“暗礁”
所以，似乎应该取消这种僵化的“三个环境”的配置管理策略，系统只有一个环境，但是由外部的配管系统来进行统一的配置项管理。
第一个办法比较容易，bundle+capistrano 能解决这个问题么？也许 @xdite 会有办法 第二个办法比较“大”，如果能结合一片“云”来做更好，所以可能仅适合大公司
@bhuztez 是因为有个 bug 只有 production 环境才能重现 https://github.com/ruby-china/ruby-china/pull/143
小数据保持每日备份，上 10G 的数据不知有何办法 其实这和跑步跑测试没有关系，这次问题是正好哪里有个漏洞，才导致的。
应该从数据库级别限制：
- 不允许删除数据库
- 不允许全表删除
赞同 @reus ，简单最好。
我上午发过一个贴，现在这个状况也适合：疏忽大意的危险在于每个人都认为自己没有疏忽大意。没有摔过跤，就总会觉得悲剧不会在自己身上发生。我也是挂过一次服务器才养成了每日备份的意识。
说下我们的备份方案: 1, RAID 1 2, 每天夜间 rsync 增量备份 3, 每天夜间 rsync 异地机房备份 4, mysql 主从复制
