一、數據倉庫服務架構chrome
數據倉庫服務（Data Warehouse Service），下面簡稱DWS 。主要爲客戶提供數據存儲，數據挖掘，數據分析等功能。其內核採用開源的關係數據庫管理系統Postgres SQL加以定製開發。服務部署在集羣上，集羣有3~32個虛擬主機組成。用戶使用DWS集羣的請求處理流程以下：數據庫
1.一、用戶經過客戶端，例如chrome，IE，FireFox等瀏覽器登陸DWS界面，對應於下圖中的1。瀏覽器
1.二、用戶對DWS集羣作了一個操做，好比重啓，對應於下圖中的2。服務器
1.三、Nginx根據調度策略將重啓請求下發到某一個console節點上，對應於下圖中的3.網絡
1.四、Console節點將請求經過HAproxy根據某種調度策略，將請求下發到service節點上，對應於圖中的4。架構
1.五、service節點處理重啓任務，並更新數據庫中相關表的記錄，對應於圖中的5，並返回處理結果。併發
其它節點功能說明：運維
1.六、monitor節點：監控集羣的狀態。工具
1.七、billing節點：計費。測試
1.八、OM Sevice節點（insight）：運維節點，一些運維操做會經過該節點下發到service節點上。
1.九、DB節點：數據庫節點，一主一備。
二、可靠性測試的含義與測試過程
可靠性測試是指：系統在常規與意外環境執行和保持其功能的能力，系統必須能以一致性和可重複性的方式執行並保持其功能。（概念出自《敏捷軟件測試：測試人員與敏捷團隊的實踐指南》）
測試過程：
2.一、明確可靠性測試的目標，同一個系統，不一樣的測試目標設計出來的用例也不同。
2.二、瞭解軟件的架構。
2.三、設計可靠性測試用例。
2.四、執行可靠性測試用例。
2.五、分析可靠性測試結果並輸出測試報告返回給測試經理。
三、用例設計
主要從如下幾個方面來考慮，可靠性測試的原則之一：故障恢復後業務可以自修復。
3.一、從架構設計圖來看一共涉及的的節點有：console，service，billing，db，insight，monitor。其中只有insight部署在一臺主機上，其他節點均部署在2臺或2臺以上的服務器上，以service爲例，一臺服務器宕機了是否會影響業務，兩臺呢，或者所有宕機後開機可否自行恢復業務呢？
3.二、內存佔用率：單個節點的內存佔用率達到90%和100%；多個節點 內存佔用率達到90%或100%。
3.三、CPU佔用率：：單個節點的CPU佔用率達到90%和100%；多個節點 CPU佔用率達到90%或100%。
3.四、磁盤使用率：：單個節點的磁盤使用率達到90%和100%；多個節點 磁盤使用率達到90%或100%。
3.五、網路故障：單個節點網絡故障，多個節點網絡故障。單個節點和多個節點某個網卡down掉。
3.六、單個節點重啓，或多個節點重啓。
3.七、功能首次失敗時間，好比：建立DWS集羣首次失敗時間，即初始操做和首次失敗之間的平均時間。
3.八、DWS集羣長時間運行業務，是否出問題。
3.九、併發操做：好比同時建立50個集羣，觀察成功率，可使用BrupSuite工具。
3.十、業務可否從節點A遷移到節點B，好比建立集羣的任務正在節點service1上運行，此時，service1宕機，任務可否成遷移到service2或service3上。
四、可靠性測試過程當中用到的工具
寫滿磁盤
參考命令：dd if=/dev/zero bs=1024 count=1000000 of=/root/1Gb.file
佔滿內存
待補充
佔滿CPU
參考：https://blog.csdn.net/robertsong2004/article/details/36879233