本文記錄了穩定性摸排過程中的一些思考和沉澱。
前言
這張圖主要分爲四個部分，一、確定目標，是一切開始的前提；二、方法論部分用於沉澱穩定性建設的理論方法，支撐後續的動作；三、動作路由，對應方法論部分希望可以用一張圖把建設路徑講清楚；四、拿結果，對應各個階段進行進度跟蹤，保證可以拿到最後的結果。方法論部分會主要以如何摸排爲主回答前面的三個問題。
確定目標
做穩定性摸排的第一原則是要假設任何地方都可能出問題，但只有原則的直接影響就是，摸排過程中會覺得“都是問題，又可能都不是問題”。所以，做摸排的第一件事就是要確定目標，有了目標纔有重點和優先級。
整體的目標，應該所有業務都大體相同，“無Px以上故障”，“0資損”，“故障恢復1-5-10”。但針對不同的業務和不用應用的職責會有不同的目標偏重，比如2C業務的目標更偏重服務穩定性，2B業務的目標更偏重數據一致性，涉及到資金流轉的業務目標更偏重資損。所以在摸排之前一定要確定自己負責的業務應用的目標是什麼，可以和GOC的同學拉通所有的故障場景，這樣摸排的優先級會更清晰。有了重點目標之後，就可以分清楚哪些是核心鏈路，並且在摸排的過程中也可以將摸排出的問題標出優先級，有助於我們後續更快更有效的加監控和技改。
以我們自身的業務來舉例，我們團隊叫內容資產，是負責優酷百億級別內容引入資產的管理和價值挖掘。三塊主業務是內容版權管理的CRP，內容權利管理的CCC，以及內容引入的開放平臺。CRP管理版權信息流和資金流，所以重點目標是0資損；CCC的數據會影響下游端側是否有播放權利，內容播放不了可能會引發客訴，所以重點目標是避免數據不準確導致的客訴；開放平臺的用戶是合作商算是半2C，所以重點目標是服務可用。
CRP的第一重點是0資損，所以可能引發資損場景的就是核心鏈路；可能引發資損的問題優先級爲高；2B業務的重點在於數據的準確性，所以可能導致數據不準確的問題優先級爲重；其他的比如易用性問題、不影響前倆項的服務不可用問題等等可以列爲低。
方法論
你摸排出來的問題就是全部問題麼？
這是穩定摸排面臨的第一個問題，面臨這個問題的時候我們必須得承認，沒有任何銀彈可以幹掉一切妖魔鬼怪，順帶帶走“黑天鵝”。但如何把我們認知範圍內的隱患全部找到，應該是可以有一套方法論的。
在團隊最開始做摸排的時候，爲了解決這個問題我根據經驗拉了一個很長的list，希望在排查代碼的時候可以輔助找到所有的問題。這種方法有倆個問題：第一個“如果沒有優先級那麼所有問題都是低優先級”，假設每一行代碼都有可能出現問題就會不知道從哪開始，而且工作量巨大；第二個“只有結果沒有過程”，在實際過問題列表的時候，沒有辦法判斷是否是全部問題。
可見上述的方法不是一個可靠高效的方法，我們需要一種可以指導過程並推導出完整結果的方法論。
流程摸排路由
整個流程摸排路由中，我們需要三張圖：核心鏈路圖、流程時序圖、問題路由圖
核心鏈路圖
摸排的原則是假設每一行代碼都可能出問題，但我們不可能一次性全部摸排完成，那應該高優的摸排的代碼是哪些？這個就是需要從我們最開始確定的目標開始推導，可能會發生重點問題的流程就是高優排查的範圍。以CRP舉例，CRP的第一重點是0資損，那涉及到資損的付款流程就是我們要高優排查的模塊，其中實際的審批付款流程是需要高優排查的，付款列表等不會產生資損可以優先級放低。
根據推導我們找到了核心鏈路，轉化成業務的核心鏈路圖，圖中要重點產出：1、N條核心鏈路；2、各鏈路的調用入口；3、鏈路過程中的中間件以及查詢依賴；4、寫入依賴。
流程時序圖
有了核心鏈路圖之後，我們就確定了優先摸排的範圍，然後就要實際梳理代碼，產出核心鏈路對應的流程時序圖。時序圖要保證倆件事情：1、N個核心鏈路至少要對應N個流程時序圖，保證不會漏掉；2、在流程時序圖中，對於RPC調用和關鍵實體的操作要重點關注，不要漏掉。
問題路由圖
經過前倆步的推導，找到了核心鏈路中的關鍵節點，接下來只需要根據關鍵點的類型，路由到可能出現的問題進行重點排查。調用入口出要注意流量問題、核參校驗問題、冪等問題；寫入依賴需要注意不可用問題、冪等問題、數據一致性問題等；流程過程中要注意事務問題、併發邏輯問題以及會帶來資損的金額計算問題等。
有了這三張圖，我們就可以將每一行代碼都進行全量問題的摸排判斷，縮減爲核心流程中關鍵節點對應的各自類型的問題摸排判斷；並且過程中有了核心鏈路和關鍵節點的推導，可以保證不會帶來摸排遺漏。在組內review的時候，上面三個圖也可以提供是否“全”的判斷依據。
你加的監控加全了麼？
解決了摸排問題不全的問題，面臨的第二個問題就是我們加全了麼？監控作爲發現問題的主要手段，在日常運維工作中非常重要，如果可以儘早發現就可以及時止血。常用的監控手段有數據對賬和日誌監控倆種，數據對賬常用於信息流與資金流流轉的數據一致性監控，日誌監控常用於系統流程異常的監控。那我們又如何保證我們的監控是全面和有效的？
數據依賴路由
數據對賬是爲了發現信息和資金流轉過程中的數據不一致問題，但業務單據的字段少則幾十多則上百，到底應該加哪些字段的監控，對賬的觸發點應該怎麼設置？還是三張圖推導：場景用例圖、數據模型依賴圖、狀態機列表
場景用例圖
首先還是要從目標出發進行推導，找到所有重點問題可能發生的場景，將場景用例畫到腦圖中。重點是要涵蓋所有的問題場景，以及問題場景中所涉及的業務實體與字段。
以我們自身的業務場景爲例，版權資產的付款是優酷內容引入的資金鍊出口，容易產生資損場景。資損場景主要實際支付金額不對、付款金額計算不對、重複付款三個場景。
付款金額計算不對：
1、CRP付款單提交的時候，要保證付款的金額不能超過合同保底金額
2、......
實際支付金額不對：.......
通過上面的梳理就可以得到第二張圖
數據模型依賴圖
還是沿用上面的例子，根據上圖所有場景的描述中可以推導出所有涉及的業務實體的依賴關係以及關鍵字段，這些就是我們需要做數據對賬的核心字段。核心字段有了就要解決第二個問題，觸發對賬的event應該是什麼？多數情況下我們只會去按照業務流程走向正向的添加監控，比如以提交CRP付款單爲event，觸發單據金額與合同金額的對賬。這樣會覆蓋到大部分的問題場景，但同時可能會忽略一些低頻卻又很重要的問題。比如CRP付款單已經提交觸發正向的數據對賬通過，但在資金流流轉過程中，合同的金額變小且小於付款的金額，如果做不到及時通知並且干預，就會產生資損問題。
所以在添加監控的時候，除了根據業務走向的正向數據對賬之外，也要考慮逆向的數據對賬，並根據可能產生問題的嚴重程度進行有優先級的監控建設。
狀態機列表
由於付款單據與付款憑證（賬單）之間的狀態流轉有依賴關係，倆個單據自身的狀態流轉也有卡口規則，所以在實操過程中我們列了一個狀態機列表，輔助數據對賬準確無遺漏的落地。這個圖非必選，但如果摸排的業務中同樣有複雜的業務單據狀態流轉的依賴關係，建議畫出此圖輔助監控的添加。
系統級統一監控
除了數據對賬監控，另一個重要手段就是日誌監控。加日誌監控的時候通常會面臨一個狀況，就是加了監控也很難定位到問題。所以我們需要一個方法不僅可以發現問題發生，還能定位到具體是哪裏出現問題，具體什麼問題，甚至在多機器應用到底是哪臺除了問題。這裏我們借鑑了一位大佬的方法論，配置了一套從整體到細節，從感知到診斷的系統統一監控，可以很好的解決上面提到的問題。↓↓↓↓↓
你的技改方案考慮全了麼？
代碼中的問題都定位到了，有些需要進行技術改造，對應不同的問題你的技術方案都考慮全了麼？順着這個問題，我整理了一張圖穩定性摸排全鏈路（摸排->監控補充->技術改造->預案）的Action路由圖，希望可以使團隊同學在穩定性建設過程中有個體系化的指導。
通用方案主要分爲幾類，數據一致性方案、冪等方案、防資損方案、慢sql改造方案，慢SQL改造都是基本功，不再贅述。
拿結果
這個部分不用多說，就是對應Action路由的各個階段的過程結果監控，以及最終結果的達成。什麼展現形式不重要，重點是要有跟進保證最終結果的達成。截止目前，我們團隊在覈心鏈路上共摸排出13個高優的問題，技改方案全部產出review排期解決中；和測試的同學配合新增監控42個，其中19個是摸排出來的；無P級bug，0資損。
最後
系統穩定性是保證我們拿到一切業務價值的基礎，重要性不言而喻。穩定性建設其實是一個持續性的工作，最近一個財年交接了很多新的業務過來，所以集中做了一次突擊摸排。工作多且雜，需要測試、產品、開發團隊通力配合完成，過程中一起總結出來的一些方法論希望對大家有所幫助。
作者|肖迪(墨詡)