**為甚麼要追求高有效性是個比前面都還重要的事, 我居然是放在最後面講, 但這也並不是不對, 畢竟這也是個大哉問阿.
在 High Availability 中, 是比較少提及 "功能", "特色" 的基本 Feature, 而是一些數量上的不同, 但這才是有趣的地方, 因為我們知道, 質變會變量變, 量變也會質變, 不可能只看質或量, 由其是 HA 乍看是追求量, 可是本質還是在追求質的一種阿.**
所以可以把高有效性的量化目的以人的角度來做切割:
**1. 可以很多人使用: 在規模化上追求效率.
隨時都可以用: 在高有效性上追求穩定.
很多人都在用: 在使用者經驗上追求有效性.**
這三個看起來都是很量化的東西, 但這卻是決定一個系統好壞與否的質性判讀, 若沒有人在用, 沒辦法很多人同時用, 或沒辦法一直用, 你說這個系統會是個好系統嗎? 因此高有效性的要求看起來簡單, 的確是很重要的原因之一.
只是這邊有一句很奇怪的話, 看起來是最不技術的: "很多人都在用", 這在高有效性中可能是重點中的重點, 也就是說是否能夠做出個讓人一直在用的東西, 只是這部份不只是在 HA 是最重點, 反而是在這個網站的 Business Model 中最最重要去關心的事, 而 IT Director 與 Consultant 要在這邊著多少力是最無法知道的.
事實上也有很多人主張一個系統一開始建制沒必要花太多心力在 HA 高有效性上, 他們指的是前兩點, 很多人使用以及隨時可以用, 因為等到足夠很多人再用的時候, 確定這個商業邏輯是對的時候, 再花心力在 High Availabiility 還不遲, 在之前過於專心這個反而是分心的事, 因為這個在未來可能是成敗的關鍵, 但在一開始的時候卻不是.
因此一開始 HA 要放在那邊? 比重為何? 或是那個階段開始投入足夠的資源, 那時先做 95% 就好, 這我們可以知道一開始要把這部份做得很是不太可能, 變成是要去以時程去調整資源, 而有時最好判斷的方式是:
"若是系統失效時, 會即時損失多少? 或總損失多少" 的觀點去看這個成本, 之後去決定預算.
通常我們知道即時損失都是不高的, 但背後代表的商譽, 信任, 回復原本使用者狀況須要的成本, 大概是即時損失的三倍到五倍, 而我們通常至少以總損失做為預算, 通常是從一半到一倍做開始的預算, 因此, 一個網站一開始若是沒有甚麼收入, 自然損失就不高, 所以相對須要投入的資源也沒有那麼高, 當然這也要看網站的開發成本, 若是開發成本很高, 一開始就要開始考量高有效性.
畢竟高有效性是種服務, 所以才會有 Service Level Agreement SLA 的出現, 若是設備的話, 可能要計算的是 Mean Time Between Failure MTBF, 不同的是機器我們都知道會有失效失靈的時候, 但服務這要求是無窮無盡的, 我們往往是希望百分之百都是可以用的, 尤其是在直接面對客戶的服務, 直接給終端使用者的網站的要求是很高的, 若是企業用戶都知道上班時間 Worrk Hours, 但好的 Customer Relationship Management CRM 就會知道 HA 的代價與須求是多重要的.
尤其是網站, 除了像 EIP 內部在用的系統, 或 B2B 一些串接服務的網站, 或許 HA 不是最重要的一環, 更重要的是 Security 安全性, 但除外的網站幾乎都是必須要有大量的使用者使用才會發揮價值, 而我們也很清楚, 天底下無新鮮事, 太多創意都是已經被想過, 成功的大多不是第一個想到且實作出來, 唯一可以肯定的就是 "第一個做好的", 只是甚麼是第一個做好與否, 這句話同等於 "魔鬼在細節".
最後決定勝負的不是創意, 不是 Business Model, 反而是使用者經驗決定一切, 唯有對的使用者經驗, 即使沒有行銷預算, 也可以被到處流傳, 不然花再多錢, 若系統沒有做好, 最後也是被巨量的資訊給淹沒.
但就像我在報名這個項目時所講的:
"在 Web 2.0 時代後, 系統已經不能不考慮 Scalability 以及 Availability 的問題, 甚至 Efficiency 以及 Usability 都是其關鍵, 加上最近非常火紅的 Cloud 也是在 HA 的範籌, 但這方面在學校講的少, 實務上理論大家都沒甚麼在接觸, 因為工作 (High Performance Computing) 的關係, 累積了一些想法與經驗, 所以又想趁這機會整理一下, 提供給大家更進一步的資訊."
所以下一篇就是真的結尾了.