January 11, 2007
剛剛看到某睡睡吞布丁提及電車2.0的某相關M$廣告文, 我囧了. 倒不是因為睡睡說的 Terminal Service 有問題, 而是我曾經在某個專案當中, 碰過這種東西, 結果卻大不相同. (這篇絕對不是廣告文啊啊啊)
記得前年底, 我在支援白爛單位的專案過程中, 必須要解決 Terminal Service 的問題, RobertHu 告訴我, 某些大型行動電話業者也很認真導入『全 Terminal Service』管理, 確實是有他在管理上的便利性. 同時我們也討論到了另一個問題, 『到底 bottleneck 在哪裡』.
在 RobertHu 的 IT Advisory 個人簡史中, 曾經解決過某大型售票系統的效能問題, 他當時的 pattern 是 Critical Chain, 在我完食該系列的書之後當然有不同的想法, 但是回過頭來看這次的電車2.0事件, 恐怕一定程度雷同.
Terminal Services 本身就算是有效能問題, 但總是可以被解決的, 要不就是加 Server (我在某白爛單位就看過 100 人竟然用了 3 台 HP DL380G4 跑 Office + Outlook…Orz), 要不就是網路塞住, 加頻寬就可以解決. 怕的是系統架構本身有問題, 軟體本身有暇疵這種障礙.
話說回來, Critical Chain 確實也是軟體工程的工法之一, 書上有說. :)
我都正好有相關專案的經驗，Terminal Server的確有好用的地方，新竹國際商銀就是一個好例子。管理方便，但是不方便跑大型的AP，所以當然不能跑Office這些的，上面的程式都有限制在總和128M以內，那就很順利了。
你用Terminal Server又跑了那些程式，當然出問題。就我知道的成功案例，伺服器端的記憶體除以128M就是可支援的Terminal數目，多的就加Server這麼簡單。
我經手的AP，也都會把記憶體控制在128M以內，因為太多公司的舊機器都只有256M以下，分給OS後，可用的就是128M左右。
最後，那售票系統應該不是用Terminal Service，用的應該是內部的OA程式，不過這是我猜的。
某要改制成公家單位的二代系統也是跑在 Windows 2003 Temrinal Service 上，看客戶要解決甚麼問題。
我想高鐵的問題和用甚麼技術其實是沒有太大的關係的，我同意 Knight 的看法，人的問題才是最嚴重的。不管有沒有用 CMMI和還是任何的管理理論或機制，只要人沒有真心相信並執行，或是沒有方法強制執行的話，用甚麼工具最後都是一樣遭。
至於 Terminal Service 方面，有興趣的人可以參考 Windows Server 2003 Terminal Server Capacity and Scaling http://www.microsoft.com/downloads/details.aspx?FamilyID=a2ae95da-be56-4495-9fb5-e4b7170b33d9&DisplayLang=en
後續報導，今天得知真的有記者打電話去問微軟的 Windows PMM 說高鐵是不是用微軟的系統所以這麼不穩定，記者引述的就是微軟網站上高鐵使用 Terminal Service 的案例。我敗了…
看來小睡睡的部落格知名度還蠻高的，連記者都在看
呃…. @_@