如何做好垂直域穩定性

一個小小的故障就可能造成巨大的負面影響，因此穩定性作業復雜卻又至關重要，本文將通過故障預防、修復、復盤來講解該如何建設一個穩定性體系，

來到阿里后，我的作業內容一直都是商品中心的穩定性，這份作業對于我個人在技術和經驗上的成長提升是無比巨大的，在我看來，穩定性是一個極為復雜的作業，對人的能力考驗極大，本文希望和大家一起了解：

在我看來，穩定性作業是指日常保障系統安全生產的同時，利用技術手段以及規范開發流程，使系統在不斷的業務迭代中熵增達到最小化的一種作業，作為一家互聯網公司，穩定性作業本質上就是保障安全生產，一個故障，就可能會造成很大的負面影響，舉例幾個之前有過耳聞的故障：

由此可見，集團內部的故障，輕則影響用戶體驗、商家體驗，重則對人民財產造成重大損失；因此，保障安全生產是企業發展的頭等大事，

穩定性的事情看上去可能比較散，但結合我自己的思考，我將穩定性的價值體系劃分為幾個方面：

1）日常穩定性

① 業務保障

大促保障、業務日常的答疑等等，通過這些事情，穩定性同學會與業務同學配合，從底層性能、技術層面，更好地推動業務向前發展，日常的答疑作業是穩定性同學投入時間最多的內容之一，很多問題都會第一時間流入到穩定性同學手中：

對于體量較大、較為核心的團隊，一天涌入的問題是很多的，我們的思考和處理方案如下：

2）大促 & 活動保障

穩定性另一個核心就是負責大促和重保活動，每一次大促，上到業務，下到中臺、基礎設施，都需要抽出人力進行保障，每個域的穩定性同學則是其中的中堅力量，下面我著重從流程和內容上講一下大促保障手段，可能不同同學面臨的場景不同，但整個理論應該是相通的：

① 保障流程

② 作業內容

大促穩定性保障的作業比較復雜，在這里先放一張圖，讓沒有參與過大促的同學來點體感：

雖然看起來簡單，但真實的保障程序遠比這些事情更多，面臨的壓力也比想象的大很多，即使在大促日漸常態化的今天，參與大促保障、經歷阿里千萬級復雜流量模型洗禮仍然是提高個人能力的最佳方式，

3）優化專項 & 鏈路治理

保障業務不斷發展時，由于系統不斷的迭代，必然會導致熵增，原來可能較為穩定的鏈路，會因為迭代而不斷腐化，同時，如618、雙11等大型活動，也不斷挑戰系統的極限，一句話來總結：業務發展（系統變更）不斷的挑戰著我們系統的穩定性，我們需要持續不斷的進行性能優化，保障系統的高可用，來適應越來越龐大的業務，不同的優化專項，在不同的場景下做法可能也不同，風險也會比日常的需求高很多，

① 產生變更

隨著業務不斷的迭代，不可避免地會發生變更，如更新代碼、發布配置或做運維層面的變更等，而這些變更則可能引入一些未知的問題，這些問題可能會瞬間暴露出來，或積壓一段時間后噴涌式的爆發，一般來說，后者產生的影響可能會更大一些，

② 發現問題

故障定級經常會講提前發現，如果能夠提前發現故障，不僅能降低或者避免因故障帶來的損失，也能將故障等級縮小，那么，如何主動發現由變更產生的問題？這一部分則要依賴穩定性建設時比較重要的一環 — 監控告警：

當然，監控不可能百分之百覆寫到所有的問題，也有很多問題會從其他側反饋過來，此時就要盤點出自己的監控體系中到底還有哪些疏漏，并逐漸完善，

③ 解決問題

大致為高可用問題和資料一致性問題兩類，針對不同場景有不同的解決方法，高可用問題大家可能比較熟悉了，優化起來目標也比較明確，技術難度有高有低，不詳細展開討論，

4）成本縮減

大部分的性能優化，提升系統的性能僅僅是一方面，另一個作用則是通過性能優化提高的性能壓縮技術成本，同時，效能提升也是與穩定性同學有關的一件事情，通過制定更好的開發規范以及流程，來幫助同學們提高開發體驗和作業效率，也可以將更多的時間投入在業務發展上，來進一步促進業務發展，從而形成一個良性回圈，在我個人看來，我將成本劃分為兩類：

① 效能提升 — 人力成本

人力成本受開發效率影響，效率越高，一個需求需要的人力成本就越低；影響人力成本的原因有很多，解決方案這里不繼續展開，簡單列舉幾個會影響到人力成本的因素：

② 資源管控 — 技術成本

技術成本主要分為兩類：

計算成本與存盤成本并不是完全分離開的，舉例快取，空間存盤等中間件，往往是計算（讀寫操作）與存盤并存，那核算成本的方式以長板為主，

在成本縮減中，技術成本占的比例是最高的，如何幫助縮減掉業務增長時瘋狂擴張的成本，也是穩定性同學的一個重要課題，

5）資料治理

與數倉領域的同學不同，穩定性同學很少會對資料質量去做管理，這里提到的資料治理，主要是指治理一些會影響到穩定性情況的一些資料，比如，某業務發品時，由于邏輯沒有對齊，有些情況下雖然發品成功，但是會認為發品失敗，會不斷進行發布重試，一直失敗一直重試，也沒有設定重復上線，導致同樣一個商品最多發了上百萬次，使線上某核心鏈路查詢貨商關系時大量full gc，

一句話總結：由于鏈路不合理、黑灰產、外部胡亂操作或線上問題產出的阻塞鏈路、擴大成本的大資料內容，都算作線上不合理的資料治理范圍，每年固定的時段，穩定性同學會統一對這些資料做一次治理，降低成本，提升鏈路穩定性，

來打個比方，業務同學好比前線打仗的韓信，攻占地盤，為公司創造業務價值，而穩定性的同學則是維護大后方的蕭何，為前線的同學提供保障，維持系統的穩定運行，如果業務發展不好，則公司無法維持好經營，但是如果前方斷糧，系統的性能和穩定不足以承載這么大的業務體量，那么無論業務再怎么發展，都是白費功夫，保證系統穩定安全的運行，是穩定性同學最重要的作業，穩定性的作業強度很大，同時對人的心、腦、體考驗也極大，它需要多元能力：

1）合格的技術能力

衡量一個穩定性同學是否能cover住垂直域穩定性作業的第一個重要指標，就是他的技術能力，對于技術能力要求的細節，日常要保持一直學習的心態，養兵千日，用兵一時，不能臨時抱佛腳，在此我不做過多描述，這里只放一張關于java基礎核心能力的圖供大家感受一下：

2）臨危不亂的心理素質和強大的身體素質

從事穩定性作業，不論與你是否有關，相關業務是否了解，遇到的所有問題及故障永遠都是第一處理人，因此見到的問題故障會比一般同學多出很多，同時集團對于故障處理的要求非常嚴格，這時候就需要你有強大的心理素質，身體素質自然不用多說，如果說穩定性是業務發展的“1”，那么強壯的身體則是穩定性同學需要的那個“1”，

3）熟能生巧

如果說技術能力是排查問題需要首要條件，那么熟練度則檢驗了一個穩定性同學是否足夠老成；一個問題新人定位&處理可能需要幾個小時，但是成熟的穩定性同學憑借經驗和工具可能瞬間定位到問題的根因，確定解決方法，

4）拉通 & 人際交往能力

穩定性同學大多都會參與到橫向任務，如大促保障、跨域穩定性專項等事情中來，因此，優秀的人際交往、協調，拉通的能力，也是穩定性同學需要擁有的，與其他團隊緊密協作、積極配合，也會為自己和團隊留下較好的口碑，以后推進其他事情也可以事半功倍，

1）架構設計

穩定性作業本身偏向于底層技術，對于小、中公司而言，穩定性同學的定義更偏向于“技術架構師”的角色，所以底層技術架構上的設計是穩定性防線建設的一部分，簡單舉幾個例子：

① 容量評估

什么情況下需要進行容量評估？我理解有以下兩種場景：

容量評估是架構設計中比較重要的一環，容量太多會浪費成本，容量太少則會對線上可用性產生影響，

② 部署架構 & 容災

在分布式系統大行其道的今天，容災的場景基本在集團每個應用中都可以見到，比如集團的多單元部署，現在比較常見的架構主要是由中心A地（中心 + 混部集群）和單元B地（單元 + 混部集群）兩個比較大的單元構成的，也就是所謂的“兩地”，流量從入口端進行轉發，

容災的重要性不言而喻，如果單純在一地做集群化，若遇到天災人禍等不可避免的物理損失，將會導致服務不可用，事實上也經常出現某單元由于網路運營商的問題導致服務掛掉的情況，這個時候就可以通過從入口處切換跨地呼叫來解決，

雖然多地部署的理論比較簡單，但是部署架構的一個重點在于將流量按照不同的作用去劃分分組，如上圖中的讀、寫流量分組是分離的，且讀、寫按照不同的上游業務也有單獨拆分分組，這樣就可以保證不會因為上游某一個大業務出問題導致整個集群不可用的場景出現，

當然，每個應用所面臨的場景是不同的，那么如何部署、如何容災，也是這個垂直域穩定性同學需要考慮的問題，

③ 資料一致性保證

當今的分布式系統，設計時絕大多數都會碰到異步鏈路，不管是業務上需要異步的去處理資料，還是中間件的資料同步機制，如果涉及到異步那就有可能會出現資料一致性問題，這與高可用問題分別是兩個方向，但是他們兩個本質上一樣重要，甚至資料一致性出現問題產生的影響、恢復的難度要遠大于高可用問題，

所以，在系統架構設計之初，就要做好資料一致性的保障措施，完善對賬機制，并通過建立的防線發現存量和增量的問題，每個域面臨的資料一致性問題場景不同，對于偏資料存盤的部門，往往無法完全厘清模型與模型、資料與業務之間的關系，因此防線總會有疏漏，而一旦資料出現問題，往往是最難解決的：

整個資料一致性問題是一個非常大的專題，這里只是讓大家稍微有一些體感，想要聊透這個問題需要很長的篇幅，在這里先放一張之前總結的資損防控方法圖，供大家參考：

2）監控體系

我認為監控體系的建立是穩定性防線體系建設中最重要，也是難度最大的一環，線上的系統每天都處于不斷的變化中，這種變化既來自自身的應用迭代，也來自上游業務的不斷調整，隨著時間的發展，業務的復雜度會變的越來越高，這時候就需要一個非常完善的監控機制，能幫我們快速預防和發現線上問題，如果沒有一個好的監控體系，那么維護系統穩定性根本無從談起，

雖然說起來簡單，但是要實際建立一個完善的監控體系卻是一個非常之難的事情，即使現有的監控體系非常完善，但是隨著時間的不斷推移，現有的監控必然會隨之腐化，重新完善整套監控體系需要投入很大的人力成本（比如人員流動后，原有監控的運行體系沒有交接，可能需要重新撰寫等），

如何去建立以及維護一套完整的監控體系，其中的方法比較細節，在此列舉幾個我認為比較關鍵的內容：

① 監控覆寫面

覆寫面是評判體系是否足夠優秀的第一個標準，對于業務特別復雜的介面，覆寫面越大，發現問題的概率就越高，但是對于歷史包袱較重或業務比較復雜的系統，覆寫面做到百分百是不可能的，這里我從增量和存量兩個角度討論一下如何提高監控覆寫面：

其中，可能有的存量問題鏈路較難發現，或短時間內影響面較小，導致無人關注，或者一直梳理不出來，等到某一天問題積壓爆發，這個問題在重存盤的系統中非常明顯，我們正在討論一種解決方案：資料聚合分析，即從資料共性角度，判斷出非法資料，進而判斷出非法鏈路，

② 降噪 & 健康度

降噪是在監控中最讓人頭疼的一環，估計很多同學都有過體會，大多數情況下，線上告警出的問題并不會影響線上穩定性，這種告警一旦過多，容易讓人逐漸放松警惕，當真正出現重大故障時往往不能第一時間發現，告警的有效性，就是我們常說的“監控健康度”，

很多成熟的監控產品，會將監控健康度作為一個重要的指標，當監控的告警有效性很低時，會停用監控先進行維護，關于如何進行監控降噪提高健康度，我個人經驗有如下幾點：

③ 定時統計 & 復盤

團隊內部要針對現有的監控進行定期盤點，健康度過低的監控要及時分析原因，并判斷是否可以繼續啟用，不合理的監控關掉，避免混淆視聽和增加監控成本，

3）流程規范

在日常中，相信大家不難發現，一些大故障，往往都有幾個共性：

因此，嚴格的流程規范，會幫助我們及時發現和避免很多本不應該有的故障，當前阿里集團的安全生產團隊已經將常見的幾乎所有變更流程都進行了管控，內部如Aone、ChangeFree等平臺已經進行了嚴格的平臺化的規范，只要遵循線上正常的發布流程并加以防范，基本上不會出現特別大的故障，簡單說一下我認為比較關鍵的幾個流程：

每個應用根據自己不同的情況都會有不同的卡點，不同的應用可能有自己的卡點平臺，這些也可以通過對接Aone集成進去；至于灰度發布，大家都很熟悉了，這里就不展開討論了，

4）混沌工程

建立完自認為完美的防線之后，肯定需要校驗可用率，但是總不能通過等著線上出問題來檢驗防線是否生效，這樣成本就太高了，此時就需要引入混沌工程，相信大家應該都很了解混沌工程了，那么就在這里貼一下相關的定義：

混沌工程在阿里集團內部的體現為故障演練，基本不需要部門內部自行操作，比較出名的有每年集團都會舉辦的紅藍演練，以及日常經常發生的生產突襲、斷網演練等，

故障注入的平臺，演練時一般使用集團內部比較出名的MonkeyKing，具體的使用方法這里不表，市面上有很多開源的混沌工程平臺，原理都是類似的，

① 問題分類

針對不同種類的問題，有不同的注入和恢復機制 ，不詳細展開了，上一張分類比較好的大圖：

② 演練機制

整個故障演練機制分為四個部分，基本上也是所有混沌工程的思路：

即使防線建設做的再好，但是人難免會有疏漏，不存在能百分之百攔截故障的防線，如果故障已經發生，那么當前的重點就應該是快速止損并恢復，

從發現、處理到復盤，阿里集團有一套完整的SOP，整個處理流程非常的規范，同時，阿里集團對于高可用故障恢復的時間要求非常高，一般來說是1-5-10，即一分鐘發現，五分鐘止血，十分鐘恢復，不過肯定不是所有的故障都能嚴格達到這個高標準，但是處理速度當然是越快越好，避免故障升級，

那么下面就從定位、止血、恢復這三個階段來講述一下快恢中具體要做的事情：

1）快速定位

很多同學第一次面對問題或者故障時，往往頭腦空白不知從何查起，如果碰到大故障時，很多主管在后面圍觀，心情則會更加緊張，進一步拖慢了查問題的時間，那么如何對線上的故障和問題進行快速定位呢？

首先，在定位問題之前，要快速的確認是不是屬于本域的問題，很多時候問題的表象看似出自于自己的應用，但實則可能是上下游、中間件或者硬體問題引起的，如果方向錯誤，可能會拖延故障的處理時間，放大線上影響和故障等級，那么如何快速定位，我認為可以從變更的角度去入手思考：

本域是否發生過變更？這個是最核心的判斷因素之一，

如果沒有，那很大可能跟本域的關系不大，請注意，這個變更不僅僅是通常理解上的代碼發布、配置推送、資料操作等，而是所有可能會對線上的運行環境產生影響的操作，如代碼中的配置推送，上下線或置換容器等；當然，并不是說沒有變更就完全沒關系，有些情況也有例外，舉幾個常見的例子：

如果發現存在變更，那么要結合大盤，判斷故障的時間線是否與變更的時間線吻合或相差不大，如果是的話那么就八九不離十了，

在定位到產生問題的域后，如果不是自己的問題，那么可以盡量協助排查，如果是域內產生的問題，那么就要著手開始定位根因，這個時候就是考驗穩定性同學的基本功和經驗了，同時也要結合集團給出的一些比較好的產品化工具，例如：

① 監控大盤

常見的監控系統有很多，一些開源的監控大盤讓我們面對大多數問題時基本不需要去機器上命令列排查了，對于不同的場景，用對了監控可以事半功倍，

阿里內部有各種各樣的大盤，可以讓集團的同學在處理問題時的速度更快，同樣部分開源的大盤也非常強大，至于如何做產品選型，大家可以自行評估，思路大概就是如下幾種大盤：

② 分布式日志系統

對于一些代碼層面或業務層面的報錯，單純通過大盤進行深度定位是不現實的，究其根因還是要到底層去查日志報錯堆疊，這個時候就需要用到分布式日志系統了，通過分布式日志系統采集的資訊，可以配置相應的大盤，或直接搜索錯誤堆疊，進行細節上的排查，

2）快速止血 & 恢復

之前將問題劃分為高可用以及資料問題，那么也按照這個分類來講一下對應的止血 & 恢復策略：

① 高可用問題

止血與恢復在高可用問題上，大多數情況是相關聯的，止血即恢復，如：

同時，相信大家都接觸過高可用問題，對于這類問題的快恢也有一定的了解，限于篇幅原因這里就不再一一描述不同高可用問題的恢復策略了，直接在這里參考和拓展一下之前總結過的高可用問題快恢六招：

② 資料問題

資料問題與高可用問題有非常大的差異，高可用問題恢復起來較為簡單，通常有比較明確的策略，但資料問題則不同，我將其分為兩類：

其中，資料計算錯誤的恢復策略較為簡單，可以直接通過熔斷、切流等機制關閉增量問題來源來進行恢復止血，資料問題真正的難點在于存盤錯誤，非持久化的資料存盤，如快取，可以通過熔斷增量問題入口，清除存量資料來解決，但是一旦持久化的資料臟掉且量級非常大的話，從資料的提取到資料的回滾都非常的困難：

因此，資料存盤問題或我們常見的資損問題，往往主要關注的不是恢復時間，而是主動發現率、止血時間、資損金額等，因為要快速恢復量級很大的資料存盤問題是不現實的，往往都是依賴人為提取資料以及手動恢復，事實上針對資料存盤問題，也沒有系統能做到通用化的資料回滾策略，因為每個業務、每個系統的提取資料，回滾資料的邏輯基本都是不同的，如果依賴平臺通用邏輯回滾，那么二次故障的概率會非常高，所以說，對于資料存盤問題，要做到第一時間通過熔斷、切流等機制止血后，在優先保證資料絕對正確的情況下，再進行回滾恢復，不能盲目的追求恢復時間，

1）復盤 & Action 跟進

每一次故障都是血的教訓，但是以我的視角來看，發生故障并不完全是一件壞事，因為應用系統是人造就的，是人就一定會犯錯，所以系統也不可能保證百分之百的強壯，有問題則證明系統、流程還有不足，才能推動我們不斷的向前進步，這也是我們每一次故障之后要進行復盤的原因，犯了錯并不怕，重要的是如何改正，

集團對于故障的復盤有一套嚴格的執行流程，大概如下圖所示：

具體詳細的復盤流程不詳細展開，談談我認為復盤這個節點比較重要的幾個問題：

① 三省吾身

無論是自己，亦或是團隊其他同學導致的故障，一定要問自己幾個問題：

② Action 落實

很多時候，我們都只局限在“這一次”的故障中，而不會去思考“每一次”，在我看來，Action真正的作用，不只是為了單純的解決這一次的問題，而是要我們舉一反三，從根因上思考，系統中是否還存在與這次故障相同的問題？我們要如何分類的去解決，這樣才能真正的將這一次故障的效應和Action發揮最大的作用，

2）穩定性分享

除了穩定性的技術建設，文化宣導也是基礎建設的一部分，

除了故障方面，穩定性同學所做的底層優化專項等偏向于技術層面的作業，也可以在團隊內部或跨部門做分享，建立工程師文化，培養技術興趣，以及擴大部門和團隊在集團中的影響力，以我所在的商品團隊舉例，每月都會舉行一次“工程師之夜”的分享會，包含技術、業務模型等比較有代表性的作業成果，同時團隊內部優秀的同學也會經常跨域去做技術分享，

穩定性作業遠比文章里的內容要復雜的多，每一個單點拉出來，都能形成一篇文章去介紹，限于篇幅問題，無法將穩定性所有的內容表達出來，這里將我過去幾個月的思考和大家分享，歡迎一起交流評論，最后，也向所有從事穩定性作業的同學致敬，希望各位都能在其中獲得自己想要的成長和識訓，