在Red Accent的时候，因为是个小团队，又是创业公司，所以很多时候工作会要求你有身兼数职的能力。没有办法像大公司一样，每一个专业的领域都有专人甚至专门的团队来负责。大部分时候都是遇到问题，然后看公司里现有的资源下选用最快性价比最高的方案来解决。这里面有一个经历可能是对我个人来说非常有经验性和启发性的，所以想在这里分享一下。
我们的版本管理是用Perforce的，在公司里自己组装了一台PC运行P4来管理日常的项目开发，相当于一台内网的服务器，不过除了选用了一块监控级别的硬盘之外，这台服务器的配置和普通的家用PC其实并没有什么特别的不同，也许难以置信，但是在24小时连续运转的情况下，4年多时间里，Perforce的服务运行的稳定又健康，应付我们这样的小团队开发，似乎是绰绰有余的。
中间有段时间我偶尔想到过这个服务器一直在角落里这么忍辱负重的工作着，真的不要紧吗？需不需要个保养啥的，然后又被“看来Perforce还是挺靠谱的嘛”这种想法麻痹过去了。
直到有一天，突然有同事说他电脑上有个文件拉不下来，会持续报一个“file corrupted during transfer (or bad on the server)”的错误，查了官方的文档，说是在校验过程发现文件损坏了，有两种情况可能会造成这个问题：文件在网络传输的过程中发生了损坏，或者文件在服务器本地发生了损坏。
我寻思服务器好好运行着不太可能有问题吧，这概率太低了，难道是网络传输过程中出错了？这概率更低啊！这个损坏的文件我们尝试着重新上传了一遍，似乎问题就解决了，也可以正常的拉下来了。虽然影响不大，但本着“防火护林，警钟长鸣”的原则，我还是在下班后在服务器上运行了磁盘检查程序，没有发现任何问题，那天晚上我在一片狐疑中沉沉的睡去了。
之后的几天里一切正常，也许真的是哪根网线抽风了一下吧？我这么骗自己。但好景不长，很快又就又碰上了同样的文件损坏的问题，而且这次还是CI版本机帮我们发现的这个问题，虽然这种情况可以通过重新上传来解决，但这总是萦绕在心头的一块疑云啊，更何况无论用什么工具检查硬盘得到的结果都是一切正常。
很快P4服务器又有了新问题了，P4的Service(Windows)开始时不时宕机了，最早以为是Windows死机了，因为重启服务器后就恢复正常了，但几次之后发现其实只是P4的服务挂了，重新启动P4的服务就好了，问题越来越诡异，而且P4服务宕机的频率也开始呈现越来越频繁的趋势了。
我和小白(老板)反映了这个情况：“我们的P4服务器已经任劳任怨的跑了4年半了，也许它是有点撑不住了”。我准备不管怎么样先换一块硬盘吧，就算你检测程序再怎么跟我打包票，但文件就是在你上面坏掉的啊。
买了一块新的监控级硬盘，因为不能影响别人平时正常工作，自己周末跑到公司导了全盘的数据，换上了新的硬盘，那天晚上我在“解决了一件大事”的美妙心情中沉沉的睡去了。
可怕的是没过多久同样的问题又开始出现了，而且是赶在我出差去韩国的时候，那天又刚好是“版本之夜”，很多人在公司里为了出版本奋战到了午夜，结果在这种关键时刻P4宕机了，半夜里在韩国宾馆里接到这种电话不由得让人意识到情况已经到了刻不容缓的地步了。
但是紧接着更惊悚的事故出现了……因为苹果审核的缘故，我们接到需求需要改一点配置然后重新编一个两周前我们出过的版本，按说这个需求很简单，我们只需要在版本机上设置一下回溯的版本号，重新编一下就好了，但结果惊奇的发现那个历史版本里有一个文件竟然也损坏了！怎么可能，这个文件在两周前绝对是好的！而且版本机上也有成功的版本记录，也就是说这个文件绝不可能是在网络传输中损坏的，在到达P4服务器硬盘上的时候应该是完好的，而是在这两周中不知道哪一个时刻，随机的，这个文件就突然损坏了！！！这太TM惊悚了！
很快服务器组也遇到了同样的问题，一个配置表文件也莫名其妙的损坏了，因为之前遭到损坏的文件一直是二进制资源文件，这是我们第一次遇到文本文件的损坏，通过对比，我们发现文件中的一个字符被篡改了。我又陷入了思考……病毒？下班后我又做了全盘杀毒扫描，并再次进行了硬盘检测，还是一无所获。
苹果审核版本因为受到了影响，所以小白也开始关心起了这个问题，我决定这次干脆换整机，重新装系统，而且P4也重新安装，再通过“备份再恢复”的方式来尝试彻底解决这个问题。
P4仓库的数据安全还是关系重大的，在强撑着完成了当时soft lauch之后，我腾出了一个星期的时间，学习P4的很多系统管理的内容，包括P4内部存储的机制，备份/恢复的流程，需要注意和避免的情况，并在本地一一进行了测试，季荣也帮忙把新的P4机器组装完毕，万事俱备，准备迁移！
我准备了周末的两天来进行这个工作，我们的仓库在4年多的时间里一共是800G的大小，所以备份起来还是要花一点时间的，”p4 verfiy”是果不其然的会遇到”BAD!”的文件的，这时才发现不仅仅是我们当时工作的depot有文件损坏的，甚至一些古老的仓库中也有文件遇到了损坏，我一一检查了这些文件，所幸并没有那种不可挽回的文件损失，老项目中受损的都是历史文件。但是真正奇怪的是用”p4 admin checkpoint”备份出来的文件本身也是通不过校验的！按照官方文档的说法，这是绝不应该出现的问题，而且更诡异的是每一次备份出来的MD5值都不相同，于是迁移计划只能先推移，因为如果每一次备份的结果都不相同，我根本无法知道哪一次备份的结果是值得信赖的。
我又花了几天的时间做了更多P4备份的测试，得到了一些有用的线索：在我的机器上做备份总是可以得到一致的备份结果，MD5永远相同；在P4服务器上备份公司的仓库永远无法得到相同的结果，即使使用不同的硬盘；但是在P4服务器上备份测试用的仓库（容量小）可以得到相同的稳定的备份结果。这基本上可以证实这台服务器是有硬件问题的，我拆开机箱，看着里面满是尘土的主板，破旧的电源看着就让人很不放心，硬盘在测试过程中也换过好几个了，但似乎每个部件都是不值得信赖的。
我准备放弃调查了，直接在一台可以得到稳定备份结果的机器上备份，然后全部移到新服务器上就好了，老的服务器爱咋咋地吧。但是你知道的，有些事放在心里不知道为什么真的很难受，我感觉已经非常接近事情的真相了，那天晚上我在一片思索中怎么也睡不着……
第二天我赶在所有人之前到了公司，我先把P4服务器断网，找了找有什么好用的内存检测软件，哦，原来Windows系统自己就带的，测试的结果是令我震惊且欣喜的，原来我最认为不可能出问题的硬件，它出问题了……
换上了一根新的内存，在老P4服务器上备份的结果也一致了，原来这个内存上有个字节（也许只是一个bit）坏掉了，所以当数据恰好覆盖到这个字节的时候，数据就被改变了。因为并不是每次操作都会用到这个字节，所以问题出现是随机的。P4服务宕机应该也是因为运行到了坏掉内存而导致P4程序崩溃了。小仓库的备份因为小所以用到的内存也少，而我们公司的仓库因为大，所以备份时是用满内存的，所以一定会覆盖到这个字节，所以每一次备份的结果都是不同的。
备份恢复后，新的P4服务器持续稳定的一直运行到今天，我为在解决这个问题的过程中曾经怀疑过P4算法和数据结构的稳定性而感到抱歉，也深深的明白了备份机制的重要性，尤其是对于小团队自己维护服务器的人力成本还是不可忽视的。另外，对于计算机学科来说，我最喜欢的部分就是无论问题是多么的诡异，多么的不规律，多么的不科学，它背后都一定是有一个确定的，规律的，科学的原因在导致问题的出现。
我终于可以安心的沉沉的睡去了：）