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