第一次接觸穩定性這個詞是在加入阿里第一年的雙十一KO會上，接觸到限流、擴容、壓測等詞匯，只覺得穩定性作業是瑣碎的、繁雜的、無流程性的、無明確衡量指標的、無從下手的，
今年，我和兩個小伙伴一起在穩定性保障作業中投入了大量的精力，我也從他們那里學到了不少關于穩定性保障相關知識，開始對穩定性作業有了一定的理解，
穩定性作業也是有條理有步驟的，按照步驟一步步來，就能夠輕松將穩定性保障作業做全、做對、做好，
所謂好記性不如爛筆頭，趁機梳理記錄下來，以便后續使用時能夠信手拈來，
根據前人總結，穩定性保障就是保障系統的穩定，在各種不可預知的情況發生時仍然能夠持續穩定的運行和提供服務，
個人感覺穩定性保障很像一個水利工程，在應用系統中，水可以是用戶流量，也可以是資金流，而穩定性作業就是保障這些水能夠按照預定的渠道路徑流淌，保障沒有滲水、漏水、渠道垮塌的現象，或者出現這類現象也能夠及時修復將損失降到最低，
穩定性保障作業到底做什么？自然是實作穩定性保障目標，
根據前文穩定性保障的定義可知“在各種不可預知的情況發生時仍然能夠持續穩定的運行和提供服務”就是穩定性保障作業的目標，
這個目標怎么實作？還是一頭霧水，無從下手，那是因為這個目標太大太虛了，
遇到一個大而虛的目標，可以使用目標細化分而治之的方式，需要如下圖的紅色虛線箭頭所示的幾個步驟，
首先，將目標細分為子目標，可以通過抽取目標中的關鍵字定義子目標，從“在各種不可預知的情況發生時仍然能夠持續穩定的運行和提供服務”中可提取出 不可預知的情況、發生時、持續穩定、運行、提供服務，這五個關鍵字就是穩定性保障作業的子目標，
然后，針對每個子目標進行提問，凡是自己有疑問的都羅列出來，包括但不限于對目標的理解類疑問、對目標實作的方法類疑問、對目標實作的標準類疑問，
之后，對自己所有的疑問找出答案或解決方案，就像上學期間導師給出課題，自己去理解去解決的程序，這可能需要查閱資料、現狀分析、方案選擇、最終決策、實際落地，
如此，所有的子目標都將逐一實作，最終，子目標的實作進而完成終極目標的整體實作，
綜上，上圖中最外層的淡藍色圈中的內容就是我們為了實作穩定性保障目標所需要做的作業了，初看起來很多，細看下來隱有規律，再看之下發現本質就是這幾點：什么現象？如何發現？什么影響？如何處理？現象、影響、處理方式都與具體例外耦合，發現靠監控告警，
總結起來就是：梳理例外情況->配置監控告警->評估影響面->預定解決方案，
接下來，將從這四個步驟入手闡述穩定性保障作業具體如何落地，大框架先展示如下圖所示：
那么什么是例外情況？例外情況很多很瑣碎啊，像RT飆高、訊息佇列阻塞、FullGC、NPE、資料例外、資料不一致、資金金額計算出錯、資料庫連接超時、網路例外、代碼出現bug造成例外等等，這么多梳理起來如何保證覆寫率？
繼續使用前文的目標細化分而治之的方式，但此時目標細化無法通過拆分關鍵字實作了，此時可以通過類目細化的方式定義子目標，
對例外情況進行類目細化，從上面列出的這些例外情況可進行歸類梳理，可見訊息佇列、資料庫連接、FullGC等都是中間件導致的例外，而代碼bug、資料不一致、資金金額算錯這類例外屬于開發寫出的bug或者產品設計缺陷，綜上，可將中間件這類例外定義為基礎設施例外，bug和產品缺陷類的例外定義為業務功能例外，
再反向梳理一下，基礎設施例外包括網路、容量、連接、磁盤、快取、JVM等等中間件或者底層硬體設施產生的例外；這類例外日常一般不會發生，只可能發生在大而突然的流量變化時，基礎設施扛不住過大的流量導致例外，因此多發生在大促期間，
業務功能例外包括代碼邏輯例外和資金例外，與業務功能息息相關，因此這類例外一般出現在每次業務邏輯的變更后，與日常需求相對應，可在每次業務需求開發的同時進行梳理，也可根據例外梳理結果在代碼中預置開關和訂正工具，萬一上線后例外情況出現，就可使用預置開關和訂正工具進行止血和修復，
順便提一下，根據例外的分類，平日里大家習慣性將穩定性保障作業分為日常穩定性保障和大促穩定性保障，
監控告警分為三類，基礎設施監控告警、業務功能監控告警、資金安全監控告警，
基礎設施監控告警一般都是在應用創建之初進行配置的，涵蓋應用和所有的中間件、網路等，集團對基礎監控告警的覆寫范圍有明確規定，
業務功能監控告警都是在日常業務功能開發時由開發人員配置的，用于監控特定的業務場景，
資金安全監控告警主要面向與資金相關的應用，例如下單支付，如果沒有就需要從0到1的創建，之后就隨著每次業務功能開發進行增量式設定，
大促前夕一般會對所有的監控告警進行梳理并查漏補缺，
資料流向圖
監控告警配置其實是個省略句，其完整的表達應該是：監控告警資料源的準備、監控告警配置，
監控告警的整體資料流向如上圖所示，主要通過日志、訊息、持久化資料作為資料源，將資料收集起來后用于監控告警的配置，
其中日志主要用于監控大盤展示，實時反應線上真是情況；訊息主要用于實時核對的觸發媒介，觸發資金安全核對，資金安全核對通過采用旁路核對、資金一致性核對、兩兩核對等方式核對線上邏輯；持久化資料主要用于離線核對，通過兩兩核對的方式校驗資料正確性，具體核對邏輯后文詳述，
最終，監控核對都將告警資訊匯總到告警系統，觸發告警，同步到告警回應人進行處理，
配置步驟
綜上對監控告警的資料源及其流向有了了解，就可以按照以下步驟配置監控告警了：
值得一提的是，雖然先要有資料，才能配置監控，但是其實資料準備和監控配置這兩者應該是并行的，根據監控項的大概規劃準備監控資料，然后進行監控告警配置，有任何資料不滿足配置的情況都要回傳進行資料準備步驟，
個人認為一個監控的好壞評判標準主要通過三個指標：正確性、覆寫率、直觀性，正確性保證監控的基本功能，能夠正確的反應真實情況，沒有正確性的監控毫無存在意義，覆寫率是衡量一個監控系統成功與否的關鍵指標，覆寫率越高，監控系統就越能夠完美的體現系統的實際運行情況，直觀的展示監控指標有助于快速發現例外、快速定位問題，
對于告警，個人認為告警的配置最重要的是：及時性、有效性、責任制，告警出現一般都是有例外情況，可能涉及到資損或者故障，發現越及時，止血越及時，損失就越小，告警最終都是人工處理，無效的告警會浪費人力成本，因此告警配置要注意過濾噪音，保障告警的有效性，保證報出的確實是問題，至于責任制則是強調告警必須要有人回應，每條告警最好分配到人，有回應的告警才是最終有效的，
資金安全核對
資金安全核對的本質是檢查是否有資損事件的發生，做到及時報警快速止血，最終達到資損防控的目的，資金邏輯相比一般的業務邏輯存在一些共性，因此我們能夠針對這些共性思考出一些通用的資金安全核對方法和資損防控措施，
對于資金安全核對的方法論，根據前輩們的總結概括，資金安全問題主要是對資金關鍵要素的處理程序中出現例外導致的，資金關鍵要素的生命周期主要包含三個重要節點：生產、傳遞和消費，三個節點分別可能出現的錯誤為生產錯誤、漏傳錯傳、消費錯誤，針對這些錯誤，前輩們提出三大核對方法，所謂核對，都是尋找有一個正確資料作為預期，將實際情況與預期資料進行對比核對，
-
基線核對是將歷史資料作為預期進行對比核對，這種方式依賴歷史資料的正確性，投入少，實效低，可發現大的資金問題，
-
兩兩核對將上游作為預期，進行對比核對，精準度高，時效性高，成本比較高，難以覆寫全面，
-
業務邏輯核對將業務專家的經驗作為預期進行核對，需要大量人力投入，對經驗的依賴度高，但是精準度高，時效性高，
我的專攻資損防控的小伙伴做了很全面的總結歸納，如下圖所示，資損防控的策略包括保存量、盤增量、控高危、盯特有，資損防控是一個長期的程序，需要時常維護，對存量布控不斷優化保鮮；對新增變更進行資損評估，發布前卡點確認，保證有對應的核對規則；對于易資損場景和資料進行專項重保；對大促特有邏輯或者場景進行特別關注，
資損防控，需要對全鏈路資金安全風險場景進行梳理，從失血型別、規則表達、規則型別、依賴因子等多方面分析資損場景，建立相應的失血模型，為保證快速、精確，可監聽異步訊息來進行實時核對，同時結合特定的錯誤日志告警，再加上小時級離線持久化資料核對兜底來保障資金安全，對于核對腳本，可通過組織review和攻防驗證保障其正確性，
建立資損大盤，在大促高峰期值班期間安排專人盯盤，及時回應問題處理，同時對于高資損風險項預置必要的應急預案，在緊急情況發生時可以及時熔斷止血以保障資金安全，
基礎設施的例外分多種，例如程度較輕的僅僅是短期內的負載高，嚴重的某個中間件（例如MetaQ）不可用、機房斷電，光纜被挖斷，其例外的嚴重程度直接決定了影響面，可能錯誤率飆高、RT飆高、訊息阻塞、FullGC頻繁，影響到系統的持續穩定性，也可能系統癱瘓不可用、網路不可用、流量跌零，不過對于這種嚴重的例外一般不會發生，機房都是多機房部署，硬體容災考慮有專門的團隊去保障，中間件也要專門的團隊運維保障，
穩定性保障作業對于基礎設施例外一般只考慮大促流量激增引起的容量不足、系統壓力大等問題，這類問題的原因明確，就是流量過大，直接現象就是錯誤率飆高、RT飆高、訊息阻塞、FullGC頻繁等，較嚴重的情況下會引起客訴和輿情，
業務功能例外就是錯誤，無論是邏輯例外還是資金計算錯誤，資金流轉錯誤，本質上就是產品設計有缺、開發留下的bug或者某處配置有誤，這類例外與具體的業務場景有關，小則僅影響某一個區域小功能，大則影響核心功能，可能引起客訴和輿情，資金例外可能導致資損，
前文大框架中，我們已經知道了預定的解決方案大概有限流、壓測、擴容、預案等措施，那么這些解決方案具體如何落地呢？他們之間是否存在一定的順序？
解決方案與例外型別強相關，不同的型別有不同的解決方案，因此解決方案也分為業務功能例外的解決方案和基礎設施例外的解決方案，
業務例外的解決方案
穩定性保障對于業務例外主要是從“萬一發生了怎么辦”這個角度出發去思考解決方案的，因此需要提前準備錦囊，以備不時之需，
業務類例外的解決方案一般分為三類，止血解決方案、臨時解決方案和長期解決方案，需要消耗的時間逐漸增多，對問題的解決程度逐漸增加，都是問題發生后的應對方案，
止血解決方案一般不需要走代碼變更發布，通過預案、設定、開關等實作，通常也是需要提前有所計劃，有所準備的，臨時解決方案和長期解決方案一般需要走代碼變更發布，耗時較長，因此遇到問題一般都先執行效率最高的止血解決方案，如果止血解決方案依舊承受較大的損失，就需要快速拿出臨時方案來解決問題，臨時方案雖然一定程度上解決了問題，但是可能存在一些小功能問題、性能問題或者優雅性方面的瑕疵，因此需要在問題得以緩解之后思考出一個穩定優雅的長期解決方案，當然，那已經是后話了，不屬于穩定性保障的作業范疇，
對于業務功能例外，在日常開發時就需要提前打算，準備好能夠多維度多程度降級的開關或者設定，留作例外發生時緊急止血使用，也就是預案，
預案需要預演進行驗證，保證預案配置和執行的正確性，
預案
預案的本質是一個或者多個能夠快速改變代碼邏輯的設定，例如開關、diamond配置或者其他工具，將這些配置跳過繁瑣的審批流程、實作快速執行就是預案，是用于大促前期關閉非核心功能、大促期間緊急問題及時止血保障主要功能而選擇斷尾某些功能的操作配置，
提前預案是大促前期自動執行用于關閉非核心功能以保障核心功能的預案，例如日志降級等；這類預案一般不會造成損失，風險可控，影響面是業務和消費者都可接受的，
應急預案是大促期間發現線上問題，經過大促負責人審批同意后由相關測驗或者開發人員手動執行，用于及時止血以保障主要功能的預案，這類預案類似于壁虎斷尾的行為，舍棄小的損失，保留大的功能，因此一般都存在一定的損失，
預案項需要提前梳理清楚，對功能無影響但是對性能無影響的錦上添花的部分在大促期間是是可以作為提前預案降級；對于可能出現例外情況的代碼邏輯，或者評估風險較高的邏輯都要不吝增加開關設定，實作多維度降級（業務身份維度、商品類目維度、商家維度等等），在大促前夕配置好緊急預案，
預案設定越多越好，但是預案執行須謹慎，預案越多，能夠快速應對的例外場景就越多，就越能夠快速止血，當然也要考慮維護成本，但是配置預案的時候就要全面細致的評估清楚其執行影響，這樣到了執行的時候才能正確選擇合適大小的創可貼應對止血傷口，執行預案時須謹慎，按照大促要求走相應的流程，保證有double check，
預演
預演就是預先演練一遍，包括功能預演、活動預演、預案預演等，
基礎設施例外的解決方案
穩定性保障對于基礎設施例外主要是從“如何才能不發生”這個角度出發去思考解決方案的，因此需要提前修煉內功，增強自身實力，
對于基礎設施例外，一旦發生，難以快速止血和修復，因此一般都是在大促前夕就要做足穩定性保障作業保證大促時不發生或者少發生這類例外，可通過壓測、預演提前發現例外，提前提出解決方案進行修復處理，
如前文所述，對于基礎設施例外，穩定性保障作業僅考慮流量過大導致的例外，因此這類例外的原因明確就是流量過大，其解決方案也就明確是解決流量問題，分為對外解決方案和對內解決方案，對外限流拒絕過多流量對自身進行保護，但限流需要基于容量預估，有考量有依據的設定，對內擴容增強自身實力，并提前預熱做好應對準備，
內外解決方案通過壓測相互協調配合，最終達到一種權衡利弊后的和諧，
綜上，先要進行容量預估，預估外部流量峰值，再根據預估容量進行限流設定，然后進行壓測，評估內部容量是否能夠支撐預估容量，如果無法支撐，就要考慮擴容，擴容后根據機器數量進行限流調整，然后再次壓測，壓測后能夠支撐預估容量甚至游刃有余時可以考慮再次調整限流，承載更多的流量，最后可以考慮在大促前進行快取預熱防止流量峰值擊穿快取，
容量預估
-
1、對上游：詢問預估流量，即他們要求我們的保障值，上游需要呼叫我們的服務，因此我們提供的服務量級需要滿足他們的訴求，簡言之，我們的水渠需要能夠容納得住從他們那里流下來的水流量，
-
2、對自身：梳理自身上下游鏈路，基于自身預估，根據上游訴求，預估對下游的訴求，
-
3、對下游：提供自己的預估容量，要求下游提供足夠的容量，
自身容量如何預估呢？一般是通過以下幾個方法進行：
-
1、梳理業務變化對流量影響：業務邏輯每年都在變化，進而對流量有所影響，因此要梳理去年同一大促結束到今年大促之前這段時間內的業務變化，預估其對流量的影響量，
-
2、參考往年同一大促容量值：梳理往年同一大促的流量、峰值發生時間、整體流量走勢；參考預估，沒有影響流量的業務變化的情況下（理想情況），基本可以直接用來作為預估值，
-
3、參考同年之前的大促容量值：梳理同年前一次大促的流量參考預估，對比往年兩次大促的流量比例來預估，例如，如果去年618與雙11的的流量比是1:2，那么可以將今年618的容量乘以2的值來作為今年雙11的容量預估值，
-
4、結合上游訴求：收集到所有上游的訴求保障值，總結歸納，再對比自身預估容量，一般是兩者取大，但是如果差異很大，就需要再認真核對，可能有預估錯誤或者遺漏，
對下游的訴求保障值如何預估呢？
限流
限流類似于水渠源頭的閘門，這個閘門開的大小直接決定了水渠中的水流量，將閘門開啟到一定程度，而非完全打開，保障水渠不至于被沖垮的行為就是限流，
無論有沒有擴容，無論系統是游刃有余還是苦苦支撐，都需要對系統進行限流，限流是系統的門衛，超出的容量可以被攔截在外，
我們一般都使用單機限流，即設定單臺機器最大可接受的QPS，超過則觸發限流，限流可以直接拒絕，即快速失敗，也可以排隊等待，單機限流可以進行呼叫來源應用維度的限流，可以對所有上游應用一概而論（流控應用設定為default），也可以因人而異保障主要業務（針對核心的應用限流設定較大，非核心的應用限流設定較小），
壓測
所謂壓測，就是構造資料流量通過幾臺壓力機模擬用戶持續并發請求系統介面，測驗系統的性能和承受能力的程序，
集團的壓測分為單鏈路壓測和全鏈路壓測，所謂單鏈路壓測，即自己的應用服務入口作為壓測入口進行觸發壓測，主要面對的僅限于單個應用，涉及應用少，涉及人員少，全鏈路壓測則從用戶實際操作入口作為壓測入口，這個操作涉及到的所有應用服務全部參與壓測，是一個跨部門跨應用的程序，每次全鏈路壓測，涉及到鏈路上所有團隊的協調參與共同努力，
全鏈路壓測更能反應線上真是情況，條件允許的情況下都選擇全鏈路壓測，
集團的壓測都會提前構造影子鏈路，即真實鏈路的影子，和真實鏈路一模一樣，卻又不會對真實鏈路產生影響，庫表也是使用影子表，將壓測的持久化資料與真實持久化資料分開，
壓測是一個復雜的程序，需要專業的壓測團隊的同學支撐，對于一個從未參加過壓測的應用而言，要做的作業簡要概括如下：
-
1、應用適配改造：要走通壓測鏈路，涉及改動較多，包括應用系統改造、nginx升級、中間件改造、快取端升級、DB端升級等等，
-
2、構造壓測資料：壓測資料構造需要根據具體的業務，例如價保的壓測，需要構造的壓測資料是處于價保有效期內的訂單，如果要壓到申請鏈路，還要構造優惠制造差價，
-
3、創建壓測模型：所謂壓測模型是指壓測資料的分布情況，壓測模型要能夠反應線上真實流量占比，要覆寫到所有鏈路，不同業務的流量占比等同線上真實情況，中心機房和單元機房的流量比例也要按照線上比例分配，
-
4、進行壓測：壓測分為單鏈路壓測和全鏈路壓測，單鏈路壓測是指僅僅對自己關注的系統進行壓測；全鏈路壓測是從用戶發起請求開始到整個業務邏輯結束的全部鏈路壓測，壓測入口也分為http介面壓測和端上介面壓測，具體根據系統情況而定，
-
5、觀測與總結：在壓測的程序中，要時刻盯盤，觀測系統水位，壓測后總結梳理出壓測報告，
壓測一般不是一次就能夠完成的，可能因為各種原因導致壓測結果不理想，因此要多次壓測，每次根據壓測問題進行修復后再次壓測，直到壓測結果符合預期為止，
上圖中只繪制了壓測適配原因導致的重新壓測，如前文所示擴容和限流后也要進行壓測，
擴容
如果壓測的結果，系統無法達到上游訴求，為了保證業務的順利進行，就需要擴容，并再次壓測，直到系統能夠保障目標容量，
如果壓測的結果皆大歡喜，滿足了上游訴求，那么就不需要擴容了，
預熱
預熱可簡單的理解為參賽前的熱身，讓容器、快取、資料庫等都準備好迎接大促的流量峰值，
預熱分為快取預熱和啟動預熱，快取預熱屬于大促穩定性保障作業，但是啟動預熱屬于一種日常的性能優化，
集團每年大促的商品預熱是被人所熟知的，就是將熱點商品提前加載進快取中，避免大促期間快取擊穿，流量直接打掛db的情況，這就是快取預熱，多用于大量依賴快取的應用，
啟動預熱一般是處理服務剛啟動時服務RT較大甚至超時的問題，處理方式是在啟動時通過構造引數，模擬真實請求的方式把代碼跑熱后再對外提供服務，
穩定性保障作業從時間上來說，包括日常業務需求開發時的監控告警配置和開關預留，大促前夕的容量預估、壓測、限流、擴容和預熱，其實還有一部分，上文未及提及，那便是大促值班，
建議在值班前寫一個值班手冊，將可能出現的問題，解決方案，需要使用到的工具鏈接全部羅列清楚，避免值班時手忙腳亂找資料找工具，還有必要的權限申請在值班前申請好，
在大促期間，嚴陣以待，這個時候需要做到兩動，主動關注監控大盤，注意流量變化，監控基礎設施指標；被動關注告警，一旦被告警提醒就是有例外情況了，要立刻投入定位解決，
最后，穩定性保障作業是沒有盡頭的，其重要性不言而喻，但是也要在業務功能與穩定性之間做好權衡，如果穩定性核對的呼叫流量都超過了業務流量，那么穩定性作業就有點過了，從機器成本、人力成本上都沒有這個必要，
本文整理了自己對穩定性保障的認識和理解，可能存在理解有誤或者認識不足的情況歡迎指正，也期待更多的學習逐漸修正和完善自己的穩定性相關知識，
本文來自博客園，作者：古道輕風，轉載請注明原文鏈接：https://www.cnblogs.com/88223100/p/Four-steps-to-ensure-landing-stability.html
轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/542400.html
標籤：其他
上一篇：四個步驟，教你落地穩定性保障作業
下一篇：上古神兵,先天至寶,Win11平臺安裝和配置NeoVim0.8.2編輯器搭建Python3開發環境(2023最新攻略)
