關於RCA

markdown

# 關於RCA * RCA : 根本原因分析 ## 結論 * RCA是一種通用報告的格式，提供了一些通用的方法與計巧，讓問題可以從根本上被解決，可以參考[Here](https://asq.org/quality-resources/root-cause-analysis#resources) ## 我們小組上使用的簡易格式 * I. Problem Statement -> 定義/描述問題 * II. Cause & Effect -> 分析原因/造成影響 * III. Solution & Evaluation -> 提出解決方案/評估可行性 * IV. Topics behind the scenario -> 延伸討論 (如果還有的話) ### 節錄部份壓測的RCA報告 ```markdown ## I. Problem Statement * 接入平台需要能承受較大量的用戶。 * 壓測試後發現承載人數低下。 * 測試行為，登入 + 打訊息 + 圖片上傳 & 只打訊息，以不同的人數成增長與訊息數量測試。 ## II. Cause & Effect ### 登入導至OOM * 登入API 密碼加密每次使用64MB空間加密 -> 過多記憶體導至系統崩潰。 ### 併發下物件過多導至GC壓力 * 部份API在高併發下產生大量的物件建立與釋放 -> 使CPU 70%以上的時間花費在GC回收上 ### 編解碼使用的方式不適合高併發場景 * 通訊server的編解碼使用`map[string]interface` -> CPU效能 + GC壓力 ... ... ## III. Solution & Evaluation ### 登入導至OOM * 將密碼加密使用的空間降低 * 需注意玩家的token失效問題 * 要編寫過渡的程式才能無感更換 ### 併發下物件過多導至GC壓力 * 對於重覆使用的物件，在高併發下應使用sync.Pool池來減少GC壓力 ### 編解碼使用的方式不適合高併發場景 * 通訊server的CPU壓力可以透過多台機器分擔壓力(目前的做法) * 或調整編解碼方式減少物件壓力 * 由於MQ訊息沒分離，解決時應考慮所有種類訊息得情況 注意： 目前通訊server沒有自動化水平擴展 ## IV. Topics behind the scenario * MQ方面 redis stream 的訊息與通道是由程式維護，加上redis看似遇到瓶頸，考慮是否更換 redis 做為MQ的部份。 * 在尖峰流量的時候可以採用批次送訊息的方式，減少I/O壓力。 * 目前的設計模式能處理的人數與訊息量是有限的，應考慮以任何可行的方式逐步調整設計模式，除非已預期承載人數已足夠使用。 ... ... ``` > **根本原因分析**（**RCA**，**Root cause analysis**），旨在找到[問題](https://zh.wikipedia.org/wiki/%E9%97%AE%E9%A2%98 "問題")的[根本原因](https://zh.wikipedia.org/wiki/%E6%A0%B9%E6%9C%AC%E5%8E%9F%E5%9B%A0 "根本原因")，是分析問題、[解決問題](https://zh.wikipedia.org/wiki/%E8%A7%A3%E5%86%B3%E9%97%AE%E9%A2%98 "解決問題")的一種「[治本](https://zh.wikipedia.org/w/index.php?title=%E6%B2%BB%E6%9C%AC&action=edit&redlink=1 "治本（頁面不存在）")」的方式。 > 透過調查和分析問題哪裡出錯、為什麼出錯，尋求防止差錯事故再次發生的必要措施，從而提高服務安全和品質。 > By [維基百科](https://zh.wikipedia.org/wiki/%E6%A0%B9%E6%9C%AC%E5%8E%9F%E5%9B%A0%E5%88%86%E6%9E%90)