前言

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

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

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

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

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

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

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

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

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

展開(kāi)全文

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

它其實(shí)是一個(gè)綜合指標(biāo)，為什么這么說(shuō)？因?yàn)槲覀冊(cè)诜?wù)可用的定義上會(huì)有一些差別，常見(jiàn)的服務(wù)可用包括：服務(wù)無(wú)異常、服務(wù)響應(yīng)時(shí)間低、服務(wù)有效（邏輯正確）、服務(wù)能正常觸發(fā)等。

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

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

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

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

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

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

上線前

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

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

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

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

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

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

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

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

未測(cè)試需求直接上線

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

上線的新需求有 bug

上線后沒(méi)有線上驗(yàn)證

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

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

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

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

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

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

① 編碼規(guī)范

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

② 技術(shù)方案評(píng)審

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

③ 代碼評(píng)審

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

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

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

④ 發(fā)布計(jì)劃評(píng)審

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

① 消除單點(diǎn)

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

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

冗余依賴，消除單點(diǎn)的策略：

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

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

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

② 冗余設(shè)計(jì)

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

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

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

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

③ 強(qiáng)弱依賴

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

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

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

④ 熱點(diǎn)極限值處理

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

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

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

大客戶從普通客戶分庫(kù)分表中拆出來(lái)隔離建庫(kù)表，隔離享用專(zhuān)有資源以及獨(dú)立庫(kù)表拆分路由邏輯以及隔離服務(wù)邏輯計(jì)算資源；

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

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

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

⑤ 資損風(fēng)險(xiǎn)

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

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

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

⑥ 彈性處理

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

⑦ 兼容性

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

⑧ 安全性

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

⑨ 其他異常情況

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

4）容量評(píng)估

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

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

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

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

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

上線中

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

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

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

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

上線后

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

監(jiān)控報(bào)警

故障管理

緊急預(yù)案

故障容災(zāi)演練

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

全鏈路壓測(cè)

全鏈路跟蹤

1）監(jiān)控告警

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

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

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

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

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

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

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

3）故障管理

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

4）Case Study

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

5）緊急預(yù)案

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

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

舉個(gè)例子：如果發(fā)現(xiàn)了故障A，那么我們需要排查B和C兩個(gè)方面來(lái)精準(zhǔn)定位問(wèn)題，定位后，我們?cè)偻ㄟ^(guò)D—E—F三個(gè)操作來(lái)解決問(wèn)題。

即：整個(gè)過(guò)程中，只需要照做，不需要思考，因?yàn)樗伎季蜁?huì)產(chǎn)生選擇，而選擇取舍是最耗費(fèi)時(shí)間的事情，如果做不到這點(diǎn)，那么證明應(yīng)急預(yù)案還有優(yōu)化的空間。

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

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

故障發(fā)生時(shí)應(yīng)該通知哪些人或團(tuán)隊(duì)；

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

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

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

常見(jiàn)故障以及對(duì)應(yīng)的止損方式；

止損的原則是什么，什么是最重要的。善后方案誰(shuí)來(lái)拍板；

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

6）自動(dòng)防御

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

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

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

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

7）全鏈路壓測(cè)

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

8）全鏈路跟蹤

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

四、技術(shù)團(tuán)隊(duì)文化

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

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

團(tuán)隊(duì)工作規(guī)范

1）日常巡檢

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

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

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

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

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

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

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

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

2）每個(gè)報(bào)警不要放過(guò)，每個(gè)報(bào)警及時(shí)響應(yīng)處理

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

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

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

3）線上問(wèn)題要復(fù)盤(pán)，不論是否為定級(jí)故障，不論問(wèn)題大小

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

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

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

人員能力培養(yǎng)

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

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

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

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

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

五、總結(jié)

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

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

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

作者丨孔凡勇

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

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

關(guān)于我們

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

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