1天，我计划的时间。
3天，实际需要的时间。
这个是我到客户那边部署系统的实际情况。为什么时间上差距这么大呢？主要是俩方面的原因，今天也总结一下：
一方面是技术方面的原因，由于服务器是有专门的维护组维护的，所以在我部署ASP.NET Web Application的时候，他们已经将帮我安装好了操作系统(windows 2003 server enterprise edition + sp1)和IIS6.0；所以按照道理我只要安装好数据库和将程序在IIS中设置就好了。但是事情就是不可能那么顺利，这回卡着我的是的IIS，首先出现的问题是，无论请求什么页面(.html, .aspx)还是资源文件(图片等)，页面总是显示"Service Unavailable"，查看IIS6.0中Web Application的应用程序池，发现DefaultAppPool没有处于运行状态，运行DefaultAppPool，再次浏览某个网页，问题依旧，然后再查看应用程序池，结果发现DefaultAppPool又被停止了。这样意识到是可能在运行Web Application的时候出现了问题所以导致应用程序池被停止。查看系统日志中的“应用程序”，发现了应用程序池在访问一个DCOM组件的时候权限不够，日志里面提供了CLSID信息，这个需要到注册表的HKEY_CLASSES_ROOT下得CLSID中找到对应的CLSID值，然后就可以知道对应的DCOM组件了，按照日志的提示将对应的权限进行设置一般就可以了。设置了权限再次浏览网页，现在页面显示了HTTP1.1的提示页面 -- “页面无法显示”，这个时候“应用程序”日志中间已经没有对应的信息了，所以这个时候需要查看的日志是系统盘WINDOWS文件夹下的System32下的LogFiles文件夹，里面有一个HTTPERR和W3SVC1两个文件，里面可以根据时间找到对应的记录信息，从HTTPERR中发现造成显示“页面无法显示”的原因是“Connection_Dropped”，而从W3SVC1中的日志可以看到对应的HTTP状态码是404.3，在网络上查了一下以下是对404.3状态码的描述:
HTTP Error 404.3 - Not Found描述: 由于 Web 服务器上配置的多用途 Internet 邮件扩展(Multipurpose Internet Mail Extensions, MIME)映射策略的原因，无法处理所请求的页面。您请求的页面具有无法识别的文件扩展名，因而不被允许。看来是针对后缀名的解析问题，尝试了一下.html和图片文件(如：.gif)，显示正常，唯独对.aspx等后缀名的文件不能正常运行，查看IIS6.0中的“Web应用程序扩展”，发现对应的解析都已经启用了，没有办法，重新安装IIS6，重新运行Web Application，问题解决。(这里跑一下题，微软的东西不是重启就是重装，真是有道理。)，至此已经消耗了2天的时间了。
明天是第三天，主要是为服务器分配一个IP以便员工能够访问服务器的应用程序，这个本来和我没有什么关系，有专门的网络组来进行分配和调试，但是对于用户来说他们希望是万无一失的，所以全部要到场，所以明天还要去一天。希望能一切顺利，不要又节外生枝什么的。想想以后像最后一天这样的情况是可以尝试避免的，以后在部署系统的时候就要询问清楚，客户需求的网络条件，如果发现网络条件不满足(比如服务器IP的分配、DNS的配置)这些都可以提前和对应网络维护人员打招呼，这样实际上就是并行进行工作了，可以节省时间，现在实际成了串行操作。
今天写这个日志主要是两点，一是IIS出现问题的分析方法，日志看来是一个非常重要的东西，以后在每个系统中都要搭建完备的日志系统；二是对于工作的职责分配和安排要尽量做到并发，这样可以节省时间。
P.S. 感谢我的主管陈峰和导师倪骏无私耐心的帮助。