1. 項(xiàng)目定位容災(zāi)備份中心的第三方測試到底測什么接手“軍工信息系統(tǒng)容災(zāi)備份中心建設(shè)軟件第三方測試方案”這個(gè)項(xiàng)目時(shí)第一反應(yīng)不是去翻需求文檔而是先想清楚一個(gè)前提問題這套容災(zāi)備份系統(tǒng)在建設(shè)完成之后為什么還要單獨(dú)拉一支第三方測試隊(duì)伍進(jìn)場容災(zāi)備份中心的核心價(jià)值就一句話業(yè)務(wù)數(shù)據(jù)不丟、核心業(yè)務(wù)不停。對應(yīng)到技術(shù)指標(biāo)上就是RPO Recovery Point Objective恢復(fù)點(diǎn)目標(biāo)和RTORecovery Time Objective恢復(fù)時(shí)間目標(biāo)。RPO決定了你能容忍丟多少數(shù)據(jù)RTO決定了你能容忍業(yè)務(wù)中斷多久。軍工信息系統(tǒng)的業(yè)務(wù)連續(xù)性要求極高RPO和RTO往往卡得非常緊數(shù)據(jù)丟失和業(yè)務(wù)中斷的代價(jià)都不是用金錢能衡量的。第三方測試的價(jià)值在于“獨(dú)立性”。研發(fā)方自測天然存在盲區(qū)開發(fā)人員對自己寫的代碼有路徑依賴測來測去總是繞著熟悉的功能打轉(zhuǎn)運(yùn)維方關(guān)注的是日常運(yùn)行很難站在“故意搞破壞”的角度去驗(yàn)證系統(tǒng)的極限能力。第三方測試的核心思維是“假設(shè)它會(huì)壞然后想辦法讓它壞”。只有通過主動(dòng)制造故障、故意中斷鏈路、模擬極端場景才能把容災(zāi)系統(tǒng)真正的底牌摸清楚。這次項(xiàng)目的“部分內(nèi)容”定位也很明確不是從零開始寫一份完整測試方案而是針對容災(zāi)備份中心建設(shè)中的關(guān)鍵測試專項(xiàng)進(jìn)行細(xì)化設(shè)計(jì)。整體方案里已經(jīng)確定了測試范圍、測試資源、進(jìn)度計(jì)劃這部分內(nèi)容重點(diǎn)解決的是“具體怎么測、判定標(biāo)準(zhǔn)是什么、故障怎么注入、數(shù)據(jù)怎么校驗(yàn)”這些可落地的細(xì)節(jié)。適合讀這篇內(nèi)容的人主要是三類一是做容災(zāi)備份系統(tǒng)測試的工程師可以參考測試項(xiàng)設(shè)計(jì)和判定準(zhǔn)則二是做數(shù)據(jù)中心建設(shè)項(xiàng)目的管理人員可以用里面的檢查點(diǎn)去監(jiān)督第三方測試質(zhì)量三是剛?cè)胄邢胱鰷y試方案設(shè)計(jì)的同學(xué)里面有很多實(shí)際執(zhí)行層面的坑和經(jīng)驗(yàn)。2. 第三方測試的總體策略與方案設(shè)計(jì)要點(diǎn)2.1 測試策略四類測試的投入比例怎么定容災(zāi)備份系統(tǒng)的第三方測試我習(xí)慣劃分為四大類功能性測試、性能測試、可靠性測試、安全性測試。這四類不是平均用力而是根據(jù)系統(tǒng)建設(shè)階段和風(fēng)險(xiǎn)等級動(dòng)態(tài)調(diào)整。功能性測試重點(diǎn)驗(yàn)證容災(zāi)備份的基本能力包括數(shù)據(jù)同步是否正常、備份任務(wù)能否按策略執(zhí)行、切換流程是否完整、恢復(fù)操作是否可用。對于軍工信息系統(tǒng)功能測試要覆蓋“正常路徑”和“異常路徑”兩條腿很多人只測正常路徑結(jié)果故障演練的時(shí)候一步都走不通。性能測試關(guān)注的是同步延遲、備份窗口、恢復(fù)速度、并發(fā)處理能力等指標(biāo)。這里有個(gè)關(guān)鍵點(diǎn)容災(zāi)備份系統(tǒng)的性能指標(biāo)必須在“接近真實(shí)負(fù)載”的條件下測試而不是在空庫、低并發(fā)環(huán)境下測一個(gè)好看的數(shù)字。我在模擬項(xiàng)目X中接過一個(gè)項(xiàng)目前期的性能測試報(bào)告非常漂亮數(shù)據(jù)同步幾乎零延遲結(jié)果真實(shí)業(yè)務(wù)接入后延遲暴漲原因就是測試環(huán)境的寫入并發(fā)只有生產(chǎn)環(huán)境的十分之一?？煽啃詼y試是重頭戲包括故障注入測試、切換演練、斷電斷網(wǎng)模擬、數(shù)據(jù)損壞模擬等。這部分測試的投入占比至少要達(dá)到40%以上。可靠性測試不是“走個(gè)過場”而是要真正制造故障觀察系統(tǒng)的真實(shí)反應(yīng)。安全性測試在軍工場景下尤為重要包括備份數(shù)據(jù)的加密存儲(chǔ)、訪問控制、傳輸鏈路安全、備份介質(zhì)管理等方面必須確保容災(zāi)數(shù)據(jù)本身不被泄露或篡改。2.2 測試環(huán)境搭建隔離、仿真、脫敏三原則測試環(huán)境是第三方測試的“試驗(yàn)臺(tái)”搭建得好不好直接決定測試結(jié)果的可信度。容災(zāi)備份系統(tǒng)的測試環(huán)境搭建我總結(jié)為三個(gè)原則隔離性、仿真性、數(shù)據(jù)脫敏。隔離性是底線。測試環(huán)境必須與生產(chǎn)環(huán)境完全隔離網(wǎng)絡(luò)不能互通存儲(chǔ)不能共用賬號體系也要分開。有些單位為了省事在生產(chǎn)環(huán)境的空閑網(wǎng)段上劃一塊出來做測試這種做法非常危險(xiǎn)故障注入測試一旦失控可能直接影響生產(chǎn)業(yè)務(wù)。軍工信息系統(tǒng)對隔離性的要求更高物理隔離比邏輯隔離更穩(wěn)妥。仿真性決定了測試結(jié)果的有效性。網(wǎng)絡(luò)拓?fù)湟抡丈a(chǎn)環(huán)境容災(zāi)鏈路的帶寬、時(shí)延、抖動(dòng)參數(shù)要盡量接近真實(shí)情況。存儲(chǔ)設(shè)備型號、磁盤陣列配置、備份軟件的版本也要與生產(chǎn)環(huán)境保持一致。如果測試環(huán)境和生產(chǎn)環(huán)境差異太大測出來的RPO、RTO數(shù)據(jù)就沒有參考價(jià)值。數(shù)據(jù)脫敏是軍工項(xiàng)目不可跳過的一環(huán)。用生產(chǎn)數(shù)據(jù)做測試必須經(jīng)過脫敏處理涉密字段要替換關(guān)鍵業(yè)務(wù)數(shù)據(jù)要變換。但脫敏有個(gè)度的問題脫的太狠數(shù)據(jù)特征失真測試結(jié)果不可信脫的不夠存在泄密風(fēng)險(xiǎn)。建議的做法是保留數(shù)據(jù)的結(jié)構(gòu)特征、數(shù)據(jù)量級、分布規(guī)律只替換具體的內(nèi)容值。2.3 測試工具選型商業(yè)、開源、自研如何組合容災(zāi)備份測試的工具鏈?zhǔn)忻嫔蠜]有一套完全通用的方案實(shí)際項(xiàng)目中往往是商業(yè)工具、開源工具、自研腳本三者組合。商業(yè)工具方面磁盤陣列和備份軟件廠商一般會(huì)提供配套的測試工具比如存儲(chǔ)層的性能測試工具、備份軟件的驗(yàn)證工具。我的建議是廠商工具必須用但不能只用。廠商工具通常用來證明“我的產(chǎn)品沒問題”第三方測試需要用獨(dú)立的視角去驗(yàn)證完全依賴廠商工具相當(dāng)于讓運(yùn)動(dòng)員自己當(dāng)裁判。開源工具的靈活性更高。網(wǎng)絡(luò)層故障注入可以用Linux自帶的tc命令模擬延遲、丟包、亂序磁盤I/O故障可以用device-mapper工具模擬壞塊、讀寫超時(shí)數(shù)據(jù)庫層的數(shù)據(jù)校驗(yàn)可以用Perl、Python腳本做比對。我在實(shí)際項(xiàng)目中網(wǎng)絡(luò)抖動(dòng)模擬、數(shù)據(jù)一致性校驗(yàn)大部分都是用腳本完成的。自研腳本主要解決兩類問題一是批量構(gòu)造測試數(shù)據(jù)二是自動(dòng)化執(zhí)行故障注入和結(jié)果采集。比如主備切換測試需要在高并發(fā)寫入的場景下觸發(fā)切換純手工操作很難捕捉到精確的RPO值寫一個(gè)數(shù)據(jù)生成腳本持續(xù)寫入同時(shí)另一個(gè)腳本控制切換觸發(fā)最后比對寫入序號和切換后數(shù)據(jù)庫中的數(shù)據(jù)就能算出真實(shí)的RPO。3. 核心測試項(xiàng)設(shè)計(jì)與實(shí)操過程3.1 主備切換與故障注入測試怎么“故意搞壞”系統(tǒng)主備切換是容災(zāi)系統(tǒng)的核心動(dòng)作也是測試中最容易出問題的環(huán)節(jié)。設(shè)計(jì)切換測試時(shí)我遵循一個(gè)原則先分級、后注入、再驗(yàn)證。分級指的是切換場景分級。一級場景是計(jì)劃內(nèi)切換比如設(shè)備維護(hù)、軟件升級導(dǎo)致的主動(dòng)切換二級場景是計(jì)劃外切換比如主機(jī)宕機(jī)、存儲(chǔ)故障、網(wǎng)絡(luò)中斷導(dǎo)致的被動(dòng)切換。測試必須覆蓋兩個(gè)級別因?yàn)橛?jì)劃外切換的判定邏輯和執(zhí)行路徑與計(jì)劃內(nèi)切換完全不一樣。故障注入方式要多樣化不能只測“拔網(wǎng)線”。物理層故障包括主機(jī)斷電、存儲(chǔ)離線、光纖鏈路中斷網(wǎng)絡(luò)層故障包括核心交換機(jī)宕機(jī)、鏈路丟包率飆升、網(wǎng)絡(luò)抖動(dòng)加劇應(yīng)用層故障包括數(shù)據(jù)庫進(jìn)程崩潰、中間件服務(wù)假死、備份任務(wù)異常終止。我在模擬項(xiàng)目X中設(shè)計(jì)了一組故障用例對生產(chǎn)主機(jī)執(zhí)行了模擬斷電操作結(jié)果發(fā)現(xiàn)系統(tǒng)的雙機(jī)心跳檢測機(jī)制在8秒后才完成故障確認(rèn)比設(shè)計(jì)指標(biāo)多了3秒主要原因就是心跳探測的失敗重試次數(shù)配置了5次每次超時(shí)1.6秒正常情況下這個(gè)配置沒問題但在高負(fù)載條件下心跳響應(yīng)變慢導(dǎo)致故障確認(rèn)時(shí)間超標(biāo)。切換功能的驗(yàn)證點(diǎn)包括故障檢測是否及時(shí)、切換決策是否正確、數(shù)據(jù)同步是否完整、業(yè)務(wù)是否平滑接管、切回操作是否正常。每一步都要有明確的判定標(biāo)準(zhǔn)和預(yù)期結(jié)果不能只看“系統(tǒng)沒報(bào)錯(cuò)”就判定通過。3.2 數(shù)據(jù)一致性校驗(yàn)與RPO實(shí)測別只看工具報(bào)表RPO是容災(zāi)系統(tǒng)最核心的指標(biāo)之一但很多測試團(tuán)隊(duì)測RPO的方法過于粗糙直接看同步軟件顯示“已同步到最新”就認(rèn)為RPO為零。這種做法在軍工項(xiàng)目中是不可接受的。正確的RPO實(shí)測方法應(yīng)該是這樣的在業(yè)務(wù)寫入持續(xù)不斷的場景下人為制造主中心故障然后檢查備用中心的數(shù)據(jù)狀態(tài)計(jì)算出故障發(fā)生時(shí)刻與備用中心實(shí)際恢復(fù)點(diǎn)之間的數(shù)據(jù)差。具體操作上我通常會(huì)寫一個(gè)帶有遞增序號的數(shù)據(jù)寫入程序持續(xù)向源端寫入數(shù)據(jù)同時(shí)在某個(gè)隨機(jī)時(shí)刻觸發(fā)主中心故障故障恢復(fù)后統(tǒng)計(jì)備用中心數(shù)據(jù)中最大的連續(xù)序號用“源端寫入總量減去備用中心已接收量”換算成時(shí)間差就是真實(shí)的RPO。這里有一個(gè)很隱蔽的坑如果數(shù)據(jù)同步是異步模式正常時(shí)段同步延遲很小但在大事務(wù)提交、批量導(dǎo)入、日志備份的瞬間同步隊(duì)列會(huì)積壓RPO會(huì)瞬間拉大。只測穩(wěn)態(tài)下的RPO遠(yuǎn)遠(yuǎn)不夠必須在高寫入壓力、大事務(wù)集中提交的場景下反復(fù)測試才能暴露真實(shí)的極端RPO。數(shù)據(jù)一致性校驗(yàn)不能只依賴數(shù)據(jù)庫自身的事務(wù)日志要獨(dú)立做數(shù)據(jù)比對。文件級別的系統(tǒng)可以比文件MD5值數(shù)據(jù)庫系統(tǒng)可以抽查關(guān)鍵表的記錄數(shù)和關(guān)鍵字段值中間件系統(tǒng)要驗(yàn)證消息隊(duì)列的未消費(fèi)數(shù)量和順序號。比對的時(shí)間點(diǎn)要在切換完成之后立即進(jìn)行拖的時(shí)間越長后續(xù)新增數(shù)據(jù)越會(huì)干擾判斷。3.3 恢復(fù)演練與RTO實(shí)測切換成功不等于恢復(fù)成功恢復(fù)測試是最容易被低估的工作因?yàn)椤扒袚Q成功”和“業(yè)務(wù)恢復(fù)”是兩個(gè)概念。切換只是把服務(wù)從A點(diǎn)挪到了B點(diǎn)恢復(fù)則要求B點(diǎn)的服務(wù)能正常對外提供業(yè)務(wù)數(shù)據(jù)完整、權(quán)限正確、網(wǎng)絡(luò)可達(dá)、外部依賴都能工作。RTO的實(shí)測要精確到秒級。常規(guī)做法是定義一個(gè)計(jì)時(shí)起點(diǎn)和一個(gè)計(jì)時(shí)終點(diǎn)比如從“模擬故障注入完成”到“備用中心對外正常提供服務(wù)”之間的時(shí)長。實(shí)際操作中計(jì)時(shí)點(diǎn)的定義很關(guān)鍵。如果故障注入還沒完成就開始計(jì)時(shí)測出來的RTO會(huì)偏小如果把整個(gè)演練過程的準(zhǔn)備時(shí)間都算進(jìn)去RTO又會(huì)偏大。我的做法是在測試方案中明確約定故障注入生效的瞬間作為T0業(yè)務(wù)驗(yàn)證請求返回成功的瞬間作為T1T1-T0就是RTO。恢復(fù)驗(yàn)證要分三個(gè)層次系統(tǒng)層驗(yàn)證檢查服務(wù)進(jìn)程狀態(tài)、監(jiān)聽端口、資源占用是否正常應(yīng)用層驗(yàn)證通過模擬業(yè)務(wù)請求確認(rèn)核心業(yè)務(wù)流程可以跑通數(shù)據(jù)層驗(yàn)證確認(rèn)數(shù)據(jù)完整性和一致性達(dá)標(biāo)。三層都通過才能判定恢復(fù)成功?；謴?fù)測試還要覆蓋增量恢復(fù)和全量恢復(fù)兩種方式增量恢復(fù)看重的是日志回放效率和斷點(diǎn)續(xù)傳能力全量恢復(fù)看重的是數(shù)據(jù)拷貝速度和一致性校驗(yàn)機(jī)制。我在某容災(zāi)項(xiàng)目的恢復(fù)測試中就踩過一個(gè)坑備用中心的數(shù)據(jù)庫服務(wù)成功拉起后表面看一切正常但遺漏了數(shù)據(jù)庫序列號的同步校驗(yàn)導(dǎo)致后續(xù)業(yè)務(wù)寫入主鍵沖突整整排查了四個(gè)小時(shí)才定位到問題。從那以后恢復(fù)驗(yàn)證清單上就永久加上了“序列號/流水號一致性檢查”這一項(xiàng)。3.4 備份有效性驗(yàn)證能備份更要能恢復(fù)容災(zāi)和備份是兩條腿缺一不可。容災(zāi)解決的是“業(yè)務(wù)連續(xù)性”備份解決的是“數(shù)據(jù)可恢復(fù)”。很多單位的備份系統(tǒng)每天都在跑備份任務(wù)全部顯示成功但真正到了要恢復(fù)數(shù)據(jù)的時(shí)候才發(fā)現(xiàn)備份文件損壞、恢復(fù)流程斷裂、備份介質(zhì)不可讀。備份有效性驗(yàn)證的核心思想就是備份成功不等于備份可用只有恢復(fù)成功的備份才叫有效備份。備份驗(yàn)證的測試設(shè)計(jì)要覆蓋備份的全生命周期備份策略配置是否合理增量備份和全量備份的組合是否滿足恢復(fù)需求備份文件的完整性是否經(jīng)過校驗(yàn)備份介質(zhì)的生命周期管理是否到位異地備份的數(shù)據(jù)是否可以直接用于容災(zāi)切換。實(shí)操中最常用的方法是“抽樣恢復(fù)驗(yàn)證”。對所有備份任務(wù)按一定比例抽樣執(zhí)行恢復(fù)操作驗(yàn)證備份數(shù)據(jù)可以直接用于恢復(fù)。抽樣要有代表性不能只挑小的備份任務(wù)驗(yàn)證。我通常的做法是不同業(yè)務(wù)系統(tǒng)的備份至少各抽一個(gè)不同時(shí)間點(diǎn)的備份各抽一個(gè)不同存儲(chǔ)介質(zhì)上的備份各抽一個(gè)。抽到的備份必須完整執(zhí)行恢復(fù)流程不能只做文件列表比對要真正把數(shù)據(jù)恢復(fù)到可用狀態(tài)。備份數(shù)據(jù)的安全性測試也值得專項(xiàng)設(shè)計(jì)。備份文件往往比生產(chǎn)數(shù)據(jù)更容易被忽視權(quán)限管控做得不如業(yè)務(wù)系統(tǒng)嚴(yán)格。要驗(yàn)證備份文件的存儲(chǔ)權(quán)限、傳輸加密、訪問審計(jì)是否符合要求防止備份數(shù)據(jù)變成數(shù)據(jù)泄露的缺口。4. 執(zhí)行過程中的典型問題與排查實(shí)錄4.1 故障注入后系統(tǒng)不切換心跳機(jī)制和仲裁策略的雙重陷阱故障注入后系統(tǒng)不切換是最常見也最頭疼的問題。正常情況下注入故障后系統(tǒng)應(yīng)該在幾秒內(nèi)完成故障確認(rèn)并觸發(fā)切換但實(shí)際執(zhí)行中經(jīng)常出現(xiàn)“故障已經(jīng)注入了系統(tǒng)毫無反應(yīng)”的情況。我遇到過的一個(gè)典型案例是容災(zāi)系統(tǒng)的雙機(jī)心跳機(jī)制配置了網(wǎng)卡直連心跳和以太網(wǎng)心跳雙鏈路按設(shè)計(jì)任意一條心跳鏈路中斷都不影響故障檢測。實(shí)際測試時(shí)我斷掉了網(wǎng)卡直連心跳系統(tǒng)沒有觸發(fā)切換再斷掉以太網(wǎng)心跳還是沒有觸發(fā)切換。后來排查發(fā)現(xiàn)心跳檢測的閾值配置了“兩條心跳鏈路同時(shí)中斷才判定故障”這在設(shè)計(jì)文檔里沒有明確說明配置人員和測試人員理解不一致導(dǎo)致測試預(yù)期和實(shí)際行為完全偏離。另一個(gè)典型問題是仲裁策略問題。分布式容災(zāi)系統(tǒng)通常需要仲裁機(jī)制防止“腦裂”如果仲裁節(jié)點(diǎn)的網(wǎng)絡(luò)路徑同時(shí)被故障注入波及系統(tǒng)的自我保護(hù)機(jī)制會(huì)優(yōu)先選擇“保持現(xiàn)狀”而不是“發(fā)起切換”這是正常的安全機(jī)制但是在測試設(shè)計(jì)階段如果沒有考慮到這個(gè)細(xì)節(jié)就容易被判定為測試不通過。解決方案是在測試方案中明確區(qū)分“仲裁節(jié)點(diǎn)故障”和“數(shù)據(jù)節(jié)點(diǎn)故障”兩類場景分別定義預(yù)期行為。4.2 數(shù)據(jù)一致性校驗(yàn)差異別急著報(bào)缺陷先查業(yè)務(wù)特征數(shù)據(jù)一致性校驗(yàn)出現(xiàn)差異不一定都是容災(zāi)系統(tǒng)的問題可能是業(yè)務(wù)數(shù)據(jù)自身的特點(diǎn)導(dǎo)致的。比如某些流水類業(yè)務(wù)表存在“邏輯刪除”機(jī)制數(shù)據(jù)行的物理內(nèi)容沒變但邏輯狀態(tài)已經(jīng)改變某些系統(tǒng)存在定時(shí)任務(wù)批量更新數(shù)據(jù)的窗口校驗(yàn)時(shí)正好趕上更新過程中。我的排查路徑是這樣的第一步確認(rèn)校驗(yàn)比對的方法是否正確。是行數(shù)比對還是內(nèi)容比對是否考慮了表結(jié)構(gòu)差異和字符集差異第二步確認(rèn)比對的時(shí)間點(diǎn)是否有業(yè)務(wù)寫入。如果校驗(yàn)直接在生產(chǎn)業(yè)務(wù)運(yùn)行期間執(zhí)行出現(xiàn)短暫的數(shù)據(jù)不一致是正常的要先確認(rèn)目標(biāo)系統(tǒng)的同步狀態(tài)是否為“實(shí)時(shí)”還是“準(zhǔn)實(shí)時(shí)”。第三步確認(rèn)差異數(shù)據(jù)的具體內(nèi)容分析差異是否有規(guī)律性是集中在一個(gè)業(yè)務(wù)表還是分布在各表是增量數(shù)據(jù)還是存量數(shù)據(jù)的差異。曾有一次校驗(yàn)發(fā)現(xiàn)備用中心某張表的行數(shù)比源端多了幾千行排查下來發(fā)現(xiàn)是備用庫上有人手動(dòng)執(zhí)行過數(shù)據(jù)補(bǔ)入操作和容災(zāi)系統(tǒng)本身沒有任何關(guān)系。這個(gè)經(jīng)驗(yàn)告訴我們發(fā)現(xiàn)差異后要保留現(xiàn)場先定位差異數(shù)據(jù)的具體內(nèi)容再判斷原因不要一上來就報(bào)缺陷。4.3 恢復(fù)超時(shí)大部分不是恢復(fù)慢是驗(yàn)證方法有問題RTO實(shí)測超時(shí)的原因一半以上不是系統(tǒng)真的恢復(fù)慢而是測量方法不嚴(yán)謹(jǐn)。最常見的錯(cuò)誤是拿“服務(wù)進(jìn)程啟動(dòng)”當(dāng)恢復(fù)成功的標(biāo)志。數(shù)據(jù)庫進(jìn)程起來了不代表數(shù)據(jù)庫可以對外提供服務(wù)還需要完成實(shí)例恢復(fù)、日志回放、網(wǎng)絡(luò)監(jiān)聽注冊等一系列工作。有些恢復(fù)測試把進(jìn)程啟動(dòng)時(shí)間作為RTO終點(diǎn)測出來的數(shù)據(jù)比真實(shí)RTO短了一大截。還有一類常見問題是恢復(fù)完成之后立刻做業(yè)務(wù)驗(yàn)證發(fā)現(xiàn)業(yè)務(wù)請求超時(shí)就把責(zé)任算到恢復(fù)頭上。實(shí)際上切換完成后網(wǎng)絡(luò)路由收斂、負(fù)載均衡權(quán)重調(diào)整、客戶端連接池重建都需要時(shí)間這些不算恢復(fù)時(shí)間但在RTO測量中必須預(yù)留余量。我的建議是RTO指標(biāo)應(yīng)該拆分為“系統(tǒng)恢復(fù)時(shí)間”和“業(yè)務(wù)恢復(fù)時(shí)間”兩個(gè)子項(xiàng)分別測量、分別考核避免混在一起互相掩蓋問題。4.4 測試結(jié)果偏離指標(biāo)先質(zhì)疑測試方法再質(zhì)疑系統(tǒng)能力當(dāng)實(shí)測RPO、RTO偏離設(shè)計(jì)指標(biāo)時(shí)不要急于斷定系統(tǒng)不達(dá)標(biāo)。第三方測試的結(jié)論影響重大必須先排除測試方法本身的問題。要檢視的測試因素包括測試工具的計(jì)時(shí)精度是否足夠、故障注入的力度是否與實(shí)際故障場景一致、數(shù)據(jù)寫入的并發(fā)量是否達(dá)到預(yù)設(shè)值、網(wǎng)絡(luò)環(huán)境的背景流量是否模擬了生產(chǎn)情況。排除測試方法問題之后再分析系統(tǒng)配置層面的因素比如同步模式是否被意外修改、壓縮傳輸配置是否生效、備份窗口是否與業(yè)務(wù)高峰重疊。在一個(gè)實(shí)際項(xiàng)目中實(shí)測RTO是設(shè)計(jì)指標(biāo)的2倍排查后發(fā)現(xiàn)是測試期間備用中心的殺毒軟件在進(jìn)行全盤掃描占用了大量磁盤I/O。這個(gè)案例說明恢復(fù)測試必須保證備用中心的環(huán)境處于“干凈”狀態(tài)任何可能影響性能的維護(hù)操作都要提前禁止。測試執(zhí)行前我會(huì)專門發(fā)一份“測試期間環(huán)境約束清單”明確禁止在測試窗口內(nèi)執(zhí)行備份任務(wù)、系統(tǒng)升級、批量數(shù)據(jù)處理等操作。5. 測試記錄與交付要點(diǎn)5.1 測試記錄的可追溯性每一步都要能還原現(xiàn)場軍工項(xiàng)目的第三方測試測試記錄的要求比一般商用項(xiàng)目嚴(yán)格得多。每一項(xiàng)測試都要有完整的執(zhí)行記錄、原始數(shù)據(jù)、截圖佐證和操作人員簽名。這不僅是質(zhì)量管理的要求更是責(zé)任界定的依據(jù)。如果項(xiàng)目后續(xù)出現(xiàn)問題測試記錄就是第一手的追溯材料。我的習(xí)慣是每次測試執(zhí)行前先錄制一份“測試準(zhǔn)備狀態(tài)確認(rèn)單”記錄測試環(huán)境的初始狀態(tài)、數(shù)據(jù)基線、配置版本測試執(zhí)行過程中關(guān)鍵操作通過腳本自動(dòng)記錄時(shí)間戳手工操作要在測試記錄表中注明操作人和操作時(shí)刻測試結(jié)束后立即輸出測試原始數(shù)據(jù)清單避免后續(xù)整理時(shí)信息丟失。測試記錄具體包括以下內(nèi)容測試用例編號、測試目的、前置條件、操作步驟、預(yù)期結(jié)果、實(shí)際結(jié)果、結(jié)論判定、問題描述、執(zhí)行人、執(zhí)行時(shí)間、環(huán)境狀態(tài)。判定為“通過”的用例要保留通過依據(jù)判定為“不通過”的用例要保留問題現(xiàn)象和故障現(xiàn)場數(shù)據(jù)。5.2 測試結(jié)論的表達(dá)問題分級與整改建議第三方測試的交付物不止是測試報(bào)告更重要的是結(jié)論的恰當(dāng)表達(dá)。軍工項(xiàng)目的測試結(jié)論不能模棱兩可但也不能不加區(qū)分地一概否定。我的做法是對發(fā)現(xiàn)的問題做嚴(yán)重程度分級A級問題致命缺陷數(shù)據(jù)丟失、系統(tǒng)不可恢復(fù)、安全漏洞必須立即整改整改完成后重新測試。B級問題嚴(yán)重缺陷切換失敗、恢復(fù)超時(shí)、數(shù)據(jù)不一致必須在項(xiàng)目驗(yàn)收前完成整改。C級問題一般缺陷流程不完善、配置項(xiàng)缺失、文檔不完整可以在后續(xù)優(yōu)化改進(jìn)。D級問題建議項(xiàng)操作便利性、監(jiān)控告警完善、性能優(yōu)化空間。整改建議要具體可執(zhí)行。比如針對“故障檢測時(shí)間超長”的問題不能只寫“優(yōu)化心跳機(jī)制”而要寫明“調(diào)整心跳超時(shí)參數(shù)將失敗重試次數(shù)從5次降為3次同時(shí)增加心跳響應(yīng)延遲的告警閾值”。針對“備份恢復(fù)流程文檔缺失”的問題要列出文檔應(yīng)包含的章節(jié)和維護(hù)責(zé)任人。5.3 驗(yàn)收指標(biāo)核驗(yàn)與回歸測試策略第三方測試的最后一環(huán)是配合驗(yàn)收指標(biāo)的核驗(yàn)。軍工容災(zāi)備份中心項(xiàng)目的驗(yàn)收指標(biāo)通常包含具體數(shù)值RPO不超過多少分鐘、RTO不超過多少小時(shí)、備份成功率不低于多少百分比、恢復(fù)驗(yàn)證通過率不低于多少。每一項(xiàng)指標(biāo)都要有對應(yīng)的測試用例作為佐證。整改完成后的回歸測試策略要提前定好規(guī)則。我的經(jīng)驗(yàn)是A級問題修復(fù)后進(jìn)行全量回歸重點(diǎn)驗(yàn)證問題涉及的功能域及其關(guān)聯(lián)功能B級問題修復(fù)后進(jìn)行功能域回歸確認(rèn)修復(fù)沒有引入新的問題C、D級問題的修復(fù)在后續(xù)測試輪次中附帶驗(yàn)證即可?；貧w測試不能只重復(fù)原用例還要補(bǔ)測與原問題相關(guān)的邊界場景。6. 寫在最后的幾點(diǎn)經(jīng)驗(yàn)容災(zāi)備份系統(tǒng)的第三方測試做了這么多年最大的體會(huì)是這套系統(tǒng)的測試不是驗(yàn)證“正常情況下的可用性”而是驗(yàn)證“異常情況下的生存能力”。很多系統(tǒng)在正常情況下運(yùn)行得非常好數(shù)據(jù)同步及時(shí)、備份任務(wù)穩(wěn)定、監(jiān)控告警完善但一旦遇到真實(shí)故障就暴露出各種設(shè)計(jì)缺陷和配置問題。原因也很簡單正常路徑是開發(fā)人員天天走的路異常路徑是很少被走過的路。對于剛開始做容災(zāi)測試的同行我給三點(diǎn)建議第一點(diǎn)測試方案要從指標(biāo)反推設(shè)計(jì)。項(xiàng)目定了RPO和RTO指標(biāo)你的測試方案就要圍繞驗(yàn)證這兩個(gè)指標(biāo)展開設(shè)計(jì)能夠精確測量這兩個(gè)指標(biāo)的測試方法和工具。方案先于執(zhí)行測量方法先于系統(tǒng)實(shí)現(xiàn)這是保證測試不跑偏的前提。第二點(diǎn)故障注入不要只做一次。容災(zāi)系統(tǒng)的穩(wěn)定性需要通過反復(fù)測試來驗(yàn)證同一個(gè)故障場景至少執(zhí)行三次確認(rèn)每次的行為一致。有些系統(tǒng)的故障切換帶有偶發(fā)性第一次成功不代表每次都成功。第三點(diǎn)測試記錄從第一天就要規(guī)范起來。不要等到要寫報(bào)告了再補(bǔ)記錄現(xiàn)場記錄哪怕潦草一點(diǎn)也比事后回憶可靠得多。項(xiàng)目收尾時(shí)整理的測試報(bào)告價(jià)值就藏在這些每天的原始記錄里。