背景

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

一、穩定性保障機制

穩定性涉及團隊所有不同水平技術人員、所有系統、研發所有環節、線上時時刻刻，單個技術人員是無法保障好的，必須建立團隊流程機制來可持續保障。

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

1、規范先行

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

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

?架構設計規范：概要設計、模塊詳細設計、API、Domain、數據緩存、容錯設計、風險設計等。

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

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

?代碼提測規范：Test單測、代碼編譯構建、系統運行穩定性等、

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

?預發&引流壓測規范：黃金鏈路必須進行R2引流驗證。

?發布上線規范：可灰度、可驗證、可回滾等

?驗收規范：業務、產品驗收規范

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

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

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

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

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

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

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

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

?開發：了解業務 -> 定位問題 -> 排查問題 -> 解決問題

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

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

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

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

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

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

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

二、穩定性建設方向

1、地基要打牢

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

2、工作在日常

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

需要團隊人人參與、持續完善監控告警、檢查每一個告警是否配置、及時消滅線上小隱患。可參考每周的穩定性會議。

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

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

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

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

3、預案是關鍵

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

4、大促特殊場景

系統在大促的穩定性和日常穩定性的區別在哪呢？個人理解核心是兩點：

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

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

5、執行是王道

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