這是農歷去年（陽歷2016.1.29）的事了。公司的一個項目已開發得七七八八了，要准備上線了。項目經理與公司領導及用戶協商，定於2016.1.28日（周四）上線。但這天由於項目經理需要去機場接人，加上運維組同事也忙着。就推后一天上線。這里就不得不談下公司的項目從開發到上線的過程：公司項目分開發，測試，預發布，正式四個環境。開發和測試環境由開發人員部署，預發布環境由開發人員協助測試人員部署（我們組的測試不懂，全程操作還是由開發來部署），正式環境由開發人員協助運維組部署。
這個項目上線所需要部署的有DB，WEB程序，WCF接口程序，Windows服務程序以及文件服務器部署。 由於我們這個是嶄新的項目第一次上線。就有有很多工作要做。一周前已由項目經理申請了三台機器：DB一台機器，WEB，WCF,Windows服務共用一台機器，文件服務器一台機器。定於周五上午九點半正式開始上線，我（開發）准時去找運維同事，運維沒來，加上其他一些事直到10點多上線正式開始，我也是在這家公司的第一次協助運維做新項目上線，首先，找到運維人A（女），催促其上線。上線一般都是先部署DB（大家都知道），A說DB的部署不歸她負責，叫我找B（男），我就找B並轉發上線郵件包括上線說明文檔，B知道后說知道我們的這個項目要上線這回事，但這三台機器好像沒交到他們運維手上（沒收到郵件，由另外的同事發出的，具體誰不清楚），然后和A及其運維領導討論說了下，說機器應該是已經在運維手上了，然后B查了下，果然他們已有權限操作。B又說，這個DB部署的話要裝數據庫，這台機器應該是沒有裝SQL的。然后說要現狀SQL，那就裝吧。因為是年底了，技術部很多小組的項目都在等着上線或執行DB腳本，運維的都很忙。中間時不時有人打斷，運維組的中午又有聚餐。11點半，我回到自己的座位，下午2點半，又拿着電腦去運維組那邊。催促B，此時B開始裝SQL，大約4:20分樣子，SQL安裝好了。然后DB配置這台新機器的環境以及部署我所提供的本項目的數據庫。下午5點過點部署完成。因為項目有數據同步，需要訪問其他項目組的數據庫，B還需要配置其他數據庫針對本項目的權限及安全措施什么的。 我看他這邊差不多了，在去找A，讓A部署程序包。A這邊部署比較順利，三個部署包加配置文件修改差不多三十多分鍾。至此，A,B這邊都已部署完成。項目正式部署完成。
問題來了：由於一些主數據是Windows服務從上游數據庫同步過來的。好，先啟動服務程序。查數據庫同步的數據及看服務Log，嘎嘎！數據沒有同步過來，但服務日志沒有報錯信息。初略的想了下，感覺部署配置什么的沒有問題，我去找開發數據同步功能的同事C（女）過來看。好吧，她也沒找到問題所在。又請教了下另外一位開發同事（架構師），猜想應該是哪里異常沒記錄，沒辦法，我只得看代碼了，果然：此段代碼中有try catch但catch中沒有記錄日志和拋出異常的處理，加上異常處理重新部署Windows服務程序，還是無數據無異常日志，繼續看代碼，發現方法內調用的一個方法（因為代碼的邏輯並不是都在一個方法里，而是方法1中會調用方法2方法3或者更多）也有try catch但catch中沒有記錄日志和拋出異常的處理，加上並檢查其他方法，然后重新部署，好了，服務LOG中記錄了異常信息：無權限訪問本項目的數據庫，去找B，B重啟了下DB這台機器，然后又報另外一個異常：無權限訪問USERbase數據庫，完了，上游數據庫出無權限訪問了。此時B已經下班走了，幸好另外一位運維同事D也有權限操作，讓D加權限。再次啟動同步服務。同步的數據還是沒有過來，繼續看日志，出來了兩個異常。上游DB庫M沒有某個視圖，上游DB庫N某個視圖中缺少某個字段。完了，上游其他系統提供給本項目的一些東西都還沒有上線，沒辦法了。此時已經差不多八點多了。之前同事C和其他組確認過，都是說已經上線了，臨了居然沒上。項目經理和我們商量着說，只有等到明年在上了（因為下周我們組人差不多都回家過年走了）。運維這邊說上線單還是按已完成來做，發郵件說明明年來了在上。然后各回各家了。
悲催的一次上線經歷。待續。