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