本次容災測試背景：
伺服器：Linux、K8S
資料庫：MongoDB（副本集模式，3臺數據庫）
應用程式：Java、SpringBoot
1、整理所有可能參與到測試的節點
1。1：儘量將一些重要的介面羅列出來
1。2：從基礎資源 ——》上層應用的思路，將各個環節的考慮因素羅列齊全
1。3：測試時間不宜過長，一般定在5分鐘左右，主要就是透過常規測試觀察一下結果
1。4：每次的容災測試，都要記錄好日誌，以便後續分析
2、基礎服務因素
2。1：一般是主從模式，或者單機模式
2。2：單機模式
2。2。1：宕機，恢復
2。3：主從模式
2。3。1：宕主機，恢復主機
2。3。2：宕從機，恢復從機
3、服務節點
3。1：比如當前服務給了兩個pod
3。1。1：先宕掉一個pod，然後恢復
3。1。2：再宕掉另外一個，然後恢復
3。2：比如給了兩個node
3。2。1：先宕掉一個node，然後恢復
3。2。1：再宕掉另外一個，然後恢復
4、觀察的一些指標
4。1：服務是否正常可用
4。2：如果有重啟或者過渡時間，大概要多久，太久的話也是可用性很低的
5、MongoDB的一些指標
5。1：接管主機是否正常
5。1。1：主機宕機之後，Secondary是否接管了Priamary
5。2：讀寫效能
5。2。1：查詢資料是否正常，是否存在異常耗時
5。2。2：寫操作是否有影響，是否存在異常耗時
5。2。3：是否有重複寫操作出現（比如重複儲存，重複更新、重複刪除）
5。2。4：測試期間，有沒有異常的請求，比如併發請求等等
5。3：服務恢復耗時
5。3。1：觀察服務自動恢復的響應速度
5。4：從機宕機之後影響與主機宕機之後影響的對比
5。4。1：從機與主機地位同等重要，觀察兩者宕機之後產生的影響
5。5：處理業務的失敗率（失敗的業務處理數/總業務處理數），大概瞭解一下維持正常業務的處理能力
5。5。1：按常理來說，過了過渡期，服務處理能夠正常進行是比較好的
============ 服務慢定位 ============
1、從容器側定位
1。1：設定一個簡單的網址，訪問看下情況。若卡住或者慢，那麼就是容器這塊的問題，比如tomcat限流
1。2：容器是否做了併發限制
2、應用程式
2。1：程式執行了一些耗時操作
2。2：程式執行了一些耗損CPU操作，比如死迴圈、無限遞迴、檔案操作等等
3、資料庫
3。1：沒有連線池設定，建立大量的資料庫連線，消耗CPU
3。2：存在連線池，但是連線沒有正確的回收，導致連線池不生效
3。2。1：比如建立資料庫連線之後沒有及時的歸還連結，設定沒有歸還，就會導致連線數激增，最終導致連線數超了，資料庫不可用
3。2：檢查是否存在慢查詢，慢查詢的危害不可小覷，影響會波及整個網站
3。2。1：一般因為慢查詢導致網站響應慢的可能性比較大，大多是由於編寫了一些不規範的SQL語句導致的
3。2。2：通常SQL沒有走索引的情況居多
3。2。3：再者查詢大資料量庫表資料導致全表掃描也有可能
4、中介軟體
4。1：比如使用了redis，程式碼中使用了keys（）函式導致redis執行緒卡住
4。1。1：redis的keys函式是嚴禁在正式環境使用的
4。1。2：比如java中使用jedis操作redis，每次操作完都沒有釋放連線，會最終導致redis不可用，有使用redis服務的業務程式將不可用
4。2：kafka服務宕機，應用程式呼叫不通，沒有做耗時檢測處理
4。2。1：由於程式呼叫kafka推送服務，而此時服務不響應，若業務程式沒有進行自身的耗時處理，很容易造成timeout的結果
