一提到金融行業(yè)的IT系統(tǒng)大家最先想到的往往是核心交易、高并發(fā)、數(shù)據(jù)強一致這些詞但真正讓運維團隊夜不能寐的反而是“萬一機房被水淹了怎么辦”“光纜被挖斷了怎么辦”這種平時不太起眼、一出事就要命的問題。業(yè)務連續(xù)性在金融行業(yè)從來不是選擇題而是及格線。最近我參與并復盤了一個很有代表性的項目——中亦科技助力人保科技打造金融級業(yè)務連續(xù)性新范式。這個項目讓我重新梳理了從架構(gòu)設計、災備建設到常態(tài)化演練的完整鏈路也踩過不少值得記錄的坑。這篇文章就把整個思路、關鍵決策和實操細節(jié)拆開來講適合正在做災備體系、雙活數(shù)據(jù)中心或者金融行業(yè)IT規(guī)劃的同行參考。1. 金融級業(yè)務連續(xù)性需求與項目背景拆解1.1 從監(jiān)管要求到業(yè)務底線為什么金融行業(yè)必須做業(yè)務連續(xù)性保險行業(yè)屬于強監(jiān)管行業(yè)業(yè)務連續(xù)性的相關要求散落在《保險業(yè)信息系統(tǒng)災難恢復管理指引》等規(guī)范里但一線從業(yè)者都知道真正驅(qū)動項目的不是“應付檢查”而是業(yè)務部門越來越依賴線上化的現(xiàn)實?，F(xiàn)在的保單承保、理賠、資金收付都跑在系統(tǒng)上系統(tǒng)中斷半小時損失的不只是交易量更是客戶信任和監(jiān)管評級。中亦科技在這個項目里要解決的不是簡單的“拉兩臺機器做備份”而是從業(yè)務影響分析出發(fā)把所有關鍵系統(tǒng)恢復目標量化再反過來設計技術(shù)方案。我見過不少企業(yè)把災備當成“存儲復制”的代名詞覺得只要數(shù)據(jù)能定期同步過去就算完成了容災。但在人?？萍歼@種體量下系統(tǒng)有成百上千個底層技術(shù)棧從傳統(tǒng)數(shù)據(jù)庫到分布式中間件都有單純復制數(shù)據(jù)根本撐不起“業(yè)務連續(xù)”四個字。真正的核心問題是當災難發(fā)生時業(yè)務流、數(shù)據(jù)流、會話狀態(tài)能不能在目標時間內(nèi)整體切換賬單支付、保單查詢這些場景能否無縫銜接這些問題必須在項目啟動階段就回答清楚。這次項目還有一個背景值得說道人?？萍急旧沓袚麄€集團數(shù)字化轉(zhuǎn)型的技術(shù)底座職責所以它的業(yè)務連續(xù)性體系不僅要滿足自身需要還要能向成員單位輸出能力。這意味著方案的標準化、可復制性很重要不能靠“人肉腳本”和臨時救火。中亦科技在項目里的角色更像是一起定義“范式”而不是只交付一套設備。1.2 立項定位從單點災備向體系化連續(xù)性演進很多金融企業(yè)已經(jīng)走過了“兩地三中心”的基礎設施建設階段但“有災備”不等于“能切換”。傳統(tǒng)的災備中心平時承擔查詢類或非關鍵業(yè)務生產(chǎn)中心一旦故障應用拉起往往耗時數(shù)小時甚至一兩天這離“業(yè)務連續(xù)”差距很大。增量變化就是把災備能力從“被動恢復”推向“主動接管”甚至讓兩個中心在平時就同時承擔生產(chǎn)流量。人?？萍歼@個項目的定位非常明確建設一套覆蓋同城和異地的業(yè)務連續(xù)性管理體系核心系統(tǒng)實現(xiàn)同城雙活或準雙活重要系統(tǒng)具備異地快速切換能力。這里要澄清一個容易混淆的概念“雙活”不是簡單的負載均衡而是兩個數(shù)據(jù)中心都能讀寫數(shù)據(jù)實時同步任何一個站點故障時另一個站點能繼續(xù)對外服務會話和狀態(tài)能平滑轉(zhuǎn)移。這對網(wǎng)絡、中間件、數(shù)據(jù)庫同步機制的要求都很高也是項目里最有挑戰(zhàn)的部分。另外一個容易被忽略的點是組織流程的連續(xù)性。即便技術(shù)切換成功了如果現(xiàn)場沒有清晰的應急指揮體系、決策權(quán)限和溝通機制一樣會造成業(yè)務長時間受損。所以項目一開始就確定了“技術(shù)流程演練”三條線并行推進的思路這個定位直接影響后續(xù)所有工作安排。2. 總體設計與架構(gòu)選型2.1 同城雙活還是異地災備常見架構(gòu)對比與決策邏輯項目組在前期花了很多時間做架構(gòu)選型核心是在兩種主流模式之間取舍。第一種是同城雙活兩個機房物理距離一般在50公里以內(nèi)網(wǎng)絡專線延遲低存儲和數(shù)據(jù)庫可以采用同步復制故障切換時RPO恢復點目標理論上趨近于零RTO恢復時間目標可以控制在分鐘級。第二種是異地災備機房距離幾百公里以上復制方式多為異步數(shù)據(jù)延遲幾秒到幾十秒能抵御區(qū)域性災難但切換后可能丟失部分數(shù)據(jù)。人?？萍嫉膶嶋H情況是既有北京、上海等地的核心生產(chǎn)資源又有集團層面的容災需求。所以最終采用了“同城雙活為骨干異地災備為兜底”的混合架構(gòu)核心賬務、支付類系統(tǒng)在同城雙活中心之間做同步復制承擔日常流量統(tǒng)一備份數(shù)據(jù)和部分可容忍少量數(shù)據(jù)丟失的系統(tǒng)放在異地做異步復制。這在業(yè)內(nèi)其實算比較成熟的思路但難點在于如何給不同系統(tǒng)精確分級而不是眉毛胡子一把抓。在RTO/RPO目標設定上我們和業(yè)務部門反復校準了很多輪。一開始業(yè)務方聽說RPO可以做到零非常興奮要求所有系統(tǒng)都按零丟失來建設。但實際上同步復制對網(wǎng)絡質(zhì)量極其敏感專線抖動都會拖垮寫入性能而且數(shù)據(jù)零丟失必須以應用能正確處理沖突和回滾為前提。最后我們采用分級策略核心交易系統(tǒng)RPO0RTO5分鐘重要系統(tǒng)RPO15秒RTO30分鐘一般系統(tǒng)RPO5分鐘RTO2小時。這個分級結(jié)果寫進了項目章程成為后續(xù)所有設計的基準。2.2 關鍵組件選型與容災等級評估技術(shù)組件層面存儲復制和數(shù)據(jù)庫復制是兩條并行路線不能互相替代。存儲復制如華為、宏杉、NetApp等存儲自帶遠程復制對應用透明適合文件類、歸檔類數(shù)據(jù)數(shù)據(jù)庫復制如Oracle Data Guard、MySQL主從、分布式數(shù)據(jù)庫多副本則能感知業(yè)務邏輯更適合事務型系統(tǒng)。人?？萍嫉沫h(huán)境里既有傳統(tǒng)集中式數(shù)據(jù)庫也有分布式數(shù)據(jù)庫所以不能只用一套方案包打天下。數(shù)據(jù)庫層面核心系統(tǒng)負載高我們用的是“同步復制自動故障轉(zhuǎn)移”的組合。以Oracle為例Data Guard的三種保護模式里最大保護模式可以做到零數(shù)據(jù)丟失但對主庫的提交延遲有影響通常生產(chǎn)環(huán)境很少直接啟用最大可用性模式是更常見的選擇它允許在同步鏈路故障時自動降級從而保證業(yè)務可用性鏈路恢復后再自動補齊數(shù)據(jù)。這里的邏輯需要講清楚容災架構(gòu)本質(zhì)上是“數(shù)據(jù)零丟失”和“業(yè)務可用性”之間的博弈沒有完美方案只有適合業(yè)務的取舍。存儲層面還需要考慮雙活仲裁機制。兩個中心的存儲做成雙活集群如華為HyperMetro當鏈路中斷時為了避免“腦裂”出現(xiàn)兩個中心各自寫入的情況必須引入仲裁機制。仲裁點通常放在第三地或云端一旦鏈路抖動超過閾值仲裁會決定保留哪個站點的數(shù)據(jù)另一個站點自動隔離。這個機制在實施中非常關鍵我們專門做了鏈路丟包、延遲增大、完全中斷三類故障模擬確保仲裁邏輯符合預期。3. 核心實施環(huán)節(jié)與實操重點3.1 關鍵業(yè)務系統(tǒng)分級梳理從業(yè)務影響分析開始很多團隊做業(yè)務連續(xù)性容易陷入“技術(shù)開練”的狀態(tài)直接上復制軟件卻忘了最基礎的一步梳理業(yè)務依賴關系。人保科技的業(yè)務鏈條里一個保單可能同時涉及承保系統(tǒng)、收付費系統(tǒng)、影像系統(tǒng)、短信通知而底層又依賴數(shù)據(jù)庫、緩存、消息隊列。如果只把核心數(shù)據(jù)庫做了復制應用層沒有配套的啟動順序和依賴檢查災難發(fā)生時依然拉不起來。我們專門組織了業(yè)務影響分析工作坊讓每個系統(tǒng)的負責人回答三個問題系統(tǒng)中斷后影響哪些業(yè)務可容忍的停機時間是多少可容忍的數(shù)據(jù)丟失量是多少這些問題看似簡單但業(yè)務方經(jīng)常答不上來。后來我們換了辦法直接拉出近一年的真實運營數(shù)據(jù)統(tǒng)計每個關鍵交易在一天內(nèi)的分布計算中斷一小時可能影響的交易筆數(shù)和金額業(yè)務方看到數(shù)字才真正重視起來。所以分級梳理不能靠詢問要靠數(shù)據(jù)說話。最終分級結(jié)果用兩個維度劃分高/中/低影響等級加上同步/異步復制方式。高影響且依賴關系復雜的系統(tǒng)進入首批雙活建設清單中等影響系統(tǒng)定為異地快速切換低影響系統(tǒng)只做定期備份和恢復驗證。這個矩陣還要考慮系統(tǒng)折舊周期一些即將升級替換的舊系統(tǒng)沒必要再做復雜容災避免重復投資。3.2 數(shù)據(jù)同步與切換編排的落地細節(jié)數(shù)據(jù)同步選型確定之后真正的硬骨頭是切換編排。所謂切換不是管理員在生產(chǎn)中心敲一下命令把VIP漂移到災備中心那么簡單。真實場景下涉及DNS解析變更、負載均衡策略切換、數(shù)據(jù)庫角色切換、應用實例拉起、消息隊列消費位點重置、外圍接口重新對接等多個環(huán)節(jié)。任何一個環(huán)節(jié)遺漏切換后業(yè)務就是“半身不遂”。雙活場景下應用層通常采用七層負載均衡同時分發(fā)到兩個中心的服務器組數(shù)據(jù)庫則是一主一備同步復制。正常情況下應用可以就近讀寫主中心數(shù)據(jù)庫當主中心故障需要將數(shù)據(jù)庫備庫提升為主庫同時負載均衡策略需要把所有寫流量打到新主庫所在中心。這里有一套動作序列必須通過自動化編排平臺來控制而不是靠人工逐個點擊。我們在中亦科技的項目中實際采用了“半自動加人工確認”的編排策略預定義好切換劇本每個步驟自動執(zhí)行但關鍵節(jié)點如數(shù)據(jù)庫角色切換后、應用拉起后會停頓并做自動校驗校驗通過才進入下一步。這個設計看起來“不夠酷”但非常實用。全自動切換在復雜金融系統(tǒng)里太危險一旦校驗條件不充分很容易產(chǎn)生生產(chǎn)事故。3.3 演練體系與驗收方法從“能切”到“敢切”業(yè)務連續(xù)性項目做得好不好不看建設方案多漂亮而是看真實演練時能不能按目標恢復業(yè)務。人保科技和中亦科技團隊在項目后期把重心全部放在了演練上頻率基本達到每月一次定向演練、每季度一次全量演練。演練不是走過場每次都有明確的業(yè)務場景、故障注入方式和恢復驗收標準。完整演練的過程大致分為六個階段宣布演練開始、確定故障場景、執(zhí)行切換腳本、應用拉起、業(yè)務驗收、回切。驗收階段特別重要不能只看系統(tǒng)進程起來了而是要跑真實的業(yè)務Joy。我們會在演練前準備一批專用的測試保單數(shù)據(jù)用自動化測試工具模擬承保、理賠、支付流程確認全鏈路返回正確結(jié)果。只有業(yè)務驗收通過才算演練成功。還要提一個細節(jié)演練必須包含回切而且回切通常比切出更危險。因為回切時數(shù)據(jù)增量如何反向同步、應用是否要短暫停機、如果回切失敗如何處理都需要提前設計。很多項目只練切出不練回切真到需要回切時手忙腳亂。我們規(guī)定每次演練都安排至少一次完整的切出和回切讓團隊形成肌肉記憶。4. 常見問題與排查技巧實錄4.1 數(shù)據(jù)一致性校驗的坑數(shù)據(jù)同步鏈路雖然是實時的但數(shù)據(jù)一致性并不理所當然。最常見的是邏輯同步工具如基于日志解析的CDC在某些特殊DDL操作或手工改數(shù)據(jù)后出現(xiàn)位點錯亂導致備端數(shù)據(jù)與主端不一致。如果沒發(fā)現(xiàn)演練切換后業(yè)務就會遇到臟數(shù)據(jù)。我們的經(jīng)驗是數(shù)據(jù)校驗不能只靠數(shù)據(jù)庫自帶的checksum還必須結(jié)合業(yè)務規(guī)則做抽樣驗證。具體操作上我們建立了一張統(tǒng)一的對賬任務表每天自動比對主備兩端核心表的總行數(shù)、關鍵字段累加值、最新更新時間等指標。對賬會故意加一些小概率的偏差閾值比如主備行數(shù)允許臨時差異但必須在一定時間內(nèi)追上如果持續(xù)漂移就觸發(fā)告警。這里有一個很典型的坑數(shù)據(jù)庫的快照或復制過程可能因為表上有未提交事務比對時會顯示差異其實數(shù)據(jù)是一致的。后來我們規(guī)定對賬腳本必須使用一致的快照點或先做短暫的讀鎖定避免誤報。還有一次演練中我們發(fā)現(xiàn)核心表主鍵重復原因是人工導入數(shù)據(jù)時沒有走復制鏈路導致主端多了幾條記錄而備端通過同步也復制了這幾條本來是一致的?？珊髞韨涠俗鳛榻庸軙r應用又往同樣主鍵寫數(shù)據(jù)直接報錯。排查半天才發(fā)現(xiàn)是歷史數(shù)據(jù)清理不徹底。從此之后所有人工數(shù)據(jù)變更必須走統(tǒng)一流程禁止繞過復制鏈路直接操作兩端。4.2 切換演練時DNS與會話保持問題雙活架構(gòu)下網(wǎng)絡切換通常不是大問題但DNS和會話保持的細節(jié)經(jīng)常讓人崩潰。有一次演練切換后業(yè)務人員反饋部分網(wǎng)頁登錄后頻繁掉線查了半天發(fā)現(xiàn)是負載均衡器的會話保持策略不匹配。生產(chǎn)中心會話保持是基于客戶端IP綁定到固定應用服務器但切換后客戶端IP的物理位置沒有變負載均衡卻把請求分發(fā)到了另一個中心的應用實例會話數(shù)據(jù)沒有同步就導致掉線。解決思路有兩條一是改造應用層把會話數(shù)據(jù)放到分布式緩存如Redis里兩個中心的應用實例通過緩存訪問會話徹底擺脫本地內(nèi)存綁定二是負載均衡策略做調(diào)整切換到“基于Cookie會話保持”或者“全部中心按權(quán)重分發(fā)”。前者是治本方案但需要應用改造工作量不小后者是治標但實施快。我們的落地方式是核心系統(tǒng)盡量改造到分布式會話非核心系統(tǒng)用Cookie保證切換后會話不中斷。另外DNS緩存也是一大坑。切換時如果DNS記錄更新不及時客戶端可能還在訪問已經(jīng)停掉的VIP導致部分流量持續(xù)失敗。后來我們在負載均衡器上配置了較短的TTL并在切換劇本里加入“主動刷新DNS緩存”的步驟同時向全國各網(wǎng)絡節(jié)點推送新的解析記錄明顯減少了切換過渡期的問題。4.3 人員組織與流程協(xié)作避坑技術(shù)問題再多最后都要靠人來落地。業(yè)務連續(xù)性演練最忌諱“演練前臨時拉群通知”一定要有固定的指揮組織。人保科技這邊建立了由運維、應用、網(wǎng)絡、數(shù)據(jù)庫、業(yè)務驗證組成的五方協(xié)同小組每個小組有明確的A/B角演練命令由總指揮統(tǒng)一下達。演練過程中任何組報告異?？傊笓]決定繼續(xù)、回退還是暫停其他所有組必須服從。有一次演練時數(shù)據(jù)庫組已經(jīng)完成了角色切換但應用組還在等并沒說應用拉起完畢導致總指揮誤以為整體失敗差點發(fā)出回退指令。原因就是各組的狀態(tài)通報格式不統(tǒng)一有人發(fā)“切換完成”有人發(fā)“切換中”但通訊群里信息合并后產(chǎn)生歧義。后來我們設計了標準化的狀態(tài)交接模板每個組必須在指定時間點按“當前狀態(tài)已完成動作存在問題”三段式上報溝通效率明顯提升。這個經(jīng)驗對任何大型故障指揮場景都適用不要低估操作紀律的價值。5. 運維運營與持續(xù)改進經(jīng)驗5.1 業(yè)務連續(xù)性不是“建設完就結(jié)束”項目上線只是開始業(yè)務連續(xù)性體系的運營是長期的。很多團隊在災備項目驗收后復制鏈路就不再關注導致半年后真正使用的時候才發(fā)現(xiàn)鏈路早已斷了。我們的做法是建立了一套常態(tài)化健康檢查機制每天自動巡檢復制鏈路狀態(tài)、延遲時間、存儲復制一致性、數(shù)據(jù)庫歸檔日志連續(xù)性任何異常都有告警。另一個重要的是變更管理。金融系統(tǒng)每天都在迭代應用某次發(fā)版如果不小心改了數(shù)據(jù)庫連接串或負載均衡策略很可能影響雙活切換劇本。我們要求所有變更過審時必須評估“對容災切換的影響”并且超過一定級別的變更后必須重跑一次定向演練。這個要求一開始業(yè)務部門覺得麻煩但后來幾次變更后真的避免了切換失敗大家才認可其價值。還有容量管理。雙活中心同時承載生產(chǎn)流量后很多系統(tǒng)的性能基線會變化需要持續(xù)監(jiān)控兩中心的資源水位。如果主中心負載過高備中心卻有大量閑置資源就要考慮流量調(diào)度策略是否合理。我們根據(jù)半年數(shù)據(jù)做過一次“雙中心流量均衡分析”發(fā)現(xiàn)部分讀流量可以從主中心動態(tài)分流到備中心從而提升整體資源利用率相當于把原本“閑置”的容災資源變廢為寶運維團隊也更愿意投入精力維護備中心。5.2 成本與效能平衡如何讓高層愿意持續(xù)投入業(yè)務連續(xù)性建設通常是一次性投入大后續(xù)維護看不到收益所以很容易被預算削減。在這個項目里我們總結(jié)出一個有效的匯報邏輯把業(yè)務連續(xù)性定位為“保險措施”把演練作為“檢驗項”把雙活流量分擔作為“投資收益”。如果備中心能夠常態(tài)化承擔部分業(yè)務負載那么容災成本就從“純支出”變成了“資源復用”高層自然會愿意持續(xù)投入。具體來說我們把一些查詢類、報表類業(yè)務穩(wěn)定分流到備用中心雖然名義上還是容災資源但已經(jīng)在產(chǎn)生業(yè)務價值。同時每次演練都用數(shù)據(jù)說話展示切換對業(yè)務的影響時間從最初的平均25分鐘降到現(xiàn)在的5分鐘以內(nèi)這個數(shù)據(jù)比任何方案都更有說服力。人?？萍歼@個項目讓人印象深刻的一點是他們把業(yè)務連續(xù)性能力做成了標準化的“產(chǎn)品”輸出給集團內(nèi)其他子公司既有統(tǒng)一的平臺又有差異化的分級服務這種共建共享模式值得借鑒。我個人在實際操作中的體會是業(yè)務連續(xù)性建設最難得的不是技術(shù)而是堅持“把每一次演練當真實故障把每一次故障當演練復盤”的心態(tài)。再完善的雙活架構(gòu)如果沒有持續(xù)運營和真實演練關鍵時刻也會掉鏈子。中亦科技和人保科技這次合作能形成新范式核心就在“把復雜留給自己把簡單交給機制”這句話上希望這篇復盤對你正在推進的容災項目有所啟發(fā)。