接下來，我們就來探討，軟體品質指標有那些種類 可用度 Availability =============================================================================== 一個服務的可用度，是由很多環節組合起來的，某些環節是掌控在開發者手中，某些環節則是 在使用者手中的；對使用者來說，一個服務的可用度，是由底下幾個環節的總合： - 軟體本身的可用度 - IT/Cloud 架構本身的可用度 - 服務提供者端的網路環境 - 外部服務的可用度 - 使用者端的網路環境 在計算 Availability 時，是把上面幾個因素相乘起來，便是你服務的可用度，假設你的IT架構 本身只能提供 99.99% 的可用度，那你的服務本身的可用度將會小於 99.99% 。當然，你可以透 過 Multi-Host 的方式，將服務布建在多個不同 Data Center，此時你的服務可用度，將可超 過單一平台可以提供的可用度。 假設 Cloud A 可以提供的可用度是 99% ， Cloud B 可以提供的可用度是 98% ，而你將服 務同部布建在兩者之上，那麼兩者一起停機的機會是 (1-99%)*(1-98%) = 0.02% ，因此可靠 度提昇為 99.98% 。 然而，為了提高可靠到而佈建到 Multi-Host 時，不只要把 Presentation Layer / Frontend 放 到多個平台上面去，同時，使用者的資料也要同步到多個平台去，這樣，才能夠必免單一IT平台停機的 問題。但是這麼一來，當停機的平台再次上線時，如何處理資料的不一致問題，便成了另一難題。因此 ，多數的服務提供者只會把服務佈建在單一平台上。 服務提供者端的網路環境 ------------------------------------------------------------------------------- 目前，多數的雲端服務商仍是把主機設立在海外，在台灣沒有 Data Center ，因此，當台灣對外的海 纜出了問題時，雖然服務本身在海外仍是可用的，但是在台灣就連不上線，這一點，也是台灣的開發者 在選用雲端平台時需要考慮進去的。 過去幾年來，台灣對外的海纜，幾乎每兩年都會斷線超過一天。 - 2001/02/09 中美海纜遭魚船勾破，數據傳輸容量遽減至原來的四成。HiNet, SeedNet, TaNet 均受影響 - 2003/10/02 中美海纜遭魚船勾破 - 2006/12/26 恆春地震造成四條國際海纜中美海纜、法新歐亞三號、亞太光纜一號二號網絡斷線， 影響到台灣對中國、香港、新加坡等東南亞國家和地區，以及上述地區對外的國際通信。耗時三週修複。 - 2009/08/13 莫拉克颱風造成對外海纜斷線，影響台灣往中國大陸汕頭及東南亞地區，包括新加坡、菲律 賓及香港等地之通信。影響時間超過一週 - 2010/03/04 高雄甲仙地震造成中美海纜斷線，影響時間超過一個月 - 2011/11/14 ~ 2012/21/26 海纜進行維修，將造成HiNet連線中國之部份連網服務傳輸延遲時間變長。 若是你服務的對像是以亞洲為主，還是建議放在台灣或日本，若是服務對像以全球為目標，建議還是就放在美國吧。 外部服務的可用度 / SOA in Reality ------------------------------------------------------------------------------- .. image:: /images/2012-05-22/cloud-farm.jpg :width: 400 px 在幾年前，流行的系統架構是 SOA ，讓每一個團隊專注在單一面向功能的服務，將服務透 過SOAP/Restful API供內部及外部的使用者來使用。這樣的好處是，可以增快服務更新的速度減少 測試的範圍，在組織上，也可讓組織將重點放在核心服務上，而將其它的需求委由外部服務處理。 如此一來，對使用者來說，多重 SOA 子服務組合而成的服務，看起來就像是在雲端運行的一台大電 腦，跟舊式的服務並沒有差異。 .. image:: /images/2012-05-22/cloud-server.png :width: 400 px 然而經過幾年的經驗後，大家發現實際上的經驗並不是那麼的美好；如同開頭所說的，服務的可用度， 是所有子服務的總合，單一服務的問題，將會把整體的可用度都拉低。 在我的實務經驗上， SOA 架構，反而變成無止境的 finger pointing ，最後變成，需要對所有外 部服務的可用度做長期的追縱，評估他實際上的可用度。另外，在委外給外部服務時，只會把可以離線 處理的服務委外給外部服務，需要線上即時處理的，還是自行開發較好。 .. image:: /images/2012-05-22/finger-pointing.png :width: 400 px Service Level Agreement / Term of Service ------------------------------------------------------------------------------- TBD 可維護性 Manageability =============================================================================== 可維護性指的是，一個服務在運行時，留下了多少的資料，供 admin 做為判斷服務狀況的依據。一 個線上的服務，除了基本的 log 檔外，還需提供底下的特性 - Configurability: 提供設定檔，讓 admin / tester 能夠在不修改程式碼本身，而對軟體的 功能做調整。 - Monitorability : 提供開放性的介面，讓 admin 可以很容易的去追縱服務本身的建康狀態及用 量，供 admin 來判斷，是否需要增加硬體的來分散線上伺服器的負擔。 Monitoring is Must ------------------------------------------------------------------------------- 在提供一個服務時，我們一定要監控服務本身的狀況，並且要把這份資料與外部分享，減少本身溝通的 成本及增加客戶對服務的信任。 不管是設計多麼精良的服務，各個軟體平台商仍免不了會發生大型的災難，如： - Amazon AWS 於 2008, 2010, 2011 各發生過數小時的問題，造成 EBS 使用上的問題，導 制 reddit, zynga 等下遊廠商的服務問題 - Google Gamil 於 2009 年發生過大形的停機，耖造成拳體用戶無法使用 Gmail 兩個半小時。 - Azure 於 2012/02/29 ，由於時間同步的問題，造成用戶無法開啟新的 VM instance. Performance =============================================================================== 效能，算是個最常用的品質指標了，在講效能時我們通常會分成兩塊來講，一塊是反應時間(Response Time)， 另一塊是處理量(throughput)，前者只的是服務單一需求所要花的時間，後者則是單位時間內，可同 時服務的總需求數量。 影響效能的因素有很多，在多數的系統中，往往處理量增加的結果就是反應時間也一起增加，因此在系 統設計的初期，這些就要納入規格中，變成設計的一環；那麼，什麼是好的效能呢？在反應時間這邊有 個很好的指標，就是跟人互動的UI程式，如果反應時間能壓在 100ms 以下，那麼人們的認知就會覺的 這個程式是即時使用的，如果反應時間拉到 200ms 以上，就會開始覺得頓頓的。 對於網頁程式來說，反應時間不只是從 Web Server 這一端出去的時間，還要算上網路傳輸的時間以 及流覽器繪製畫面的時間，因此能留給網站主機的反應時間只剩下 50ms 上下；如果你的程式還有呼叫 其於的外部程式，那麼每多一層，反應時間至少增加 20ms ，或者是說少 20ms 給你的程式使用。 Reliability =============================================================================== 可靠度(Reliability)跟可用度(Availability)是兩個常被弄混的名詞，Availability講的是， 在一段長的時間內，系統可被使用的時間(Up Time)，Reliability則講的是在單位時間內，系統出 錯的次數。一個線上服務，可能是可用的(Available)但是他的輸出結果是有問題的(Unreliable) Reliability 的評量指標有 - 單位時間內，回傳錯誤訊息或者是無回應的次數。 - 單位時間內，輸出結果是錯誤的次數。 Reliability的問題，往往是系統內的 Bug ，只是在使用量大時，才會凸顯他的存在，因此軟體開發 者不可忽略這微小的訊號。 Scalability =============================================================================== Scalability 講的是你的服務能不能夠隨著用戶數的增長，而跟著成長，服務的可延展性可以分為 ， **直向擴充 Scale Up** 及 **橫向擴充 Scale Out** ，兩者都可以幫你增加可同時服務的 線上用戶數，但是後者的可擴充的程度，仍是遠高過前者的。 Scalability 讓我們動態的依事件配置不同數量的伺服器數量，以防止 Slashdot Effect 的發生 ，如總統大選或報稅截止日等事件，往往會在一日內擁入超過平日百倍的用戶數，如何讓服務正常運做 ，是軟體品質極重要的一環。 而 Scalability 對 Application Service Provider 更是重要，因為 Cloud Based ERP or CRM 系 統，較一般的網頁更有黏著性，一個有數萬個用戶的中型網站，同時間上線的用戶可能只有數百個，而 於他們的 Session 中存的資料也只有數 kilo bytes。然而對企業用戶來說 Cloud Based ERP, CRM ， 在上班時間，可是一直在使用的，一間 200 人公司用的 ERP 系統，可能就會有 200 active sessions ，每 個 Session 又存了許多正在處理中的表格資料。 如何 scale up/out database intensive application 變成 ASP 提供者不得不面對的難題。 Security =============================================================================== 網路服務的安全性問題，常常是個被誤會且忽略的問題，台灣許多主流的 Hosting Company 及 Billing Provider 的網站都出 過問題；他們的問題是，某本常用的軟體手冊的程式碼，在教導如何實作使用者認證時，只有在首頁 有檢查帳號，等帳號檢查過了，就會被導到內部的網頁去，然而，在內部網頁這邊，卻沒有檢查使用 者有沒有登入。 變成，只要得知內部網業的網址(form target)就可以直接存取內部的資料，因此，許多網站就 被 Search Engine Crawler 長驅直入，把所有的使用者資料都放在搜尋結果中公開了。至於實際 的例子我就不多舉了。 另外我有寫過一篇 `專文`_ 討論，該如合保護一個 WebService ，台灣的政府及民間網站，常常 用一些沒有被認可的電子簽證來做 https 的安全通訊，然而 https 的金鑰交換，在第一次是不安 全的，因此，若是你的金鑰是沒有經過第三方簽核的，那麼再交換金鑰時可能會受到 `Man in the middle attack`_ 直接把金鑰換掉。 使用 https 時，必需遵守幾個使用規範，這樣子通訊才會是安全的。 .. _專文: /blog/2012/01/03/how-to-protect-a-webservice/ .. _Man in the middle attack: http://en.wikipedia.org/wiki/Man-in-the-middle_attack 回到正題，服務的安全性可以分為幾塊 - 通訊的安全性。 - 身份的認可查核 - 資料的安全性及使用權限 - 資料的使用及變更的計錄追蹤 待續 =============================================================================== 在下一篇，我將講述，如何把這些概念，轉換成實際的數值指標。