**高有效性 High Availbility 而言並不是可以運作就好, 而是這個運作是可被使用者接受, 或者是符合 BI 企業智慧, 甚至是最大的重點是符合 User Expierence (使用者經驗) 的優化 Optimization, 也就是 UEO, 這其中最重要的就是效率要能夠對應使用者的期待, 算出來的結果也要讓使用者接受, 而這個條件就是要效率與效能達到一定的標準.

當然效能調校的第一步驟就是我在這專題寫的第一項: Monitor and Alert, 也就是說把效能做一定的監控, 才有可能做效能調校的下一步, 而往往效能的瓶頸是會導致失效的最主要原因之一, 而若能把效能的瓶頸提升, 這部份的 Failuare 才有可能進一步的避免.**
要追求效能一定要知道瓶頸在那邊?

1. 使用者終端
2. 使用者網路端
3. 網路骨幹端
4. 網站上流端
5. 網路設備端
6. 伺服器端
7. 資料庫端
8. 程式端
9. 作業系統端
10. 系統架構端

當然這每一個項目都還有很多細項, 像一台機器往往也會有記億體, CPU, 匯流排, 儲存設備, I/O 等等的瓶頸, 無論是在量的瓶頸或效率的瓶頸, 要把每一項瓶頸去做確認, 並找出原因, 這就是效能調校最大的工夫.

事實上效能說是高有效性的一環, 相對的, 高有效性也是高效能的手段之一, 因為現在的效能已經也不是只靠一台機器, 而是靠許多台機器去完成, 在某方面就必須包含一個具有 Fault Tolerance 的一個系統.

只是機器越多, 要讓所有機器一起運作做同一件事, 一定會有多餘的負荷 Over Head, 如何降低這個多餘的負擔, 至少不會產生 Threshold 讓要去共同運作所須要的資源反而超過加入一台機器能給的資源, 這反而又形成另一個瓶頸.

能夠提升效率的源頭就內部的資源控制有很多方法:

1. 演算法
2. 程式語言
3. 程式設計方式
4. Framework
5. 作業系統
6. 機器效能
7. 資料庫
8. 流程架構

每一個細項都有可能造成很大的影響, 尤其我們最不想承認的一些系統本身就有天生的優缺點, 甚至有些是很意識型態的紛爭, 但說起來還是資源與公司政策與政治決定一切, 事實上這在某些觀點就是: "條件".

說起來高有效性的層級是相當高的, 在某方面不是一個不夠資深的工程師能夠掌握的, 甚至可以說因為這是須要很高的經驗與知識, 沒有達到這些經驗時, 很難去做到, 加上這些又會受到公司架構的影響, 最後往往是決定在 IT Director, 但這個 Director 是否有這經驗去判斷, 須要依賴的就是相關經驗的顧問了.