前言

系統(tǒng)的穩(wěn)定性，主要決定于整體的系統(tǒng)架構(gòu)設(shè)計，然而也不可忽略編程的細節(jié)，正所謂“千里之堤，潰于蟻穴”，一旦考慮不周，看似無關(guān)緊要的代碼片段可能會帶來整體軟件系統(tǒng)的崩潰。

穩(wěn)定性的工作，一般都是水下的工作。就像冰山，真正強大的系統(tǒng)下，要有更加強大的底層支撐，水面下的問題才是真正需要解決的問題。當(dāng)然不一樣的工作內(nèi)容，水下的工作是不同的，對于蓋樓來說，可能就是地基的深度。對于我們寫業(yè)務(wù)邏輯來說，水下的工作就是CatchException的處理，異常情況的處理。對于系統(tǒng)來說，水下的工作可能是一些接口系統(tǒng)的穩(wěn)定性。類似于金字塔結(jié)構(gòu)，下層基礎(chǔ)決定上層建筑。對于軟件系統(tǒng)來說，穩(wěn)定性至關(guān)重要。

在開始介紹服務(wù)穩(wěn)定性之前，我們先聊一下SLA。SLA（service-level agreement，即 服務(wù)級別協(xié)議）也稱服務(wù)等級協(xié)議，經(jīng)常被用來衡量服務(wù)穩(wěn)定性指標(biāo)。通常被稱作“幾個9”，9越多代表服務(wù)全年可用時間越長服務(wù)也就越可靠，即停機時間越短。通常作為服務(wù)提供商與受服務(wù)用戶之間具體達成承諾的服務(wù)指標(biāo)——質(zhì)量、可用性，責(zé)任。

3個9，即99.9%，全年可停服務(wù)時間：365 * 24 * 60 *（1-99.9%）= 525.6min

4個9，即99.99%，全年可停服務(wù)時間：365 * 24 * 60 *（1-99.99%）= 52.56min

5個9，即99.999%，全年可停服務(wù)時間：365 * 24 * 60 *（1-99.999%）= 5.256min

在嚴(yán)苛的服務(wù)級別協(xié)議背后，其實是一些列規(guī)范要求來進行保障。

2021 年全球重大的系統(tǒng)事故，其中不乏亞馬遜、特斯拉、Facebook 等行業(yè)巨頭。

一、何為系統(tǒng)穩(wěn)定性

展開全文

我們先看下百度百科對穩(wěn)定性定義：

系統(tǒng)穩(wěn)定性是指系統(tǒng)要素在外界影響下表現(xiàn)出的某種穩(wěn)定狀態(tài)。

其次維基百科對穩(wěn)定性定義：

穩(wěn)定性是數(shù)學(xué)或工程上的用語，判別一系統(tǒng)在有界的輸入是否也產(chǎn)生有界的輸出。

若是，稱系統(tǒng)為穩(wěn)定；若否，則稱系統(tǒng)為不穩(wěn)定。

簡單理解，系統(tǒng)穩(wěn)定性本質(zhì)上是系統(tǒng)的確定性應(yīng)答。

從另一個角度解釋，服務(wù)穩(wěn)定性建設(shè)就是如何保障系統(tǒng)能夠滿足SLA所要求的服務(wù)等級協(xié)議。

Google SRE中(SRE三部曲[1])有一個層級模型來描述系統(tǒng)可靠性基礎(chǔ)和高層次需求(Dickerson's Hierarchy of Service Reliability)，如下圖：

該模型由Google SRE工程師Mikey Dickerson在2013年提出，將系統(tǒng)穩(wěn)定性需求按照基礎(chǔ)程度進行了不同層次的體系化區(qū)分，形成穩(wěn)定性標(biāo)準(zhǔn)金字塔模型。

金字塔的底座是監(jiān)控(Monitoring)，這是一個系統(tǒng)對于穩(wěn)定性最基礎(chǔ)的要求，缺少監(jiān)控的系統(tǒng)，如同蒙上眼睛狂奔的野馬，無從談及可控性，更遑論穩(wěn)定性。更上層是應(yīng)急響應(yīng)(Incident Response)，從一個問題被監(jiān)控發(fā)現(xiàn)到最終解決，這期間的耗時直接取決于應(yīng)急響應(yīng)機制的成熟度。合理的應(yīng)急策略能保證當(dāng)故障發(fā)生時，所有問題能得到有序且妥善的處理，而不是慌亂成一鍋粥。

事后總結(jié)以及根因分析(PostmortemRoot Caue Analysis)，即我們平時談到的“復(fù)盤”，雖然很多人都不太喜歡這項活動，但是不得不承認這是避免我們下次犯同樣錯誤的最有效手段，只有當(dāng)摸清故障的根因以及對應(yīng)的缺陷，我們才能對癥下藥，合理進行規(guī)避。

假設(shè)一個系統(tǒng)從初次發(fā)布后就不再進行更新迭代，做好上述三個方面的工作就能基本滿足系統(tǒng)對于穩(wěn)定性的全部需求?？上壳盎静粫嬖谶@樣的系統(tǒng)，大大小小的應(yīng)用都離不開不斷的變更與發(fā)布，因此要保證系統(tǒng)在這些迭代中持續(xù)穩(wěn)定，測試和發(fā)布管控(TestingRelease procedures)是必不可少的。有效的測試與發(fā)布策略能保障系統(tǒng)所有新增變量都處于可控穩(wěn)定區(qū)間內(nèi)，從而達到整體服務(wù)終態(tài)穩(wěn)定。

除了代碼邏輯更新，迭代同樣可能帶來業(yè)務(wù)規(guī)模及流量的變化，容量規(guī)劃(Capacity Planning)則是針對于這方面變化進行的保障策略。現(xiàn)有系統(tǒng)體量是否足夠支撐新的流量需求，整體鏈路上是否存在不對等的薄弱節(jié)點，都是容量規(guī)劃需要考慮的問題。

位于金字塔模型最頂端的是產(chǎn)品設(shè)計(Product)與軟件研發(fā)(Development)，即通過優(yōu)秀的產(chǎn)品設(shè)計與軟件設(shè)計使系統(tǒng)具備更高的可靠性，構(gòu)建高可用產(chǎn)品架構(gòu)體系，從而提升用戶體驗。

為了方便，本文闡述的系統(tǒng)主要指軟件系統(tǒng)。那么如何衡量系統(tǒng)穩(wěn)定性的高與低呢？一個常用的指標(biāo)就是服務(wù)可用時長占比，占比越高說明系統(tǒng)穩(wěn)定性也越高，如果我們拿一整年的數(shù)據(jù)來看，常見的 4 個 9（99.99%）意味著我們系統(tǒng)提供的服務(wù)全年的不可用時長只有 52 分鐘！

它其實是一個綜合指標(biāo)，為什么這么說？因為我們在服務(wù)可用的定義上會有一些差別，常見的服務(wù)可用包括：服務(wù)無異常、服務(wù)響應(yīng)時間低、服務(wù)有效（邏輯正確）、服務(wù)能正常觸發(fā)等。

二、穩(wěn)定性建設(shè)目標(biāo)

架構(gòu)設(shè)計源于生活，穩(wěn)定性建設(shè)也肯定是源于生活，一般會把穩(wěn)定性和消防放在一起進行比喻方便大家的理解，處理火災(zāi)主要是階段：在火災(zāi)前預(yù)防火災(zāi)，在第一時間知道發(fā)生火災(zāi)了，在發(fā)生火情的時候如何快速救火。通過火災(zāi)處理對比軟件系統(tǒng)的穩(wěn)定性，也就是預(yù)防（事前）、發(fā)現(xiàn)和處理（事中）了，最后（事后）我們加入了復(fù)盤。發(fā)生問題不可怕，可怕的是已發(fā)生的問題重復(fù)發(fā)生。一定要杜絕有問題的事情第二次發(fā)生。

防火的最高境界是，防患于未然。這也就催生了，現(xiàn)代軟件系統(tǒng)里面，大家把更多的精力放在事前（全鏈路壓測和故障演練方面）。

三、穩(wěn)定性治理

影響穩(wěn)定性的主要在兩個階段，一個階段是非運行期，一個階段是運行期。非運行期主要就是我們?nèi)粘＿M行開發(fā)的時候，技術(shù)方案設(shè)計，代碼書寫，線上操作配置等引發(fā)的穩(wěn)定性問題。運行期主要是因服務(wù)自身問題、外部調(diào)用問題，外部依賴問題引發(fā)的穩(wěn)定性，所以治理也主要從這兩個方面出發(fā)。

接下來會以上線前、上線中、上線后三個階段進行總結(jié)穩(wěn)定性治理。

上線前

很多時候我們都以為系統(tǒng)穩(wěn)定只是線上運行穩(wěn)定就好了，但事實上需求研發(fā)流程是否規(guī)范，也會極大地影響到系統(tǒng)的穩(wěn)定性。試想一下，如果誰都可以隨便提需求、做的功能沒有做方案設(shè)計、誰都可以直接操作線上服務(wù)器，那么這樣的系統(tǒng)服務(wù)能夠穩(wěn)定得了嗎？所以說，需求上線前的過程也是影響系統(tǒng)穩(wěn)定性的重大因素。

在我看來，在上線前這個階段，主要有三大塊非常重要的穩(wěn)定性建設(shè)內(nèi)容，分別是：

研發(fā)流程規(guī)范

發(fā)布流程規(guī)范

高可用架構(gòu)設(shè)計

1）研發(fā)流程規(guī)范

研發(fā)流程規(guī)范，指的是一個需求從提出到完成的整個過程應(yīng)該是怎樣流轉(zhuǎn)的。一般的需求研發(fā)流程包括：產(chǎn)品提出需求、技術(shù)預(yù)研、需求評審、技術(shù)方案設(shè)計、測試用例評審、技術(shù)方案評審、測試用例評審、需求開發(fā)、代碼評審、需求測試。不同公司根據(jù)情況會有所調(diào)整，但大差不差。

在這個流程中，與研發(fā)相關(guān)的幾個比較重要的節(jié)點是：技術(shù)方案設(shè)計及評審、測試用例評審及評審、需求開發(fā)、代碼測試覆蓋率、代碼評審。我們上面提到的幾個影響穩(wěn)定性的因素，就是因為沒有做好這幾個節(jié)點的工作導(dǎo)致的，包括：

未測試需求直接上線

上線的需求產(chǎn)品不知道

上線的新需求有 bug

上線后沒有線上驗證

系統(tǒng)設(shè)計方案存在缺陷

系統(tǒng)代碼實現(xiàn)存在缺陷

如果能夠處理好上述幾個節(jié)點，那么就能夠極大地降低研發(fā)流程導(dǎo)致的問題。這里每個節(jié)點都有很深的學(xué)問，這里就不展開講了，我們主要說個思路。

研發(fā)團隊最希望拿到的需求是真正有業(yè)務(wù)價值的需求，而不是一個短期或臨時的需求，因為如果是一個臨時需求的話，往往對應(yīng)的解決方案也是臨時的，如果太多臨時的解決方案遺留在系統(tǒng)中，久而久之將會變成巨大的“技術(shù)債”，總有一天會爆發(fā)，對系統(tǒng)穩(wěn)定性及業(yè)務(wù)迭代速度造成巨大影響。

另外有一點比較重要的是，通過需求評審，不僅僅是評審產(chǎn)品業(yè)務(wù)需求，更重要的是需要研發(fā)挖掘出一些非功能需求，包括性能指標(biāo)要求、依賴三方接口qps、安全等要求。

對于編碼規(guī)范、技術(shù)方案評審、代碼評審、發(fā)布計劃評審，這里重點講一下這四點。

① 編碼規(guī)范

對外接口命名方式、統(tǒng)一異常父類、業(yè)務(wù)異常碼規(guī)范、對外提供服務(wù)不可用是拋異常還是返回錯誤碼、統(tǒng)一第三方庫的版本、哪些場景必須使用內(nèi)部公共庫、埋點日志怎么打、提供統(tǒng)一的日志、監(jiān)控切面實現(xiàn)等，編碼規(guī)范除了能規(guī)范開發(fā)的編碼行為、避免犯一些低級錯誤和踩一些重復(fù)的坑外，另一個好處是讓新入職的同學(xué)能快速了解公司的編碼原則，這點對編碼快速上手很重要，更多可以參考阿里巴巴的Java開發(fā)規(guī)范。

② 技術(shù)方案評審

再也沒有比糟糕的設(shè)計更有破壞力的東西了，技術(shù)方案設(shè)計評審和 CR 可以放在一起做，先評審設(shè)計再進行 CR，有人就會說，都編碼完了才進行設(shè)計評審是不是晚了？其實這要看情況而定，如果團隊內(nèi)部經(jīng)常產(chǎn)出“糟糕設(shè)計”，那么我覺得設(shè)計評審就應(yīng)該編碼之前來做，但如果團隊成員專業(yè)能力和經(jīng)驗都還不錯，那么我們允許你再編碼之后再做設(shè)計評審，而且編碼的過程其實也是設(shè)計的過程，可以規(guī)避提前設(shè)計而導(dǎo)致后續(xù)編碼和設(shè)計不一致的問題。設(shè)計評審的原則是，既要講最終的設(shè)計方案，也要講你淘汰的設(shè)計方案！

③ 代碼評審

代碼質(zhì)量包括功能性代碼質(zhì)量和非功能性代碼質(zhì)量，功能質(zhì)量大多通過測試能夠去發(fā)現(xiàn)問題，非功能性代碼質(zhì)量用戶不能直接體驗到這種質(zhì)量的好壞，代碼質(zhì)量不好，最直接的“受害者”是開發(fā)者或組織自身，因為代碼質(zhì)量好壞直接決定了軟件的可維護性成本的高低。

代碼質(zhì)量應(yīng)該更多的應(yīng)該從可測性，可讀性，可理解性，容變性等代碼可維護性維度去衡量，其中 CodeReview 是保證代碼質(zhì)量非常重要的一個環(huán)節(jié)，建立良好的 CodeReview 規(guī)范與習(xí)慣，對于一個技術(shù)團隊是一件非常重要核心的事情，沒有 CodeReview 的團隊沒有未來。

每次項目開發(fā)自測完成后，通常會組織該小組開發(fā)人員集體進行代碼 review，代碼 review 一般 review 代碼質(zhì)量以及規(guī)范方面的問題，另外需要關(guān)注的是每一行代碼變更是否與本次需求相關(guān)，如果存在搭車發(fā)布或者代碼重構(gòu)優(yōu)化，需要自行保證測試通過，否則不予發(fā)布。

④ 發(fā)布計劃評審

涉及到10人日以上的項目，必須有明確的發(fā)布計劃，并組織項目成員統(tǒng)一參加項目發(fā)布計劃 review，發(fā)布計劃主要包含如下幾點：

明確是否有外部依賴接口，如有請同步協(xié)調(diào)好業(yè)務(wù)方；

發(fā)布前配置確認包括配置文件、數(shù)據(jù)庫配置、中間件配置等各種配置，尤其各種環(huán)境下的差異化配置項；

二方庫發(fā)布順序，是否有依賴；

應(yīng)用發(fā)布順序；

數(shù)據(jù)庫是否有數(shù)據(jù)變更和訂正，以及表結(jié)構(gòu)調(diào)整；

回滾計劃，必須要有回滾計劃，發(fā)布出現(xiàn)問題要有緊急回滾策略；

生產(chǎn)環(huán)境回歸測試重點 Case。

2）發(fā)布流程規(guī)范

發(fā)布流程規(guī)范主要是為了控制發(fā)布權(quán)限以及發(fā)布頻率的問題。

在項目初始，為了快速響應(yīng)業(yè)務(wù)，一般權(quán)限控制都很松，很多人都可以進行線上服務(wù)的發(fā)布。但隨著業(yè)務(wù)越來越多、流量越來越大，相對應(yīng)的故障也越來越多，到了某個時候就需要對權(quán)限做管控，并且需要對需求的發(fā)布頻率做控制。

對于需求發(fā)布流程來說，一般有幾種發(fā)布方式，分別是：Release Train 方式、零散發(fā)布方式。Release Train 意思是固定時間窗口發(fā)布，例如每周四發(fā)布一次。如果無法趕上這次發(fā)布時間，那么就需要等到下次發(fā)布窗口。零散發(fā)布方式，指的是有需要就發(fā)布，不做發(fā)布時間控制。但這種方式一般只在項目初期發(fā)揮作用，后期一般都會收緊。

除此之外，發(fā)布流程中都會設(shè)有緊急發(fā)布流程，即如果某個需求特別重要，或者有緊急漏洞需要修復(fù)，那么可以通過該流程來緊急修復(fù)，從而避免因未到時間窗口而對業(yè)務(wù)產(chǎn)生影響。但一般來說，緊急發(fā)布流程都比較麻煩，除非迫不得已不然不要審批通過，不然 Release Train 方式可能會退化成零散發(fā)布方式。

3）高可用架構(gòu)設(shè)計

高可用架構(gòu)設(shè)計指的是為了讓系統(tǒng)在各種異常情況下都能正常工作，從而使得系統(tǒng)更加穩(wěn)定。其實這塊應(yīng)該是屬于研發(fā)流程規(guī)范中的技術(shù)方案設(shè)計的，但研發(fā)流程規(guī)范更加注重于規(guī)范，高可用設(shè)計更加注重高可用。另外，也由于高可用設(shè)計是非常重要，因此獨立拿出來作為一塊來說說。

對于高可用設(shè)計來說，一般可分為兩大塊，分別是：服務(wù)治理和容災(zāi)設(shè)計。

服務(wù)治理就包括了限流、降級、熔斷、隔離等，這一些考慮點都是為了讓系統(tǒng)在某些特殊情況下，都能穩(wěn)定工作。例如限流是為了在上游請求量太大的時候，系統(tǒng)不至于被巨大的流量擊垮，還可以正常提供服務(wù)。服務(wù)治理這塊像SpringCloud Alibaba都有標(biāo)準(zhǔn)的成熟解決方案，比如可以基于sentinel實現(xiàn)限流、降級、熔斷、隔離，隔離可以實現(xiàn)線程池隔離和信號量隔離，這里不再做詳細介紹。

容災(zāi)設(shè)計應(yīng)該說是更加高端點的設(shè)計了，指的是當(dāng)下游系、第三方、中間件掛了，如何保證系統(tǒng)還能正常運行?？梢哉f容災(zāi)設(shè)計比起服務(wù)治理，其面臨的情況更加糟糕。例如支付系統(tǒng)最終是通過 A 服務(wù)商進行支付的，如果 A 服務(wù)商突然掛了，那我們的支付系統(tǒng)是不是就掛了？那有什么辦法可以在這種情況（災(zāi)難）發(fā)生的時候，讓我們的系統(tǒng)還能夠正常提供服務(wù)呢？這就是容災(zāi)設(shè)計需要做的事情了，接下來將重點介紹一些容災(zāi)設(shè)計方案。

① 消除單點

從請求發(fā)起側(cè)到服務(wù)處理返回的調(diào)用全鏈路的各個環(huán)節(jié)上避免存在單點（某個環(huán)節(jié)只由單個服務(wù)器完成功能），做到每個環(huán)節(jié)使用相互獨立的多臺服務(wù)器進行分布式處理，要針對不同穩(wěn)定性要求級別和成本能力做到不同服務(wù)器規(guī)模分布式，這樣就避免單個服務(wù)器掛掉引發(fā)單點故障后進而導(dǎo)致服務(wù)整體掛掉的風(fēng)險。

可能涉及的環(huán)節(jié)有端動態(tài)獲取資源服務(wù)(html js 小程序包等)、域名解析、多服務(wù)商多區(qū)域多機房IP入口、靜態(tài)資源服務(wù)、接入路由層、服務(wù)邏輯層、任務(wù)調(diào)度執(zhí)行層、依賴的微服務(wù)、數(shù)據(jù)庫及消息中間件。

冗余依賴，消除單點的策略：

在服務(wù)邏輯層采用多運營商多IP入口、跨地同地多機房部署、同機房多機器部署、分布式任務(wù)調(diào)度等策略。

在數(shù)據(jù)存儲層采用數(shù)據(jù)庫分庫分表、數(shù)據(jù)庫主從備集群、KV存儲消息等分布式系統(tǒng)集群多副本等策略。

有分布式處理能力后，需要考慮單個服務(wù)器故障后自動探活摘除、服務(wù)器增刪能不停服自動同步給依賴方等問題，這里就需引入一些分布式中樞控制系統(tǒng)，如服務(wù)注冊發(fā)現(xiàn)系統(tǒng)、配置變更系統(tǒng)等，例如zookeeper是一個經(jīng)典應(yīng)用于該場景的一個分布式組件。

② 冗余設(shè)計

冗余設(shè)計，對于飛機而言，體現(xiàn)在機組包括機長副機長，引擎至少雙發(fā)，操作系統(tǒng)至少兩套等等，于我們的系統(tǒng)而言，則通常體現(xiàn)在:

數(shù)據(jù)冗余，數(shù)據(jù)多份副本，DB 一主多備，出現(xiàn)問題時可以快速切換。

計算能力冗余，服務(wù)器的計算能力始終保持一定冗余，在一組服務(wù)器出現(xiàn)問題時其他服務(wù)器可以接替提供服務(wù),亦或在業(yè)務(wù)量波動時可以承受沖擊。

網(wǎng)絡(luò)，存儲或其他基礎(chǔ)設(shè)施冗余，出現(xiàn)意外時，比如斷電，光纖斷裂時均有備用可以實現(xiàn)切換，快速恢復(fù)。

③ 強弱依賴

當(dāng)服務(wù)依賴各類微服務(wù)時，避免強依賴（依賴服務(wù)掛掉會到自己服務(wù)掛掉），盡可能在對應(yīng)服務(wù)出現(xiàn)問題時做到自動降級處理（弱依賴）或者手工降級，降級后依賴服務(wù)功能局部去掉或做合適局部提示，局部體驗上有部分降級，但不會讓主鏈路和整體功能掛掉。

對于穩(wěn)定性要求很好的關(guān)鍵系統(tǒng)，在成本可接受的情況下，同時維護一套保障主鏈路可用的備用系統(tǒng)和架構(gòu)，在核心依賴服務(wù)出現(xiàn)問題能做一定時間周期的切換過渡（例如mysql故障，階段性使用KV數(shù)據(jù)庫等）。

強依賴的服務(wù)越少，系統(tǒng)整體基礎(chǔ)穩(wěn)定性就越高。部分特殊數(shù)據(jù)依賴多于邏輯依賴的系統(tǒng)，做去依賴架構(gòu)設(shè)計也是一個思路，將依賴服務(wù)數(shù)據(jù)統(tǒng)一整合到自有服務(wù)的數(shù)據(jù)存儲中，通過消息 或定時更新的方式更新，做到不依賴 或少依賴其他系統(tǒng)，進而提高穩(wěn)定性，但這樣做也會有副作用：數(shù)據(jù)冗余可能會引發(fā)不同程度一定時間窗口數(shù)據(jù)不一致性。

④ 熱點極限值處理

業(yè)務(wù)規(guī)模以及數(shù)據(jù)規(guī)模大的部分系統(tǒng)，在系統(tǒng)中會出現(xiàn)數(shù)據(jù)熱點、數(shù)據(jù)極度傾斜、少量大客戶超過極限閾值使用等極限場景，例如超級大客戶廣告投放物料、廣告點擊展示數(shù)據(jù)、API調(diào)用頻次都是比普通客戶大很多，如果按照客戶維度分庫分表，基本在物料更新、查詢、報表查看等一系列的場景都可能導(dǎo)致單庫抖動，這除了影響大客戶自己外也會影響分布在該分庫分表上所有普通客戶。

電商中極度暢銷商品以及秒殺、微博等訂閱類明星大V的信息發(fā)布等都是少量極限場景可能會引發(fā)整體系統(tǒng)穩(wěn)定性問題。因此，架構(gòu)設(shè)計時，要分析自己系統(tǒng)中是否存在極限場景并設(shè)計對應(yīng)方案做好應(yīng)對。

極限場景中不同類型場景處理架構(gòu)方案也不一樣，可能的方式：

大客戶從普通客戶分庫分表中拆出來隔離建庫表，隔離享用專有資源以及獨立庫表拆分路由邏輯以及隔離服務(wù)邏輯計算資源；

大客戶特定極限數(shù)據(jù)計算做預(yù)約計算以及預(yù)加載，在低峰期預(yù)約或提前優(yōu)化完成；

秒殺系統(tǒng)極限值可以考慮核心邏輯簡化+消息解耦、同商品庫存拆分獨立交易、部分查詢或處理KV存儲替代關(guān)系型存儲、數(shù)據(jù)提前預(yù)熱加載、排隊、限流策略等策略；

在特定極限值系統(tǒng)架構(gòu)以及資源無法滿足的情況，產(chǎn)品側(cè)以及技術(shù)側(cè)要明確采用最高閾值調(diào)用限制。

⑤ 資損風(fēng)險

交易系統(tǒng)對于數(shù)據(jù)準(zhǔn)確性、一致性、資金損失等都是很敏感的，這一塊在是否使用緩存、事務(wù)一致性考量、數(shù)據(jù)時延、數(shù)據(jù)不丟不重、數(shù)據(jù)精準(zhǔn)核對和恢復(fù)等需要額外架構(gòu)設(shè)計考量。

仔細評估交易以及營銷的全鏈路各個環(huán)節(jié)，評估其中出現(xiàn)資損的可能性以及做好應(yīng)對設(shè)計，例如增加多層級對賬、券總額度控制、異常金額限制和報警等資損防控的考量等。

不同層次不同維度不同時間延遲的對賬以及預(yù)案是一個重要及時感知資損和止血的有效方式。全鏈路的過程數(shù)據(jù)要做好盡可能持久化和冗余備份，方便后續(xù)核對以及基于過程數(shù)據(jù)進行數(shù)據(jù)修復(fù)，同時盡量針對特殊數(shù)據(jù)丟失場景提供快速自動化修復(fù)處理預(yù)案（如交易消息可選擇性回放和基于冪等原則的重新消費）。

⑥ 彈性處理

消息重復(fù)消費、接口重復(fù)調(diào)用對應(yīng)的服務(wù)是否保證冪等？是否考慮了服務(wù)降級？哪些業(yè)務(wù)支持降級？支持自動降級還是手工降級？是否考慮了服務(wù)的超時熔斷、異常熔斷、限流熔斷？觸發(fā)熔斷后對客戶的影響？服務(wù)是否做了隔離，單一服務(wù)故障是否影響全局？這些問題統(tǒng)統(tǒng)需要我們想清楚對應(yīng)的解決方案，才會進一步保證架構(gòu)設(shè)計的合理性。

⑦ 兼容性

上下游依賴是否梳理過，影響范圍多大？怎么進行新老系統(tǒng)替換？新老系統(tǒng)能否來回切換？數(shù)據(jù)存儲是否兼容老的數(shù)據(jù)處理？如果對你的上下游系統(tǒng)有影響，是否通知到上下游業(yè)務(wù)方？上下游依賴方進行升級的方案成本如何最小化？這些問題需要有完美的解決方案，稍有不慎會導(dǎo)致故障。

⑧ 安全性

是否徹底避免 SQL 注入和 XSS？是否有數(shù)據(jù)泄露的可能性？是否做了風(fēng)控策略？接口服務(wù)是否有防刷保護機制？數(shù)據(jù)、功能權(quán)限是否做了控制？小二后臺系統(tǒng)是否做了日志審計？數(shù)據(jù)傳輸是否加密驗簽？應(yīng)用代碼中是否有明文的 AK/SK、密碼？這些安全細節(jié)問題需要我們統(tǒng)統(tǒng)考慮清楚，安全問題任何時候都不能輕視。

⑨ 其他異常情況

整體系統(tǒng)架構(gòu)高可用還需要考慮可測性、可運維性，除了正向邏輯、性能、擴展性設(shè)計等外，要增加一個異常設(shè)計視角，窮盡思考各類異常情況以及設(shè)計應(yīng)對策略。

4）容量評估

系統(tǒng)設(shè)計整體至少考慮應(yīng)對5到10倍或近1到3年系統(tǒng)規(guī)模增長，要保障后續(xù)通過增加機器資源等快速方式能實現(xiàn)系統(tǒng)水平擴容。例如分庫分表的規(guī)模提前設(shè)計好提前量，避免臨時數(shù)據(jù)庫能力不足導(dǎo)致需要臨時重構(gòu)擴容（增加分庫分表以及修改路由以及遷移數(shù)據(jù)）；服務(wù)邏輯層設(shè)計持有數(shù)據(jù)狀態(tài)導(dǎo)致無法加機器做服務(wù)層擴容。

互聯(lián)網(wǎng)產(chǎn)品發(fā)展變化較快，不一定會如期爆發(fā)，容量架構(gòu)設(shè)計上也要注意不要過度提前設(shè)計，避免提前復(fù)雜化引發(fā)研發(fā)效率以及機器成本問題。

針對線上流量峰值，建議系統(tǒng)常態(tài)保持近期峰值3倍左右容量余量，上線前和上線后要定期做壓測摸高，寫流量可用影子表等方式做壓測，壓測可單接口以及模擬線上流量分布壓測結(jié)合，根據(jù)壓測結(jié)果優(yōu)化架構(gòu)或擴容，持續(xù)保持容量富余。

對于可能超過系統(tǒng)現(xiàn)有容量的突發(fā)峰值，限流策略是線上要配置的策略。入口側(cè)入口流量調(diào)用 、不同渠道服務(wù)依賴調(diào)用、對依賴服務(wù)的調(diào)用都要評估可極限調(diào)研的上限值，通過中間件等合適方式限制超過閾值調(diào)用，避免引發(fā)雪崩效應(yīng)。特定業(yè)務(wù)系統(tǒng)，對于超過峰值流量，可以通過消息架構(gòu)以及合適體驗設(shè)計做削峰填谷。針對惡意攻擊流量也要考慮在入口層部署防DDOS攻擊的流量清洗層。

部分系統(tǒng)峰值變化較大且需要持續(xù)盡可能承載保障，可考慮引入彈性伸縮策略，預(yù)約 或根據(jù)流量變化觸發(fā)系統(tǒng)自動擴縮容，以確保以盡量小成本來自動化滿足變化峰值。

上線中

上線時這個階段，主要是確保功能按照原先設(shè)計的方案進行部署，這個階段主要是確保規(guī)范操作，避免失誤，因此可以制定相關(guān)的 CheckList 以及變更審批。其次，為了避免還可能存在未發(fā)現(xiàn)的功能缺陷，有時候還可以使用灰度發(fā)布降低風(fēng)險。在這個階段能做的一些穩(wěn)定性建設(shè)如下圖所示。

對于發(fā)布前的checklist更多可以參考前面所講的發(fā)布計劃，發(fā)布后的checklist更多的需要根據(jù)測試提供的測試用例進行生產(chǎn)環(huán)境回歸測試驗證。

這里涉及到的變更審批非常關(guān)鍵，根據(jù)實際情況，有些審批可以提前提交申請。

灰度保障及時在小流量情況，發(fā)現(xiàn)問題，避免引發(fā)大范圍故障。因此在做系統(tǒng)任何變更時，要考慮灰度方案，特別是大用戶流量系統(tǒng)?；叶确绞娇赡苡邪酌麊斡脩?、按用戶Id固定劃分后不同流量比例、機器分批發(fā)布、業(yè)務(wù)概念相關(guān)分組分比例（例如某個行業(yè)、某個商品、某類商品）等，灰度周期要和結(jié)合系統(tǒng)風(fēng)險和流量做合適設(shè)計，重要系統(tǒng)灰度周期可能持續(xù)超過一周或更多。

上線后

當(dāng)系統(tǒng)成功上線后，很多小伙伴以為工作就結(jié)束了，但實際上我們還有不少工作可以做。根據(jù)我的經(jīng)驗，在上線后我們能做的穩(wěn)定性建設(shè)包括：

監(jiān)控報警

故障管理

緊急預(yù)案

故障容災(zāi)演練

案例學(xué)習(xí)

全鏈路壓測

全鏈路跟蹤

1）監(jiān)控告警

監(jiān)控報警，指的是我們需要對應(yīng)用做好運行數(shù)據(jù)的收集，監(jiān)控好系統(tǒng)的運行狀態(tài)。當(dāng)系統(tǒng)狀態(tài)異常時，我們需要及時地發(fā)現(xiàn)并報警，從而讓研發(fā)人員快速地解決問題。一般來說，監(jiān)控報警分為系統(tǒng)級別的監(jiān)控報警和業(yè)務(wù)級別的監(jiān)控報警。系統(tǒng)級別的監(jiān)控報警包括 CPU、內(nèi)存、磁盤等服務(wù)器資源的監(jiān)控，而業(yè)務(wù)級別的報警則需要根據(jù)業(yè)務(wù)情況自行定義。

2）故障容災(zāi)演練

故障容災(zāi)演練需要從已知、半已知和未知三個維度去做。

已知：已知故障類型，按照應(yīng)急預(yù)案SOP，一步一步去做，從生疏到熟練，從20分鐘到5分鐘，從有限的人能做變成所有人能做。

半已知：在已知故障類型的演練中，發(fā)現(xiàn)了未知因素，如：當(dāng)緩存集群故障的時候，切換到備用緩存集群，但發(fā)現(xiàn)備用緩存集群里面的緩存數(shù)據(jù)有問題，需要重新清空及重新進行緩存預(yù)熱。

未知：未知故障類型，臨時決策安排人員有序散開排查，臨時根據(jù)現(xiàn)象定位問題，采用回滾版本或者重啟等方式嘗試性解決問題，或定位到問題后，采用有損的方式試圖臨時解決問題等。

故障容災(zāi)演練是提升系統(tǒng)穩(wěn)定性的一把利器，很多時候即使我們設(shè)計得很完美，但實際上卻沒發(fā)揮作用，究其根本就是沒有實踐過。是驢是馬，得拉出來溜溜才知道。

3）故障管理

故障管理，就是當(dāng)發(fā)生故障時，我們需要遵循的整套處理規(guī)范。 團隊小的時候可能無所謂，但是當(dāng)團隊大了的時候，我們就需要統(tǒng)一大家的故障處理流程，從而可以更快速地解決故障。此外，在故障解決完成之后還需要進行復(fù)盤，產(chǎn)出對應(yīng)的故障報告。

4）Case Study

Case Study 機制指的是定期學(xué)習(xí)其他團隊的高可用或者線上故障進行學(xué)習(xí)，從而提高團隊的系統(tǒng)設(shè)計能力，避免踩坑。

5）緊急預(yù)案

緊急處理預(yù)案，簡單就是要想到各種可能發(fā)現(xiàn)的情況，然后做好預(yù)案。之后結(jié)合容災(zāi)演練不斷進行優(yōu)化，從而形成一套很好的處理預(yù)案。這樣當(dāng)線上發(fā)生類似故障時，就可以輕松應(yīng)對了。

在發(fā)生故障的時候，大多數(shù)人的腦子都是一片空白，很難迅速做出最合理的反應(yīng)。衡量一個應(yīng)急預(yù)案的好壞，關(guān)鍵是看它是否足夠“無腦化”。

舉個例子：如果發(fā)現(xiàn)了故障A，那么我們需要排查B和C兩個方面來精準(zhǔn)定位問題，定位后，我們再通過D—E—F三個操作來解決問題。

即：整個過程中，只需要照做，不需要思考，因為思考就會產(chǎn)生選擇，而選擇取舍是最耗費時間的事情，如果做不到這點，那么證明應(yīng)急預(yù)案還有優(yōu)化的空間。

另外，預(yù)案也不是一蹴而就的事情，需要跟隨架構(gòu)和業(yè)務(wù)的演進，不斷進行更新迭代，同時，也需要不斷做減法，該摒棄的摒棄，該合并的合并，如果只增不減，那么一年以后，預(yù)案就會變成一本書。

緊急預(yù)案一般要包含如下內(nèi)容：

故障發(fā)生時應(yīng)該通知哪些人或團隊；

如何選出協(xié)調(diào)者，什么情況下該選出協(xié)調(diào)者；

協(xié)調(diào)者的職責(zé)有哪些；

需要操作開關(guān)時，誰有權(quán)利決策；

常見故障以及對應(yīng)的止損方式；

止損的原則是什么，什么是最重要的。善后方案誰來拍板；

預(yù)案很重要，完備的預(yù)案能降低故障定位和止損的時間，提升協(xié)作效率。

6）自動防御

這是件很能體現(xiàn)出工程師能力和素養(yǎng)的事情，需要工程師在coding過程中，在任何關(guān)鍵環(huán)節(jié)都具備安全意識。如：

當(dāng)下游依賴的存儲集群，由于不可用而觸發(fā)代碼中的失敗次數(shù)或失敗時間閾值時，自動切換到備用的存儲集群。

當(dāng)下游依賴的核心服務(wù)，由于不可用而觸發(fā)代碼中的失敗次數(shù)或失敗時間閾值時，自動降級到備用方案，如：將請求切換到存儲非實時數(shù)據(jù)的ES中，接受有損。

當(dāng)系統(tǒng)由于響應(yīng)時間激增而導(dǎo)致服務(wù)不可用時，自動對下游依賴的非核心服務(wù)進行降級熔斷，減少服務(wù)接口的整體響應(yīng)時間，保證可用。

7）全鏈路壓測

全鏈路壓測，指的是對整個鏈路進行壓測。不同公司可能會采用不同的方案，有些會直接在線上進行壓測，然后用流量標(biāo)記的方式識別測試流量。有些則是進行流量錄制，之后重新搭建一套與線上非常類似的系統(tǒng)進行壓測。一般來說，第一種效果肯定會更好，成本也更低，但是對研發(fā)人員要求也更高，風(fēng)險也更大。比如阿里天貓每年雙11都會進行全鏈路壓測，基于線上流量回放機制。

8）全鏈路跟蹤

全鏈路跟蹤是生產(chǎn)環(huán)境問題排查利器，開源的有skywalking，阿里內(nèi)部對應(yīng)的是eagleeye，能夠根據(jù)請求traceid，快速診斷出生產(chǎn)環(huán)境bug。

四、技術(shù)團隊文化

人的意識是最重要的，專業(yè)能力可以鍛煉培養(yǎng)。如果意識不足或松懈，好的能力以及機制流程也會形同虛設(shè)。

永遠要對敬畏線上，敬畏客戶體驗。面向線上的穩(wěn)定性戰(zhàn)術(shù)上可以基于專業(yè)度鍛煉后自信，但戰(zhàn)略和思想上必須持續(xù)如履薄冰、三省吾身。線上穩(wěn)定性保障是作為技術(shù)人自己專業(yè)度的追求和必須保持初心，始終保持敬畏。不因為業(yè)務(wù)繁忙、個人心情狀態(tài)、團隊是否重視而有變化，只要職責(zé)在，就要守護好。技術(shù)主管以及系統(tǒng)owner要有持續(xù)感知穩(wěn)定性隱患和風(fēng)險，保持銳度，集中性以及系統(tǒng)性查差補漏。

團隊工作規(guī)范

1）日常巡檢

為什么要把系統(tǒng)健康度巡檢放到技術(shù)管理里，我覺得這是一個非常重要的環(huán)節(jié)。像傳統(tǒng)的航空、電力、汽車行業(yè)都要有一定的巡檢機制，保障設(shè)備系統(tǒng)正常運轉(zhuǎn)，同樣軟件系統(tǒng)也同樣需要巡檢機制保障業(yè)務(wù)健康發(fā)展。

隨著業(yè)務(wù)的不斷發(fā)展，業(yè)務(wù)量和數(shù)據(jù)量不斷的上漲，系統(tǒng)架構(gòu)的腐蝕是避免不了的，為了保障系統(tǒng)的健康度，需要不斷的考慮對系統(tǒng)架構(gòu)、性能進行優(yōu)化。

系統(tǒng)的監(jiān)控與報警能夠一定程度發(fā)現(xiàn)系統(tǒng)存在的問題，系統(tǒng)存在的一些隱患需要通過對系統(tǒng)的巡檢去發(fā)現(xiàn)，如果優(yōu)化不及時在極端情況會導(dǎo)致故障，巡檢粒度建議每周巡檢一次自己所負責(zé)的業(yè)務(wù)系統(tǒng)。

系統(tǒng)巡檢重點要關(guān)注如下幾點：

系統(tǒng)指標(biāo)：系統(tǒng) CPU、負載、內(nèi)存、網(wǎng)絡(luò)、磁盤有無異常情況波動，確認是否由發(fā)布導(dǎo)致，還是系統(tǒng)調(diào)用異常。

慢接口：通常 RT 大于3s的接口需要重點關(guān)注，極端并發(fā)場景下容易導(dǎo)致整個系統(tǒng)雪崩。

慢查詢：MySQL 慢查詢需要重點關(guān)注，隨著數(shù)據(jù)量上漲，需要對慢查詢進行優(yōu)化。

錯誤日志：通過錯誤日志去發(fā)現(xiàn)系統(tǒng)隱藏的一些 BUG，避免這些 BUG 被放大，甚至極端情況下會導(dǎo)致故障。

2）每個報警不要放過，每個報警及時響應(yīng)處理

快速定位和快速恢復(fù)是個人以及團隊專業(yè)能力沉淀，但快速報警響應(yīng)是每個敬畏線上敬畏用戶體驗的技術(shù)同學(xué)可以做到的。

在監(jiān)控完備和持續(xù)前提下，每個報警及時處理即可以降低故障影響范圍，也會持續(xù)減少小的隱患。報警一些小的實踐技巧：報警按照方向收斂報警群，建立報警天級值班機制，報警短信手機設(shè)置為震動模式（不打擾同空間家人或朋友情況下，自己第一時間感知），主管要訂閱報警作為團隊報警兜底處理人，報警響應(yīng)好的同學(xué)和不好的同學(xué)要數(shù)據(jù)化表揚和批評。

從團隊角度，報警及時響應(yīng)必須配合報警治理進行，否則過多無效報警也會讓有責(zé)任心的同學(xué)變得麻木。所以必須控制無效報警的數(shù)量，例如單應(yīng)用無效報警（不需要線上問題進行定位以及修復(fù)處理的）不要超過5條，個人維度無效報警天級別不超過10條。

3）線上問題要復(fù)盤，不論是否為定級故障，不論問題大小

小的線上問題也要復(fù)盤，復(fù)盤準(zhǔn)備度可以低于定級故障，但都需要思考反思以及落實優(yōu)化Action。小的線上問題就是未來線上故障的前兆。我們團隊周會上都會有一個環(huán)節(jié)，上周如有線上問題則會安排對觸發(fā)人做復(fù)盤。

4）每個用戶反饋要重視，定位到根本原因

一個用戶反饋背后必然有多個實際線上問題，只是這個用戶無法忍受，知道反饋路徑以及對這個產(chǎn)品有熱愛 或強依賴才選擇反饋的。徹底定位一個voc，就是修復(fù)了一類線上問題。而且到用戶反饋的程度，這個線上問題就已經(jīng)有一定程度用戶體驗影響了。我們現(xiàn)在技術(shù)團隊有一個voc日清機制，針對線上voc問題對用戶做好日內(nèi)響應(yīng)答復(fù)，也是一個不錯對于這個意識的數(shù)字化衡量。

人員能力培養(yǎng)

單個技術(shù)同學(xué)個人技術(shù)以及穩(wěn)定性保障能力是團隊在每個穩(wěn)定性任務(wù)上拿到結(jié)果的執(zhí)行者和基礎(chǔ)，因此技術(shù)主管重視識別不同同學(xué)個人優(yōu)勢和不足，針對性做工作安排以及培養(yǎng)鍛煉。只要線上意識上足夠重視，能力對于大部門技術(shù)同學(xué)是可以培養(yǎng)的。

團隊內(nèi)同學(xué)由于入行時間、歷史經(jīng)驗等各方面原因，對于當(dāng)前系統(tǒng)穩(wěn)定性保障能力是有強弱的差異的，對于個人是正常情況，但對于團隊而言，不能因為團隊個別同學(xué)能力上存在不足而引入團隊層面穩(wěn)定性保障風(fēng)險。

需要主管很好熟悉以及判斷同學(xué)能力段位，在負責(zé)系統(tǒng)和模塊、流程機制約束、輔導(dǎo)人等方面做好差異化安排。例如校招同學(xué)X個月不做線上發(fā)布，前X個月發(fā)布有師兄協(xié)同發(fā)布機制，并發(fā)高 或資金交易等等風(fēng)險高的系統(tǒng)讓更加有經(jīng)驗的負責(zé)。同時設(shè)計培養(yǎng)機制，能力當(dāng)前不足但有潛力的同學(xué)，可以安排由經(jīng)驗豐富的同學(xué)指導(dǎo)以及提供一些進階實操路徑，按照節(jié)奏從易到難逐漸承擔(dān)更高風(fēng)險的系統(tǒng)職責(zé)。

能力培養(yǎng)方式有技術(shù)Review、代碼CR和輔導(dǎo)、參與團隊穩(wěn)定性保障機制、安排合適師兄指導(dǎo)、過程中主管指導(dǎo)、逐漸承擔(dān)更高職責(zé)等。代碼層面，對于Java同學(xué)來說， 《阿里巴巴Java開發(fā)手冊》是一個很好的實踐性指南，超出代碼風(fēng)格，提供了日志、異常處理、集合等庫使用、數(shù)據(jù)庫設(shè)計、分層設(shè)計等多個提升代碼質(zhì)量的實踐做法，我們自己團隊所有Java研發(fā)同學(xué)都會100%通過阿里云上阿里巴巴代碼認證考試，同時團隊有一個團隊內(nèi)新人品碼機制，這些都是不錯地培養(yǎng)同學(xué)寫出好代碼的培養(yǎng)方式。

好多小團隊、大團隊、公司都有很多不錯提升穩(wěn)定性機制和案例，積極主動參考學(xué)習(xí)以及結(jié)合自己業(yè)務(wù)系統(tǒng)思考踐行，是自己提升的重要路徑。架構(gòu)上高可用以及架構(gòu)相關(guān)經(jīng)典書籍自我學(xué)習(xí)，從理論上做系統(tǒng)性認知也是有必要。

五、總結(jié)

在軟件架構(gòu)上有一句名言，沒有最完美的架構(gòu)，只有最適合的架構(gòu)。推廣到穩(wěn)定性上，沒有完全完美的穩(wěn)定性方案，只有適合的穩(wěn)定性方案。

系統(tǒng)穩(wěn)定性壓倒一切，只有保障了好了穩(wěn)定性，才能幫助業(yè)務(wù)蓬勃增長，因此穩(wěn)定性治理始終是工程師基本能力之一。

穩(wěn)定性建設(shè)是一個系統(tǒng)的基石，也是一個持續(xù)的過程，面對業(yè)務(wù)的不同發(fā)展階段，對穩(wěn)定性的落地要求不同，取舍也不同（適合的才是最好的~），但隨著業(yè)務(wù)發(fā)展，占比越來越大，關(guān)注點也會越來越高。

作者丨孔凡勇

來源丨公眾號：互聯(lián)網(wǎng)技術(shù)集中營（ID：gh_68f7d245f87a）

dbaplus社群歡迎廣大技術(shù)人員投稿，投稿郵箱：editor@dbaplus.cn

關(guān)于我們

dbaplus社群是圍繞Database、BigData、AIOps的企業(yè)級專業(yè)社群。資深大咖、技術(shù)干貨，每天精品原創(chuàng)文章推送，每周線上技術(shù)分享，每月線下技術(shù)沙龍，每季度GdevopsDAMS行業(yè)大會。

關(guān)注公眾號【dbaplus社群】，獲取更多原創(chuàng)技術(shù)文章和精選工具下載