今天一大早，一至交好友告诉我,"我们部门内平日用的编译服务器上周断电后，系统自动装了，盘被格了，平时代码都在上面，群里炸锅了"，然后我们这些朋友就开始各种奇思妙想，希望能帮他找回代码，然而。。。
仔细了解后，他们公司开发环境是这样的：内网有一台编译服务器，代码放在上面，负责代码编译与测试。研发的同学用samba将编译服务器的目录与自己的windows目录关联，每个人一个模块，所以一直没出问题。然而就在今天，编译服务器断电了，pxe又是神奇的实现了自动格盘、重装系统。
说到这里，介绍下我们公司的开发状况，我们使用php做为主要开发语言，php的运行环境不需要特别多的内存、cpu、硬盘。所以架构是这样：把一台服务器分成若干台虚拟机，每个开发人员会分到一台虚拟机做为开发机。虚拟机上的各种环境都是通过puppet统一管理，php版本、nginx的虚拟主机配置等都可以统一管理。新入职的开发人员，都会分到一台虚拟机，只要把虚拟机的web根目录与自己电脑的web目录关联，就可以快速进行项目开发。重要的一点，我们的目录关联使用的是sftp，而不是samba做的目录共享，也就是说，我们的代码存两份，两份之间会自动同步。而samba是只有一份代码，另一份只是一个虚拟存在。
好吧，再说说好友的情况，因为使用samba共享目录，所以当编译服务器挂掉后，只能呵呵了。但是版本控制系统的意义何在呢？因为是开发环境，不可能每行代码都提交版本控制，有可能一整天都在调试一个模块，所以实时提交代码到版本控制系统也是不科学的。
进入正题，这个锅应该谁来背？经过几个大牛的讨论，这个锅应该由物业来背，哈哈，哈哈。再看看其它的选项有哪些：
-
运维要背此锅，自动重装系统是什么鬼，这锅必须有你们背
-
研发主管（架构师）的锅，这开发环境也是醉了，必须由你们背
-
物业的锅，为什么要断电，怎么不通知我们
好吧，再说说今天跟一同事讨论一问题：程序里用了一个很大的数组，本地是正常运行的，但是能不能上线，上线后有可能会出问题。按照墨菲定理，有可能发生的事情一定会发生。然而在现实中，妥协是必要的，我们不能要求所有的事情都准备好之后才做出行动。人生也如此，正确的选择，合理的评估风险会事半功倍。
最后说一下关于此事的处理结果，“谁代码丢了谁重写”，哈哈，这个妥协我给打10分！