一、穩定性的定義
量化平台的穩定性通常有兩種方式，首先是平台的可用性，其次是線上問題和線上故障。
可用性一般等於（年度總時間 - 網站不可用時間） / 年度總時間
可用性的標准通常以幾個九來衡量，比如四個九，即 99.99%的可用性，即平台全年的不可用時間不能超過0.01% * 365 * 24 * 60 = 52.56分鍾。這是一個嚴峻的挑戰。
線上故障通常指大規模地影響到了平台服務的質量甚至是可用性，通常分為P1/P2/P3/P4四個等級，一般稱為P1/P2為重大故障。故障不一定會影響可用性，可用性有影響一定是有故障發生。
線上問題是指平台服務的小問題，小Bug，沒有故障那么嚴重，但一定程度可以反映平台的穩定性。
穩定性的目標通常是 杜絕一切故障隱患，在上線前保證問題的發現與解決，若故障難以避免，要求有能快速發現並報警的方法，且有快速處理解決故障的能力。
二、穩定性保障的思路
2.1 核心鏈路梳理
梳理出產品中真正核心業務模塊，對整個調用鏈路進行分析，如，是否為強依賴，是否需要降級和限流側率，資源是否滿足極限要求等。
通常來說，當某個服務不可用時，業務鏈路不能繼續進行且直接影響到業務功能，則為強依賴，否則為弱依賴。在進行強弱依賴治理時，要去除不合理的依賴，盡可能將非必須的強依賴降低為弱依賴。
對於強依賴要保障，合理分析制定降級、限流策略，緩存、資源調優。
對於弱依賴要隔離，故障時及時進行限流、超時攔截設置關停業務，以免對核心服務造成影響。
2.2 監控能力
監控反應的是能夠盡可能快地發現線上故障從而快速解決，以此來降低損失。
監控通常包括以下方面：
系統監控：機器資源狀態 （內存、CPU） 、應用性能指標狀態（qps/latency）、Core異常監控、日志監控
業務監控：業務指標大盤、業務服務監控
對於業務監控，監控的頻率通常和監控目標的重要程度有關，必要時也要按一定周期（日/周）進行匯總統計。
2.3 性能摸底、資源調優
性能摸底是對現上服務服務的當前的極限能力就行探測，合理規划機器資源，對於資源過甚的業務要減少機器預算，對於觸及資源紅線的要進行擴容。
性能摸底壓測流程可以例行化，一來可以及時發現業務迭代過程中可能帶來性能問題，二來是時刻進行資源預警和分配。
限流摸底方案參考《一種性能資源摸底的方案》
2.4. 限流降級
限流是根據某個應用或基礎部件的某些核心指標，如QPS 或並發線程數，來決定是否將后續的請求進行攔截。限流可以犧牲少部分用戶的體驗從而保障大部分用戶的產品體驗。
降級是通過判斷某個應用或組件的服務狀態是否正常，來決定是否繼續提供服務（服務降級）
降級從策略上又可以分為多級：功能降級（抵御短時峰值陡增）、Cache降級（抵御長時峰值增長）削峰限流（抵御長時超高峰值）、極端容災（抵御極端服務宕機災情）
2.4.預案措施
預案是在有意識的為潛在或有可能出現的風險制定應對處置方案，涉及 事前預防、事中救援、事后處理三個風險階段，又從容錯、容量兩個維度進行考量。容量分別是對服務上、下限保障的處理措施，如在超上限時進行限流，在遇到故障的惡劣情況下需要保證服務的最低質量，容錯又分為無損、有損。無損不會對用戶的體驗造成損失。比如，事先准備預案鏈路、准備擴容機房。有損，會犧牲全部/部分用戶的全部/部分體驗，限流和降級都是有損的。
2.6 故障處理
故障處理機制的目的是為了縮短故障時間，時間越短，用戶影響就越小。
因此需要事先准備好各種故障下的處理流程：服務回滾流程、服務開關管理、cache管理、限流降級開關管理。
三、保障體系
綜合以上點 穩定性保障體系框圖如下：
