在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上，推敲出目前專案的狀況)
每一個人都不是全能的，資訊領域那麼大，大家各自有擅長的技術，彼此幫忙解決問題，才是我們想看到的結果，因為特定領域不熟悉，甚至羞於尋求幫助，並不是我們想鼓勵的文化，我們沒有讓每一位員工很忙，也是因為希望能夠多一些時間彼此幫忙。另一個有趣的現象，你會慢慢地發現，團隊中最有人緣或最有領導力的，常常是那個對其他人施予幫助的，而非技術能力最強的人。
分享
我們接洽的這位同事很可愛的在網路上找了這篇:
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上，推敲出目前專案的狀況)
每一個人都不是全能的，資訊領域那麼大，大家各自有擅長的技術，彼此幫忙解決問題，才是我們想看到的結果，因為特定領域不熟悉，甚至羞於尋求幫助，並不是我們想鼓勵的文化，我們沒有讓每一位員工很忙，也是因為希望能夠多一些時間彼此幫忙。另一個有趣的現象，你會慢慢地發現，團隊中最有人緣或最有領導力的，常常是那個對其他人施予幫助的，而非技術能力最強的人。
分享
留言