在**運維實踐中，除了網路、伺服器等硬體故障導致的系統可用性風險外，還有來自軟體系統本身的風險。
下面會介紹一些為了保證線上系統的可用而採取的一些與傳統軟體按開發不同的質量保證。
1.**發布
**需要保證7x24高可用執行，同時**又需要不斷地發布新功能吸引使用者以保證在激烈的市場競爭中獲得成功。
許多大型**每週都需要發布一到兩次，而中型**則更加頻繁，一些處於快速發展期的**甚至每天發布十幾次。
不管發布的新功能是修改了乙個按鈕的布局還是增加了乙個核心業務，都需要在伺服器上關閉原有的應用，
然後重新部署啟動新的應用，整個過程還要求不影響使用者的使用。
這相當於要求給飛行中的飛機換個引擎，既不能讓飛機有劇烈晃動（影響使用者體驗），
也不能讓飛機降落（系統停機維護），更不能讓飛機墜毀（系統故障**完全不可用）。
**的發布過程事實上和伺服器宕機效果相當，其對系統可用性的影響也和伺服器宕機相似。
所以設計乙個**的高可用架構時，需要考慮的伺服器宕機概率不是物理上的每年一兩次，而是事實上的每週一兩次。
也許你認為這個應用不重要，重啟也非常塊，使用者可以忍受每年一到兩次的宕機故障，因而不需要複雜的高可用設計。
事實上，由於應用的不斷發布，使用者需要面對的是每週一到兩次的宕機故障。
發布過程中，每次關閉服務的伺服器都是集群中的一小部分，並在發布完成後立即可以訪問，因此整個發布過程不影響使用者使用。
2.自動化測試
**在發布到線上伺服器之前需要進行嚴格的測試。
即使每次發布的新功能都在原有系統功能上的小幅增加，但為了保證系統沒有引入未預料的bug，**測試還是需要對整個**功能進行全面的回歸測試。
此外還需要測試各種瀏覽器的相容性，在發布頻繁的**應用中，如果使用人工測試，成本、時間及測試覆蓋率都難以接受。
目前大部分**都採用web自動化測試技術，使用自動測試工具或指令碼完成測試。
比較流行的web自動化測試工具是thoughtworks開發的selenium。
selenium執行在瀏覽器中，因此selenium可以同時完成web功能測試和瀏覽器相容測試。
大型**通常也會開發自己的自動化測試工具，可以一鍵完成系統部署，測試資料生成、測試執行、測試報告生成等全部測試過程。
許多**測試工程師的編碼能力毫不遜色於軟體工程師。
3.預發布驗證
即使是經過嚴格的驗證，軟體不是到線上伺服器之後還是會經常出現各種問題，甚至根本無法啟動伺服器。
主要原因是測試環境和線上環境並不相同，特別是應用需要依賴的其他服務，
如資料庫、快取、公共業務服務等，以及一些第三方服務，如電信簡訊閘道器、銀行網銀介面等。
也許是資料庫表結構不一致，也許是介面變化導致的通訊失敗，也許是配置錯誤導致連線失敗，
也許是依賴的服務線上環境還沒有準備好，這些問題都有可能導致應用故障。
因此在**發布時，並不是直接把測試通過的**包直接發布到線上伺服器，而是先發布到預發機器上，
開發工程師和測試工程師在預發布伺服器上進行預發布驗證，執行一些典型的業務流程，確認系統沒有問題後才正式發布。
預發布伺服器是一種特殊用途的伺服器，它和線上的正式伺服器唯一的不同就是沒有配置在負載均衡伺服器上，外部使用者無法訪問。
預發布伺服器和線上正式伺服器都部署在相同的物理環境，
同乙個資料中心甚至同乙個機架上，如果使用虛擬機器，甚至可能在同一臺物理伺服器上，使用相同的線上配置，依賴相同的線上環境。
不過，也有可能會因為預發布驗證而引入問題。
因為預發布伺服器連線的是真實的環境，所有預發布驗證操作都是真實有效的資料，這些操作也許會引起不可預期的問題。
比如建立乙個店鋪，上架乙個商品，就有可能有真的使用者過來購買，如果不能操作，就會導致使用者投訴。
此外，在**應用中強調的乙個處理錯誤的理念是快速失敗（fast failed），即系統如果在啟動時發現問題就立刻丟擲異樣，
停止啟動讓工程師介入排查錯誤，而不是啟動後執行錯誤的操作。
4.**控制
對於大型**，核心應用系統和公共業務模組涉及許多團隊和工程師，需要對相同的**庫進行共同開發和維護。
而這些團隊對同乙個應用的開發維護（開發周期和發布時間各不相同），如果**控制環節出了問題，
可能將有問題的**發布上線，將問題帶入生產環節，導致系統故障。
****控制的核心問題是如何進行**管理，既能保證**發布版本的穩定正確，同時又能保證不同團隊的開發互不影響。
目前大部分**使用的源**版本控制工具是svn，svn**控制和版本發布方式一般有以下兩種。
（1）主幹開發、分支發布
**修改都在主幹（trunk）上進行，需要發布的時候，從主幹上拉乙個分支（branch）發布，
即分支成為乙個發布版本，如果該版本發現bug，繼續在該分支上修改發布，將修改合併（merge）回主幹，直到下次主幹發布。
（2）分支開發、主幹發布
任何修改都不得在主幹上直接進行，需要開發乙個新功能或者修復乙個bug時，從主幹拉乙個分支進行開發，
開發完成且通過測試後，合併回主幹，然後從主幹進行發布，主幹上的**永遠是最新發布的版本。
這兩種方式各有優缺點。
主幹開發、分支發布方式，主幹**反應目前整個應用的狀態，一目了然，便於管理和控制，也利於持續整合。
分支開發、主幹發布方式，各個分支獨立進行，互不干擾，可以使不同發布週期的開發在同一應用中進行。
目前**應用開發中主要使用的是分支開發、主幹發布的方式。
可以想象，如果使用主幹開發、分支發布，那麼在同乙個應用上，對於不同開發周期，不同發布時間的專案，
有可能a專案發布時，b專案只開發了一半，這時候的主幹**是半成品，根本不能發布。
而使用分支開發、主幹發布的方式，只需要將a專案的分支合併到主幹即可發布，不受b專案發布時間的影響。
目前在開源技術社群，git作為版本控制工具，正逐步取代svn的地位。
git對分布式開發、分支開發等有更好的支援，也更容易在各個開發分支上及時反應主幹最新跟新，
避免svn在最後提交**時發現主幹**差別太大難以merge成功。
5.自動化發布
**版本發布頻繁，整個發布過程需要許多團隊通力合作，發布前，多個**分支合併回主幹可能發生衝突（conflict），
預發布驗證也會帶來風險，每次發布又相當於一次宕機事故。因此**發布過程中荊棘叢生，一不小心就會踩雷區。
對於有固定發布日期的**，很多**選擇周四作為發布日，這樣一周前面有三天時間可以準備發布，
後面還有一天可以挽救錯誤，如果選擇周五發布，發現問題就需要加班加點了。
火車發布模型：將每個應用的發布過程看作一次火車旅行，火車定點執行，期間有若干站點，
每一站都例行檢查，不通過的專案下車，剩下的專案繼續坐著火車，直到火車到達終點（應用發布成功）。
由於火車發布模型是基於規則驅動流程，所以這個流程可以自動化採用火車發布模型的**回開發乙個自動化發布工具實現發布過程自動化。
根據響應驅動流程，自動構建**分支，進行**合併，執行發布指令碼等。
正常流程下，可以做到發布過程無人值守，無需scm（**配置管理員）參與，
每個專案相關人員基於流程執行相應的操作，即可完成自動化發布。
人的干預越少，自動化程度越高，引入故障的可能性就越小。
6.灰度發布
應用發布成功後，仍然可能發現應為軟體問題而引起的故障，這時候就需要做發布回滾，
即解除安裝剛剛發布的這個軟體，將上乙個版本的軟體包重新發布，使系統復原，消除故障。
大型**的主要業務伺服器集群規模非常強大，比如某大型伺服器應用集群伺服器數量超過一萬台。
一旦發生故障，即使想要發布回滾也需要很長時間才能完成，只能眼睜睜看著故障時間不斷增加。
為了應付這種局面，大型**都會使用灰度發布模式，將集群伺服器分廠若干部分，持續幾天才能把整個集群全部發布完畢，
期間如果發現問題，只需要回滾已發布的一部分伺服器即可。
就像乙個大型網路遊戲，不能說一次把所有區更新完畢，而是分批次完成，即使更新失敗也能回到之前版本，回滾時間也能接收。
灰度發布也常使用者使用者測試，即在部分伺服器上發布新版本，其餘伺服器保持老版本（或者發布另乙個版本），
然後監控使用者操作行為，收集使用者體驗報告，比較使用者對兩個版本的滿意度，以確定最終的發布版本。這種手段叫做ab測試。
軟體質量保證
一 軟體質量的概念 概括的說 軟體質量就是 軟體與明確地和隱含地定義的要求相一致的程度 具體的說 軟體質量是軟體與明確地敘述的功能和效能需求 文件中明確描述的開發標準以及任何專業開發的軟體產品都應該具有的隱含特性相一致的程度。有3個要點 1 軟體需求是度量軟體質量的基礎，與需求不一致就質量不高。2 ...
軟體質量保證 軟體質量
這篇博文將較為全面深入地談談軟體質量保證中關於軟體質量的概念，內容等相關問題。關於質量的定義，不同的領域，不同的人，不同的側重點會得出截然不同的結果。因此關於其質量的基礎概念相對而言較為好理解，但是具體如何去定義實際上確是無關緊要的。不過我們在分析軟體質量的時候，不僅要考慮其面向使用者的需求覆蓋率，...
軟體質量 軟體測試和質量保證
軟體質量 軟體質量包括 內部質量 外部質量 使用質量 就是說軟體滿足規定或潛在使用者需求的能力，要從軟體在內部 外部和使用中的表現來衡量 軟體測試 軟體由文件 資料以及程式組成，那麼軟體測試就應該是對軟體形成過程中的文件 資料以及程式進行測試，而不僅僅是對程式進行的測試。軟體測試和質量保證的區別 軟...