一 概述
自己以及帶領的團隊曾經負責較多不同類型的互聯網服務系統，如幾十萬應用數&億級流量的雲計算平臺、年營收將近千億的廣告系統、億級用戶千萬級日活的釘釘工作臺系統、億級交易額的釘釘市場&交易系統、算法在線離線工程系統等相關係統或子系統，整體而言無重大故障，達到定級故障數也很少，線上穩定性保障在一個不錯的水位上。階段性總結下我從團隊技術負責人視角做好穩定性建設的實踐性思考和簡要思路，爲感興趣的技術同學提供一個實踐指南。
我的團隊穩定性建設思路包括了3大技術要素：良好的系統架構和實現、完備的團隊研發運維流程機制、技術同學良好意識和能力，以及1個業務要素：良好的研發項目管理。
二 良好的系統架構和實現
1 架構設計
根據不同系統業務特點、不同發展階段（系統規模、團隊規模）、不同系統指標側重性要求等，有很多不同的架構思路和折中考量，例如存儲選型、服務化治理、中間件選型、中臺系統抽象等。本文簡要講述會影響系統穩定性的一些架構設計點以供參考，設計考量點具體內容可自行搜索細看。
消除單點
從請求發起側到服務處理返回的調用全鏈路的各個環節上避免存在單點（某個環節只由單個服務器完成功能），做到每個環節使用相互獨立的多臺服務器進行分佈式處理，要針對不同穩定性要求級別和成本能力做到不同服務器規模分佈式，這樣就避免單個服務器掛掉引發單點故障後進而導致服務整體掛掉的風險。可能涉及的環節有端動態獲取資源服務(html& js &小程序包等)、域名解析、多服務商多區域多機房IP入口、靜態資源服務、接入路由層、服務邏輯層、任務調度執行層、依賴的微服務、數據庫及消息中間件。
消除單點的策略：
- 在服務邏輯層採用多運營商多IP入口、跨地&同地多機房部署、同機房多機器部署、分佈式任務調度等策略。
- 在數據存儲層採用數據庫分庫分表、數據庫主從備集羣、KV存儲&消息等分佈式系統集羣多副本等策略。
- 有分佈式處理能力後，需要考慮單個服務器故障後自動探活摘除、服務器增刪能不停服自動同步給依賴方等問題，這裏就需引入一些分佈式中樞控制系統，如服務註冊發現系統、配置變更系統等，例如zookeeper是一個經典應用於該場景的一個分佈式組件。
數據一致性
在分佈式處理以及微服務化後，相關聯的數據會存在於不同的系統之中，相關聯的數據庫表、數據存儲、緩存等數據會因爲架構設計或子系統抖動故障失敗等原因，導致彼此數據出現不一致，這也是一類穩定性故障。最簡單的一致性，就是關係型數據庫的同請求內同庫相關聯的多個數據表更新的一致性， 這個可通過數據庫的事務以及不同事務級別來保證。從架構層面，數據一致性也會根據業務特點，做強一致性、最終一致性的架構選型，不同選型根據CAP理論，也會帶來可用性以及分區容忍性的一些折衷。
在做好SLA高的基礎系統選型、分佈式事務中間件使用、冪等設計，針對性提升好微服務本身SLA後，可根據不同數據一致性級別要求，考慮通過消息觸發多系統對賬、定時調度對賬、子流程失敗後主動投遞消息延遲重試、消息消費失敗後迴旋重試、數據庫記錄過程中狀態後做定時調度掃描未成功記錄後重試、離線全量對賬。緩存更新機制不合理也容易引發緩存和數據庫之間數據不一致，一般在數據更新時考慮併發更新時緩存刪除優先或固定單線程串行更新策略。
複雜分佈式業務系統或微服務化治理後，基於消息中間件的解耦是普遍方式，這時選擇一個確保自身不重不丟以及高SLA消息中間件非常重要，利用消息中間件自身的多次迴旋重試基本能保障很高的最終一致性，數據一致性要求更高的，再配合不同級別對賬機制即可。
強弱依賴梳理和降級
當服務依賴各類微服務時，避免強依賴（依賴服務掛掉會到自己服務掛掉），儘可能在對應服務出現問題時做到自動降級處理（弱依賴）或者手工降級，降級後依賴服務功能局部去掉或做合適局部提示，局部體驗上有部分降級，但不會讓主鏈路和整體功能掛掉。對於穩定性要求很好的關鍵系統，在成本可接受的情況下，同時維護一套保障主鏈路可用的備用系統和架構，在覈心依賴服務出現問題能做一定時間週期的切換過渡（例如mysql故障，階段性使用KV數據庫等），例如釘釘IM消息核心系統就實現對數據庫核心依賴實現一套一定週期的弱依賴備案，在覈心依賴數據庫故障後也能保障一段時間消息收發可用。
強依賴的服務越少，系統整體基礎穩定性就越高。部分特殊數據依賴多於邏輯依賴的系統，做去依賴架構設計也是一個思路，將依賴服務數據統一整合到自有服務的數據存儲中，通過消息 或定時更新的方式更新，做到不依賴 或少依賴其他系統，進而提高穩定性，但這樣做也會有副作用：數據冗餘可能會引發不同程度一定時間窗口數據不一致性。
熱點或極限值處理
業務規模以及數據規模大的部分系統，在系統中會出現數據熱點、數據極度傾斜、少量大客戶超過極限閾值使用等極限場景，例如超級大客戶廣告投放物料、廣告點擊展示數據、API調用頻次都是比普通客戶大很多，如果按照客戶維度分庫分表，基本在物料更新、查詢、報表查看等一系列的場景都可能導致單庫抖動，這除了影響大客戶自己外也會影響分佈在該分庫分表上所有普通客戶。電商中極度暢銷商品以及秒殺、企業IM中大組織羣&大組織涉及全員關注更新行爲、微博等訂閱類明星大V的信息發佈等都是少量極限場景可能會引發整體系統穩定性問題。因此，架構設計時，要分析自己系統中是否存在極限場景並設計對應方案做好應對。
極限場景中不同類型場景處理架構方案也不一樣，可能的方式：
- 大客戶從普通客戶分庫分表中拆出來隔離建庫表，隔離享用專有資源以及獨立庫表拆分路由邏輯以及隔離服務邏輯計算資源；
- 大客戶特定極限數據計算做預約計算以及預加載，在低峯期預約或提前優化完成；
- 秒殺系統極限值可以考慮核心邏輯簡化+消息解耦、同商品庫存拆分獨立交易、部分查詢或處理KV存儲替代關係型存儲、數據提前預熱加載、排隊、限流策略等策略；
- 大組織IM場景設計合適讀擴散或寫擴散的策略，同時針對業務特點（不同人延遲度不一樣）做到不同人員體驗平滑，或者爲大組織或大V提供專屬計算存儲資源或專屬查詢更新邏輯。
- 在特定極限值系統架構以及資源無法滿足的情況，產品側以及技術側要明確採用最高閾值調用限制。
資金交易類系統要仔細考慮資損的風險
交易系統對於數據準確性、一致性、資金損失等都是很敏感的，這一塊在是否使用緩存、事務一致性考量、數據時延、數據不丟不重、數據精準覈對和恢復等需要額外架構設計考量。仔細評估交易以及營銷的全鏈路各個環節，評估其中出現資損的可能性以及做好應對設計，例如增加多層級對賬、券總額度控制、異常金額限制和報警等資損防控的考量等。不同層次不同維度不同時間延遲的對賬以及預案是一個重要及時感知資損和止血的有效方式。全鏈路的過程數據要做好儘可能持久化和冗餘備份，方便後續覈對以及基於過程數據進行數據修復，同時儘量針對特殊數據丟失場景提供快速自動化修復處理預案（如交易消息可選擇性回放和基於冪等原則的重新消費）。
離線數據流
基於數據的搜索推薦、機器學習算法系統、數據產品等，核心功能依賴離線產出 或 增量產出數據，這類數據可能規模大、來源廣、生產鏈路長，在整體生產和傳輸鏈路中，很容易出現數據少量丟失、部分環節失敗、數據生產延遲等情況，最終消費在線系統也很難感知少量數據錯誤進而導致故障。
針對離線數據流，要增加不同傳輸環節數據完整性校驗、不同生產環節數據正確性校驗、數據延遲監控、數據生產失敗監控、端到端數據正確性規則校驗、數據錯誤或延遲兜底預案、數據回滾重刷工具等機制。機器學習類系統還要考慮離線特徵和線上特徵數據一致性，確保離線訓練的模型，線上預測應用效果是一致的，因此模型上線時以及線上定期做離線和線上特徵數據一致性覈對。
其他異常情況處理
整體系統架構，除了正向邏輯、性能、擴展性設計等外，要增加一個異常設計視角，窮盡思考各類異常情況以及設計應對策略。
2 容量評估設計
系統設計整體至少考慮應對5到10倍或近1到3年系統規模增長，要保障後續通過增加機器資源等快速方式能實現系統水平擴容。例如分庫分表的規模提前設計好提前量，避免臨時數據庫能力不足導致需要臨時重構擴容（增加分庫分表以及修改路由以及遷移數據）；服務邏輯層設計持有數據狀態導致無法加機器做服務層擴容。互聯網產品發展變化較快，不一定會如期爆發，容量架構設計上也要注意不要過度提前設計，避免提前複雜化引發研發效率以及機器成本問題。
針對線上流量峯值，建議系統常態保持近期峯值3倍左右容量餘量，上線前和上線後要定期做壓測摸高，寫流量可用影子表等方式做壓測，壓測可單接口以及模擬線上流量分佈壓測結合，根據壓測結果優化架構或擴容，持續保持容量富餘。
對於可能超過系統現有容量的突發峯值，限流策略是線上要配置的策略。入口側入口流量調用 、不同渠道服務依賴調用、對依賴服務的調用都要評估可極限調研的上限值，通過中間件等合適方式限制超過閾值調用，避免引發雪崩效應。特定業務系統，對於超過峯值流量，可以通過消息架構以及合適體驗設計做削峯填谷。針對惡意攻擊流量也要考慮在入口層部署防DDOS攻擊的流量清洗層。
部分系統峯值變化較大且需要持續儘可能承載保障，可考慮引入彈性伸縮策略，預約 或根據流量變化觸發系統自動擴縮容，以確保以儘量小成本來自動化滿足變化峯值。
3 運維方案設計
系統要考慮持續迭代發佈變更以及線上運維的訴求，做到可灰度、可監控、可回滾。
可灰度保障及時在小流量情況，發現問題，避免引發大範圍故障。因此在做系統任何變更時，要考慮灰度方案，特別是大用戶流量系統。灰度方式可能有白名單用戶、按用戶Id固定劃分後不同流量比例、機器分批發布、業務概念相關分組分比例（例如某個行業、某個商品、某類商品）等，灰度週期要和結合系統風險和流量做合適設計，重要系統灰度週期可能持續超過一週或更多。
監控項要系統性確認是否完備以及保持更新，可能監控項：錯誤日誌前端js錯誤、用戶體驗到的性能和白屏率、接口成功率、依賴服務成功率、機器基礎負載相關監控（CPU利用率、cpu Load、內存、IO、網絡等）、服務基礎監控（端口、進程、狀態探活、JVM full gc、OOM等）、數據庫負載監控、數據庫慢請求、流量同比劇烈變化。監控項的報警策略也要根據業務系統特點以及監控項的特點，做不同報警策略設計，例如秒級&分鐘級報警、錯誤率報警、錯誤日誌次數報警、連續出錯報警等。核心監控可摘要一個監控大盤，一個大盤快速判斷服務穩定性情況。
可回滾：新增功能增加配置開關，當線上出現問題時，可通過關閉功能開關，快速下線最新升級 或部分有問題功能。針對不同出錯場景，有配置驅動一些預案，例如降級對某個服務的依賴、提供合適功能維護中公告、切換到備用服務等預案，在特定問題出現時，可以快速做線上止損和恢復。發佈功能注意提前考慮出現問題時快速回滾步驟，部分經常發佈注意對回滾步驟做演練。
4 安全設計
數據以及應用安全問題一旦出現可能很致命，一定要加以考慮。安全是一個比較專業領域，常規在針對業務系統經典安全場景做好考量的同時，儘量引入專業安全技術同學評估。所有資源訪問需要合適鑑權，避免越權訪問；防Sql注入等攻擊，做參數合法性校驗；資源消耗頻次管控，如短信資源等；用戶防騷擾，設置用戶通知、彈屏等觸達閾值和頻次；敏感信息過濾或脫敏等。
5 高質量的代碼實現
合適實現和經典性實踐是非常重要代碼質量保障的方式，大量線上問題還是由少量代碼細節考慮不周全和經驗不足引發的。這方面考量不同語言都會有自己一些最佳的實踐，例如Java，可以參考《Java開發手冊》。比較通用保障方式是分支覆蓋完備的單元測試 、線上引流回歸測試、完備迴歸測試用例等測試質量保障措施。
三 團隊研發運維流程機制
穩定性涉及團隊所有不同水平同學、所有系統、研發所有環節、線上時時刻刻，單個同學是無法保障好的，必須建立團隊流程機制來可持續保障。
主要流程機制如下：
- 技術Review：不同體量設計安排經驗更加豐富同學Review，架構師、主管、外部架構師的Review、定期系統整體Review等。
- 代碼Code Review：建立規範和標準，通過CR認證合格同學執行code review動作。
- 單測：不同風險的系統設定儘量高的行覆蓋 & 分支覆蓋率標準，複雜邏輯類追求100%分支覆蓋。
- 迴歸測試：持續積累迴歸用例，在上線前和上線後執行迴歸動作；上線前線上引流測試也是一種模擬測試方式，端類型系統還可以用monkey工具做隨機化測試。
- 發佈機制：設計發佈准入和審批流程，確保每次上線發佈都是經過精細設計和審覈的，上線過程要做到分批、灰度、支持快速回滾、線上分批觀察（日誌確認）、線上迴歸等核心動作。建立發佈紅線等機制，不同系統設計合適發佈時段以及發佈灰度觀察週期。
- 團隊報警值班響應機制 （報警羣、短信、電話）：確保報警有合適人員即時響應處理，團隊層面可定期做數據性統計通曬，同時建立主管或架構師兜底機制。
- 定期排查線上隱患：定期做線上走查和錯誤日誌治理、告警治理，確保線上小的隱患機制化發現和修復。例如在釘釘針對企業用戶早晚高峯的特點，設計早值班機制，用於高峯期第一時間應急以及每天專人花一定時間走查線上，該機制在釘釘技術團隊持續踐行多年，有效發現和治理了釘釘各個線上系統的隱患。
- 用戶問題處理機制：Voc日清、周清等。在釘釘也經歷Voc周清到日清的持續機制精進。
- 線上問題覆盤機制：天內、周內問題及時覆盤，確保針對每個線上問題做系統和團隊精進。
- 代碼質量抽查通曬：定期抽查團隊同學代碼，做評估和通曬，鼓勵好的代碼，幫助不好代碼的改善。
- 成立穩定性治理專門topic：合適同學每週做好穩定性過程和精進。
- 定期壓測機制：定期機制化執行，覈查線上容量情況。
- 日常演練機制：預案演練，模擬線上故障的不通知的突襲演練提升團隊線上問題應對能力。
流程機制要和團隊同學共創達成一致後，配合建立topic負責人機制，對流程機制執行度和執行效果要做好過程監測和通曬，建立明確數字化標準和衡量機制（例如釘釘技術團隊針對線上問題設定1-5-10標準，1分鐘響應5分鐘內定位10分鐘內恢復），同時建立對應獎懲機制。流程機制也要根據系統狀態進行精簡或精進，確保流程機制可執行性和生命力。
四 技術同學意識和能力
人的意識是最重要的，專業能力可以鍛鍊培養。如果意識不足或鬆懈，好的能力以及機制流程也會形同虛設。
永遠要對敬畏線上，敬畏客戶體驗。面向線上的穩定性戰術上可以基於專業度鍛鍊後自信，但戰略和思想上必須持續如履薄冰、三省吾身。線上穩定性保障是作爲技術人自己專業度的追求和必須保持初心，始終保持敬畏。不因爲業務繁忙、個人心情狀態、團隊是否重視而有變化，只要職責在，就要守護好。技術主管以及系統owner要有持續感知穩定性隱患和風險，保持銳度，集中性以及系統性查差補漏。
1 團隊對線上敬畏的一些具象體現和要求
每個報警不要放過，每個報警及時響應處理
快速定位和快速恢復是個人以及團隊專業能力沉澱，但快速報警響應是每個敬畏線上敬畏用戶體驗的技術同學可以做到的。
在監控完備和持續前提下，每個報警及時處理即可以降低故障影響範圍，也會持續減少小的隱患。報警一些小的實踐技巧：報警按照方向收斂報警羣，建立報警天級值班機制，報警短信手機設置爲震動模式（不打擾同空間家人或朋友情況下，自己第一時間感知），主管要訂閱報警作爲團隊報警兜底處理人，報警響應好的同學和不好的同學要數據化表揚和批評。
從團隊角度，報警及時響應必須配合報警治理進行，否則過多無效報警也會讓有責任心的同學變得麻木。所以必須控制無效報警的數量，例如單應用無效報警（不需要線上問題進行定位以及修復處理的）不要超過5條，個人維度無效報警天級別不超過10條。
線上問題要覆盤，不論是否爲定級故障，不論問題大小
小的線上問題也要覆盤，覆盤準備度可以低於定級故障，但都需要思考反思以及落實優化Action。小的線上問題就是未來線上故障的前兆。我們團隊週會上都會有一個環節，上週如有線上問題則會安排對觸發人做覆盤。
錯誤日誌要重視
要定期分析線上錯誤日誌，隱患的問題是藏在錯誤日誌中的。我們現在技術團隊會有早值班機制，每個方向每天都有一個技術同學走查線上，以發現線上隱患問題爲導向，走查監控大盤、錯誤日誌、用戶反饋，通過這個例行機制，很好地防微杜漸。
每個用戶反饋要重視，定位到根本原因
一個用戶反饋背後必然有多個實際線上問題，只是這個用戶無法忍受，知道反饋路徑以及對這個產品有熱愛 或強依賴才選擇反饋的。徹底定位一個voc，就是修復了一類線上問題。而且到用戶反饋的程度，這個線上問題就已經有一定程度用戶體驗影響了。我們現在技術團隊有一個voc日清機制，針對線上voc問題對用戶做好日內響應答覆，也是一個不錯對於這個意識的數字化衡量。
2 能力培養
單個技術同學個人技術以及穩定性保障能力是團隊在每個穩定性任務上拿到結果的執行者和基礎，因此技術主管重視識別不同同學個人優勢和不足，針對性做工作安排以及培養鍛鍊。只要線上意識上足夠重視，能力對於大部門技術同學是可以培養的。
團隊內同學由於入行時間、歷史經驗等各方面原因，對於當前系統穩定性保障能力是有強弱的差異的，對於個人是正常情況，但對於團隊而言，不能因爲團隊個別同學能力上存在不足而引入團隊層面穩定性保障風險。需要主管很好熟悉以及判斷同學能力段位，在負責系統和模塊、流程機制約束、輔導人等方面做好差異化安排。例如校招同學X個月不做線上發佈，前X個月發佈有師兄協同發佈機制，併發高 或資金交易等等風險高的系統讓更加有經驗的負責。同時設計培養機制，能力當前不足但有潛力的同學，可以安排由經驗豐富的同學指導以及提供一些進階實操路徑，按照節奏從易到難逐漸承擔更高風險的系統職責。
能力培養方式有技術Review、代碼CR和輔導、參與團隊穩定性保障機制、安排合適師兄指導、過程中主管指導、逐漸承擔更高職責等。代碼層面，對於Java同學來說， 《Java開發手冊》是一個很好的實踐性指南，超出代碼風格，提供了日誌、異常處理、集合等庫使用、數據庫設計、分層設計等多個提升代碼質量的實踐做法，我們自己團隊所有Java研發同學都會100%通過阿里雲上阿里巴巴代碼認證考試，同時團隊有一個團隊內新人品碼機制，同時釘釘大技術團隊層面有一個品碼會機制，這些都是不錯地培養同學寫出好代碼的培養方式。
好多小團隊、大團隊、公司都有很多不錯提升穩定性機制和案例，積極主動參考學習以及結合自己業務系統思考踐行，是自己提升重要路徑。架構上高可用以及架構相關經典書籍自我學習，從理論上做系統性認知也是有必要，相關書籍網上有很多推薦，例如《高性能網站建設》、《大型網站系統與Java中間件實踐》等。
少量的同學在主管和團隊儘可能幫助和輔導後在穩定性性保障的意識和能力上持續不能達標，這類同學要做好階段性高風險系統隔離以及堅定做汰換。對業務、客戶體驗、團隊內其他同學負責，及時汰換他以降低這一塊穩定性風險。
五 良好的研發項目管理
從經驗看，線上系統大部分故障是由新的變更引入和觸發的，變更是業務和產品迭代演進方式，因此不可能沒有變更，但我們可以對變更項目做合適質量管理，進而有效提高線上穩定性。
項目管理的四要素：工作範圍（需求）、時間（交付時間）、質量、成本（人 & 機器資源等），簡稱STQC，這四個要素是相互關聯的和制約的，形成一個項目管理質量管理鐵三角，一個要素變動就會影響到其他要素，因此要保障好質量就必須要考慮怎麼管理好其他三個要素。
此外，我們可以進一步理解項目成功的要素，以終爲始聚焦考慮如何提升實際影響成功的質量，成功的項目不僅取決於項目本身從開始到結束的執行過程，還取決於開始前和結束後的努力。成功的項目應該取決於三個階段的努力：
- 項目開始前必須 “瞭解什麼是客戶的成功”，只有客戶成功了項目才能成功；——理解客戶真正的需求。
- 項目執行中能夠“擔負客戶成功的責任”，按要求完成承諾的工作。
- 項目結束後能“幫助客戶實現價值”，只有客戶說項目成功了纔是真正的成功。——幫助客戶實現業務目標、用戶價值目標、商業價值目標。
質量管理鐵三角
互聯網產品迭代速度很快，推崇快速推出、快速試錯、快速佔據市場先機，交付時間的快是互聯網產品、業務同學對於研發團隊顯性的要求，而交付質量和線上持續穩定則是一個隱性需求，產品業務默認研發團隊應該做到，但往往在時間、成本等方面沒有給予顯性考慮，這一塊就需要研發項目管理同學主動評估考量進來，有自己專業判斷和堅持。
理解好真正的客戶需求和交付後客戶價值的實現，可以幫助在四要素衝突的時候合適取捨需求來保障時間和質量，以及和業務產品&客戶基於客戶價值實現爭取時間、資源來保障質量。項目管理角度穩定性保障基本動作包括確定和充分理解幫助客戶成功的需求範圍、控制好需求變更、預留質量保障環節時間、動態管控交付預期時間、爭取充足人力以及機器等成本資源。進階動作：在提前瞭解和理解甚至共同參與制定業務戰略和策略基礎上提前規劃需求範圍和研發節奏&人員排兵佈陣&架構佈局、深入理解業務基礎上協助做需求取捨和優化。
本文爲阿里雲原創內容，未經允許不得轉載。