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. 感謝我的主管陳峯和導師倪駿無私耐心的幫助。