6101项目总结

       6101的项目就快要结束了，在这个项目我的职责是安装/配置/维护测试环境。在做6101的前一个项目6014之前，项目组长就跟我说下一个项目由我来做测试环境的维护。当时心情有点紧张，主要是担心自己做不来。一方面自己做安装和配置做得很少，另一方面感觉压力会很大。一旦测试环境出问题，搞不定是要影响全局的。当时心里诚惶诚恐。从过去的经历中，我发现，在做任何事时，只要是第一次尝试，我都会犯很多的错误，甚至是很严重的。就我个人而言，对新鲜事物我总是抱有热情。所以当时在lead和我讲时，心情既兴奋又紧张。

       在6014的项目，我没有真正意义上去做安装和配置，只是应要求安装了机器，从安装操作系统到把所有软件配置完成。6014是一个小项目，持续了三周时间。下一个项目6101，环境的维护就完全由我来做了。

       开头的几天，一切还比较顺利。可能是因为机器的环境都还比较“单纯”，所以在配置过程中少遇到问题。后来情况就大不一样了。一方面需要维护的机器数量增多，有时候得同时安装几台机器。另一方面，自己也犯了不少不错，比如在运行脚本之前忘记修改配置文件或者写错了等等。当时一遇到问题，紧张得不得了，好像自己犯了天大的错误，急忙找同事来解决。在刚开始的时候，更多是由自己的失误造成的。有一个同事告诉我，如果是比较紧急的任务，遇到问题赶紧解决，不管采取什么方法。如果时间充裕，可以多花时间研究一下。可惜，我没有将这句箴言完全落到实处。到后轻车熟路了，遇到常见的问题就能知道错在哪里。不过也会遇到同事未曾碰到过的问题。这些问题中不少与环境有关，比如数据库或者其它。偶尔也会遇到连google也搜不出任何关于它的信息，这类问题与某个类相关，比如这个类找不到，或者因其他的文件丢失而导致初始化失败等等。如果从log输出能直接看到某个文件丢失，大可从其他机器上拷贝过来即可。但是有一些就非常棘手，解决的唯一办法就是重装，尽管我认为这是最没技术含量的办法。改善的一点是，我逐步过渡到自己解决问题的阶段，在问题解决的方法上，我可以自己选择。是的，事情既然由我负责，那么我应该是解决问题的主体。

       维护测试环境的压力，我认为大概是由两种情况造成的。一是任务的复杂性，二是问题的复杂性。如果同时安装多台机器，增加了犯错的概率，会影响心情。特别是对有限期的任务，压力感会更大。当测试环境出现故障，导致其无法使用而问题又很紧急且一时半会又没辙的时候，压力就特别大。

       回头望望，我认为自己最大的失误是，在项目一开始，我并没有任何关于安装环境的安排和计划，采取的是一种基于需求的策略，属于被动型。需求是难以捉摸的，有时候一个没有，有时候可能会扎堆。因此，在一开始应该有一定策略来分散这些需求。比如没有需求时，主动去更新某台机器的环境，或者制定一个计划安装或更新某些server，并让所有使用的同事知道。同时，尽早收集同事的需求。经过总结，有如下改进工作的规则。

1.      在项目开始之初，和lead商量，优先安装某些测试环境

2.      在考虑安装其他测试环境时，先收集需求。根据需求的优先级来安排时间表。

3.      除了根据需求来安排时间表，在需求少的情况下，主动去update测试环境。

4.      在维护环境中遇到问题时，一般会有多种解决途径，重装是下下策。

5.      考虑紧急情况。对突发事件的处理。比如一个月以前，将servers搬到新Building之后，许多server不能正常运行。对某一事件带来的风险，应该进行估计然后考虑可能的应对策略。

6.      最好将配置过程和问题解决方法文档化。将遇到的问题记录下来。

7.      在项目正式开始之前，就要做一些必要的准备。比如需要安装的软件以及相关资源，甚至估计在测试过程中可能会遇到哪些严重问题，并寻找解决方案。