背景

穩(wěn)定性建設(shè)需要一系列具體的建設(shè)活動(dòng)推進(jìn)和落地，這些建設(shè)活動(dòng)涉及人員、機(jī)制和文化，全方位的建設(shè)活動(dòng)才能更好地落實(shí)建設(shè)模式。

一、穩(wěn)定性保障機(jī)制

穩(wěn)定性涉及團(tuán)隊(duì)所有不同水平技術(shù)人員、所有系統(tǒng)、研發(fā)所有環(huán)節(jié)、線上時(shí)時(shí)刻刻，單個(gè)技術(shù)人員是無法保障好的，必須建立團(tuán)隊(duì)流程機(jī)制來可持續(xù)保障。

人為因素的根源一方面是專業(yè)能力不足，經(jīng)驗(yàn)不足，另一方面很多都是無心之失，所以需要通過流程、規(guī)范來保住“底線”，減少人為因素導(dǎo)致的故障。大家嚴(yán)格遵守咱們的各種規(guī)范即可（CodeReview規(guī)范、發(fā)布xbp流程、上線后doublecheck機(jī)制）。通過流程和doublecheck機(jī)制確保每個(gè)人發(fā)布不會(huì)太差，解決人的因素。永遠(yuǎn)要記住團(tuán)隊(duì)的力量是無窮的，要學(xué)會(huì)借力。

1、規(guī)范先行

穩(wěn)定性關(guān)鍵還是要靠大家，如何靠大家呢？穩(wěn)定性工作，規(guī)范先行.就是要落地一套穩(wěn)定性的機(jī)制體系，用機(jī)制的嚴(yán)格執(zhí)行來約束大家，不然無法展開。這套機(jī)制包括：

?方案評審機(jī)制：在完成系統(tǒng)的建設(shè)或改造方案初稿后，需通過由業(yè)務(wù)、技術(shù)、測試、運(yùn)維領(lǐng)域組成的團(tuán)隊(duì)進(jìn)行方案評審，才能進(jìn)一步對方案進(jìn)行實(shí)施。

?架構(gòu)設(shè)計(jì)規(guī)范：概要設(shè)計(jì)、模塊詳細(xì)設(shè)計(jì)、API、Domain、數(shù)據(jù)緩存、容錯(cuò)設(shè)計(jì)、風(fēng)險(xiǎn)設(shè)計(jì)等。

?代碼編寫規(guī)范：規(guī)范覆蓋代碼基礎(chǔ)、日志、配置、多線程、數(shù)據(jù)庫、異常使用等多層面，提升代碼質(zhì)量；

?代碼評審規(guī)范：changelist描述、兼容性、性能、復(fù)雜性、團(tuán)隊(duì)評審文化等。

?代碼提測規(guī)范：Test單測、代碼編譯構(gòu)建、系統(tǒng)運(yùn)行穩(wěn)定性等、

?代碼測試規(guī)范：進(jìn)入穩(wěn)定性測試階段，要嚴(yán)格審查系統(tǒng)是否達(dá)到測試準(zhǔn)入條件，即滿足測試實(shí)施的所有必要條件，如果未滿足，則不開展穩(wěn)定性測試。在穩(wěn)定性測試實(shí)施結(jié)束后，嚴(yán)格檢查所有測試準(zhǔn)出條件是否滿足，如：沒有進(jìn)行中的缺陷等，否則不予測試通過。

?預(yù)發(fā)&引流壓測規(guī)范：黃金鏈路必須進(jìn)行R2引流驗(yàn)證。

?發(fā)布上線規(guī)范：可灰度、可驗(yàn)證、可回滾等

?驗(yàn)收規(guī)范：業(yè)務(wù)、產(chǎn)品驗(yàn)收規(guī)范

?制定變更規(guī)范：提供變更級(jí)別、角色職責(zé)、活動(dòng)階段以及輸入輸出的詳細(xì)規(guī)定

?制定運(yùn)維操作規(guī)范：針對公司日志標(biāo)準(zhǔn)，提供統(tǒng)一的日志排查命令及規(guī)范。

?報(bào)警響應(yīng)機(jī)制：針對運(yùn)維相關(guān)的監(jiān)控告警制定告警處理流程、告警升級(jí)機(jī)制

?值班及責(zé)任判定機(jī)制：設(shè)置值班制度，每天有技術(shù)人員負(fù)責(zé)值班，值班周期內(nèi)的所有問題由值班人員治理，不能及時(shí)完成的，添加到BUG定期跟蹤并統(tǒng)計(jì)。在出現(xiàn)生產(chǎn)事件后，由專家團(tuán)隊(duì)對該問題進(jìn)行詳細(xì)分析，確定問題的發(fā)生原因、解決辦法后，對該問題進(jìn)行問責(zé)，明確責(zé)任團(tuán)隊(duì)、責(zé)任人、責(zé)任承擔(dān)比例等內(nèi)容。避免在穩(wěn)定性治理中產(chǎn)生“囚徒困境”。

?故障管理機(jī)制：故障管理機(jī)制包括規(guī)范管理故障響應(yīng)流程、故障升級(jí)機(jī)制、故障復(fù)盤機(jī)制，規(guī)范技術(shù)人員在應(yīng)對突發(fā)故障時(shí)的操作流程，明確職責(zé)邊界，提升溝通效率，推動(dòng)故障閉環(huán)，提升故障處理效率2、開發(fā)和SER的區(qū)別

提到穩(wěn)定性，先講個(gè)概率SRE（Site Reliability Engineering，站點(diǎn)可靠性/穩(wěn)定性工程師）

一說到 Software Developer，人們腦子里就能反映出需求評審、編碼、調(diào)試、測試、上線、修 bug等具體工作內(nèi)容。那 SRE 呢？SRE與普通的開發(fā)工程師（Dev）不同，也與傳統(tǒng)的運(yùn)維工程師（Ops）不同，SRE更接近是兩者的結(jié)合，也就是2008年末提出的一個(gè)概念：DevOps，這個(gè)概念最近也越來越流行起來。SRE模型是Google對Dev+Ops模型的一種實(shí)踐和拓展（可以參考《Google運(yùn)維解密》一書），SRE這個(gè)概念我比較喜歡，因?yàn)檫@個(gè)詞不簡單是兩個(gè)概念的疊加，而是一種對系統(tǒng)穩(wěn)定性、高可用、團(tuán)隊(duì)持續(xù)迭代和持續(xù)建設(shè)的體系化解決方案；

都是做技術(shù)的，很多開發(fā)剛剛轉(zhuǎn)向穩(wěn)定性方面時(shí)，有些彎轉(zhuǎn)不過來。舉個(gè)例子：對于“問題”，傳統(tǒng)的開發(fā)人員更多的傾向于是“bug/錯(cuò)誤”，而SRE傾向于是一種“風(fēng)險(xiǎn)/故障”，所以，兩者對“問題”的處理方法是不一樣的：

?開發(fā)：了解業(yè)務(wù) -> 定位問題 -> 排查問題 -> 解決問題

?SRE：了解業(yè)務(wù)歸屬 -> 快速定位問題范圍 -> 協(xié)調(diào)相關(guān)人投入排查 -> 評估影響面 -> 決策恢復(fù)手段

可見，開發(fā)人員面對問題，會(huì)首先嘗試去探究根因，研究解決方案；而SRE人員首先是評估影響，快速定位，快速止損恢復(fù)。目標(biāo)和側(cè)重點(diǎn)的不同，造成了SRE思考問題的特殊性。

所以，成為一名SRE，就一定要從態(tài)度和方式上進(jìn)行轉(zhuǎn)變，切換到一個(gè)“團(tuán)隊(duì)穩(wěn)定性負(fù)責(zé)人”的角度上去思考問題。3、談?wù)剛€(gè)人對SRE的幾點(diǎn)要求

1.責(zé)任心、細(xì)心、耐心。

• 負(fù)責(zé)任是第一要素，主動(dòng)承擔(dān)，對報(bào)警、工單、線上問題、風(fēng)險(xiǎn)主動(dòng)響應(yīng)，不怕吃苦；一個(gè)不負(fù)責(zé)任的人，遇到問題與我無關(guān)的人，邊界感太強(qiáng)的人，難以做好穩(wěn)定性的工作；
• 及時(shí)、快速的響應(yīng)，這是最關(guān)鍵的一點(diǎn)，作為一個(gè)SRE，能夠及時(shí)、快速的響應(yīng)是第一要?jiǎng)?wù)，遇到報(bào)警、工單、線上問題，能夠第一時(shí)間沖上去，不要去問是不是自己的，而是要問這個(gè)事情的影響是什么，有沒有坑，有沒有需要優(yōu)化的風(fēng)險(xiǎn)？
• 主動(dòng)走到最前面、主動(dòng)想優(yōu)化的辦法、主動(dòng)出頭解決問題、主動(dòng)挖掘系統(tǒng)風(fēng)險(xiǎn)薄弱點(diǎn)。

2.不能只做當(dāng)下，要看到未來的風(fēng)險(xiǎn)，善于總結(jié)。

3.把機(jī)制建立好，切實(shí)落地。作為一個(gè)SRE，想做到“不出問題”這個(gè)基線，關(guān)鍵還是要靠大家。

二、穩(wěn)定性建設(shè)方向

1、地基要打牢

穩(wěn)定性建設(shè)工作重在預(yù)防，根據(jù)多年的工作經(jīng)驗(yàn)，至少70%的線上故障都可以通過預(yù)防工作來消除。因此，在日常工作中，我們需要投入相應(yīng)的精力來進(jìn)行根基建設(shè)。所謂的根基建設(shè)，就是要把開發(fā)、測試和上線這三大流程做到透徹。包括：DesignReview、CodeReview、提測流程、上線流程、引流驗(yàn)證、性能測試等。

2、工作在日常

俗話說養(yǎng)兵一日，用兵一時(shí)。穩(wěn)定性工作不是一蹴而就，而是日常的點(diǎn)點(diǎn)滴滴，一步一個(gè)腳印走出來的。

需要團(tuán)隊(duì)人人參與、持續(xù)完善監(jiān)控告警、檢查每一個(gè)告警是否配置、及時(shí)消滅線上小隱患?？蓞⒖济恐艿姆€(wěn)定性會(huì)議。

?梳理：主動(dòng)梳理團(tuán)隊(duì)的業(yè)務(wù)時(shí)序、核心鏈路流程、流量地圖、依賴風(fēng)險(xiǎn)，通過這個(gè)過程明確鏈路風(fēng)險(xiǎn)，流量水位，時(shí)序冗余；

?技術(shù)債務(wù)治理：主動(dòng)組織技術(shù)債務(wù)的風(fēng)險(xiǎn)治理，將梳理出來的風(fēng)險(xiǎn)，以專項(xiàng)的形式治理掉，防患于未然。但需要注意別由于治理而導(dǎo)致線上問題，需要加強(qiáng)引流驗(yàn)證比對。

?演練：把風(fēng)險(xiǎn)化成攻擊，在沒有故障時(shí)制造一些可控的故障點(diǎn)，通過演練來提高大家響應(yīng)的能力和對風(fēng)險(xiǎn)點(diǎn)的認(rèn)知。

?報(bào)警：除了前面說過的主動(dòng)響應(yīng)之外，還要經(jīng)常做報(bào)警保險(xiǎn)和機(jī)制調(diào)整，保證報(bào)警的準(zhǔn)確度和大家對報(bào)警的敏感度。同時(shí)也要做到不疏忽任何一個(gè)點(diǎn)，因?yàn)槭韬龅狞c(diǎn)，就可能導(dǎo)致問題。

3、預(yù)案是關(guān)鍵

我們需要認(rèn)識(shí)到預(yù)案的重要性，并投入相應(yīng)的精力來進(jìn)行預(yù)案的制定和更新。這樣，我們才能更好地應(yīng)對各種突發(fā)情況，保障項(xiàng)目的順利進(jìn)行。通過每周的穩(wěn)定性去深入挖掘每個(gè)接口的隱患及不足，比如業(yè)務(wù)指標(biāo)是否加上、業(yè)務(wù)指標(biāo)是否能真實(shí)反饋該接口的特性等。

4、大促特殊場景

系統(tǒng)在大促的穩(wěn)定性和日常穩(wěn)定性的區(qū)別在哪呢？個(gè)人理解核心是兩點(diǎn)：

1、【技術(shù)】高并發(fā)流量：大促流量峰值是日常的N倍（幾十、幾百倍），需要具備更高的并發(fā)流量處理能力，以保證系統(tǒng)的穩(wěn)定性這方面。針對這評估好流量，做好容量規(guī)劃即可。

2、【業(yè)務(wù)】業(yè)務(wù)場景多樣化：大促會(huì)增加很多日常用不到的場景，很明顯的比如預(yù)售場景、Promise特殊時(shí)效控制、停運(yùn)降級(jí)功能等。針對日常不用，大促才用的功能點(diǎn)?？烧砉δ茳c(diǎn)，在大促前1個(gè)月模擬大促，業(yè)務(wù)進(jìn)行相關(guān)功能配置，演練全流程，類似每年大促都進(jìn)行的預(yù)售場景演練。因?yàn)槊磕晷枨蠖荚诘黾?，難免會(huì)影響之前的功能點(diǎn)。這樣就可避免大促期間突然使用功能發(fā)現(xiàn)不好用的問題

5、執(zhí)行是王道

其實(shí)聽復(fù)盤會(huì)學(xué)東西是一方面，最主要是應(yīng)該問問我們系統(tǒng)是不是也存在這種問題，我該怎么規(guī)避或解決這類風(fēng)險(xiǎn)問題，別人暴露的我也存在，應(yīng)該第一時(shí)間去解決，而不是我知道但我不做。