簡(jiǎn)介這是一份面向企業(yè)容災(zāi)規(guī)劃、IT運(yùn)維與架構(gòu)設(shè)計(jì)人員的《容災(zāi)方案》規(guī)范化寫作模板聚焦災(zāi)備策略如何制定、恢復(fù)等級(jí)怎樣選擇、資源要素如何落地等關(guān)鍵問(wèn)題適合作為制度文件或項(xiàng)目方案的底稿。壓縮包內(nèi)為1個(gè)Word格式文檔整體大小約73KB目前已有160人學(xué)習(xí)/下載。文檔采用模塊化結(jié)構(gòu)開(kāi)篇總結(jié)以高層訪談、業(yè)務(wù)影響分析、成本效益分析、合規(guī)要求與可擴(kuò)展性為依托的容災(zāi)設(shè)計(jì)原則并細(xì)致界定機(jī)房火災(zāi)、電力故障及網(wǎng)絡(luò)攻擊等典型場(chǎng)景。正文依據(jù)恢復(fù)時(shí)間目標(biāo)與恢復(fù)點(diǎn)目標(biāo)將能力分為六級(jí)進(jìn)而圍繞數(shù)據(jù)備份、備用數(shù)據(jù)處理、備用網(wǎng)絡(luò)、備用基礎(chǔ)設(shè)施、專業(yè)技術(shù)團(tuán)隊(duì)、運(yùn)行維護(hù)管理及災(zāi)難恢復(fù)預(yù)案七個(gè)要素展開(kāi)架構(gòu)設(shè)計(jì)每個(gè)要素均給出了建設(shè)建議和資源需求分析。結(jié)尾還補(bǔ)充了云備份、虛擬化、異地站點(diǎn)選擇以及全天候監(jiān)控演練等建議可作為容災(zāi)體系評(píng)審、項(xiàng)目申報(bào)或內(nèi)部制度編撰的實(shí)用參考。該模板兼顧理論框架與實(shí)操落地適合直接復(fù)制調(diào)整使用。1. 容災(zāi)方案(模板).doc為什么一份空模板撐不起真實(shí)故障手里這份“容災(zāi)方案(模板).doc”多半是從文庫(kù)下載的標(biāo)準(zhǔn)框架封面、目錄、風(fēng)險(xiǎn)分析、備份策略、恢復(fù)流程目錄齊全表格規(guī)整。但真正讓它失效的從來(lái)不是格式而是里面填的數(shù)字沒(méi)被認(rèn)真算過(guò)——RTO 拍腦袋寫 2 小時(shí)RPO 抄同行寫 15 分鐘切換步驟只寫到“聯(lián)系廠商”演練記錄一欄全是“計(jì)劃中”。下面按著這份 doc 的章節(jié)順序把每欄該填什么、參數(shù)怎么計(jì)算、流程怎么推演講清楚再列出我在真實(shí)切換里踩過(guò)的五個(gè)坑。適合正在補(bǔ)交容災(zāi)文檔的系統(tǒng)維護(hù)工程師也適合負(fù)責(zé)評(píng)審這類方案的人拿來(lái)做對(duì)照清單。2. 先把 RTO/RPO 和故障分級(jí)定死再填模板這兩個(gè)數(shù)字決定方案值多少錢2.1 用業(yè)務(wù)可接受的損失倒推 RTO/RPO而不是抄同行的值很多模板里“核心系統(tǒng) RTO≤2小時(shí)、RPO≤15分鐘”寫得很整齊問(wèn)來(lái)源答參照某某大廠架構(gòu)。這就是空模板最容易埋雷的地方。容災(zāi)目標(biāo)和恢復(fù)能力是兩件事能力由同步備份方案決定目標(biāo)必須由業(yè)務(wù)能扛的損失倒推。我一般會(huì)請(qǐng)業(yè)務(wù)負(fù)責(zé)人回答三組問(wèn)題系統(tǒng)中斷多久會(huì)造成多少實(shí)際營(yíng)業(yè)額損失或合同違約丟失多長(zhǎng)時(shí)間的數(shù)據(jù)你是否能向財(cái)務(wù)、監(jiān)管交差哪些訂單和報(bào)表事后可以補(bǔ)錄哪些必須原樣保留把答案換算成時(shí)間再除以 2 作為緩沖系數(shù)才是該寫進(jìn)模板的目標(biāo)值。比如業(yè)務(wù)說(shuō)停 4 小時(shí)以內(nèi)可以人工引導(dǎo)客戶排隊(duì)那 RTO 就定 2 小時(shí)說(shuō)丟 10 分鐘以上數(shù)據(jù)沒(méi)法交代那 RPO 就定 5 分鐘。緩沖是為了給切換操作留出錯(cuò)空間真故障時(shí)一切都比預(yù)想慢一點(diǎn)。下面是一個(gè)我常用的目標(biāo)值參照表具體值必須按業(yè)務(wù)訪談修正系統(tǒng)類別典型業(yè)務(wù)容忍建議 RTO建議 RPO數(shù)據(jù)同步要求核心交易/支付中斷 30 分鐘開(kāi)始產(chǎn)生重大損失≤15 分鐘≤5 分鐘同步復(fù)制或?qū)崟r(shí)日志訂單/客戶主數(shù)據(jù)中斷 1 小時(shí)內(nèi)可接受人工引導(dǎo)≤30 分鐘≤15 分鐘半同步/秒級(jí)日志內(nèi)部 OA/協(xié)作中斷半天可接受≤2 小時(shí)≤30 分鐘分鐘級(jí)同步數(shù)據(jù)分析平臺(tái)中斷一天可接受≤4 小時(shí)≤1 小時(shí)小時(shí)級(jí)增量同步表格寫完后必須讓業(yè)務(wù)負(fù)責(zé)人和分管領(lǐng)導(dǎo)簽字。不是走形式是明確“這個(gè)目標(biāo)是你認(rèn)可的”否則真出了 3 小時(shí)數(shù)據(jù)丟失業(yè)務(wù)方第一反應(yīng)是“誰(shuí)定的 RPO 15 分鐘”。模板里如果沒(méi)有這一欄自己加一頁(yè)“目標(biāo)確認(rèn)與評(píng)審簽字”。2.2 故障分級(jí)表怎么寫等級(jí)、判據(jù)、響應(yīng)人三列必須精確到人故障分級(jí)不是按設(shè)備壞了幾臺(tái)而是按業(yè)務(wù)損失范圍和時(shí)間來(lái)分。分級(jí)表的目的是讓當(dāng)班人員在一分鐘內(nèi)決定“要不要啟動(dòng)容災(zāi)切換”。我常見(jiàn)的問(wèn)題是把判據(jù)寫成“核心系統(tǒng)故障”“重大故障”什么叫核心、什么算重大兩個(gè)人有兩個(gè)解釋。判據(jù)必須數(shù)字化。故障等級(jí)判據(jù)滿足任一即升級(jí)響應(yīng)負(fù)責(zé)人處置時(shí)限上報(bào)路徑是否啟動(dòng)切換一級(jí)核心業(yè)務(wù)中斷超過(guò) RTO 的一半或數(shù)據(jù)丟失風(fēng)險(xiǎn)達(dá)到 RPO或出現(xiàn) SLA 違約系統(tǒng)負(fù)責(zé)人 運(yùn)維總監(jiān)立即響應(yīng)15 分鐘內(nèi)決策10 分鐘內(nèi)上報(bào) CTO/COO是二級(jí)非核心業(yè)務(wù)中斷或核心業(yè)務(wù)性能嚴(yán)重下降但未中斷模塊負(fù)責(zé)人1 小時(shí)內(nèi)處置并決策1 小時(shí)內(nèi)上報(bào)部門主管評(píng)估后決定三級(jí)單節(jié)點(diǎn)故障、部分功能降級(jí)業(yè)務(wù)未中斷當(dāng)班運(yùn)維4 小時(shí)內(nèi)修復(fù)記入日?qǐng)?bào)否每一條判據(jù)都必須是硬條件比如“核心業(yè)務(wù)中斷超過(guò) RTO 的一半”RTO 是 2 小時(shí)那 1 小時(shí)就是觸發(fā)點(diǎn)“數(shù)據(jù)丟失風(fēng)險(xiǎn)達(dá)到 RPO”意思是同步延遲已經(jīng)超過(guò) RPO 目標(biāo)不能只盯中斷。桌面推演時(shí)最容易吵起來(lái)的就是“這個(gè)算一級(jí)還是二級(jí)”把數(shù)字寫在表格里爭(zhēng)議立刻小一半。具體操作上故障分級(jí)表要貼在值班室的墻上也要存在內(nèi)部文檔庫(kù)監(jiān)控系統(tǒng)的告警級(jí)別和分級(jí)表一一對(duì)應(yīng)。告警級(jí)別和故障級(jí)別如果不一致值班員會(huì)按監(jiān)控優(yōu)先級(jí)來(lái)判斷而不是按業(yè)務(wù)影響來(lái)判斷。模板里往往缺這一條對(duì)齊規(guī)則務(wù)必加上。2.3 “系統(tǒng)掛了”和“數(shù)據(jù)丟了”是兩件事恢復(fù)點(diǎn)到底指什么模板里“數(shù)據(jù)恢復(fù)點(diǎn)目標(biāo)RPO”這一節(jié)經(jīng)常被寫成“備份保留 30 天”。這是完全兩回事。RPO 指的是數(shù)據(jù)能恢復(fù)到故障發(fā)生前的哪個(gè)時(shí)刻它取決于“最后一次能用的備份/日志點(diǎn)”不是“備份文件存了多久”。舉個(gè)例子數(shù)據(jù)庫(kù)每天凌晨 2 點(diǎn)全量備份二進(jìn)制日志實(shí)時(shí)傳到災(zāi)備端。如果災(zāi)備端只是接收日志、沒(méi)有持續(xù)應(yīng)用那么故障發(fā)生在上午 11 點(diǎn)可恢復(fù)點(diǎn)仍然可能是凌晨 2 點(diǎn)而不是 10:59。只有災(zāi)備端把這些日志連續(xù)應(yīng)用并落盤恢復(fù)點(diǎn)才會(huì)接近故障時(shí)刻。所以模板里必須分兩欄寫數(shù)據(jù)備份保留周期數(shù)據(jù)同步與日志應(yīng)用方式。前者回答“我能回溯多少天”后者回答“我能離故障時(shí)刻多近”。組件備份/同步方式最近可用恢復(fù)點(diǎn)影響 RPO 的瓶頸備注主數(shù)據(jù)庫(kù)全量凌晨 2 點(diǎn) 日志實(shí)時(shí)傳輸并應(yīng)用故障前最后一條已應(yīng)用日志日志應(yīng)用延遲延遲超過(guò) 300 秒需告警配置中心配置變更記錄 每 5 分鐘導(dǎo)出最近一次導(dǎo)出點(diǎn)導(dǎo)出任務(wù)是否成功對(duì)象存儲(chǔ)保留 7 天對(duì)象存儲(chǔ)跨區(qū)域復(fù)制復(fù)制目標(biāo)端最后同步時(shí)間復(fù)制隊(duì)列積壓每天檢查積壓數(shù)量同樣的邏輯也適用于 RTORTO 不是“數(shù)據(jù)庫(kù)進(jìn)程啟動(dòng)時(shí)間”而是“業(yè)務(wù)能對(duì)外提供完整功能的時(shí)間”。完整功能包含登錄、查詢、下單、消息推送任何一個(gè)依賴服務(wù)沒(méi)恢復(fù)都不能算恢復(fù)。因此寫方案時(shí)把“數(shù)據(jù)恢復(fù)時(shí)間”“應(yīng)用恢復(fù)時(shí)間”“依賴恢復(fù)時(shí)間”三個(gè)字段分開(kāi)列最后回填到切換流程里才能避免把局部成功宣傳成整體恢復(fù)。這也是評(píng)審時(shí)最容易被問(wèn)倒的地方。3. 逐節(jié)拆解模板拓?fù)洹⑼椒绞?、切換流程這三處最容易填成廢話3.1 文檔頭、術(shù)語(yǔ)表和職責(zé)矩陣模板的占位說(shuō)明留不得從文庫(kù)下載的模板第一頁(yè)基本是“項(xiàng)目名稱、編制人、日期”的占位符。很多人只改了項(xiàng)目名就往下交。但真正決定這份方案能不能在故障時(shí)被執(zhí)行的是最不起眼的三個(gè)部分版本記錄、術(shù)語(yǔ)表、職責(zé)矩陣。版本記錄至少要有日期、修改人、修改內(nèi)容三列并且每次演練后都要加一行。否則現(xiàn)場(chǎng)拿到的方案自己都不知道是不是半年沒(méi)更新的舊版。術(shù)語(yǔ)表需要把 RTO、RPO、災(zāi)備中心、切換、回切這些詞統(tǒng)一解釋一遍因?yàn)闃I(yè)務(wù)、運(yùn)維、管理層對(duì)“切換”的理解經(jīng)常是完全相反的。職責(zé)矩陣比人員名單更實(shí)用寫清每個(gè)階段“誰(shuí)有權(quán)拍板、誰(shuí)來(lái)操作、誰(shuí)來(lái)驗(yàn)證、通知誰(shuí)”。階段決策人執(zhí)行人驗(yàn)證人通知對(duì)象時(shí)限故障發(fā)現(xiàn)、定級(jí)當(dāng)班運(yùn)維當(dāng)班運(yùn)維監(jiān)控系統(tǒng)值班長(zhǎng)5 分鐘一級(jí)故障升級(jí)運(yùn)維總監(jiān)值班長(zhǎng)無(wú)CTO/COO10 分鐘啟動(dòng)容災(zāi)切換運(yùn)維總監(jiān) 業(yè)務(wù)負(fù)責(zé)人系統(tǒng)工程師業(yè)務(wù)代表全員公告15 分鐘災(zāi)備業(yè)務(wù)驗(yàn)證業(yè)務(wù)負(fù)責(zé)人應(yīng)用工程師業(yè)務(wù)代表客服/客戶經(jīng)理30 分鐘回切決策運(yùn)維總監(jiān) 業(yè)務(wù)負(fù)責(zé)人系統(tǒng)工程師業(yè)務(wù)代表全員公告回切窗口內(nèi)特別注意執(zhí)行人一欄寫崗位不要寫具體人名。我見(jiàn)過(guò)某份方案把切換執(zhí)行人寫成一位已經(jīng)離職的同事真故障時(shí)所有人看著這個(gè)空位不敢動(dòng)。崗位定義之后人員變動(dòng)只需要更新排班表不需要改方案正文。3.2 容災(zāi)拓?fù)湓趺串嬌a(chǎn)中心、災(zāi)備中心、同步鏈路一個(gè)不能少拓?fù)鋱D不需要畫得多漂亮但必須包含四個(gè)信息生產(chǎn)中心與災(zāi)備中心各自的范圍每條數(shù)據(jù)同步鏈路的復(fù)制方式和方向鏈路帶寬與時(shí)延切換邊界。很多方案只畫了生產(chǎn)到災(zāi)備兩條線旁邊標(biāo)注“同步復(fù)制”看起來(lái)干凈卻丟失了大量決策信息。更重要的是拓?fù)湟岩蕾囅到y(tǒng)畫全。切換數(shù)據(jù)庫(kù)和應(yīng)用只是第一步DNS 解析、負(fù)載均衡、認(rèn)證中心、消息隊(duì)列、對(duì)象存儲(chǔ)這些外圍依賴如果還指向生產(chǎn)業(yè)務(wù)就會(huì)“切了個(gè)寂寞”。比如客戶端配置了固定 IP 直連生產(chǎn)DNS 切了也沒(méi)用負(fù)載均衡后端沒(méi)切換流量還是會(huì)進(jìn)到老的服務(wù)池。要素生產(chǎn)環(huán)境災(zāi)備環(huán)境依賴關(guān)系切換后需要改什么Web 入口/VIP生產(chǎn) SLB 地址災(zāi)備 SLB 地址依賴 DNS、證書DNS 記錄、LB 后端池應(yīng)用服務(wù)集群生產(chǎn)應(yīng)用節(jié)點(diǎn)災(zāi)備應(yīng)用節(jié)點(diǎn)依賴配置中心、數(shù)據(jù)庫(kù)配置項(xiàng)、環(huán)境變量主數(shù)據(jù)庫(kù)生產(chǎn)主庫(kù)災(zāi)備從庫(kù)/備庫(kù)同步鏈路、日志應(yīng)用數(shù)據(jù)源地址消息隊(duì)列生產(chǎn)集群災(zāi)備集群消費(fèi)端連接客戶端連接地址對(duì)象存儲(chǔ)生產(chǎn)桶災(zāi)備桶復(fù)制任務(wù)域名/路徑改寫在鏈路帶寬與時(shí)延的填寫上給一個(gè)經(jīng)驗(yàn)值同城機(jī)房 RTT 小于 2 毫秒存儲(chǔ)層同步復(fù)制基本能接受跨城 RTT 超過(guò) 20 毫秒時(shí)同步復(fù)制會(huì)嚴(yán)重拖累生產(chǎn)寫入性能常見(jiàn)做法是降級(jí)為半同步或異步日志。模板里如果沒(méi)有“時(shí)延”這個(gè)參數(shù)欄請(qǐng)自己加因?yàn)樗沁x型同步方式的主要依據(jù)。3.3 數(shù)據(jù)同步方式選型和帶寬評(píng)估這塊最容易在兩年后翻車數(shù)據(jù)同步方式?jīng)Q定 RPO 上限帶寬決定同步是否能持續(xù)跟上。模板里“數(shù)據(jù)同步方案”一節(jié)通常只寫幾個(gè)字“主備庫(kù)實(shí)時(shí)同步”。具體用什么機(jī)制、多久校驗(yàn)一次、帶寬夠不夠一個(gè)字都沒(méi)有。這里給一張對(duì)比表方便你直接替換到方案里。同步方式原理典型 RPO 能力對(duì)生產(chǎn)影響切換復(fù)雜度適用距離存儲(chǔ)層同步復(fù)制塊設(shè)備級(jí)鏡像秒級(jí)距離近時(shí)影響較小鏈路抖動(dòng)可能拖慢 IO低存儲(chǔ)版本需一致同城/短距離數(shù)據(jù)庫(kù)日志同步日志實(shí)時(shí)傳輸并應(yīng)用秒級(jí)到分鐘級(jí)低占用少量網(wǎng)絡(luò)與 IO中需處理一致點(diǎn)同城/跨城均可應(yīng)用雙寫業(yè)務(wù)代碼同時(shí)寫兩中心亞秒級(jí)高需改造代碼、處理沖突高需設(shè)計(jì)補(bǔ)償機(jī)制任意定時(shí)備份傳輸周期性備份后傳到災(zāi)備小時(shí)級(jí)低低任意選擇邏輯不復(fù)雜能接受 5 分鐘級(jí) RPO日志同步是性價(jià)比最高的要求秒級(jí)則存儲(chǔ)層同步或應(yīng)用雙寫。需要提醒的是存儲(chǔ)同步復(fù)制不是“買了就穩(wěn)”鏈路抖動(dòng)會(huì)導(dǎo)致生產(chǎn)寫 IO 變慢災(zāi)備端磁盤慢也會(huì)反過(guò)來(lái)拖生產(chǎn)。所以方案里要注明同步鏈路必須獨(dú)立于業(yè)務(wù)帶寬并且每季度壓測(cè)一次。帶寬評(píng)估我一般用一個(gè)經(jīng)驗(yàn)公式帶寬需求Mbps≈ 每日增量數(shù)據(jù)量GB× 8 × 壓縮比系數(shù) × 峰值系數(shù) / 備份窗口小時(shí)/ 3600 × 1000。舉個(gè)例子每天日志增量 200GB文本類日志壓縮比按 0.3 算峰值系數(shù)取 2要求 4 小時(shí)傳完帶寬需求就是 200 × 8 × 0.3 × 2 / 4 / 3600 × 1000約 67Mbps。再考慮切換時(shí)繼續(xù)追增量實(shí)際申請(qǐng)帶寬建議留 30% 到 50% 余量至少申請(qǐng) 100Mbps。模板里不要只寫“帶寬 100M”要把這個(gè)計(jì)算過(guò)程留在附錄里方便兩年后數(shù)據(jù)量翻倍時(shí)重新評(píng)估。3.4 切換與回切流程必須精確到人、分鐘和具體命令模板里的“切換流程”常常寫著通知業(yè)務(wù)、停止生產(chǎn)、拉起災(zāi)備、驗(yàn)證。四個(gè)動(dòng)詞就想覆蓋一次事故。真實(shí)切換至少有十步每一步都要有負(fù)責(zé)人、預(yù)計(jì)耗時(shí)、檢查手段和通過(guò)標(biāo)準(zhǔn)步驟操作負(fù)責(zé)人預(yù)計(jì)耗時(shí)通過(guò)標(biāo)準(zhǔn)1. 發(fā)布故障公告并凍結(jié)變更客服、CMDB 同時(shí)公告值班長(zhǎng)5 分鐘公告已發(fā)出變更窗口關(guān)閉2. 停止生產(chǎn)寫入口掛維護(hù)頁(yè)/停接入運(yùn)維工程師5 分鐘新寫入流量歸零3. 確認(rèn)災(zāi)備同步一致點(diǎn)查詢?nèi)罩緫?yīng)用位置DBA10 分鐘延遲為 0無(wú)報(bào)錯(cuò)4. 拉起災(zāi)備數(shù)據(jù)庫(kù)切換主備角色DBA15 分鐘數(shù)據(jù)庫(kù)可讀寫5. 進(jìn)行一致性檢查對(duì)比關(guān)鍵表行數(shù)/checksumDBA10 分鐘差異為 06. 切換配置中心與 DNS更新配置項(xiàng)/DNS 記錄應(yīng)用工程師10 分鐘新域名解析指向?yàn)?zāi)備7. 拉起應(yīng)用服務(wù)集群?jiǎn)?dòng)災(zāi)備應(yīng)用應(yīng)用工程師10 分鐘健康檢查通過(guò)8. 驗(yàn)證核心業(yè)務(wù)鏈路登錄/查詢/寫測(cè)試數(shù)據(jù)業(yè)務(wù)代表15 分鐘全部用例通過(guò)9. 對(duì)外公告恢復(fù)客服、客戶經(jīng)理同步運(yùn)維總監(jiān)5 分鐘公告已發(fā)布10. 觀察窗口監(jiān)控連接數(shù)與錯(cuò)誤率當(dāng)班運(yùn)維30-120 分鐘錯(cuò)誤率低于閾值有些步驟可以并行但這張表是最慢路徑的基線。方案里必須寫清第 3 步和第 5 步的具體檢查命令和期望輸出比如“查詢同步狀態(tài)IO/SQL 線程均為 Yes延遲小于 300 秒”。沒(méi)有這些期望輸出操作者會(huì)憑感覺(jué)判斷是否一致這正是切換失敗的主要來(lái)源?；厍斜惹袚Q更容易翻車。災(zāi)備端作為生產(chǎn)運(yùn)行期間也會(huì)產(chǎn)生增量數(shù)據(jù)回切時(shí)必須把這些增量按相反方向同步回生產(chǎn)再做一致性校驗(yàn)才能把流量切回來(lái)。模板里如果只有“切換”沒(méi)有“回切”直接補(bǔ)一節(jié)回切窗口選業(yè)務(wù)低峰期、先反向增量同步、校驗(yàn)行數(shù)與 checksum、切換生產(chǎn)入口、做破壞性驗(yàn)證。我見(jiàn)過(guò)最慘的一次事故就是在回切時(shí)數(shù)據(jù)不一致導(dǎo)致重復(fù)訂單比故障本身?yè)p失更大。4. 讓模板變成能跑的體系演練四步法加配套文檔而不是網(wǎng)盤里的擺設(shè)4.1 演練四步法從桌面推演到真切換每一步的產(chǎn)出物是什么容災(zāi)方案最怕的是“文檔寫完了一次沒(méi)練過(guò)”。不演練的方案等于給領(lǐng)導(dǎo)看了張效果圖。責(zé)任心強(qiáng)也沒(méi)用因?yàn)楹芏嗉?xì)節(jié)只有跑一遍才會(huì)暴露。我建議把演練拆成四個(gè)遞進(jìn)等級(jí)按季度和年度滾動(dòng)執(zhí)行每一級(jí)都有明確產(chǎn)出物。演練級(jí)別操作內(nèi)容頻率建議產(chǎn)出物參與范圍桌面推演按方案逐條朗讀流程口頭模擬每季度流程修訂清單全體相關(guān)角色單組件模擬災(zāi)備端拉起數(shù)據(jù)庫(kù)/存儲(chǔ)驗(yàn)證同步每季度數(shù)據(jù)一致性報(bào)告DBA 運(yùn)維半切換只將只讀流量或測(cè)試賬號(hào)切到災(zāi)備每半年連通性與性能報(bào)告應(yīng)用 業(yè)務(wù)代表實(shí)切演練低峰期按正式流程切換真實(shí)生產(chǎn)流量每年切換記錄 改進(jìn)項(xiàng)全員桌面推演的成本很低但收獲最大。第一次推演大多會(huì)發(fā)現(xiàn)流程里有 3 到 5 處矛盾比如職責(zé)矩陣寫“DBA 執(zhí)行切換”可 DBA 的排班表上那天不在切換流程第 2 步“停止生產(chǎn)寫入口”和第 3 步“同步一致點(diǎn)”的邏輯順序反了冒然停寫會(huì)丟失最后一小段數(shù)據(jù)。推演的目的就是把這些問(wèn)題改到紙上而不是留到故障時(shí)現(xiàn)場(chǎng)解決。單組件模擬用來(lái)驗(yàn)證災(zāi)備端本身是否可用。很多災(zāi)備端數(shù)據(jù)庫(kù)從搭建就沒(méi)有再用過(guò)補(bǔ)丁落后、磁盤余量不足、同步作業(yè)早就失敗只有模擬時(shí)才會(huì)暴露。半切換則測(cè)試“流量改道”這一環(huán)DNS、負(fù)載均衡、客戶端緩存都可能在這里現(xiàn)形。4.2 配套腳本和 check 清單光有 doc 沒(méi)有 runbook 就是廢紙模板正文寫得再細(xì)也代替不了可執(zhí)行的操作卡。我們內(nèi)部叫“runbook”每個(gè)容災(zāi)對(duì)象系統(tǒng)都要有一份。runbook 不必是復(fù)雜系統(tǒng)一個(gè)表格就可以操作步驟、執(zhí)行位置、檢查命令、期望輸出、失敗處理。關(guān)鍵是要讓一個(gè)不熟悉該系統(tǒng)的人也能照著做。步驟執(zhí)行位置檢查命令/操作期望輸出失敗處理1災(zāi)備數(shù)據(jù)庫(kù)主機(jī)查詢主從同步狀態(tài)IO/SQL 線程均為 Yes延遲 300 秒聯(lián)系 DBA禁止繼續(xù)切換2災(zāi)備數(shù)據(jù)庫(kù)主機(jī)檢查磁盤剩余空間剩余空間 200GB 或超過(guò)增量 2 倍清理并擴(kuò)容后再繼續(xù)3生產(chǎn)負(fù)載均衡停用生產(chǎn)后端節(jié)點(diǎn)生產(chǎn)流量為 0確認(rèn)維護(hù)頁(yè)已生效4災(zāi)備應(yīng)用主機(jī)啟動(dòng)應(yīng)用服務(wù)健康檢查接口返回 200查日志重復(fù)啟動(dòng)步驟不超 3 次5災(zāi)備環(huán)境執(zhí)行核心業(yè)務(wù)用例登錄、查詢、下單全部成功報(bào)告指揮啟動(dòng)回退預(yù)案這些命令必須寫明“期望輸出”不能只寫“檢查是否正常”。正常情況下誰(shuí)也說(shuō)不清正常長(zhǎng)什么樣有了期望輸出的對(duì)照?qǐng)?zhí)行人一點(diǎn)不猶豫。失敗處理也要預(yù)先寫好比如“同步狀態(tài)異常時(shí)禁止切換”而不是“聯(lián)系 DBA 確定”因?yàn)楣收犀F(xiàn)場(chǎng)的高壓環(huán)境里聯(lián)系 DBA 的結(jié)果往往是等 DBA 慢慢查半小時(shí)。腳本和 runbook 要進(jìn)版本管理和方案 doc 一起發(fā)布并且每次演練后更新。常見(jiàn)做法是在內(nèi)部代碼倉(cāng)庫(kù)建一個(gè)“容災(zāi)”目錄每個(gè)系統(tǒng)一組方案 doc、切換腳本、checklist、演練記錄、復(fù)盤報(bào)告。這套東西不是一次性的是持續(xù)維護(hù)的運(yùn)維資產(chǎn)。只把模板存在網(wǎng)盤里不管下次用的時(shí)候一定和你記憶中的版本不一樣。4.3 文檔版本管理與復(fù)盤機(jī)制模板要在演練后繼續(xù)活容災(zāi)方案和代碼一樣必須版本化。每次架構(gòu)變化都要觸發(fā)更新應(yīng)用從物理機(jī)遷到虛擬化數(shù)據(jù)庫(kù)版本升級(jí)網(wǎng)絡(luò)分區(qū)變動(dòng)業(yè)務(wù)系統(tǒng)下線。這些變化任何一個(gè)都會(huì)讓既有方案失效。模板里如果只有“編制日期”沒(méi)有“版本記錄”說(shuō)明這份方案大概率已經(jīng)過(guò)期。我建議給模板加兩個(gè)機(jī)制一是每年評(píng)審機(jī)制到期由運(yùn)維負(fù)責(zé)人發(fā)起評(píng)審確認(rèn) RTO/RPO 是否仍然被業(yè)務(wù)認(rèn)可災(zāi)備容量是否跟得上生產(chǎn)增長(zhǎng)同步延遲是否在合理區(qū)間。二是演練后強(qiáng)制復(fù)盤機(jī)制每次實(shí)切演練結(jié)束后 5 個(gè)工作日內(nèi)必須輸出復(fù)盤報(bào)告列出“流程偏差、原因、改進(jìn)動(dòng)作、責(zé)任人”。復(fù)盤報(bào)告要回到文檔本身改錯(cuò)的直接改到模板里而不是只寫一句“下次注意”。這就是讓 doc 從“被下載的模板”變成活文檔的關(guān)鍵。5. 容災(zāi)方案落地避坑5 個(gè)讓模板失效的血淚點(diǎn)5.1 現(xiàn)象RPO 拍板寫 15 分鐘真故障丟了 3 小時(shí)增量數(shù)據(jù)某次故障后復(fù)盤方案白紙黑字寫著“RPO ≤ 15 分鐘”實(shí)際恢復(fù)時(shí)卻丟失了約 3 小時(shí)的數(shù)據(jù)。原因不是恢復(fù)操作失誤而是 RPO 目標(biāo)與數(shù)據(jù)同步能力根本沒(méi)有對(duì)賬備份作業(yè)每 4 小時(shí)一次最后一次全量已經(jīng)跑了 2 小時(shí)日志傳輸鏈路中間斷了 1 小時(shí)沒(méi)人發(fā)現(xiàn)恢復(fù)時(shí)只能回到最后一次成功的備份點(diǎn)。RPO 是“寫出來(lái)的承諾”同步能力是“實(shí)際交付的水平”兩者差了一截。解決把 RPO 目標(biāo)值除以 3 作為同步告警閾值。比如目標(biāo) 15 分鐘那么同步延遲超過(guò) 5 分鐘就要告警超過(guò) 10 分鐘必須人工介入。同時(shí)每周統(tǒng)計(jì)一次“最近可用恢復(fù)點(diǎn)與當(dāng)前時(shí)間”的差值把它做成儀表盤貼在運(yùn)維周報(bào)里。這樣 RPO 從紙面數(shù)字變成可觀測(cè)指標(biāo)不再是黑匣子。5.2 現(xiàn)象災(zāi)備端切換成功業(yè)務(wù)卻連不上DNS 和接入層沒(méi)人管演練時(shí)數(shù)據(jù)庫(kù)和應(yīng)用都起來(lái)了測(cè)試工程師輸入域名卻打不開(kāi)頁(yè)面。查了半天發(fā)現(xiàn)切換腳本只切了數(shù)據(jù)庫(kù)與應(yīng)用的 IP 地址DNS 解析還指向生產(chǎn)環(huán)境的 VIP負(fù)載均衡后端也仍然綁著生產(chǎn)節(jié)點(diǎn)。也就是說(shuō)肚子里已經(jīng)換了系統(tǒng)門口的路標(biāo)還指著舊地址。很多人默認(rèn)“數(shù)據(jù)庫(kù)切了就代表容災(zāi)成功”忘記了用戶只能通過(guò)入口訪問(wèn)。解決在模板中把流量入口切換作為獨(dú)立步驟列出四類入口DNS 記錄、負(fù)載均衡后端、客戶端連接配置、CDN 回源地址。切換后必須做“從外部視角”的驗(yàn)證比如從一臺(tái)不相關(guān)的主機(jī)執(zhí)行域名解析和健康檢查而不是在生產(chǎn)環(huán)境的服務(wù)器上自測(cè)。自測(cè)出現(xiàn)“本地通”的情況十有八九是走了本機(jī) hosts 或內(nèi)網(wǎng)地址。5.3 現(xiàn)象災(zāi)備機(jī)房從沒(méi)被讀過(guò)恢復(fù)時(shí)才發(fā)現(xiàn)磁盤滿了、補(bǔ)丁落后一次真實(shí)切換災(zāi)備數(shù)據(jù)庫(kù)拉起來(lái)后只讀測(cè)試就報(bào)錯(cuò)進(jìn)一步看磁盤剩余空間只有幾 GB數(shù)據(jù)庫(kù)補(bǔ)丁落后生產(chǎn)兩年復(fù)制任務(wù)三個(gè)月前就因磁盤滿而失敗。原因是災(zāi)備端一直處于“待機(jī)”狀態(tài)平時(shí)沒(méi)人巡檢備份作業(yè)報(bào)了錯(cuò)也只是報(bào)警郵件躺在郵箱里。沒(méi)有業(yè)務(wù)流量不代表沒(méi)有運(yùn)維任務(wù)災(zāi)備端需要持續(xù)喂養(yǎng)。解決給災(zāi)備端建立專項(xiàng)巡檢清單每天查同步狀態(tài)與延遲每周查磁盤容量、備份作業(yè)日志每月做一次“只讀拉起”測(cè)試至少把庫(kù)啟動(dòng)起來(lái)跑幾條查詢每季度做完整冒煙。更重要的是把這些巡檢結(jié)果接入現(xiàn)有監(jiān)控平臺(tái)而不是靠人肉眼去看否則只要連續(xù)兩周沒(méi)人看這個(gè)方案就等于又回到了紙面狀態(tài)。5.4 現(xiàn)象切過(guò)去了回不來(lái)回切流程永遠(yuǎn)只是模板里的一句話某系統(tǒng)故障時(shí)順利切到災(zāi)備運(yùn)行兩天后需要回切卻發(fā)現(xiàn)災(zāi)備端產(chǎn)生的增量數(shù)據(jù)沒(méi)有同步回生產(chǎn)兩邊的庫(kù)存表行數(shù)差了幾十萬(wàn)回切直接導(dǎo)致重復(fù)訂單。模板里的“回切”只有一句話“按照切換流程反向操作”完全沒(méi)寫增量同步和一致性校驗(yàn)。災(zāi)備端作為生產(chǎn)運(yùn)行的每一分鐘都在產(chǎn)生新數(shù)據(jù)把這些數(shù)據(jù)弄回生產(chǎn)正是回切的關(guān)鍵。解決在方案中單獨(dú)寫回切章節(jié)故障恢復(fù)后業(yè)務(wù)繼續(xù)在災(zāi)備端運(yùn)行至少 24 小時(shí)選擇低峰窗口回切先做反向增量同步比較關(guān)鍵表的行數(shù)和 checksum差異歸零后再恢復(fù)生產(chǎn)流量回切后關(guān)閉災(zāi)備端寫入口防止兩邊同時(shí)寫入造成腦裂?；厍泻颓袚Q一樣要寫入年度演練計(jì)劃至少每年實(shí)切一回否則項(xiàng)目里這最后一公里永遠(yuǎn)是盲區(qū)。5.5 現(xiàn)象軟件授權(quán)到期了技術(shù)支持才說(shuō)“只覆蓋安裝不覆蓋切換”有單位買的容災(zāi)軟件授權(quán)里技術(shù)支持響應(yīng)時(shí)限是“工作時(shí)間內(nèi) 48 小時(shí)”真在周六凌晨發(fā)生故障電話打了三小時(shí)沒(méi)人接最后是供應(yīng)商值班人員“友情支持”處理的。合同里根本沒(méi)寫“故障啟動(dòng)支持”和“演練陪伴”服務(wù)。軟件授權(quán)通常只保證你能用軟件不保證有人能幫你切換也不保證切換時(shí)業(yè)務(wù)能通。解決把服務(wù)問(wèn)題寫進(jìn)方案附錄而不是口頭約定。方案里要有一頁(yè)“供應(yīng)商責(zé)任矩陣”明確軟件版本、維保期限、支持響應(yīng)時(shí)限、是否包含演練技術(shù)支持、是否包含故障現(xiàn)場(chǎng)支持。至少每半年更新一次供應(yīng)商聯(lián)系人。這個(gè)動(dòng)作不復(fù)雜但能讓容災(zāi)方案從“軟件功能清單”變成“可承諾的業(yè)務(wù)保障”。要知道出故障時(shí)最可怕的不是恢復(fù)時(shí)間長(zhǎng)而是沒(méi)人拍板、沒(méi)人能操作、沒(méi)人承擔(dān)邊界。6. 容災(zāi)方案的最后一公里用“紅隊(duì)演練”驗(yàn)證這版 doc 的真實(shí)成色6.1 一個(gè)值得養(yǎng)成的習(xí)慣每年做一次不打招呼的“故障注入”常規(guī)演練都有一個(gè)通病提前通知所有人該修的隱患提前修了該背的腳本提前背了演練結(jié)果自然好看卻很難證明方案真正可靠。紅隊(duì)演練的思路是只有運(yùn)維負(fù)責(zé)人和高層知道業(yè)務(wù)側(cè)與當(dāng)班人員完全不知情在某個(gè)月業(yè)務(wù)低峰時(shí)段對(duì)生產(chǎn)系統(tǒng)做一次“受控故障注入”觀察值班人員在沒(méi)有預(yù)演的情況下是不是真的能按模板完成切換。實(shí)施時(shí)要控制邊界階段操作要點(diǎn)準(zhǔn)備期選定一個(gè)只讀功能或非核心接口提前申請(qǐng)變更窗口選錯(cuò)故障點(diǎn)會(huì)傷到生產(chǎn)紅隊(duì)演練也別真把數(shù)據(jù)搞壞故障注入模擬同步鏈路中斷或數(shù)據(jù)庫(kù)連接池打滿制造的是“可觀測(cè)故障”不是“不可控災(zāi)難”觀察期不提示只記錄從告警到啟動(dòng)預(yù)案的時(shí)間重點(diǎn)看值班人員是否第一時(shí)間想到翻模板復(fù)盤期對(duì)照 RTO/RPO 目標(biāo)逐項(xiàng)打分找出超過(guò)閾值的步驟回寫方案和腳本我第一次組織紅隊(duì)演練時(shí)把災(zāi)備數(shù)據(jù)庫(kù)的同步狀態(tài)設(shè)成了“延遲 10 分鐘”觀察發(fā)現(xiàn)值班員看到了告警卻等了 20 分鐘才叫醒負(fù)責(zé)人更沒(méi)人去打開(kāi)容災(zāi)模板因?yàn)槟_本里的執(zhí)行人寫著某位離職工程師的名字。那次之后我養(yǎng)成了兩個(gè)習(xí)慣所有容災(zāi)文檔的“執(zhí)行人”一律寫崗位不寫人名每季度翻一次模板改掉所有與實(shí)際環(huán)境不一致的地方。紅隊(duì)演練不用多一年一次就好但它能把一份模板從“目錄整潔”變成“真能被執(zhí)行”。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取