日期：2014-02-24 23:11:37
　　嗯，今天出了点临时的状况，本来准备晚上多更新一点的，只能趁睡前抓紧点时间来写一小段。
　　如果把lz到目前为止近15年的工作经历做个划分的话，在进入目前这家公司之前呆过的4家公司是一个阶段，从1999年9月到2007年7月，差不多8年，2007年7月至今，一直为一家同一家外企服务，7年多，两个阶段正好各占一半时间。
　　第一个阶段，总体来说混的比较失败，前4个要么是创业型的小公司，要么是夕阳产业，公司制度不成熟，没有企业文化，没有战略规划，很多事情都是老板一句话决定。前面有朋友说羡慕我运气好，也有身边的朋友这么说，总是在关键的时候有人出手相助。但是从我个人的经历来说，前8年得到不少领导的赏识和帮助，但是还不是混的很惨？
　　从我个人的意愿来说，我更愿意在一个不需要依靠别人特别的赏识，而是依靠企业、组织成熟的文化、制度，依靠公平、有序的竞争，让有能力的人能够自然而然的出头，而不是寄希望于关系或者特殊的对待，这样的环境当中工作。

　　关于第二个阶段，正好这里集中回复一下前面很多朋友的疑问：
　　第一，楼主是以高中学历应聘这家外企的软件工程师的职位，不是一上来就是总监，罗马也不是一天就能建成的是么？
　　第二，关于60万年薪多还是少，每个人的看法肯定不一致，就我个人而言，一方面肯定超出了7年前进入这家公司时的期望，当时希望能稳定的掙个2万以上的月薪就已经非常满足了，但是另一方面，偶尔回顾过往的时候，会很后悔2件事，一是没有拿到本科文凭，二是前8年走了太多的弯路，如果这2点能做的更好一些的话，肯定要比现在做的更好一些。俗话说，人比人的气死人，所以还是少跟别人横向来别，多跟自己纵向比一下更有积极意义一些。

　　第三，楼主大概花了6年多近时间一步步从一个普通工程师升到总监的位置，差不多进入这家公司将近一年开始读一个本科文凭，按学校的计划是要5年，但是最后一年因为论文的问题多读了半年，所以实际上升总监职务的时候，学历仍然只有高中，现在还没拿到文凭，不过也快了，估计再有2，3个月就能拿到了。
　　好吧，前一阶段基本总结完了，下一阶段也做了个概括性的介绍，下面开始详细讲一下进入这家外企后的经历。
　　日期：2014-02-26 16:25:10
　　进公司后，马上开始体会到成熟公司的氛围，进去第一天除了领到了早就准备好的新笔记本电脑，然后就是各种入职培训，之后一个月内也参加了不少专门的业务知识培训，虽然那个时候由于刚开始接触金融业务，对于很多培训都还有些茫茫然，理解的不多，但是确实很感慨，毕竟楼主在之前8年左右工作经历中，就几乎从没有接受过任何的培训。
　　除了各种培训之外，主要工作就是学习公司的一个新产品的源码，杨总专门和我谈了一次，让我自己定了个学习计划，准备花接近3个月的时间，把这个产品的代码系统的学习一遍。
　　结果才1个多月，学习计划就被意外的打断了。公司当时在外地有一个新项目，刚刚上线，但是上线后问题比较多，于是我所在项目组的同事逐渐都被派过去了。当时在听到这个事情的时候，说实话我对公司的安排是有些疑问的，既然是新项目，为什么不在一开始就多派些人过去，结果现在搞成了添油战术。到最后项目组无人可派，连我这个刚入职的新人也不得不被派了过去。
　　到了之后，发现项目组的情况确实很糟糕，一方面系统刚上线，问题不少，几乎每天都有新的问题产生，另一方面，由于之前开发周期紧，一部分功能没有如期投产，客户要求一个月之内必须把这些剩下的功能都投产，所以导致10来个同事一方面不停的解决生产问题，另一方面还要开发新功能，配合测试，工作强度非常大，已经到了每天顶多只能睡2-3个小时的地步。
　　我由于是新人，对业务不熟悉，所以安排了两个纯技术的生产问题给我。一个是关于该系统无法部署新规则的问题，一个是系统日志无故丢失的问题。这两个问题从系统一上线就发生了，截止目前已经2周多，但是完全没有任何进展。尤其是第二个问题，系统每次启动之后没多久，日志就完全没有了，导致其他的生产问题也无从查起。这里说一下，公司的这个产品，也是完全采用的各种JAVA开源框架来实现的。

　　所以我优先解决第二个问题，由于系统采用的log4j的开源日志框架，所以先读了一下系统里面集成log4j的相关代码，没发现什么问题，然后因为系统对log4j做了些封装，也就是自己实现了部分日志功能，我担心会不会有压力问题，于是自己写了些代码做了下压力测试，发现没有问题。于是首先就排除了代码问题、性能问题这两点，最后我根据经验，开始怀疑是不是因为系统集成的某些开源的框架的日志功能和系统的日志功能出现了冲突，然后就对整个系统的代码以log4j为关键字进行了全文检索，结果真的发现了问题，原来系统集成的某个功能模块，也试用了log4j的日志，而且有自己的配置文件，原本已经被禁用了，但是后来不知道被谁给打开了。于是只要有人使用了这个功能，就会尝试再初始化一次log4j的日志引擎，就会导致系统原本的日志全部都没了。

　　我来了之后只花了不到2天就解决了之前困扰了大家很久的故障，而且这个故障解决之后，日志可以正常输出了，大家排查其他生产故障的效率也提高了很多，我也再接再厉，开始解决分配给我的第二个故障，即不能部署新规则的问题。
　　规则其实是个我之前完全没有接触过的比较高端的技术，一般只在企业级的应用中才会使用，所以我一方面囫囵吞枣地了解了一下公司使用的开源规则引擎的基本情况，然后开始结合日志排查问题。结果我在与操作时间接近的日志里面看到了一些非常熟悉的内容，因为这个时候系统是部署在Windows服务器上，而这些同样的内容我以前曾经在原公司所使用的Linux服务器的系统上看到过，即类似“文件句柄数达到了最大限制”。这个时候我非常惊讶，因为我之前在Linux上碰到的问题是由于Linux服务器有默认的限制，一个应用程序打开的文件句柄数不能超过1024或者2048个，但这是个系统级的参数，可以自己修改，所以把这个参数修改到更高就解决问题了。但是windows上会有类似的问题吗？后来通过网上查询了解到，原来是客户采用的中间件服务器自带的JDK版本存在问题，调用了Windows的一个比较底层的函数，而该函数有打开文件句柄数的限制。经过试验，只要升级JDK版本就可以解决问题，但是这时候出现了另外一个问题，即客户不同意随意升级JDK，因为客户作为一个大型的外资金融企业，对于各种软硬件的版本，都有着严格的要求和规范，只有经过正规的测试后的版本才能够允许部署，现在不能因为我发现的问题就随便升级。

　　这个时候比较纠结，如果要解决问题就得升级JDK版本，但是客户又要求必须经过全面测试之后才能升级，而这时候我们显然没有时间针对JDK安排全面的测试。最后我灵机一动，既然此问题是由于在部署规则的时候，系统打开了过多的文件句柄l，而且这时候我们部署的最终系统是以war包方式部署，在war包里面最终的部署程序是以单独的class文件方式存在，并没有打包成jar文件，如果我们先打包成jar文件，那对系统来说就是一个jar文件，而不是成千上万个class文件，这时候再部署，会不会有效呢？结果测试之后发现居然真的有效，这样我们既不需要升级JDK，也不需要做别的大的改造，仅仅是改变一下最终发布的代码的方式，就解决了这个问题。

　　于是，一个星期之内，我一下子解决了两个很麻烦的技术问题，开始在项目组内有立足之本了。
　　日期：2014-02-26 16:40:49