SaaS模式中的品質管理

       SaaS模式無疑是對軟體品質管理的新挑戰，我們有必要找出相應的對策來保障高品質的軟體服務。

　　隨著互連網的迅猛發展，特別是Web2.0的興起，將軟體作為一種服務形式提供給客戶的需求逐漸增加，軟體產業正在發生越來越大的變化，其中最突出的就是形成軟體即服務(Software as a Service，SaaS)模式。

　　SaaS模式就是以軟體部署為基礎，通過互連網直接為客戶提供服務，而且客戶還可以按需定製自己特定的服務。

        這種新模式的出現正是順應了這個需求，用軟體服務代替傳統的軟體產品銷售，不僅可以使軟體免於盜版的困擾，而且可以降低軟體消費企業購買、構建和維護基礎設施和應用程式的成本和困難。SaaS模式已經給傳統套裝軟體廠商帶來了實實在在的壓力，其自身的發展越來越快，許多著名調查或諮詢公司所提供的資料進一步顯示了這一趨勢。

　　其中著名的代表有SalesForce、WebEx、oDesk、OpenAir、eProject等，而且像甲骨文、IBM、Microsoft和SAP等軟體巨頭開始關注這一模式，並投入巨資力圖將傳統的軟體產品銷售模式逐漸向軟體服務遷移，

　　例如，甲骨文相繼收購了J.D. Edwards、PeopleSoft和Siebel CRM OnDemand，而IBM開始宣稱自己一直是一家按需服務（On-demand service）公司，Microsoft開始力推其live.com的戰略，而以百度、Google、eBay和Amazon等以消費者為中心的服務也從側面證明了SaaS模式是可以進一步擴充的。

　　這些也無疑是對軟體品質管理的新挑戰，我們有必要找出相應的對策來保障高品質的軟體服務。

　　SaaS模式有很多特定要求包括對軟體開發方法和流程、對系統架構的靈活性、相容性和擴充性等有更高的要求、對系統部署、操作、支援人員和維護要求等等。這些也無疑是對軟體品質管理的新挑戰，我們有必要找出相應的對策來保障高品質的軟體服務。

SaaS品質需求的焦點

　　品質高的軟體應同時滿足使用者的需求和軟體企業自身的需求。滿足使用者的需求，就是要滿足使用者在功能上、介面易用性、可用性、可靠性和安全性等方面的要求。

　　滿足軟體企業自身的需求，就是要降低軟體系統的複雜性，具有可擴充性、移植性等，使系統更容易維護。對於SaaS，軟體品質需求的焦點在於系統的有效性、可靠性、安全性和可維護性等。

　　產品或服務對於客戶的是否能保持有效，即在預定的啟動時間中，系統真正可用並且完全已耗用時間所佔的百分比，可以用“系統平均無故障時間（MTTF，Mean Time To Failure）除以總的已耗用時間（MTTF與損毀修復時間之和）”來計算系統的有效性。

　　例如，網上銀行系統需要高有效性（如 >99.99%）才能滿足品質要求。

　　一個有效性需求可以這樣說明:“工作日期間，在當地時間早上6點到午夜，系統的有效性至少達到99.5%，在下午4點到6點，系統的有效性至少要達到99.95%”。

　　系統的健壯性和有效性有時可看成是可靠性的一部分。

　　衡量軟體可靠性的方法，包括正確執行操作所佔的比例、在發現新缺陷之前系統啟動並執行時間長度和缺陷出現的密度。軟體系統的可靠性和效能是相互關聯的，更確切地說是相互影響的，高可靠性可能降低效能，比如資料的複本備份、重複計算等可以提高軟體系統的可靠性，但在一定程度上降低了系統的效能。

　　又比如，一些協同工作的關鍵流程要求快速處理，達到高效能，而這些關鍵流程可能是單點失效設計，其可靠性是不夠的。

　　對於SaaS，還必須認真地考慮安全性、擴充性和可維護性等。安全性，除了資料存放區、備份等要求之外，還需要設定系統合理的、可靠的系統和資料的存取權限，防止一些不速之客的闖入和駭客的攻擊，以避免資料泄密和系統癱瘓。

　　軟體系統的安全性和可靠性，一般是一致的，安全性高的軟體，其可靠性也要求相對高，因為任何一個失效，可能造成資料的不安全。

　　一個安全相關的關鍵組件，需要保證其可靠，即使出現錯誤或故障，也要保證代碼、資料被儲存在安全的地方，而不能被不適當的使用和分析。

　　但軟體的安全性和其效能、適用性會有些衝突，如密碼編譯演算法越複雜，其效能可能會越低;或者對資料的訪問設定種種保護措施，包括使用者登入、口令保護、身分識別驗證、所有操作全程追蹤記錄等等，必然在一定程度上降低了系統的適用性。

適應SaaS品質需求的軟體開發流程

　　SaaS通過互連網向使用者提供服務，而這基礎是軟體系統的部署。這就要求在軟體需求分析、設計和驗證時，要充分考慮系統部署的需求，包括伺服器叢集、分布式網路、容錯移轉、系統線上擴充、資料備份和恢複等。所以系統的架構設計是非常重要的，需要投入足夠的時間和資源。

　　另一方面，由於軟體部署由軟體服務商自己控制，且不會像渠道銷售軟體套裝產品那樣花費很長時間和製造成本，所以SaaS軟體發布周期可以大大縮短，力求在軟體開發過程中做到最簡單和最有效，最優先要做的是通過儘早的、持續的交付有價值的軟體來使客戶滿意。

　　對於SaaS軟體開發，可以將敏捷方法和RUP過程方法結合起來，敏捷過程能夠保持快速、穩定的開發速度，RUP過程可以保證系統的靈活架構、良好的擴充性和移植性，促進開發過程達到一個最佳的平衡狀態，以獲得很高的滿意度。

　　軟體服務模式的產品發布程式比一般軟體產品的發布要複雜得多，要涉及到軟體產品部署和實施的前期活動和後期活動，其中增加了“軟體產品的部署（Deployment）規劃、部署設計、部署設計的驗證和實施、監控”等活動。

　　在開發中，要考慮到網站或資料的遷移、多種升級方式、多版本共存的運行環境等需求，對資料/系統的相容性要進行充分的討論和分析，保證使用者升級過程中，所獲得服務沒有受到影響，資料受到保護，一切使用正常。

　　而且，要處理好客戶之間的關係，對於功能變化較大的新版本升級，一般要事先得到使用者的許可或同意。

　　對於軟體服務模式，當產品發布到運行環境（伺服器）中，在使用者開始使用之前，還要進一步驗證。所以，對軟體服務模式的產品發布中最後實施階段，其時間性非常強，一般放在周末或晚上時間（9:00pm～6:00am）。如果提供7x24不間斷的軟體服務，就需要採用DNS、伺服器、目錄等快速切換方式來實現無縫升級。

部署的規劃、設計和驗證

　　軟體部署(Deployment) 是SaaS一個必不可少的、關鍵的環節。軟體部署是通過整合的、虛擬化的或邏輯化的資源和進程的集中管理，對所要啟動並執行程式提供技術和環境的支撐，從而保證軟體系統被部署到合適的運行環境中能具有最優的、最可靠的效能表現，並能對使用者和系統的各種資料進行有效儲存、備份和恢複等。

　　在軟體部署的技術分析上，就是以營運目標為出發點，將這些要求轉化為可用來設計部署體繫結構的技術規範。而在部署設計中，必須考慮多種品質因素。

　　邏輯體繫結構 它能決定服務分配的最佳方式和系統擴充性、維護性等。

　　服務需求品質 必須滿足服務品質 (QoS) 要求，建立在邏輯體繫結構和QoS要求的映射關係，從而達到效能、可用性、延展性、可維護性等軟體服務的品質目標。

　　用量分析 有助於通過系統負載的使用模式來隔離效能瓶頸，開發出滿足 QoS 要求的策略，用於部署設計中。

　　用量分析因素主要有:使用者數量及類型、活動和非活動使用者、系統管理使用者、使用模式、使用者增長、使用者事務和使用者/曆史資料等。

　　使用案例 儘管使用案例已包含在用量分析中，但評估部署設計時，應參考使用案例，確保任何案例中所揭示的問題在設計中得到處理或解決。

　　根據效能指標，對一些關鍵的使用案例進行研究，以確定在系統層次如何保證該要求得到實現的結構、技術或方式。

　　服務等級協定 指定了最低效能要求以及未能滿足此要求時必須提供的客戶支援層級和程度，相當於設計的底線(Bottom Line)。

　　成本 有必要設計2-3個軟體部署方案，通過分析、比較，對資源最佳化，採用平衡策略，能夠在業務約束範圍內達到業務要求，並獲得成本最佳化。

　　營運目標 是軟體部署的最終目標，包括這些目標實現的業務要求或約束。軟體部署設計的品質好壞，最終取決於對滿足營運目標的能力的評估。

　　除此之外，下面還要著重討論可用性、延展性和安全性的影響因素和規劃策略，保證部署設計成功。對可用性、延展性和安全性等的驗證，也是至關重要的。

可用性的規劃策略

　　當可用性的要求達99.99%或99.999%，通常要求系統必須是一個容錯系統。容錯系統必須能夠在硬體或軟體出現故障時繼續運行，其實現手段是為提供關鍵服務的硬體（如 CPU、記憶體和網路裝置）及軟體配置冗餘組件。

　　可用性設計將考慮到可用性降低或組件丟失時所發生的情況，其中要考慮串連的使用者是否必須重新啟動會話和一個地區內的故障對系統的其他地區的影響程度。QoS 要求應考慮這些方案並指定部署如何對這些情況作出反應。

　　單一故障點（Single-point failure）是指沒有備用的冗餘組件的硬體或軟體組件，而這些組件是重要路徑的組成部分，即該組件出現故障會使系統無法繼續提供服務。設計容錯系統時，必須確定並消除潛在的單一故障點。

　　其常用的可用性策略有:

　　Server Load Balancer 使用冗餘硬體（如伺服器叢集-Server Cluster）和軟體組件來分流處理負載。

　　Server Load Balancer器（如NetScaler LoadBalance） 把對某個服務的任意請求引導至該服務的伺服器叢集中當前負載最小的某個伺服器上。如果任一執行個體發生故障，其他執行個體可以承擔更大的負載。

　　容錯移轉 涉及對冗餘硬體和軟體的管理，在任何組件發生故障時提供對服務的不間斷訪問並保證關鍵資料的安全。如Sun Cluster 軟體為後端組件管理的關鍵資料提供了容錯移轉解決方案。

　　複製或備份服務 為同一資料的訪問提供多個源，如目錄伺服器為LDAP目錄訪問提供多個複製和同步策略。

可伸縮系統的規劃

　　延展性是指增加系統容量的能力，而且要求在增加系統資源時不改變部署的體繫結構。

　　在系統需求分析、設計階段，系統容量的預測往往只是估計值，可能與部署系統的實際情況存在較大差異，所以部署具體設計時，應考慮到必然存在的偏差，引入系統部署延展性的策略，使部署後的系統具備足夠的靈活性，具有足夠的處理合理時間內（如系統運行後 6～12 個月）增加負載的潛在容量，以便在出現異常峰值負載時能夠從容應對。

　　可伸縮系統的規劃，一般有以下3個策略，可從中選擇一個或多個組合策略。

　　高效能設計策略 在效能要求的確定階段加入潛在容量，以處理可能會隨時間推移而增長的負載，並在預算控制內儘可能提高系統的可用性。這一策略可使系統具有一定的緩衝時間來應付增長的負載，所以可以相對從容地制訂更大的系統擴充方案。

　　漸增式部署 基於負載的要求以及評估，事先明確系統擴充的條件以及條件可能達到的時間，對每一個重大的系統擴充特定日期/時間有一個估計和安排，從而建立部署的整個議程表。

　　大範圍效能監控 對效能進行監視有助於確定向部署中增加資源的時機。監視效能的要求可為負責維護和升級的操作員和管理員提供指導。

安全性的規劃

　　安全性是一個複雜的主題，涉及到部署系統的各個層級，主要包括以下內容:

　　物理安全 物理安全是對路由器、伺服器、伺服器機房、資料中心及基礎結構中其他部分的物理訪問。如果未經授權的人可以進入伺服器機房然後拔掉路由器電源，則其他安全措施將毫無意義。

　　網路安全 網路安全是通過防火牆、安全訪問區、存取控制清單和連接埠訪問對網路進行訪問。應開發針對未授權訪問、篡改和拒絕服務的攻擊的策略。

　　應用程式和應用程式資料安全 包括通過驗證和授權過程及策略訪問使用者帳戶、公司資料和公司專屬應用程式程式，包括口令、加密、認證、存取權限和控制等策略。

　　個人安全慣例 組織範圍的安全性原則，定義工作環境和所有使用者必須遵守的慣例，以確保其他安全措施按設計實行。

 

通常的做法是編印安全手冊並對使用者進行培訓。要實現有效總體安全性原則，可靠的安全慣例必須成為企業文化的組成部分。

SaaS軟體系統的維護品質

　　首先確保系統的可維護性，其次制定一系列系統維護的操作規則和變更控制流程，切實保證系統能得到及時、有效維護。

　　可維護性是指對部署系統進行維護的容易程度，包括系統監視、系統出現故障的修複、系統功能的增強、系統資料的更新和備份、系統軟硬體的升級等任務執行的難易程度，其影響的因素還包括使用模式、停機時間計劃和相應的流程等。可維護性和可用性存在一定的依賴性，良好的可維護性才可能保證系統啟動並執行高可用性。

　　軟體部署維護，首先必須由專業的、獨立的維護團隊，其成員的技術構成應比較完備，包括硬體工程師、網路設計工程師、安全認證工程師、（操作）系統工程師、資料庫管理員(DBA)和應用系統的技術人員等。

　　其次要有完整的操作流程和規範，告訴每個維護人員，如何進行操作，哪些操作是允許的，哪些操作是不允許的。對於出現的緊急事件，制定相應的應急方案。除此之外，通過下列措施，進一步提高軟體部署維護的品質。

　　安裝有運行環境的監控程式，隨時監控運行環境的情況，任何問題的先兆可以及時通知維護人員，形成預警機制;保證7×24任何時間內有人值班或保持被呼叫（on-call）狀態;有一套系統（如Remedy Ticket System），報告系統問題，並能及時得到響應和處理;除了容錯移轉機制之外，有冗餘的裝置或冗餘的系統運行能力;做好軟體部署的維護記錄。

SaaS模式的特定要求

　　(1)軟體開發方法和流程要敏捷，其實施要具有簡單性。

　　(2)允許客戶自我定製，對系統架構的靈活性、相容性和擴充性等有更高的要求。

　　(3)通過部署系統來實現軟體服務，對系統部署、操作、支援人員和維護要求高。

　　(4)要求高可用性（7x24不間斷運行），以及效能穩定、可靠性，包括系統容錯移轉。

　　(5)SaaS 的核心是資料，使客戶能通過網路方便存取資料，同時要保證資料的安全性，包括資料加密、隔離、備份和恢複等。