2011年5月12日 星期四

在IIS上設定WCF Services VS 不讓小問題搞死你

前陣子,委外的廠商開發了一個.svc的WCF Services,佈署到我們的新機器上之後,怎麼也跑不起來,直接瀏覽時會出現錯誤訊息,廠商先前都沒有用過WCF Services技術開發過.svc服務,在開發環境VS2010當中確實都可以運行沒有問題,因此這個Issue又觸礁無法解決...

我們接洽的這位同事很可愛的在網路上找了這篇:
http://technet.microsoft.com/en-us/library/dd632554.aspx

然後也設定了MIME,結果服務終於在瀏覽器上不會出錯,但卻根本沒法呼叫,只會出現blank text page, 因此我重新看了一下IIS的環境,最後執行底下指令:
"%windir%\Microsoft.NET\Framework\v3.0\Windows Communication Foundation\ServiceModelReg.exe" /i

就這樣,搞定!
原因當然是Windows Communication Foundation並沒有在IIS當中正確的建立 Metabase, 使得服務無法透過IIS給叫起來。

過去我們的合作廠商和同事(都是developer background),都在Hosting(或是Windows Azure)上架設網站,那些環境都是別人已經準備好的,所以當然不會有問題。然而卻從來沒有自己從頭到尾架設一個Windows Server,因此在最基本的問題上觸礁,且花了不少時間,直到客戶直接問我,為什麼環境架設那麼久,一直架設不好,回頭找員工討論,才知道卡在這個問題上。

員工知道這一定是一個可以解決的問題(不然其他Server怎麼可以run?),因此想自己解決,也不問身邊其他同事(怕被笑?),但又因為身上還有其他工作,所以這個問題就懸了快一周,一周的時間就這樣過去不打緊,對客戶來說他反映出來的是服務品質和效率,當我知道了之後覺得很遺憾,因為短短一行指令就可以解決的問題,卻讓客戶等了好幾天...

檢討這個狀況,發現基礎常識的不足,和資訊的不透通是最主要的原因,IT產業常常碰到很多的問題,每一個開發人員和IT技術人員每天都在處裡各式各樣的問題,一個問題處理完畢之後,能夠有log是最理想的狀況,但往往這些經驗是很難留在公司裏面(問題解決了很爽,寫Log卻很煩,先喝杯咖啡去,Log...再說吧),而一個問題呈現出來的現象和狀況可能有多種面向,有時候也不那麼好歸類。

但最最最糟的狀況是,某一個關鍵問題卡在一個人身上,在開會、Review進度時都沒有提出(或提的很模糊,沒人聽得懂,提的人也希望趕快跳過,不想被challenge),然後卡在某個人身上一直無法解決(他也不是懶惰,而是一直找不到方法),結果變成整個專案的瓶頸,這很冤枉,也很划不來...,明明是一個可以被處裡甚至被防範的簡單小問題,卻造成進度的落後。

後來,針對這個現象,我們訂出了工作準則,並且透過資訊系統,要求員工在手上的待處理問題,如果超過一定時間沒解決(或是根本不知道該怎麼解決),必須登入在員工每日工作的系統(EIP Portal)上, 讓這個問題公開,讓其他有經驗的同仁或他的主管,可以出手介入或施予援助。(管理單位也可以從這些Issue List上,推敲出目前專案的狀況)

每一個人都不是全能的,資訊領域那麼大,大家各自有擅長的技術,彼此幫忙解決問題,才是我們想看到的結果,因為特定領域不熟悉,甚至羞於尋求幫助,並不是我們想鼓勵的文化,我們沒有讓每一位員工很忙,也是因為希望能夠多一些時間彼此幫忙。另一個有趣的現象,你會慢慢地發現,團隊中最有人緣或最有領導力的,常常是那個對其他人施予幫助的,而非技術能力最強的人。
分享

沒有留言: