一、穩(wěn)定性及其意義

    1.什么是穩(wěn)定性？

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

    3.穩(wěn)定性建設究竟要建什么？

二、穩(wěn)定性建設面臨什么困難？

    1.穩(wěn)定性建設缺少立竿見影的短期價值

    2.穩(wěn)定性建設存在極大的復雜性和風險

三、如何進行穩(wěn)定性建設？

    1. 建立穩(wěn)定性共識

    2.明確穩(wěn)定性建設目標

    3.落地穩(wěn)定性建設任務

    4.穩(wěn)定性建設的困難是否都被解決了？

四、穩(wěn)定性建設全景圖

一、穩(wěn)定性及其意義

什么是穩(wěn)定性？

我們先來探討一個核心概念：穩(wěn)定性 。想象一下，一個系統(tǒng)、一個物體或一個過程在受到外部干擾或內部變化時，能否如一面堅實的墻壁，屹立不倒？在信息系統(tǒng)的世界里，穩(wěn)定性的定義就如同這面的墻壁，它確保在各種干擾面前，我們服務依舊保持可用。

然而，盡管這個定義聽上去很清晰，若要用它來推動我們的穩(wěn)定性建設，卻顯得有些模糊。因此，我們需要深入探討如何將這一概念轉化為切實可行的方法論。

我們將方法論定義為影響結果的公式，并為穩(wěn)定性寫下了如下公式：

穩(wěn)定性 = 全局風險可見性 * 風險轉化概率 * 故障可感知 * 預案可靠性

但隨著實踐經(jīng)驗的增長，再對上述公式因子進行正交分析后，我發(fā)現(xiàn)穩(wěn)定性其實可以簡化為：

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

我們進一步拆分這一關系：

系統(tǒng)風險(概率) = 固有風險(概率) + 變更風險(概率)

其中固有風險對應穩(wěn)定性概念的內部變化，工程上可以定義為網(wǎng)絡、服務器等運行環(huán)境變化。而變更風險，則是包括發(fā)布、配置變更在內的，由人為發(fā)起的系統(tǒng)變化。一般固有風險會由運維團隊進行關注，因此我們主要展開變更風險：

變更風險 = 變更頻率 * 變更復雜度 * 變更爆炸半徑

其中：

變更頻率：代表變更的發(fā)生次數(shù)，它一般和業(yè)務的需求有關。

變更復雜度：這不僅限于代碼的可理解性和可修改性，還包括配置的復雜性。一般來說，復雜度越高，單次變更出問題的概率也越大。

變更爆炸半徑：表示發(fā)生問題后的影響面，直接影響實際的損失。這個爆炸半徑也有很多的衡量因子，如QPS、場景重要性、強弱依賴關系等等。

接下來我們對風險處理能力進行展開：

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

其中，風險前置發(fā)現(xiàn)可以定義為在測試階段發(fā)現(xiàn)問題的場景，由于線下的風險總會有手段可以處理，因此前置風險處理并不會成為瓶頸；后置風險則可定義為上線之后暴露的問題，由于生產(chǎn)問題總會暴露，其關鍵影響點為發(fā)現(xiàn)時長，以及完成應急后最終的影響面，即應急效果。

如果認可這些穩(wěn)定性公式的拆解推導步驟，我們最終可以將穩(wěn)定性拉成一個龐大的公式：

穩(wěn)定性 =（固有風險 + 變更頻率 * 變更復雜度 * 變更爆炸半徑）

*（風險前置發(fā)現(xiàn)概率 * 前置風險處理）*（后置風險發(fā)現(xiàn)時長 * 應急效果）

而這個公式，涵蓋了影響穩(wěn)定性的一系列關鍵因素，這些關鍵因素，也將為后續(xù)的穩(wěn)定性建設定下基礎。

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

在進行如何建設穩(wěn)定性的探討之前。我們先來討論一個問題：為什么我們如此重視穩(wěn)定性？這可以從兩個重要方面來理解：

1.失去穩(wěn)定性的損失 ：

• 直接經(jīng)濟與業(yè)務損失 ：想象一下，系統(tǒng)故障導致下單鏈路出現(xiàn)異常，訂單急劇下降；營銷邏輯錯誤，導致優(yōu)惠券被濫發(fā)，直接造成公司的資損。
• 信任度與隱形資產(chǎn)損失 ：故障不可用或大規(guī)模的技術問題可能引發(fā)輿論危機，給品牌形象帶來巨大損害。尤其對云服務廠商而言，穩(wěn)定性故障更可能導致客戶的大量流失。

2.具備穩(wěn)定性的好處 ：

• 提高業(yè)務迭代效率，使得團隊能迅速應對市場變化。
• 節(jié)約值班等額外的投入，減少資源浪費。

此時，大家一定會疑惑，穩(wěn)定性差的損失容易理解，但良好穩(wěn)定性與業(yè)務迭代的高效又有何關系呢？回到我們的變更風險公式，你會發(fā)現(xiàn)，變更復雜度與業(yè)務迭代效率之間存在著顯著的負相關關系，容易的變更交付的快，復雜的變更交付的慢，這很好理解。因此：良好的穩(wěn)定性 -> 低變更風險 -> 低變更復雜度 -> 高迭代效率，形成了一個合理的邏輯鏈。

穩(wěn)定性建設究竟要建什么？

在推導出穩(wěn)定性公式之前，這個命題簡直寬泛地讓人無從下手。但推導出公式之后，所有的關鍵點都已經(jīng)成竹在胸?。ㄟ@也是方法論的魅力所在）

1.1中，我們已經(jīng)給出了穩(wěn)定性的公式，并標紅了關鍵因子。當我們應用上這個方法論時，問題就變得清晰起來：穩(wěn)定性建設的目標應該聚焦于之前提及的關鍵因素，借此我們可以制定出實用的治理項如下：

當然，每個治理項都能進一步拆分成若干舉措。由于每個團隊、每個應用的生命周期階段不同、實際特性不同，因此各團隊在需要重點治理的方向和舉措上均有所不同。但總歸跳不出這個框架。

二、穩(wěn)定性建設面臨什么困難？

穩(wěn)定性建設在當今技術驅動的時代至關重要，但它常常被視為“重要但不緊急”的任務，導致在排期過程中得不到必要的優(yōu)先級支持。許多時候，團隊甚至不得不依賴于故障的驅動才能艱難推進穩(wěn)定性建設。這一現(xiàn)象的根源，可以歸結為以下幾個方面。

穩(wěn)定性建設缺少立竿見影的短期價值

其一：量化價值不明確，收益評估困難

我們可以從上文提到的穩(wěn)定性公式中找到一些線索，尤其是兩個非常重要的因子：變更復雜度和風險前置發(fā)現(xiàn)概率。變更復雜度實際上對應的是研發(fā)引入的單次變更中攜帶風險的概率，而風險前置發(fā)現(xiàn)概率是經(jīng)過研發(fā)和測試團隊的努力后，變更風險仍被遺漏到生產(chǎn)環(huán)境中的可能性。

正是因為在穩(wěn)定性的衡量公式計算中，帶入了這2個概率因子，穩(wěn)定性建設的量化價值的不確定性就顯而易見了。概率常常需要經(jīng)過大量的樣本統(tǒng)計才能形成有效的量化指標，但在實操時聚焦到某個團隊、某個應用或某個具體的治理需求中時，它提升的概率影響往往不足以成為一個可以衡量的量化指標。甚至運氣不好的時候，可能會出現(xiàn)治理越多故障越多的離譜事件。

其二：業(yè)務壓力重，穩(wěn)定性任務排不上優(yōu)先級

我們不妨再回到穩(wěn)定性的關鍵因子，尤其是變更頻率這個有意思的指標。我們很容易通過公式推導得出：變更頻率越高的功能，其穩(wěn)定性治理的收益也越大。然而，正如你所想的，這類功能往往是在業(yè)務高速發(fā)展時誕生的，此時需求繁多且時間緊迫，在這樣的情況下，穩(wěn)定性治理的優(yōu)先級與業(yè)務的迭代需求相較，無疑排不上號。

而當業(yè)務進入穩(wěn)定期，變更頻率下降，終于有時間投入穩(wěn)定性治理了，但變更頻率的下降又同樣帶來了穩(wěn)定性風險的減小，治理優(yōu)先級隨之降低。此時的穩(wěn)定性治理就變成了“食之無味，棄之可惜”的雞肋工程，仍舊排不上優(yōu)先級。

穩(wěn)定性建設存在極大的復雜性和風險

與上文所述的不確定收益相對的，卻是穩(wěn)定性建設確定性的復雜度和風險。無論是風險識別、風險治理，還是風險預防，均需要投入大量的精力。

存量風險識別的難度

在解決問題的第一步中，發(fā)現(xiàn)問題是重中之重。穩(wěn)定性建設的第一步同樣是識別其中的穩(wěn)定性問題。但問題是，我們該如何發(fā)現(xiàn)這些問題呢？依靠故障或者TS工單嗎？這種方式確實可以幫助我們發(fā)現(xiàn)問題，并在后續(xù)解決問題。但這種亡羊補牢的操作，對于穩(wěn)定性的建設而言，實在是太過滯后，根本達不到預期的效果。

為了有效地防范問題發(fā)生，我們需要從整體上排除風險——它大到一個域，幾十個應用，成千上萬條調用鏈路；小到一個git倉庫，數(shù)萬甚至數(shù)十萬代碼——要準確評估整個域的穩(wěn)定性并識別其中的風險，這無疑是一項巨大的挑戰(zhàn)。

風險治理的難度

風險識別已經(jīng)足夠困難，風險治理的復雜性同樣不容忽視。雖然理論上，技術同學從不畏懼已知問題，但不同問題背后的復雜性，也往往會帶來不同的治理難度。

首當其沖的自然是技術同學最頭疼的排期問題，“世上無難事，只要有排期”。但正如2.1中提到的，穩(wěn)定性建設由于價值的不確定性，往往難以取得足夠的排期。即便是再高瞻遠矚的管理者，也不得不嚴格控制技術投入的占比，將更多的資源用于服務業(yè)務，創(chuàng)造更多的增長。

其次，穩(wěn)定性治理本身帶來的變更風險也不容小覷。這里貼上技術人員非常喜歡的一張圖，來貼切地表示這個難題。

上圖的這個房屋，毫無疑問是個風吹就塌的危房。但誰又真敢動手對這樣的危房進行穩(wěn)定性治理呢？如果就是個普通房屋，推倒重建就完了，但業(yè)務系統(tǒng)可無法停機。在這種情況下進行代碼改動，就如同需要持續(xù)地挪動木頭、泥土和石塊，試圖將其替換為堅固的建筑材料，卻很可能無意中移走某個重要支撐，導致整個系統(tǒng)崩潰。

這在穩(wěn)定性建設中是不可接受的。為了預防可能發(fā)生的故障，反而引入了變更故障，這實屬本末倒置。

至于另外一種治理方案……新建一個系統(tǒng)，然后把流量切過去。如果面對類似圖片這種治理難度地獄級的項目，確實是個最佳選擇，并且該方法也確實大量應用在架構治理上（如服務拆分）。但大部分應用，使用該方案又著實奢侈了。疊加上文提及的排期問題，也限制了這種方案成為穩(wěn)定性治理銀彈的可能性。

如果繼續(xù)深入探討變更風險的問題，我們必然會碰到“代碼債務”的概念。每一位技術開發(fā)者都對代碼債務耳熟能詳，深有感觸。它通常定義為低代碼質量和不合理架構設計等一系列技術負擔，而這些問題并非立刻顯現(xiàn)出危害。一個重的代碼債務，只要在生產(chǎn)環(huán)境中能夠正常運行，就意味著它是能被接受的。即如圖中的房子再怎么危房，沒塌之前，住人防風擋雨都是沒問題的。

然而，代碼債務阻礙了變更，無論是業(yè)務的迭代還是技術的治理，都會提升變更的風險。因此，最后的風險治理難度來到了穩(wěn)定性風險因子中的變更復雜度問題。

命名為變更復雜度，而非代碼復雜度這種客觀描述，也是意味著變更難度是包含主觀含義，是因人而異的。例如某個應用由一位同學貫穿始終地維護，代碼再復雜，變更復雜度也高不到哪里去。因為這份代碼從始至終，都是由同一個人，以他的思維框架，解讀業(yè)務鏈路后，再抽象建設而成的，這份代碼從頭到腳都是這位同學的形狀。他知道這些代碼從何而來，又應當往哪里去。但實際生產(chǎn)過程中，一個應用往往要經(jīng)歷多人維護，就必然出現(xiàn)信息傳遞的損失。最終，我們在面對這種代碼時，大概率會遇到理解困難以及對變更后果的無能為力。因此，變更復雜度的本質，是由不同人員的思維方式、設計理念、編碼習慣，以及業(yè)務知識在傳遞過程中的信息偏差交織在一起，構成的一種現(xiàn)象。

至此，排期、變更復雜度、變更風險三者，構成了整個穩(wěn)定性風險治理的難度。

增量風險預防的難度

在此前的討論中，我們已經(jīng)探討了存量風險的識別和治理。而本節(jié)將重點關注每次變更引入的增量風險。這是一個不可忽視的領域，因為風險的根源在于變更，而變更又是業(yè)務發(fā)展的必然過程。那么，如何有效控制這些因變更而來的風險呢？

變更可見性

首先，最重要的是確保變更的可見性和可感知性 。這里所說的可見性，不僅僅是變更執(zhí)行者本人的知曉，更是整個團隊乃至所有相關方共同的認知。畢竟，執(zhí)行變更的同事自然會清楚自己做了什么，但真正的問題在于，執(zhí)行變更的同事是否知道這些變更意味著什么，這個認知和其他相關人員——比如PM和測試人員——是否是一致的？

這就是為什么變更可見性如此重要。做過業(yè)務負責人的都知道，最擔心的事情就是業(yè)務/產(chǎn)品和技術說要改個什么一句話功能，或者是刷數(shù)等操作，技術同學順手就給做了；因為功能點太小，甚至都沒通知測試和PM，直接自測完就上線了，真就映著一句話：天知地知，你知我知。但這個卻是風險最高的行為，因為沒有任何人幫助變更同學進行二次確認，不出問題都是僥幸。

那么難點來了，對一個域少則幾十，多則數(shù)百的同學，每個迭代也是幾十個需求，上百種不同類型的變更，怎么保證每個微小的變更，都能讓變更的所有相關方都感知到，并且進行有效的二次確認呢？

方案可控性

在確認了變更共識后，下一步便是對變更方案本身進行評估，從而確保每項調整都符合預期。但此時，又出現(xiàn)了一個障礙：如何保證這個變更是符合預期的呢？

對于一項代碼的變更，它不僅會對這行代碼的所有上游場景產(chǎn)生影響，更會影響所有使用到這行代碼結果的下游場景。若是數(shù)據(jù)的變更，更是牽一發(fā)而動全身，所有讀取和寫入到這行數(shù)據(jù)的場景都要受到影響。由于整體鏈路的復雜性和不可控性，對于變更方案的風險可控性評估就顯得異常困難。

人員可靠性

最后，涉及到的還有變更執(zhí)行人員本身的可靠性 ，人是同時具備高上限和低下限的特性的。即便是一個優(yōu)秀的同學，即有高瞻遠矚，防范未然的時候；也有馬失前蹄，被"!"和“NullPointException”搞得焦頭爛額的時候。

那么怎樣在各種各樣的變更中，去保障人員的下限，不要讓這種人員的波動性影響到系統(tǒng)的穩(wěn)定性；甚至盡可能讓人員保持他們的高上限，將更多的穩(wěn)定性風險扼殺在搖籃之中？這便是穩(wěn)定性建設中最后一個需要重點考慮的問題。

三、如何進行穩(wěn)定性建設？

經(jīng)過前面的鋪墊，我們已經(jīng)明確了穩(wěn)定性建設的重要性，以及在實施過程中面臨的種種挑戰(zhàn)。那么，問題的關鍵就在于如何克服這些困難，順利進行穩(wěn)定性的建設。實際操作中，很多治理建設的思路和策略都已經(jīng)隱含在前文的分析中，現(xiàn)在我們只需將它們整合提煉出來。

建立穩(wěn)定性共識

從上文知，困難中排在第一點的，即是穩(wěn)定性治理的優(yōu)先級和的資源排期問題。因此，在解決穩(wěn)定性建設的客觀困難之前，首先需要業(yè)務團隊內部從主觀層面建立對穩(wěn)定性的一致認知：即業(yè)務團隊需要針對本團隊業(yè)務的重要性、發(fā)展階段、風險情況進行綜合評估，確定好穩(wěn)定性建設在本團隊中的重要程度。

直白點說，這個共識就是業(yè)務團隊確定好穩(wěn)定性建設將在團隊總投入中的時間占比。

這個占比可以在迭代維度進行波動，但周期拉長到季度、年維度的時候，是需要保持在一個符合預期的比例的。它可以是5%或者更低，也可以是10%甚至更高，具體的數(shù)值需要和團隊目前的業(yè)務和技術現(xiàn)狀相匹配。

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

當確定了資源比例后，接下來就是明確具體的目標。在此過程中，我們需制定可執(zhí)行的方案，將大方向細化為明確的階段目標。

回到1.3腦圖中提供的三個大方向：

• 風險前置發(fā)現(xiàn) ：側重于人和流程的管理；
• 變更風險控制 ：關注系統(tǒng)性架構建設；
• 風險后置處理 ：著眼于應急響應，同時關注人的應急流程和系統(tǒng)的預案建設；

因此，歸根結底，穩(wěn)定性的目標收斂成是練人、建系統(tǒng)兩種。我們通常建議先從練人中的強化意識和流程入手，再優(yōu)化系統(tǒng)，最后持續(xù)性地提高人員的綜合能力。

這是因為加強團隊意識和規(guī)范團隊流程的投入相對較低，通過制定規(guī)范、流程，進行宣導培訓甚至考試等形式，不需要投入過多資源就能取得良好效果。這種意識的培養(yǎng)，雖然不會立即影響故障率，但有助于營造穩(wěn)定性的文化氛圍，為長期的治理打下基礎。其次，在這一過程中，無需直接修改代碼，在初期可以盡量避免“越治理越故障”的困境。最后，加強團隊意識和規(guī)范團隊流程，有助于后續(xù)保護好穩(wěn)定性治理結果。避免一邊堵漏，一邊挖坑的迷惑行為。

需要注意的是，穩(wěn)定性建設是一個動態(tài)變化的過程。隨著時間的推移，人可能會逐漸懈怠，系統(tǒng)架構也可能因為業(yè)務迭代而腐化。因此，穩(wěn)定性建設必須是一個周期性的工作，并且建議每一個季度都專注于1-2項關鍵點，使得整個系統(tǒng)的穩(wěn)定性可以在螺旋中上升。

落地穩(wěn)定性建設任務

為了有效實施穩(wěn)定性建設，我們將其任務進一步細分為五個核心部分：意識培養(yǎng)、 安全生產(chǎn)規(guī)范、應急響應、日常巡檢和架構治理 。接下來，我們將逐一闡述這五個部分的重要性及其具體實現(xiàn)方案，并表述清楚這些部分應對的是上述的那些困難點。

意識培養(yǎng)

意識培養(yǎng)是提升團隊成員在穩(wěn)定性建設中能動性的關鍵環(huán)節(jié)。它主要涵蓋三個方面：認知、意愿和能力。換句話說，我們要弄清楚團隊成員對于穩(wěn)定性的認知程度、愿意投入的程度以及他們的能力如何。

認知 ：團隊成員是否充分了解穩(wěn)定性的重要性。

針對這一點，我們可以定期舉辦“謹慎編碼”宣講，以提高大家的意識。雖然這看似簡單，但不可忽視。因為如果長期不提及穩(wěn)定性，其重要性就會在潛意識中隨時間弱化。

意愿 ：團隊成員是否愿意花費時間和精力去評估并解決穩(wěn)定性風險。

評估穩(wěn)定性風險往往需要深入細致的工作，還需要克服習慣、自信、僥幸、嫌麻煩等心理障礙。為了提升意愿度，可從獎、懲兩方面入手。如可以通過設置穩(wěn)定性紅線或進行故障復盤來進行必要的懲罰，同時引入激勵機制，比如對表現(xiàn)突出的團隊成員進行表彰或績效激勵。此外權責到人也是激發(fā)意愿的手段之一，當同學有了固定負責的應用，并有權限進行完全控制時，會更愿意吃透其業(yè)務，保證其代碼整潔和穩(wěn)定。

能力 ：團隊成員能否識別風險，并設計有效的解決方案。

這塊可提升點就很多了：如一是案例分享可以擴展同學眼界，通過舉一反三可以避免同類問題的發(fā)生；二是沉淀組內/域內的穩(wěn)定性知識庫，將團隊的能力沉淀下來，將團隊的智慧變成個人的智慧，提高同學能力上限；三是尋求組內同學的幫助也是一種方法，這適合于發(fā)現(xiàn)了問題后，在設計方案時進行組內交流，查缺補漏，共同設計完備的解決方案。

當然，意識培養(yǎng)，或者說人的培養(yǎng)，同樣是一個龐大復雜的體系，這里僅針對三個關鍵因素進行粗淺的解讀，更多內容可以關注一些專業(yè)書籍。

安全生產(chǎn)規(guī)范

安全生產(chǎn)規(guī)范，我們定義為為了保證變更風險可控而制定的一系列流程規(guī)范。但很多人對于這些流程規(guī)范可能不以為然，認為繁瑣的過程除了降低效率外并沒有什么實際的益處。但其實，這些環(huán)節(jié)的存在是對變更方案及其風險進行二次確認的重要保障。

在一個典型的需求變更流程中，一般會有需求評審、技術方案評審、用例評審、自測/測試環(huán)節(jié)、CR、驗收等多個環(huán)節(jié)。為什么需要有這么多環(huán)節(jié)呢？

• 需求評審：針對業(yè)務變化帶來的功能變化，在產(chǎn)品、研發(fā)、測試之間達成一致，進行多方確認。
• 技術方案評審：針對功能變化對應的技術變化，在產(chǎn)品、研發(fā)、測試之間達成一致，進行多方確認。
• 用例評審：針對功能變化/技術變化帶來的用例變化，在產(chǎn)品、研發(fā)、測試之間達成一致，進行多方確認。
• 自測/測試環(huán)節(jié)：針對技術變化的正確性和完備性，在研發(fā)、測試之間達成一致，進行二次確認。
• CR：針對技術變化對應的代碼變化，在研發(fā)團隊內部進行風險確認，屬于二次確認。
• 驗收：針對功能變化的最終效果，在產(chǎn)品、研發(fā)、測試之間達成一致，屬于多方確認。

可以看到，通過這些環(huán)節(jié)，變更的可見性將得以顯著提升：幾乎所有的相關方，都能夠準確知道變更內容、變更方案和變更時間，并共同確認過變更風險。正因為這些環(huán)節(jié)在現(xiàn)有的需求流程中多半能夠充分落實，因此需求變更帶來風險的概率是相對較低的。

與需求變更的多方確認相反的是，技改需求、curl、數(shù)據(jù)訂正、Ark變更等操作，在技術部多次管控加碼之前，這些變更操作發(fā)生問題的概率遠高于需求變更。其原因正是由于這些變更可能就是某個研發(fā)順手操作了，其可見范圍極小。根本沒有相關方進行多輪有效的二次確認操作，容易出問題也就不足為奇了。其他類似的案例還有業(yè)務方突然執(zhí)行了大量的業(yè)務變更操作，突然進行了某項營銷活動導致引入遠超預期的流量等等，這同樣也是由于變更的可見性并未被技術團隊感知，而導致的變更風險。

因此，安全生產(chǎn)規(guī)范，就是用來約定當任意變更產(chǎn)生時，需要通過何種流程將該變更通知到所有相關方，并通過何種方式進行多方確認，共同確保變更風險可控的共識方案。了解了安全生產(chǎn)的本質后，各團隊就完全可以針對自己的業(yè)務特性和所有的變更場景，制定專屬的安全生產(chǎn)規(guī)范。其完備性取決于變更場景的完備性，其有效性取決于多方確認的有效性。這樣，也同時回答了“如何制定一個好的安全生產(chǎn)規(guī)范”這個問題。

應急響應

應急響應主要分三個部分：發(fā)現(xiàn)、響應和處理；關鍵的標準則是及時性和有效性。及時性確保了問題的影響不被放大，有效性則確保了已經(jīng)發(fā)生的影響能被控制和修復。

發(fā)現(xiàn)：發(fā)現(xiàn)的關鍵點是及時。若不考慮及時性，客戶進線、結算錯誤這種后置發(fā)現(xiàn)手段，是可以發(fā)現(xiàn)所有的問題的。但這種通過實際的業(yè)務損失來發(fā)現(xiàn)問題的方案，顯然不符合預期。因此，必須通過系統(tǒng)的手段，做好監(jiān)控、告警布防，不論是系統(tǒng)資源使用率、服務可用性情況，還是業(yè)務數(shù)據(jù)正確性、波動值，均要做好完善的布控，方可及時發(fā)現(xiàn)。

響應：響應的要點同樣也是及時，它關系到已經(jīng)出現(xiàn)的異常事件是否有人立即進行跟進處理，它一方面和意識培養(yǎng)直接相關，對應人的責任意識。另一方面對應的工具的正確使用，諸如手機、電腦、飛書等通知配置，也是關系到值班同學是否能第一時間獲取到緊急事件通知的關鍵。

處理：問題處理是應急響應的最后一環(huán)，它需要兼顧及時性和有效性：是否能夠快速定位根因？是否能夠有效止血？這就不僅和個人的能力有關，也和系統(tǒng)的完備性有關。

個人能力這塊基本和3.3.1提及的內容一致。但系統(tǒng)能力的完備性，則同樣可以展開大量的建設任務，如：為了定位問題根因：告警信息的重要性（是否提供關鍵信息快速定位），日志信息的完備性和串聯(lián)性（是否能夠提供足夠的信息定位問題，是否提供的信息均是重要的關聯(lián)信息，減少不必要的噪聲），都是非常重要的基礎建設。

為了快速止血：除了通過個人的能力快速找到止血方案外，更重要的在于系統(tǒng)是否預設過相應的故障，并提供了止血預案。如果有，往往可以快速解決問題。但如果沒有，要在短時間內解決問題，往往難度極高。如果操作不當，容易引入額外的風險。

最后，團隊中關于應急問題處理的知識庫也是非常重要的知識沉淀，有助于不熟悉該業(yè)務的同學，也能夠快速定位和處理問題。

日常巡檢

“防患于未然”是我們維護穩(wěn)定性的重要目標。通過日常巡檢，團隊能夠識別潛在的風險苗頭。或是慢SQL、或是慢接口，或是cpu突刺。包括業(yè)務數(shù)據(jù)量是否逐步增長到了危險的范圍，各項活動/配置是否臨近過期，上下游的調用量是否接近容量上限……等等，這些風險，均可以在相應的巡檢中發(fā)現(xiàn)問題，避免潛在風險逐步積累引發(fā)的災難性后果。

架構治理

如果之前的部分主要關注人員層面的提升，那么架構治理則是從代碼層面提升系統(tǒng)穩(wěn)定性的一項重要措施，能夠真正提升系統(tǒng)抗風險的硬實力。

從穩(wěn)定性共識中可知，架構治理的能影響的關鍵因子為變更風險 ，而變更風險主要包括變更頻率、變更復雜度和變更爆炸半徑。

對應的領域建模、高內聚低耦合、OO等的架構原則，反映到變更風險中，就是控制了變更復雜度。因為內聚性，變更多可以聚焦在單一應用中，爆炸半徑也同時得到控制。

資源隔離的架構設計，則是專門用于控制爆炸半徑，不論是容器資源、線程池，還是DB、redis，甚至是P0/PN鏈路拆分等，均為控制爆炸半徑，避免相互影響。

還有一種特殊的稱作B/C流量拆分，這種看似是爆炸半徑，但實際上也控制了變更頻次。或者更精確的說法，是運營/B/C三端拆分，它的邏輯除了流量來源不同之外，更在于場景和變更頻次不同。一般可以認為B端/運營端的供給側，相較于C端的消費側，會有更復雜的模型，更高的變更頻次。進行這幾端的拆分，更多在于減少C端（往往更核心）的變更頻次，減少變更時的相互影響。

關于架構治理還有一個關鍵點，那就是抓住主要矛盾，先從最核心的業(yè)務場景開始治理。如果沒有考慮好治理優(yōu)先級，那么茫茫多的場景和鏈路就會成為一個交織在一起的毛線球，是無法進行抽絲剝繭逐一治理的。

資損防控

最后還有一個特殊的穩(wěn)定性場景，資損防控。它在穩(wěn)定性建設中比較特殊，是一個強業(yè)務相關的防控方案。一般可以在事前、事中、事后三個環(huán)節(jié)進行防控。

事前環(huán)節(jié)：一般考慮防呆攔截/提醒、二次確認、審批流等多輪操作確認；更深入的可以增加結果預計算、影響面提示、前后對比等重提示，給到使用方對于執(zhí)行后果的直觀展示，減少誤操作可能性。

事中環(huán)節(jié)：一般會有資金上限熔斷、實時/準實時Dcheck預警、相關資金指標波動預警等策略，在出現(xiàn)資損風險的時候進行預警，或業(yè)務熔斷。

事后環(huán)節(jié)：一般會采取T+1對賬，確認多方資金數(shù)據(jù)一致。并輔以貨款抵扣、調賬等工具，在發(fā)生資金差額的情況下，進行金額補償。

穩(wěn)定性建設的困難是否都被解決了？

最后，讓我們回過頭來復盤一下第2節(jié)中提到的困難，看看這些攔路虎是否在本節(jié)中被逐一擊破。

首先是短期價值不明確帶來的爭議，這塊我們通過建立團隊的穩(wěn)定性共識得到徹底的解決。

其次穩(wěn)定性建設的復雜性和風險性：

• 先說相對明確的增量風險預防：3.3.2中的安全生產(chǎn)規(guī)范整個存在的意義就是為了通過流程來控制增量風險。
• 然后是風險治理的難度：該問題先可以通過架構治理進行分而治之，將大問題拆解成若干個小問題；再通過安全生產(chǎn)規(guī)范，控制每次解決小問題引入風險的概率。
• 最后是存量風險識別的難度：日常巡檢有助于發(fā)現(xiàn)存量風險的苗頭，意識培養(yǎng)則有助于對單應用風險的摸排，架構治理則對應了對于應用間、甚至整個域內的依賴鏈路風險評估和治理。

至此，所有的核心困難點都有了解決的方案，穩(wěn)定性治理不再是一座不可逾越的高山，剩下的無非是根據(jù)具體問題，照著公式，逢山開路，遇水搭橋了。

四、穩(wěn)定性建設全景圖

通過以上的探討，我們不僅分析了穩(wěn)定性建設的重要性，還從理論角度，揭示了穩(wěn)定性建設的核心要素與挑戰(zhàn)，提供了具體的解決方案和建設任務。簡單統(tǒng)合一下，就生成了下面的穩(wěn)定性建設全景圖，希望能為正在努力追求系統(tǒng)穩(wěn)定性的小伙伴們提供啟發(fā)與幫助。

當然，其中的支撐事項僅是拋磚引玉，每個團隊都可以因地制宜，設計有團隊特色的支撐事項。只要是能夠服務于上層的建設目標，就具備落地的價值。

圖片