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