背景簡介
對於大型應用後臺系統來說，穩定性至關重要。目前越來越多的大型應用系統採用微服務架構，更加需要關注穩定性的技術能力建設。穩定性是服務系統基礎能力的體現。
基礎知識
在介紹穩定性技術策略主題之前，我們首先梳理一些基礎概念和知識。
針對我們業務後臺系統建設，任何大型業務後臺系統絕對不是一蹴而就。它是伴隨着業務不同階段，不斷進行演進的過程。如果經歷過從 0 到 1 建設一個業務後臺系統的同學，都會有類似的體會。
啓動階段
啓動階段，業務模型相對簡單，用戶量少，這時候我們可以將所有的系統模塊耦合在一個工程裏面，進行單機部署。這時候可能僅僅需要將業務系統與數據庫進行隔離。
探索階段
探索階段，業務模型不斷演進，用戶量增加，單機服務能力瓶頸凸顯。這時候就需要由單機服務部署向集羣服務部署來優化，利用負載均衡將請求合理分配，減少單機服務壓力。另外一個方面，數據量不斷的增加，也需要考慮針對數據來進行水平的擴展(主從部署，讀寫分離)。
在這一階段，我們僅僅是做了集羣擴展，但所有的業務代碼都在同一個工程維護，所有的數據信息都在同一個數據庫中存儲。隨着團隊的擴充與業務交互不斷複雜化，在工程維護上存在很大的風險，工程研發效率受到制約，業務代碼之間的耦合也難以清晰，系統可靠性存在很大風險，一個 bug 可能會造成整個應用的崩潰不可用。
發展階段
如果我們比較幸運，業務持續快速發展，對於業務角色模型理解越來越清晰，業務角色模型之間的交互越來越確定。這時候就需要我們基於對業務充分的理解前提下進行垂直拆分。不同的業務模型會部署到不同的系統工程中，工程之間通過接口來進行交互。這樣工程內業務高度集中，工程間通過接口服務來進行解耦。這時候不管是系統維護，還是業務模塊維護，都將大大的提高效率。數據部分同樣垂直拆分，不同業務數據拆分到不同的數據庫，從而提高單機數據庫的能力。
拿電商系統的結構來說，如下圖所示：
基於業務模型分爲幾個大的系統服務，系統服務之間通過內部 RPC 接口來進行交互。
成熟階段
上面是基於大的業務模型進行劃分，隨着業務複雜度越來越高，我們必將對大業務模型，基於功能或者業務邊界進行更細粒度的拆分。比如說，我們可以將產品中心劃分爲：基礎信息中心，庫存管理中心，SKU 中心等。
這時候就涉及到微服務的拆分與治理工作。
微服務的拆分原則我們應該注意：業務功能單一； 服務間業務邊界清晰；拆分粒度合理； 分層劃分合理。
從研發的角度來說，微服務帶來的好處：研發效率提升；代碼質量更優；能夠獨立部署；單模塊複雜度降低。上面提到的產品中心我們可以拆分很多小的服務來提供，如下圖所示：
細粒度的拆分，也會帶來一定的挑戰：
微服務劃分單元越細，整體服務維護非常複雜；
微服務通過 RPC 接口交互，整個鏈路可能會不清晰；
單服務的修改或者優化會受到其他模塊的牽制。
當然這些挑戰都是我們需要思考與解決的問題，並不能抹殺微服務的優點。
大型業務後臺系統，不斷的微服務化，帶來系統之間的接口交互與依賴管理也越來越重要。我們需要從整體上考慮我們如何保證這樣一個流量併發高，業務模型複雜，服務依賴交互多的大型微服務後臺應用系統的穩定性。不能由於某個不利因素來影響整個業務微服務系統的不可用。接下來我們將重點介紹穩定性相關的內容。
穩定性技術策略
什麼是穩定性
對於大型微服務系統，在錯綜複雜的服務邏輯各種交互情景下，面對各種未知的條件變化，整體系統依舊能夠正常平穩的提供服務，這便是穩定性。
影響穩定性的因素
系統穩定性影響因素非常多，舉例來說：
1. 服務間的依賴：某個服務 BUG 造成其他依賴服務的不可用；
2. 業務邏輯變更：業務邏輯不斷迭代演變，新老服務的不兼容；
3. 訪問流量激增：流量突然增加，比如我們進行促銷活動期間，導致服務壓力過大 ，達到服務能力上限，從而導致服務崩潰；
4. 機器老化異常：任何機器和人一樣，都有生老病死，隨着長時間的運行，也會有磨損，因此某個機器故障，也是可能的異常。
還有其他各方面的因素，在這裏就不進行窮盡了，大家可以思考一下，還有那些經典的影響因素。
穩定性的衡量標準
穩定性衡量標準一般用 N 個 9 來衡量。如表格所示：
名稱級別年度停機時間描述2 個 999%87.6 小時基本可用3 個 999.9%8.8 小時較高可用性4 個 999.99%53 分鐘技術容災能力可用性5 個 999.999%5 分鐘極高可用性
比如說某個系統網站全年穩定性達到 4 個 9 ，意味着全年服務不可用的時間小於等於 53 分鐘。
穩定性技術策略
穩定性的技術策略，是我們本文介紹的重點，從大的方面來說，穩定性技術策略包含：監控，冗餘，限流，降級，回滾，重試。
監控
監控是指對整個系統服務進行實時的監控操作，準確反饋系統運行狀態，能夠做到及時發現異常故障，記錄詳細日誌與數據，提高故障發現，定位，解決的效率。從而提高系統服務整體穩定性。
監控是保證穩定性最基礎工作。我們將重點介紹監控需要從幾個方面考慮？ 有哪些監控方向？
監控可以分爲以下幾類來進行：
流量監控
流量監控包括：PV、 UV、 IP，熱門頁面，用戶響應時間。
這些基本的流量指標就不在這裏向大家詳細說明了，如果有不太清楚的同學可以自己搜索一下。
在流量監控這塊，我們需要注意的是：流量毛刺。流量毛刺往往代表了系統某個風險點或者異常情況的發生。
一個正常業務的流量趨勢具備週期一致性特徵。比如說，一個業務每天的流量峯值一般在中午 12:00 和下午 18:00，那麼這種峯值在沒有特殊情況出現的前提下，應該會遵循該峯值時間規律。 那麼流量毛刺是啥呢？ 如下圖所示：
從圖中左側部分可以看到，8 點鐘有流量的突增，這時候我們需要確認爲什麼會有流量的突增。是業務的正常表現，還是有其他的異常流量進入。
從圖中右側部分可以看到，每條曲線代表了每一天的流量統計，紅色曲線相對於其他幾天的流量曲線在凌晨 3:00 和早上 8:00 的時候有明顯的流量毛刺，這時候我們就需要確認是什麼因素造成流量數據的突變。
通過對於流量毛刺的觀察，能夠讓我們及時瞭解業務中的風險，及時做好預警與準備。
業務監控
業務監控是根據業務屬性來定義監控指標，可以用於判定整體業務的運轉是否正常。不同業務類型監控的指標肯定有所不同，比如電商場景、物流場景、遊戲場景是完全不同的監控方向。
我們拿一個電商交易業務系統來舉例，看看有哪些監控指標？大家可以參考着思考自己目前負責的業務指標。舉例來說針對一個電商交易系統我們可以監控的業務指標有：
用戶下單監控：秒/分/時 用戶下單統計 ；
用戶支付監控：秒/分/時 用戶支付統計；
用戶退款情況：秒/分/時 用戶退款統計；
商品庫存狀態：庫存消耗/剩餘統計；
業務 GMV 監控：業務整體銷售額統計；
商家在線狀態：監控商家在線狀態；
促銷運營監控：監控促銷金額與數量。
在業務監控中，還需要重點關注業務轉化漏斗概念。流量漏斗可以看出業務轉化率以及用戶的訪問深度。它是業務健康程度的監控，也是部分需求效果的衡量標準。
機器監控
機器監控需要關注的內容，應該是後臺研發比較熟悉的部分。 主要監控方向包含下面幾個部分：
當然在 linux 系統中，也有各種常用指令，來進行該類數據的收集：top、free、ping、iostat、netstat。
對於 Java 系統來說，需要進行 JVM 層面的監控內容，比如說：gc 的情況，線程創建銷燬情況，full gc 情況，內存不同模塊使用情況等。 JVM 同樣也提供了指令集，方便我們進行信息的查找：jstat、jps、stack、jmap、jhat 等。
日誌記錄
在日誌的打印過程中，我們需要注意日誌的打印規範，日誌打印內容應該包含對於問題排查有益的信息，並且日誌格式清晰，可解析性高。日誌一般是打印到服務器磁盤上面，但是由於單機磁盤能力有限，並且對於大型分佈式系統來說需要整體收集不同服務器模塊的日誌，進行統一分析，提高問題排查效率。這時候就需要一個集中式的日誌中心。
日誌中心的核心能力一般包含：獲取日誌、存儲日誌、展示日誌、分析日誌、報警服務。
相對比較簡單的實現方式可以採用ELK快速搭建自己的日誌中心。
我們利用 kafka 將日誌信息，進行異步廣播，然後進行日誌的解析，存儲到 ES 檢索系統中，利用 kibana 來進行日誌的檢索、查看等。進一步提升日誌的有效管理。
冗餘
冗餘的對立面是單點。冗餘可以有效的減少單點問題造成的影響。大家可以思考一下，如果一個系統服務只部署到一臺機器，機器服務掛掉之後，意味着服務不可用，依賴於它的服務也會出現異常，最壞的情況可能會造成雪崩。
爲了簡化冗餘的思考，我們將整個應用後臺架構簡化爲四層架構，如下圖所示：
最上層是用戶訪問，然後到反向代理，Nginx 爲流量入口； 然後到站點應用，比如說咱們的 Tomcat 或者 Jetty 應用服務器； 最後是數據層 db；爲了性能優化增加了 Cache 服務。
大家思考一下，如果這幾層服務，全部的都是單點，單點就是我們只有一個機器去部署這些服務。Nginx 只有一臺機器，Server 應用也只有一臺機器。如果機器宕機會造成什麼樣的後果？會直接導致整個系統服務不可用，這個就是單點的風險。
完全依賴一個單點 沒有任何冗餘備份，導致服務的穩定性非常脆弱。
怎麼去做冗餘呢？
對於 Nginx 層與 Server 層，我們可以從下面幾個方向考慮冗餘：
多機部署：同一個機房內，部署多個服務節點，其中一臺掛掉，還有同機房的冗餘備份；
跨機房部署：不同機房內，部署多個服務幾點，其中一個機房斷電或者其他異常情況，還有其他機房來備份提供支持；
異地多活：如果所有機房都在同一個城市，就會造成地域單點，比如說城市光纖異常。這時候異地多活部署就會減少這部分影響。
對於數據層面比如 MySQL、Redis 都有自身提供的冗餘方案。 MySQL 自身提供了主從部署，主從同步的機制，系統服務可以進行讀主寫從操作。
Redis 也類似，提供了集羣冗餘方案：主從配置，哨兵機制，集羣模式。
Redis 集羣模式能夠實現數據分區冗餘備份，主從同步，多主容災，故障自動轉移能力。
冗餘的思路，在業務實現方向也可以落地考慮，比如說重要數據的多介質存儲；重要組件的多版本選擇等等。
限流
大型微服務架構中的任何服務節點，不管咱們怎麼優化，怎麼拓展，都會有能力上限。如果達到能力上線，系統服務奔潰的可能性增加，這種情況也很容易造成整個微服務應用的雪崩效應。
作爲一個面向用戶的網站，有時候我們會面對流量激增的情形，如果這時候達到了我們某個或者多個服務的能力上限，我們應該怎麼保證系統的穩定性?
限流在這種情形下就起到了作用。
限流的目的
就是當服務器的壓力劇增的情況下，爲了保證服務不被拖垮，對一些流量採取拒絕或者降級的策略，以此來保證核心服務的正常運轉。這是一種有損的技術手段。
將部分流量進行限制速率，控制輸入和輸出，將超過限制速率部分的流量，進行拒絕服務、或者排隊等措施。以此來達到系統的自我保護目的。
限流策略：
限流策略有三種常用方式：
1. 總量計數限流：併發量或者訪問量超過設定的閾值，將拒絕提供服務；
2. 漏桶限流算法：一個固定容量漏斗，任意速率流入或者生成併發或者訪問，但會以一個固定的速率執行這些併發或者訪問。如果超過固定容量的部分將被拒絕；
3. 令牌桶限流算法：一個固定容量的令牌通，令牌按照固定速率放到桶中，請求到來時候先去令牌通獲取令牌，如果獲取到則可以進入業務邏輯部分，獲取不到則不會執行。
三者的區別：
限流的維度
如下圖所示，限流思考從三個維度去思考：
限流的實現
1. 基於 AtomicLong 來實現單機(接口)總量計數法限流；
2. 基於 Semaphore 信號量來實現單機(接口)總量計數法限流；
3. 利用 Guava limiter 來實現令牌通的算法；
4. 對於分佈式限流，我們可以考慮，利用 Redis 的 Incr 來進行實現。
降級
降級的目的
1. 削弱非核心服務資源佔用；
2. 保證業務核心服務穩定性。
舉例來說：
一個交易平臺，有用戶下單，支付等功能，同時也有用戶評論，商品推薦，廣告推薦等模塊。在促銷活動期間，用戶大批量的進入，那麼這時候由於功能模塊非常多，流量或者機器資源消耗非常大。造成系統整體負載過高。那麼很可能出現一個可怕的情況，用戶沒辦法進行正常交易。
面對這種情況，我們應該怎麼做？這時候降級就體現了它的實用價值。
降級策略
降級策略有很多方面需要思考與落地，在這裏總結一下經常用到降級策略。
頁面降級：非核心頁面模塊，佔用緊張資源，關停該頁面，減少訪問；
服務降級：將功能分類，分爲核心服務與非核心服務，將非核心服務進行關停；
依賴降級：將依賴服務梳理分類，保證核心依賴的穩定，將非核心進行降級關停；
讀寫降級：將直接讀寫數據庫切換爲讀寫緩存； 對於緩存依舊可以進行備份冗餘；
延遲降級：頁面的異步加載策略； 數據寫入異步消息隊列等。
降級實現
降級就需要一個分佈式開關，通過開關來確定降級策略的啓動與否。 分佈式開關的實現方式，我們也簡述一下：
基於 Redis 實現；
基於 ZK 來實現；
基於內部數據庫來實現。
每個具體的實現方式大家如果感興趣可以查閱一下資料，基本上都是功能實現相對簡單。
合理降級瞭解了降級方法之後， 我們還需要清楚不是所有服務都能降級，也不是等到故障發生了以後，纔去選擇或者確定哪些服務可以降級。故障的降級策略一定是要提前去規劃與思考。
系統或者服務需要分爲核心系統和非核心繫統(核心服務和非核心服務)來區分。核心服務是我們力保不能有任何問題的主流程服務 P0； 非核心服務，又可以根據重要性進行再次分層。可以劃分爲 P1、P2、P3 服務。
P0 服務網爲主服務，是力保穩定性的對象，他們掛了整個業務也就崩潰；
P1 服務爲與緊密主服務相關，但可以後續異步補償來操作的服務，比如說，結算流水，訂單統計；
P2 服務與主服務有點相關，但關閉了對主服務任何業務邏輯沒有影響，比如說，訂單評價，商品推薦等；
P3 服務於主服務沒有相關，關閉之後對主服務沒有任何影響 比如說，廣告推薦，用戶喜好，評論瀏覽等。
在梳理服務等級的時候，需要注意 2-8 原則 也就是 20% 的系統爲核心系統，80% 的系統爲非核心服務。
回滾
根據經驗，線上的大部分 BUG 都是由於新需求或者新的工程改動造成的。
那麼當系統出現 BUG 或者不穩定的時候，考慮到尋找或者排查問題耗時會比較久，我們一般都會選擇先回滾然後再去尋找問題具體原因。這種方式在一定程度上保證了系統的穩定性狀態。
回滾定義：快速恢復到變化之前的狀態，讓程序或者服務恢復到改動之前的穩定狀態。回滾目的：及時止損，減少線上問題排查付出的代價回滾影響：新改動的需求會延遲生效
那麼我們回滾的方向又有哪些呢？
回滾方向：
1. 代碼版本，也就是新舊代碼的轉換；
2. 系統服務，就是講新上線部署的功能給予回滾操作，讓服務恢復到新上線前的狀態；
3. 數據內容，將修改的數據內容重新修改爲歷史數據版本。
怎麼才能科學的回滾？
如果想把回滾的工作做好，需要處理好下面的主要內容：
發佈信息規範：每次發佈包，都有唯一的版本號；命名一定要規範。包含主要內容。 舉例：工程名稱 - 模塊名稱 - 代碼版本 - 環境類型 - 日期版本 .jar(war)
代碼管理科學：代碼分支管理科學、 代碼 review 機制、工程結構統一化。
代碼 review 時機：
大版本(需求)代碼必須 review；
線上 case 修復，代碼必須 review；
測試前代碼 review (保證測試質量)；
週期固定時間，形成團隊習慣。
數據管理規範：避免線上庫直接操作、任何變更必須有回滾腳本、線下驗證 。
注意事項:
儘量避免線上數據庫手動操作；
若手動，需要執行詳細規範；
不斷設計減少手動操作頻次。
工程上線規範：上線窗口避免流量高峯，灰度驗證避免全量上線，及時驗證迴歸測試，上線通告。
重試
重試目的
配合超時機制，正確的獲取結果，同時保護系統資源服務；
利用多次訪問策略，減少外部抖動對系統結果造成的影響；
藉助冪等概念，保證信息提交成功，達到分佈式一致性。
重試的場景可以有 異常重試，超時重試。
異常重試：我們訪問某個依賴接口的時候，如果出現接口返回異常的情況，我們可以進行訪問重試，從而獲取正確結果。
超時重試：接口在規定的超時時間內沒有得到相應的結果數據，進行重試操作。
全局思考重試策略
如何進行合理的超時重試策略設定，需要結合業務特點來進行詳細的規劃與測試。如果設定不好，很可能造成線上問題。
超時時間過長，可能導致服務阻塞； 超時時間太短，可能導致服務調用成功率降低。如果成功率降低，可能就會導致重試的概率加大。 重試必然會導致新的請求發生，增加一次訪問時間，可能在用戶體驗上存在影響。
如果不斷的重試，很可能導致不斷的新建訪問線程，重複請求，導致三方接口的壓力。
所以超時時間 重試策略 都需要根絕我們業務特點進行驗證與設計，避免上面介紹問題的出現。
峯值應對策略
當我們業務系統需要進行運營促銷活動的時候，或者面臨特殊日期將要給網站帶來高於平時流量的時候，我們需要做好應對流量峯值的準備。我們需要系統的思考如何在系統峯值時刻保證我們大型微服務系統的穩定性。
我們將峯值應對按照時間維度進行劃分：事前，事中，事後。
事前
前期準備
確定模塊：確定本次峯值影響的工程或者服務，梳理一定要完整；
團隊組建：根據影響模塊，確定本次維穩參與同學(注意跨團隊)，確認分工；
合作約定：週期性的溝通，比如週會、約會、事前會議、事後總結會議。
數據預估
容量預估方向：
數據預估的時候不僅僅要考慮峯值的應對時候的容量冗餘，同時也要考慮數據長期增量的準備。
系統壓測
系統壓測的維度由小到達來說：
單接口壓測：接口維度的壓測，人工根據接口模型進行壓測數據；我們可以使用 Apach ab、Http load 來進行。
單機初級壓測：針對機器維度來進行整體壓測，可以人工構造數據也可以線上訪問流量的複製來構造壓測數據。我們可以使用 Jemeter、LoadRunner、tcp dump 等相關工具來進行。
單機負載均衡壓測：也是針對單機維度來進行壓測，與初級壓測不同的是，根據負責均衡，將線上流量進行實時轉發，將流量比例向壓測機器傾斜，從而達到壓測的目的。
全鏈路壓測：全業務後臺服務整體壓測，複製線上真實流量，進行壓測數據的改造，然後高併發的訪問業務系統，提前相對真實的模擬峯值到來的情形。
全鏈路壓測是最困難，涉及面最廣的一種壓測方式。同時也是最能發現系統瓶頸的一種方式，全鏈路壓測的挑戰有：
困難1：鏈路梳理複雜度；
困難2：多模塊，多服務，多團隊協同；
困難3：尋找短板，避免系統雪崩風險；
困難4：壓測數據準備，髒數據處理；
困難5：壓測統籌安排，數據採樣對比。
全鏈路壓測的流程如圖所示：
容災演練
目的
主動觸發異常，熟悉異常處理流程；
驗證故障處理規範，不斷完善規範；
驗證服務異常狀態，驗證報警機制。
步驟：
目前內容，評估影響，方案確認；
制定故障 SOP 手冊，詳細到每一步執行；
根據 SOP 進行問題解決執行操作；
記錄故障數據與現象，監控報警確認；
故障分類：可以快速解決，需要外部支持。
容災演練的 SOP 建設：
服務巡檢
在峯值到達之前的一段時間裏，我們需要對系統服務整體巡檢，確保的我們的各項指標都能正常工作，及時發現可能存在的風向。
定事：
1. 對業務、流量、系統、機器、日誌 進行數據指標的 check ；
2. 確保主要數據無遺漏，不重複，沒錯誤。
定人： 專人專事，責任明確，分工合理，推進日常巡檢工作 。
定時：
1. 根據業務特點週期性的進行服務巡檢，比如每天一次，每週一次；
2. 根據業務特點，合理的安排巡檢的時間，比如說中午、下午。
定方案： 根據巡檢出現的異常數據或者不合理數據，進行解決方案的制定 方案必須可執行同時有完成時間點。
事中
峯值應對值班
在面對峯值期間，我們需要保證團隊資源的穩定，需要安排核心人員進行值班操作。值班過程中需要做一下工作：
服務觀察：業務數據，服務監控，日誌報警，趨勢檢測； **熟悉 SOP **：容災操作 SOP ，值班 SOP ，同步 SOP；組織形式：站會，日報，總結。
數據觀察同步
爲了讓團隊其他人或者合作團隊瞭解當前的系統運行情況，我們需要在固定的時間裏同步相關數據，及時檢查數據走向與趨勢。
每天固定時間進行數據同步（儘量選擇峯值時間段）；
數據同步對象包含：業務、PM、QA、RD 多個團隊；
統計指標註意跨團隊的理解程度（可理解的形式來描述）；
對比屬性，比如說目前峯值是上次活動峯值的多少倍。
線上緊急情況處理
處理準則：
這裏特別重要的一點準則就是，快速止損是第一要務，問題排查以及解決是止損之後的動作。
這時候在快速恢復線上服務的時候，就能考察我們前期的容災演練的效果了。
上面圖形展示的操作規範都應該在容災 SOP 建設中覆蓋到。
事後
1. 所有報警異常的梳理與解決，所有不規範性的討論與優化；
2. 根據真實的場景進行 SOP 的優化，這個 SOP 可能包含咱們的值班 SOP 以及容災演練 SOP 的建設；
3. 覆盤討論，需要根據業務數據、流量數據、系統服務情況統一來進行復盤整理。覆盤的邊界，不僅僅是應用後臺，還應該也包含前端研發、SRE、運營產品、中間件平臺等。
覆盤討論的內容一般包含：
應用後臺: 峯值期間業務數據、服務性能數據、整體穩定性數據；
前端研發：APP crash 率、性能表現情況、DAU、各頁面轉化率；
SRE 運維：機房整體情況、機器負載情況、網絡寬帶情況、資源利用率等；
運營產品：業務指標完成度、同比(環比)情況、未來規劃；
中間件平臺：中間件峯值穩定性情況、容量情況、服務能力情況。
性能優化策略
性能優化重要性：
用戶角度：網站體驗重要衡量標準；
系統角度：穩定性的基本要求保障；
研發角度：自身技術能力的競爭力。
在這裏由於篇幅有限，我們不針對每一塊優化的技術策略進行詳細的講解，我們重點介紹一下技術優化的整體方向與策略，以及如何選擇方案。
我們在考慮網站性能優化方案選擇的時候，從收益與投入兩個方向綜合考慮。
應用技術棧對於後臺研發同學來說是相對比較熟悉的技術內容，所以投入會相對較少，收益卻會很大。因爲大部分性能優化的問題，還都在於代碼與技術方案層面。
數據庫方面也是需要重點投入的方向，能夠避免業務數據獲取以及存儲方面的瓶頸。
其他的三個方向網絡優化，容器組件，底層環境都不是業務後臺研發同學經常學習的方向。所以這幾塊優化方向可以考慮和公司的運維同學進行共同思考與建設。
當然性能優化是一個長期重複執行的動作，需要進行不斷的總結，梳理出來符合自己業務的性能優化策略。
總結
本文介紹了大型微服務架構後臺應用系統穩定性技術策略的介紹。每個技術點都需要我們持續的思考與落地，全面整體的思考穩定性相關的建設動作。與此同時，還進行峯值應對過程中穩定性的保障工作如何開展，希望對大家有所幫助。