背景

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

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

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

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

1、規(guī)范先行

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

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

?架構設計規(guī)范：概要設計、模塊詳細設計、API、Domain、數(shù)據(jù)緩存、容錯設計、風險設計等。

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

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

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

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

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

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

?驗收規(guī)范：業(yè)務、產品驗收規(guī)范

?制定變更規(guī)范：提供變更級別、角色職責、活動階段以及輸入輸出的詳細規(guī)定

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

?報警響應機制：針對運維相關的監(jiān)控告警制定告警處理流程、告警升級機制

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

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

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

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

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

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

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

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

所以，成為一名SRE，就一定要從態(tài)度和方式上進行轉變，切換到一個“團隊穩(wěn)定性負責人”的角度上去思考問題。3、談談個人對SRE的幾點要求

1.責任心、細心、耐心。

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

2.不能只做當下，要看到未來的風險，善于總結。

3.把機制建立好，切實落地。作為一個SRE，想做到“不出問題”這個基線，關鍵還是要靠大家。

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

1、地基要打牢

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

2、工作在日常

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

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

?梳理：主動梳理團隊的業(yè)務時序、核心鏈路流程、流量地圖、依賴風險，通過這個過程明確鏈路風險，流量水位，時序冗余；

?技術債務治理：主動組織技術債務的風險治理，將梳理出來的風險，以專項的形式治理掉，防患于未然。但需要注意別由于治理而導致線上問題，需要加強引流驗證比對。

?演練：把風險化成攻擊，在沒有故障時制造一些可控的故障點，通過演練來提高大家響應的能力和對風險點的認知。

?報警：除了前面說過的主動響應之外，還要經常做報警保險和機制調整，保證報警的準確度和大家對報警的敏感度。同時也要做到不疏忽任何一個點，因為疏忽的點，就可能導致問題。

3、預案是關鍵

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

4、大促特殊場景

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

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

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

5、執(zhí)行是王道

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