这是一个创建于 4501 天前的主题，其中的信息可能已经有所发展或是发生改变。
第 1 条附言 2013-07-03 17:26:00 +08:00
@uitony 给的有关次此次事故细节及原因。http://tech.xiachufang.com/?p=18
 | 1 Livid MOD PRO 天，不知道说什么好…… |
 | 2 Kvm 2013-07-01 04:36:39 +08:00 这个彻底蛋疼了。。。。。 |
 | 3 dreamage 2013-07-01 04:39:58 +08:00 via Android 弄到SAE去吧 |
 | 4 hanbaoo 2013-07-01 08:08:49 +08:00 via iPhone 我总觉得，不是这样。。。一周前，我查一道菜，就很多null，当时还觉得奇怪没数据怎么会出现在搜索结果里 然后看了这个日志，总感觉是危机公关的味道 |
 | 5 Kenny 2013-07-01 08:21:34 +08:00 好几个应用都比下厨房好用很多，而且貌似下厨房还没出 iPad 版？ |
 | 6 Gawie 2013-07-01 08:49:28 +08:00 "那位程序员后来怎样了也顺便说下进展把。。。不要杀害他，但是可以用我们喜欢的方式折磨他吗？" |
 | 8 Fedor 2013-07-01 09:01:32 +08:00 想知道这个攻城狮后来肿么样了。 |
 | 9 vietor 2013-07-01 09:14:30 +08:00 我曾经在来北京的第一个公司就出过类似的事情。 我们公司是做“宽带计费”的，我在进行出帐的时候，不小心执行了错误的存储过程，造成出帐错误，又因为没有启用Oracle事务，造成无法恢复。计费少了，运营商亏了，好在“没有用户投诉”，我自己也没有受到太大的批评，但从此以后造成我一个习惯：做重大操作之前，必定检查再三才“怀着忐忑之心”执行。 |
| 11 vietor 2013-07-01 09:22:08 +08:00  1 关于数据删除，我在另一个公司有过类似经历。 我们公司做的是一套基于邮箱的电信增值业务。邮箱服务器放在一个RAID5的“国产”服务器上，但灾难的是两块硬盘相继损坏，造成数据丢失。将硬盘也送到“数据恢复”的公司去看，发现修复价值不大，就硬着头皮让运营商把使给平了。之后我们将邮件服务器放到一台“研华工控机”（不是做广告啊，的确让人放心）上硬是用了半年，知道我们重新购买了一个HP的服务器。那个“国产”服务器之后又坏过一次内存，造成我们只拿那台机器做备份了，不敢放任何有价值的数据。 最大的感受是：小心“国产”服务器呀，坑人那。 |
 | 13 cxshun 2013-07-01 09:24:59 +08:00 操作前不做备份，这能吐槽一下吗？貌似操作前备份数据库是必做的事情啦。 目测下厨房会失去一部分用户。 |
| 14 vietor 2013-07-01 09:29:51 +08:00 |
 | 15 xhinking 2013-07-01 10:07:29 +08:00 半夜12点操作数据库一定要清醒啊~ 感觉国内料理界倒退5年啊~~ |
 | 16 julyclyde 2013-07-01 11:11:24 +08:00 应该是没做备份和备份恢复实验 说实话国内绝大部分小企业是缺乏运维人才的 国内的教育和培训也大都是偏向开发方向 |
 | 17 Mihuwa 2013-07-01 11:25:41 +08:00 数据库操作一定要小心啊 |
 | 18 explon 2013-07-01 11:33:45 +08:00 不重视数据备份的悲剧下场 |
| 19 julyclyde 2013-07-01 11:37:37 +08:00 1 @vietor 硬盘就是耗材，你自己没做好RAID状态监控，别把责任推给厂家。厂家只要能在硬盘故障的时候点亮故障灯就算尽到义务了 |
 | 20 feiandxs 2013-07-01 11:37:59 +08:00 我打赌楼上也有不少人到现在还喜欢生产环境挽袖子就上。。。 |
| 22 vietor 2013-07-01 11:43:32 +08:00 @julyclyde 的确是没有做好做好状态监控，第一块坏了的时候没有及时补上。呵呵，总有些人为因素的。只是两块坏的间隔太短了，和产品还是有直接关系的，那个HP的一块都没有坏过那，当然国产的价格便宜了点，其中一个创始人用过那家的服务器悲剧的后果。 |
 | 24 solo7net 2013-07-01 11:56:10 +08:00 3 我也干过.... DB1 DB2 某大神:你把DB1导个表结构出来 放到DB2 我:点这? 神:恩 导入就行了 我:次奥 DB1怎么空了 发现导出的第一行 USE DB1; |
 | 29 Leo 2013-07-01 16:24:40 +08:00 被顶起来的评论 Biu爷 那位程序员后来怎样了也顺便说下进展把。。。不要杀害他，但是可以用我们喜欢的方式折磨他吗？ 虽然好忍但好想笑 |
 | 33 MayLava 2013-07-01 20:49:24 +08:00 我也犯过2。 为了调试方便在host里把线上域名指向localhost，然后各种测试。 然后有一次刚改回localhost，执行了清空数据库操作，结果浏览器的解析缓存没有重置，直接清了线上的所有数据(￣￣")。。。。 |
 | 34 xuzhe 2013-07-01 21:11:58 +08:00 1 数据不备份、备份是否完整不验证，出了事儿只能是活该了。 |
 | 35 dreampuf 2013-07-01 21:24:20 +08:00 人才都是坑出来的。 |
 | 36 likuku 2013-07-01 21:25:32 +08:00 @vietor 「。那个“国产”服务器之后又坏过一次内存，造成我们只拿那台机器做备份了，不敢放任何有价值的数据。」... 有时备份就是唯一的救命稻草，没了就死了，备份机应该比线上生产机更加可靠才行啊。 |
 | 37 zyAndroid 2013-07-01 22:39:07 +08:00 去年11月，一个误操作删除了一张表里两个多月的数据（百万行），到现在想想都心有余悸。 老板说“这是你工程师生涯的第一个里程碑”，当时差点儿羞愤自尽啊啊啊 |
 | 38 gracece 2013-07-01 23:03:14 +08:00 自己的一个小网站，一不小心也把一个表清空了，着实蛋疼了好几天。估计下厨房那个工程师会铭记这个教训的=。= |
| 39 vietor 2013-07-02 08:47:25 +08:00 @likuku 主要的原因是“成本”，老板也是在出事之后才开始腾出机器进行“备份”。 本来RAID5是一个不错的选择，哪知“点太背”，坏硬盘坏内存的。整个系统在没有任何备份的单硬盘“工控机”上都“没任何问题”的跑了半年呢，可想而知那个机器太烂了。 最终奉献一下，那家国产服务器的厂家名称：“宝德”，06-07年左右的事。 |
 | 40 hadi 2013-07-02 09:41:09 +08:00 除了备份计划，做好自动化部署也比较难出这种状况吧? |
 | 41 Hyperion 2013-07-02 09:50:10 +08:00 看到第一条回复毛骨悚然... Biu爷 那位程序员后来怎样了也顺便说下进展把。。。不要杀害他，但是可以用我们喜欢的方式折磨他吗？ 汆水? 清蒸? 凉拌?...... |
| 45 hadi 2013-07-02 15:26:39 +08:00 @likuku 的确没有什么能百分百保证不出问题，不过从 development -> staging -> production 走下来，recipes 一般不会有什么大问题吧，手工重复执行这些步骤，出错机率还是要高一些的，也不符合程序员偷懒的原则嘛。 |
 | 46 neodreamer OP @solo7net >_<!!!!! |
 | 47 akira 2013-07-02 15:45:50 +08:00 不是每家公司都会注重数据库安全的 |
 | 48 moyaya 2013-07-02 16:35:24 +08:00 我们网站也有过一次误删除数据库的经历，结果我们自己每天在AWS上有备份，阿里云有快照，大概只丢了一天的数据。 |
 | 49 kalintw 2013-07-02 19:50:00 +08:00 CTO可以下课了 |
 | 50 jjgod 2013-07-02 20:29:06 +08:00 这么大规模的上线网站，三个月没备份，挺恐怖。 |
 | 51 marginleft 2013-07-02 22:35:58 +08:00 via iPad @vietor 浪潮？ |
| 52 marginleft 2013-07-02 22:37:29 +08:00 via iPad @vietor 哦，好吧。不是浪潮 |
| 53 vietor 2013-07-02 22:37:34 +08:00 @marginleft “宝德” |
 | 54 dongbeta 2013-07-02 22:51:02 +08:00 删除过线上数据库的工程师，一抓一大把。 |
 | 57 uitony 2013-07-03 15:46:58 +08:00 2 感谢v2ex上朋友对这件事的关注， 技术总结了下技术原因和细节： http://tech.xiachufang.com/?p=18 再附上一封道歉信： http://blog.xiachufang.com/article/5601 如果数据完全恢复不了的话，确实属于「灾难性」问题。 不过最终结果我们是幸运的，感谢宽容的用户们。 下厨房技术团队有一半来源于v2exer，事故从发生到目前阶段性的解决，技术团队面对问题的积极处理和响应（几乎一直熬夜），这次事故客观上会帮助下厨房团队安全意识的提升，尽管成长代价确实有点大。 在夜里上传数据的间歇，技术团队自发地为这次事故分摊责任，总结教训，并且向公司主动请罚。 我愿意并且值得为这样的技术团队继续投以100%的信任。 |
 | 59 halfbloodrock 2013-07-03 17:05:14 +08:00 操作不严谨是外因，这个是人都会犯错。内因还是对线上系统的可靠性不重视。 难以想象是两三个月之间居然一个完整的dump备份没有。 如果这个团队没有专职System/DB Admin，可以理解，毕竟起步团队有客观原因的制约等等 如果有专职Admin，难辞其咎。。。。。。 |
 | 60 niko 2013-07-03 17:20:14 +08:00 值得沉思~ |
 | 61 manihome 2013-07-03 17:35:55 +08:00 犯过同样错误的人能体会到那位哥们的心情 |
| 64 julyclyde 2013-07-03 22:08:47 +08:00 via iPad @halfbloodrock 2011年我找工作时关注了一下团购行业，只有一家招sysop。现在看来，只有这家企业走到了最后 |
 | 65 seraphimhj 2013-07-03 22:11:45 +08:00 很好的危机营销 |
 | 67 mengzhuo 2013-07-04 01:23:14 +08:00 1 作为曾经把某汽车门户的数据库清空的实习生，当时脑子一片空白，我觉得这哥们发现的时候，脑子里也空了估计八九不离十。 虽然DBA第一时间恢复到了5分钟前的数据，但是过了两天，我最后还是引咎辞职了。 从此，没有测试系统，坚决不干活，没有备份，坚决不对生产系统升级 |
Select Language