1 前言

2 什么是系統(tǒng)穩(wěn)定性

2.1 學術定義

2.2 工程實踐定義

2.3 量化指標定義

2.4 另一種角度的定義

3 為什么要進行穩(wěn)定性建設

4 穩(wěn)定性建設面臨的困難

4.1 資源投入難以找到平衡點

4.2 穩(wěn)定性建設本身存在較高的復雜度和風險

5 怎么進行穩(wěn)定性建設

5.1 達成穩(wěn)定性建設資源投入共識

5.2 明確穩(wěn)定性建設的目標

5.3 意識的培養(yǎng)

5.4 完備的生產規(guī)范

5.5 有效的監(jiān)控預警

5.6 應急響應機制

5.7 加強日常巡檢和階段性復盤

6 后記

注：本文很多理論參考了得物技術公眾號的這篇文章商家域穩(wěn)定性建設之原理探索，本文是基于這篇文章的思考及近半年團隊內對于穩(wěn)定性建設的實踐總結而成。

1.前言

系統(tǒng)的穩(wěn)定性建設是一個龐大的話題，其貫穿了產品研發(fā)整個流程：需求階段、研發(fā)階段、測試階段、上線階段、運維階段。從系統(tǒng)規(guī)模上看，小到單個系統(tǒng)，大到一個域的系統(tǒng)集，再大到支撐整個公司全業(yè)務的系統(tǒng)全集，都離不開系統(tǒng)穩(wěn)定性建設。大家日常工作中可能會有一些關于系統(tǒng)穩(wěn)定性的疑惑，比如經典三問“是什么、為什么、怎么做”，今天我從一個后端研發(fā)的視角，來和大家聊一聊系統(tǒng)穩(wěn)定性建設的總結與思考。

2.什么是系統(tǒng)穩(wěn)定性

聊系統(tǒng)穩(wěn)定性前，得知道到底什么是系統(tǒng)穩(wěn)定性，讓我們看看其定義。

2.1 學術定義

系統(tǒng)在指定邊界條件下維持其服務質量（QoS）的能力，包括在預期負載、異常輸入或部分組件失效時，依然能提供符合SLA約定的服務級別。

這個定義有些晦澀，大家可能有點不容易理解，來看一下工程實踐上的定義，從不同維度給出具體的說明。

2.2 工程實踐定義

服務持續(xù)性：在硬件故障、網絡抖動、突發(fā)流量等異常情況下保持服務可用。性能穩(wěn)定性：99分位延遲不出現(xiàn)劇烈波動（如P99 < 500ms且抖動幅度<15%）。狀態(tài)可預期：系統(tǒng)行為符合"墨菲定律"預期（任何可能出錯的地方終將出錯，但系統(tǒng)有預設應對方案）。故障可降級：具備優(yōu)雅退化（Graceful Degradation）能力，如購物車可獨立于推薦系統(tǒng)運行。

2.3 量化指標定義

圖片

SLA ：這里指可用性SLA，也就是常說的N個9，以常說的4個9為例，按全年時間計算，服務只允許4.3h不可用。MTBF：Mean Time Between Failure，平均故障間隔時間=總運行時長/故障次數。指系統(tǒng)在相鄰兩次故障之間的平均正常運行時間，單位為小時（h）。它反映系統(tǒng)的可靠性，數值越高說明故障率越低、穩(wěn)定性越強。MTTR：Mean Time To Repair，平均修復時間=故障修復總時間/故障次數。指系統(tǒng)從故障發(fā)生到完全修復所需的平均時間，包括問題診斷、問題修復、測試驗證、上線驗證等全流程。數值越低，說明系統(tǒng)恢復能力越強。

從上面不同維度的定義可以知道，系統(tǒng)穩(wěn)定性，追求的系統(tǒng)運行過程中少出問題，取決于兩個點，一個是系統(tǒng)風險，另一個是風險發(fā)生后的應對能力。也就是說，可以將穩(wěn)定性簡化為一個公式：穩(wěn)定性 = 系統(tǒng)風險(概率) * 風險應對能力。

圖片

2.4 另一種角度的定義

穩(wěn)定性 = 系統(tǒng)風險(概率) * 風險應對能力。

咱們繼續(xù)拆解，對于系統(tǒng)風險，又分為固有風險和變更風險。固定風險一般指運維關注的網絡問題、服務器問題、容器環(huán)境相關問題；變更風險指隨著業(yè)務迭代對系統(tǒng)進行的功能上線、配置更新等人為操作引入的動態(tài)風險。運維團隊更多關注固有風險，研發(fā)技術團隊，更多關注變更風險部分。繼續(xù)拆解變更風險，可以得到：

變更風險=變更頻率 * 變更復雜度 * 變更爆炸半徑（影響范圍）變更頻率：變更次數越多，風險越大，一般和業(yè)務需求迭代頻率正相關。變更復雜度：包含業(yè)務本身的復雜度，代碼實現(xiàn)的復雜度，配置的復雜度。一般來說，復雜度越高，單次變更出問題的概率也越大。變更爆炸半徑：也叫變更影響范圍，表示發(fā)生問題后的影響面，直接影響實際的損失。

風險應對能力，分為風險發(fā)生前應對能力和風險發(fā)生后的應對能力。風險發(fā)生前：能不能發(fā)現(xiàn)，以及發(fā)現(xiàn)后能不能及時消除風險。風險發(fā)生后：能不能更快發(fā)現(xiàn)，以及發(fā)現(xiàn)后能不能及時修復。

風險處理能力 = 風險前置發(fā)現(xiàn)概率 * 前置風險處理 * 后置風險發(fā)現(xiàn)時長 * 風險應急處理

綜上能得出一個拆解后的穩(wěn)定性公式：

穩(wěn)定性 =（固有風險 + 變更頻率 * 變更復雜度 * 變更爆炸半徑）（風險前置發(fā)現(xiàn)概率 * 前置風險處理）（后置風險發(fā)現(xiàn)時長 * 應急效果）

這個公式將作為后續(xù)問題分析和實踐的理論基礎，所有的穩(wěn)定性建設，都會圍繞著這些指標進行對應策略的制定。

3.為什么要進行穩(wěn)定性建設

為什么系統(tǒng)穩(wěn)定性如此重要呢，系統(tǒng)的穩(wěn)定性是支撐業(yè)務發(fā)展的那個1，沒有這個1，后面再多的0，都將毫無意義。系統(tǒng)穩(wěn)定性差，會帶來的影響有：直接的經濟損失：比如系統(tǒng)出現(xiàn)問題，導致訂單減少，金額出錯等，阿里前段時間出現(xiàn)的轉賬打8折問題，就造成了重大的直接經濟損失，這都是最直接的真金白銀損失。專業(yè)性會受到質疑：小到個人和團隊，大到公司，形象都會受到影響。對公司而言，大的事件可能變成輿論危機，對企業(yè)品牌形象帶來負面影響。相反，穩(wěn)定性好，自然就會降低直接的經濟損失，也會傳遞出企業(yè)更專業(yè)的正面形象。除了這兩點，對于業(yè)務支撐的技術團隊，整體迭代效率會大大提高。為什么呢，因為系統(tǒng)穩(wěn)定，花在堵洞上的精力就會大大降低，可以將更多精力投入到業(yè)務迭代上。

4.穩(wěn)定性建設面臨的困難

對于技術團隊而言，每個人都知道系統(tǒng)穩(wěn)定性的重要，但落地起來又非常難。有個詞叫“bug驅動”，意思是平時只關注支撐業(yè)務發(fā)展，很多問題暴露不出來，bug出現(xiàn)后，驅動技術人去關注代碼質量、流程規(guī)范等這些。為啥需要等bug出現(xiàn)呢，因為很多時候穩(wěn)定性建設相關事項會被評定為“重要不緊急”，既然不緊急，就先緩緩再建設，緩到啥時候呢，緩到出現(xiàn)問題，然后bug驅動。究其核心原因，有以下方面：

4.1 資源投入難以找到平衡點

對于技術團隊而言，支撐業(yè)務迭代和進行穩(wěn)定性建設的資源投入，很難找到平衡點。先說第一種情況，穩(wěn)定性建設投入少，那系統(tǒng)質量肯定無法長期保證，高速支撐業(yè)務的同時，系統(tǒng)各種潛在風險隱患逐漸積累，到了臨界點，肯定會以bug或事故的形式出現(xiàn)在技術眼前。再說第二種情況，穩(wěn)定性建設方向有充足的投入，短期內又很難用可量化的指標體現(xiàn)收益，不僅無法給業(yè)務證明其價值，甚至技術內部，短期都很難看出明顯效果。業(yè)務體感上只會覺得迭代速度慢了，他們在想，為什么不能更快的進行迭代上線呢，此時在項目優(yōu)先級及排期上，就很難說服業(yè)務，業(yè)務出于壓力，肯定會將業(yè)務迭代優(yōu)先級提高，壓力自然就會透傳到技術團隊。

4.2 穩(wěn)定性建設本身存在較高的復雜度和風險

根據第一部分的公式可知，穩(wěn)定性建設核心是識別風險、治理風險、預防風險，對于這每一部分，都不簡單。

4.2.1 存量風險識別的難度

如果靠上文說到的“bug驅動”當然也是一種識別風險的辦法，只是比較滯后，不符合穩(wěn)定性建設預期。為了能防范于未然，需要主動去發(fā)現(xiàn)系統(tǒng)的風險，并想辦法解除風險。前面說了，穩(wěn)定性建設覆蓋的系統(tǒng)范圍可大可小，想要評估出其中的潛在風險，這就涉及對全范圍系統(tǒng)代碼和業(yè)務的梳理，工作量和難度可想而知。

4.2.2 風險治理的難度

比如說現(xiàn)在風險已經識別出來了，進入到了第二步治理，也有困難，比如：1.資源問題：評估風險治理成本為一個月工期，能否給到正常的排期。2.引入風險：治理過程中，怎么保證不給系統(tǒng)引入新的問題。很多時候，系統(tǒng)的狀態(tài)其實和風雨中的危房差不多，而風險治理，不是簡簡單單在旁邊建一套新的，人搬過去就行，而是需要在維持房屋不倒的情況下，逐漸把房子各個地方修一遍，這個過程稍有不慎，可能就會砸到承重墻，后果就是房屋塌了。為了維修房子結果把房子弄塌了，這是不行的。3.治理執(zhí)行：本身執(zhí)行治理方案時也會有難度，比如常說的技術債，對于一套業(yè)務迭代多個版本，代碼經手N個研發(fā)之手的系統(tǒng)而言，不同的代碼風格以及大量為了解決短時問題而寫的if充斥在整個系統(tǒng)中，對于這樣的系統(tǒng)，給出一套合理的治理方案本身就很難。

4.2.3 增量風險預防的難度

增量風險主要來源于系統(tǒng)的變更，最主要的場景就是業(yè)務需求的迭代和技術側的系統(tǒng)優(yōu)化。1.發(fā)生變更時，各方理解是否能達成一致，比如研發(fā)、測試和產品，對于變更的理解如果不一致，就會引入新風險。2.變更方案是否可控，如果保證方案最終能和預期一致，如果不一致，就會引入新風險。3.人員的可靠性，前兩步都一致了，但是研發(fā)在開發(fā)時粗心，代碼寫法上有問題，測試在驗證時粗心，剛好跳過了這條case，就會引入新風險。

5.怎么進行穩(wěn)定性建設

上面列舉了系統(tǒng)穩(wěn)定性建設的種種困難，前面說過，系統(tǒng)穩(wěn)定性建設本身是一件重要的事，所以不管有多少困難，該建設還是需要建設的，那么面對這種種困難，如何進行穩(wěn)定性建設呢？介紹建設具體方案前，先討論一個問題，系統(tǒng)穩(wěn)定性建設到底建設的什么？

通過第一節(jié)的公式可以將穩(wěn)定性建設分為三個方向，然后根據每個方向的具體影響因素指標，可以找到對應的建設思路。

圖片

5.1 達成穩(wěn)定性建設資源投入共識

從上面的分析可知，系統(tǒng)穩(wěn)定性建設排在第一位的困難是資源問題，那么想解決穩(wěn)定性建設問題，首先技術內部要對系統(tǒng)穩(wěn)定性建設投入多少資源達成一致，比如占團隊總工作量的多大百分比。這個百分比，不同的團隊不同的業(yè)務階段，都可能不一樣，需要針對本團隊業(yè)務的重要性、發(fā)展階段、風險情況進行綜合評估，確定穩(wěn)定性建設在本團隊中的重要程度，依據這個重要程度逐漸調整這個投入占比值。

現(xiàn)實中，很多業(yè)務開發(fā)團隊，對于這個大前提是沒有共識的，就是既沒有相關資源的投入又想要系統(tǒng)穩(wěn)定的結果，這個是不合理的。比如經常會遇到研發(fā)吐槽，技術設計方案、代碼CR不給時間，為了上線deadline，極致壓縮開發(fā)、測試排期，然后又要保證上線質量，這本質上是沖突的。

沒有資源投入，一切都是空中樓閣。系統(tǒng)穩(wěn)定性建設的投入共識，研發(fā)內部達成共識后，還要和業(yè)務團隊充分溝通，取得他們的共識，在需求迭代速度和系統(tǒng)穩(wěn)定性建設的資源分配上，共同探索一個合理的平衡點。

5.2 明確穩(wěn)定性建設的目標

穩(wěn)定性建設的目標，不同的階段可能不同，選取的考量指標也可能動態(tài)變化，比如年度技術三級事故不能高于M個，月度技術online問題不超過N個，再或者直接用系統(tǒng)4個9作為考量指標，都可以。明確了目標后，需要根據大目標拆解為階段性的小目標，以及根據目標制定出切實可行的落地方案。

結合穩(wěn)定性建設思路思維導圖會發(fā)現(xiàn)，其最終建設思路落地取決于“人”和“機制”兩個方面，人去落地相關事項，機制用于保障和托底落地效果。接下來咱們看看各個思路如何具體的進行落地。

5.3 意識的培養(yǎng)

前面介紹提到系統(tǒng)穩(wěn)定性建設依賴的是人來執(zhí)行，人員的主觀意識決定了建設的落地難度和最終效果。這里主要包含三個方面：認知、意愿和能力。1.認知：團隊成員是否充分理解系統(tǒng)穩(wěn)定性的重要。實踐建議就是，平時周期性提醒，典型問題重點強調，嚴重問題復盤總結，來逐漸加強大家對于穩(wěn)定性重要性的認知。2.意愿：團隊成員是否花時間和精力去評估和解決穩(wěn)定性風險（前提是有資源分配的情況下）。評估穩(wěn)定性風險需要深入細致的梳理系統(tǒng)代碼邏輯業(yè)務流程等，對耐心、細心都是考驗，有時候可能覺得麻煩就簡化或者不做了，就會帶來潛在風險。實踐建議：對表現(xiàn)好的，激勵當榜樣，對表現(xiàn)不好的，一方面制定適當的懲罰措施，另一方面階段性的用二次檢查機制托底，降低風險。3.能力：團隊成員是否能識別風險并找到解決方案。在認知和意愿沒問題的情況下，這部分屬于人員個人能力的提升范疇，方式方法很多。比如組內相互分享學習，遇到問題請教其他同學等，都可以。

5.4 完備的生產規(guī)范

一次系統(tǒng)變更（業(yè)務需求迭代或技術優(yōu)化）一般包含：需求評審、技術方案評審、編碼自測、用例評審、測試、CR、驗收、上線、線上驗證等環(huán)節(jié)。在實際項目推進過程中，嚴格執(zhí)行項目流程規(guī)范需要投入的時間可能會更多，時間成本上考慮，可能會根據項目規(guī)模、特征等因素對流程環(huán)節(jié)進行一定程度的精簡。從結果上看，有時候項目也沒出什么問題，久而久之，很多人會覺得流程規(guī)范價值不大，會降低整體效率。其實不然，項目流程規(guī)范是保障系統(tǒng)穩(wěn)定性的重要措施。每一個環(huán)節(jié)都有對應的執(zhí)行規(guī)范，下面著重介紹和研發(fā)密切相關的幾個環(huán)節(jié)。

5.4.1 技術方案評審

技術方案評審環(huán)節(jié)分兩個方向，一個是是否進行了技術方案評審，第二個是技術設計和評審的質量。1.嚴格執(zhí)行技術方案評審：對于開發(fā)周期大于N(根據不同團隊對流程要求的實際情況定，我們團隊是3人天)人天的項目，盡量有技術方案設計及評審環(huán)節(jié)，低于N人天的，可以根據復雜度、變更影響范圍等評估是否需要。

很多團隊只有那種大型項目，才會有詳細的方案設計和評審，對于普通周級別的迭代，需求評審完后，研發(fā)簡單梳理一下上下文，就直接拉分支進入開發(fā)階段。這種做法對于某些特定情況有deadline上線日期的中小項目，可以這么做，但一直這樣不重視技術方案設計，隨著時間的積累，可能就會引入穩(wěn)定性風險。2.評審關注點主次分明：技術方案的重點要放在架構的合理性、可擴展性，系統(tǒng)的高性能高可用這些方向上，而不僅僅是實現(xiàn)業(yè)務訴求需要的表和接口設計。模塊最終的研發(fā)人，既需要關注宏觀層面的架構合理性又需要關注業(yè)務實現(xiàn)中的相關細節(jié)，對于參與評審的其他人，更重點的關注點需要放到架構合理性、擴展性這些宏觀層面的項上。3.參與人要求：關于參與技術評審的人是有要求和限制的，對本次變更模塊以及關聯(lián)模塊比較熟悉的研發(fā)人員，盡量參加把關，能輔助更好的評估變更風險影響范圍。4.關注點清單：對于技術評審，需要有沉淀下來的關注點清單列表，輔助評審參與人提出通用性的相關問題。對于業(yè)務研發(fā)而言，系統(tǒng)變更遇到的絕大部分問題，都是重復問題，也就是說業(yè)內其實有通用思路和解決方案的。哪些是和業(yè)務無關的具有通用屬性的關注點呢，比如：接口的限流、熔斷、降級、超時、重試、版本兼容，為降低變更影響范圍的隔離（環(huán)境隔離、數據隔離、核心業(yè)務隔離、讀寫隔離、線程池隔離）等，這些關注點就需要在技術評審階段重點關注。

5.4.2 代碼Review階段

研發(fā)環(huán)節(jié)，CR是保障穩(wěn)定性的重要措施。這個環(huán)節(jié)該如何保證質量呢，有如下建議：1.不CR不上線：不經過Review的代碼不要上線，這是行業(yè)無數線上事故教訓后得出的建議，大家一定不要心存僥幸。這個可以通過流程上的規(guī)范限制進行強約束，比如我們的發(fā)布平臺可以設置上線前必須CR，也可以根據系統(tǒng)設置定向CR的人，否則不能進入到沙箱部署。2.代碼風格統(tǒng)一：要有團隊自己的整體代碼風格，統(tǒng)一一套編碼規(guī)范，這樣可以極大的提高CR效率。3.善用工具：善用工具發(fā)現(xiàn)代碼中的基本問題，比如用掃描工具發(fā)現(xiàn)代碼中潛在的NPE，工具比肉眼強無數倍。比如我們的發(fā)布平臺就集成了Sonar掃描功能，壞味道和bug不修復完是不允許部署沙箱的。4.不過度關注細節(jié)：CR過程不要陷入細節(jié)，關注整體風格和寫法，以及性能、安全等通用關注項。對于很多參與CR的人而言，短時間內需要了解業(yè)務需求上下文細節(jié)，然后判斷代碼實現(xiàn)是否正確，這難度是很大的，所以大部分場景CR的是代碼基礎風格和通用問題。5.時長限制：控制單次CR時長，盡量不超過2小時，否則后半程大家精力容易分散，難以發(fā)現(xiàn)問題，降低整體CR質量。6.端正CR心態(tài)：先要明確CR的目的是為了找出代碼存在的隱患降低系統(tǒng)風險。如果作為被CR的人，放平心態(tài)，CR是一個很好的學習機會，發(fā)現(xiàn)不足及時學習，不要在CR時極力證明這種寫法也沒問題，偏離主題。作為主CR的人，也不要以挑刺和為難的心態(tài)去CR，不是為了證明誰強誰弱，只討論方案和實現(xiàn)的合理性就可以了。

5.4.3 上線階段

上線過程是線上問題爆發(fā)的高發(fā)期，為什么呢，這個過程涉及系統(tǒng)部署，數據更新，配置變更，以及變更過程中中間態(tài)的問題，任何一個環(huán)節(jié)出錯，可能整個上線就失敗了。一般上線需要做到三個點：可監(jiān)控，可灰度，可回滾。1.可監(jiān)控：上線過程中相關指標的監(jiān)控，包括業(yè)務指標和技術指標，比如訂單量在上線期間是否有大的波動，接口可用率是否下降了，CPU、磁盤、網絡、異常日志這些是否正常等。這個每個公司都有自己的監(jiān)控平臺，我們有很完善的監(jiān)控系統(tǒng)Grafana平臺，上線過程就需要觀察相關指標，比如：業(yè)務指標變化情況：

圖片

異常日志情況：

圖片

2.可灰度：灰度主要是為了降低變更影響范圍，一旦出問題，也可以將問題限定在可控范圍?；叶瓤梢詮募夹g維度進行：機器、機房、區(qū)域等維度；也可以從業(yè)務維度進行：按用戶、按商家、按品類等。3.可回滾：發(fā)現(xiàn)問題及時止損最快的方式就是回滾?；貪L有兩種類型：代碼回滾和數據回滾。代碼回滾可以通過開關控制或者部署上一個版本的代碼實現(xiàn)。數據回滾指上線過程中，產生了中間態(tài)的臟數據，需要將數據回滾到正確狀態(tài)。

總結一下就是，灰度上線，上的過程眼睛緊盯各項指標是否有異常，發(fā)現(xiàn)問題，先回滾止損，再定位及修復問題。

如果系統(tǒng)順利上線，就進入到了風險后置處理環(huán)節(jié)，這個階段主要包括：發(fā)現(xiàn)問題、響應問題、解決問題、復盤問題四個部分。這個階段，除了復盤問題外，其他三個環(huán)節(jié)都和時效性強關聯(lián)，發(fā)現(xiàn)問題、響應問題、解決問題的快慢，都直接影響系統(tǒng)穩(wěn)定性，慢就可能將影響和損失擴大。

5.5 有效的監(jiān)控預警

業(yè)務反饋問題是發(fā)現(xiàn)問題的一種途徑，但如果等到業(yè)務反饋，時效性就非常滯后了，對用戶已經產生了影響，這是技術不愿意看到的。監(jiān)控預警核心作用是為了及時發(fā)現(xiàn)風險，將風險影響范圍降低。針對監(jiān)控預警，有這些建議：1.預警要全而精。全指的是對于核心業(yè)務的核心節(jié)點，都需要有相關監(jiān)控預警，不能遺漏，指標分為技術指標和業(yè)務指標。精是指監(jiān)控預警不是越多越好，預警過多很可能造成預警噪音，對產生真正影響的預警產生干擾。2.善用各種監(jiān)控預警工具。實際工作中發(fā)現(xiàn)，很多必要的監(jiān)控缺失，這樣的話，系統(tǒng)屬于無看管狀態(tài)，感知問題自然會很滯后。3.核心業(yè)務定向監(jiān)控。在監(jiān)控工具不能滿足訴求的情況下，要自主開發(fā)監(jiān)控小工具，比如業(yè)務數據校對監(jiān)控預警這種，監(jiān)控平臺系統(tǒng)層面很難有定制化的功能。

我們團隊內部關于監(jiān)控屬于兩者結合，有平臺工具監(jiān)控，這一類比如系統(tǒng)層面的日志、網絡、數據庫、線程池、接口響應率等。也有自定義的業(yè)務監(jiān)控，針對特定業(yè)務指標進行的監(jiān)控。預警方式多樣：郵件、企業(yè)微信、短信。

任務執(zhí)行異常監(jiān)控預警

圖片

業(yè)務操作異常預警

圖片

服務間接口調用監(jiān)控預警

圖片

error日志及慢sql監(jiān)控預警

圖片

特定業(yè)務數據監(jiān)控預警

圖片

5.6 應急響應機制

對于線上問題一般有三種來源：自主發(fā)現(xiàn)、業(yè)務反饋、監(jiān)控預警。不管哪一種渠道發(fā)現(xiàn)的線上問題，都需要有一套響應機制來應對，核心就是降低影響和損失。出現(xiàn)問題該如何響應呢，提供以下建議：1.響應要及時:第一時間關注并推進問題解決，要對線上問題抱有敬畏之心。2.保留問題現(xiàn)場:方便后續(xù)排查和定位問題。3.信息及時同步：同步相關問題信息和跟進進度給相關人員，比如leader、業(yè)務、關聯(lián)方。4.影響評估及止損：和業(yè)務一起評估影響，如果產生實際損失，優(yōu)先恢復服務，及時止損。恢復服務常用方法：回滾，重啟，擴容，禁用節(jié)點，功能降級等。盡快止損是應對線上問題的第一優(yōu)先級，如果其他環(huán)節(jié)和這個有沖突，比如保留現(xiàn)場會延長影響時間繼續(xù)產生損失，先犧牲掉現(xiàn)場，優(yōu)先止損，事后再想辦法復現(xiàn)問題進行定位。5.二次確認：服務恢復后，要繼續(xù)關注技術指標和業(yè)務指標一段時間，確認是否正常。

如何定位問題原因呢，需要從這幾個方向出發(fā)：1.充足的知識儲備：對于相關問題，如果沒有相關知識打底，是很難找出問題的，比如分析并發(fā)問題但是對并發(fā)編程并不熟悉，就很難找到問題根源，只能靠猜。2.善于使用各種輔助工具：比如日志平臺、鏈路追蹤、各種監(jiān)控工具、JVM性能診斷工具等。3.合適的方法：針對不同的問題，可能分析思路和方法不一樣，需要根據實際場景動態(tài)決策。比如有的直接看日志就可以判斷問題根源，有的需要測試環(huán)境復現(xiàn)，有的需要將問題逐步縮小范圍再排查等。

5.7 加強日常巡檢和階段性復盤

除了上面介紹的預防和應急方法，還有一點很重要，就是日常定期檢查，長期關注系統(tǒng)穩(wěn)定性，比如系統(tǒng)的慢SQL，偶爾的接口超時，死信消息等，一定要慎重對待，持續(xù)跟進，定期治理，防范于未然永遠好于臨時救火。

對于典型問題和嚴重事故，要重點復盤，總結經驗教訓，避免同類型問題再犯。無事故情況下，也需要定期進行階段性復盤總結，通過回顧目標，評價結果，分析原因，總結經驗這幾步，沉淀經驗，變成知識庫，方便后續(xù)組內分享學習。

簡單總結一下，系統(tǒng)穩(wěn)定性建設是一件任重而道遠的事，要取得好結果，需要基于資源的合理投入為前提，通過提升團隊穩(wěn)定性意識，健全相關機制和流程，雙管齊下。過程中不過于激進，平穩(wěn)安全的進行螺旋式建設，重視總結和優(yōu)化，逐步完善穩(wěn)定性建設的各個方面。長期堅持，某一天就會發(fā)現(xiàn)，已經取得了明顯的治理效果。

6.后記

穩(wěn)定性建設是一項龐大且系統(tǒng)的工程，涉及生產流程的各個環(huán)節(jié)，想把系統(tǒng)穩(wěn)定性建設做好，不是一蹴而就的，需要長期持續(xù)的付出努力。建設治理的過程是艱難和漫長的，流程機制會不停的升級進化，咱們在過程中也就慢慢成長了。對于任何一個還在持續(xù)運行和迭代的系統(tǒng)而言，系統(tǒng)穩(wěn)定性建設就像是一場長期革命，革命尚未成功，同志仍需努力，任重而道遠！

作者介紹

楊迎，轉轉寄賣后端研發(fā)工程師，目前負責綜合履約方向業(yè)務開發(fā)。