本發(fā)明屬于防災減災信息管理領域，具體地涉及一種基于activity的災備管理系統(tǒng)和管理方法。

背景技術：

隨著銀行業(yè)務越來越多地依賴于IT系統(tǒng)的協(xié)助，應用系統(tǒng)需要不間斷持續(xù)運轉(zhuǎn)。而硬件和軟件故障、自然災難，甚至計劃維護所導致的停機時間，都可能影響業(yè)務。這不僅會讓業(yè)務部門不滿意.也讓IT部門不堪重負，進而造成重要信息和收益的損失。主要系統(tǒng)和恢復系統(tǒng)的升級和變更必須同時進行，實施可靠、快速的恢復策略，既耗時又昂貴。管理分布在不同地點的大量的應用程序和服務器無疑是一項復雜的工作.需要使用大量的運維資源。服務器一旦發(fā)生故障，就需運維人員現(xiàn)場進行故障排查和修復，故障歷時長。

災備切換是一系列操作的組合，每次災備切換都需要耗費大量的人力和物力，而且越關鍵的業(yè)務，切換就越需要慎重，因此不能根據(jù)單一的個人意愿，而是需要集體的決策。

災備體系建設工作是一個龐大、復雜的系統(tǒng)工程，災備切換涉及網(wǎng)絡、數(shù)據(jù)中心、應用服務管理等多方面的各種環(huán)節(jié)，每個環(huán)節(jié)彼此之間有緊密的邏輯的關系，例如服務的啟動順序也有嚴格的要求。比如數(shù)據(jù)庫必須先啟動，之后才能啟動應用程序；應用服務器接管完成，才能進行網(wǎng)絡的切換。如果應用程序先于數(shù)據(jù)庫啟動，結(jié)果肯定會是出錯。在實際的災備切換過程中，其中涉及大量的登錄、鑒權(quán)、控制操作，每個環(huán)節(jié)都要求精準無誤，由于涉及到的設備眾多，操作步驟繁多，操作員每次都要耗費大量時間和精力完成一次完整的操作，例如銀行系統(tǒng)某部分切換，往往需要十幾個操作員，每天晚上連續(xù)工作一周時間，由于細節(jié)繁多，往往出現(xiàn)錯誤。由于行業(yè)要求，災備切換操作每隔一段時間都要執(zhí)行，所以如何提高切換效率，避免人為干預，減少操作失誤風險，災備切換過程管理已經(jīng)成為災備服務和運維的重點問題。

因此，有必要提供一種借助基于activity的工作流引擎進行災備切換的基于activity的災備管理系統(tǒng)和管理方法。

技術實現(xiàn)要素：

本發(fā)明的目的在于提供一種借助基于activity的工作流引擎進行災備切換的基于activity的災備管理系統(tǒng)和管理方法。

本發(fā)明的技術方案如下：一種基于activity的災備管理系統(tǒng)包括依次順序連接的流程模塊、映射模塊、遠程訪問模塊和業(yè)務邏輯模塊；所述流程模塊，用于定義業(yè)務流程模型，并通過activity流程引擎驅(qū)動每個業(yè)務邏輯按照預先定義好的流程執(zhí)行；所述映射模塊，用于記錄所述流程模塊中的每個任務節(jié)點與具體業(yè)務邏輯的映射關系；所述遠程訪問模塊，用于提供切換管理服務器到遠端主機的連接通道；所述業(yè)務邏輯模塊，用于模擬管理員對設備發(fā)送操作指令，并通過設備的回應消息或者設備狀態(tài)變化判斷指令的執(zhí)行結(jié)果。

優(yōu)選地，所述流程模塊包括activity流程引擎模塊、流程定義模塊、管理控制模塊和監(jiān)控分析模塊，所述activity流程引擎模塊分別與所述流程定義模塊、所述管理控制模塊和所述監(jiān)控分析模塊相連接。

優(yōu)選地，所述activity流程引擎模塊從所述流程定義模塊獲得當前需要執(zhí)行的業(yè)務邏輯，并依次通過所述映射模塊、所述遠程訪問模塊和所述業(yè)務邏輯模塊部署并執(zhí)行邏輯業(yè)務邏輯。

優(yōu)選地，所述activity流程引擎模塊是所述基于activity的災備管理系統(tǒng)中災備切換每個環(huán)節(jié)有序執(zhí)行的驅(qū)動引擎，在引擎的推動下每個災備步驟按照預先制定的預案有序推進完成。

優(yōu)選地，所述流程定義模塊提供拖拽式可視化Browser/Server界面操作，用戶使用瀏覽器通過所述流程定義模塊設計定義業(yè)務流程。

優(yōu)選地，所述業(yè)務邏輯模塊是一系列切換操作的集合，包括磁盤陣列操作、數(shù)據(jù)庫管理操作、中間件管理操作和應用程序管理操作。

一種根據(jù)上述基于activity的災備管理系統(tǒng)的管理方法，包括如下步驟：

步驟1：在所述流程模塊中，根據(jù)實際災備管理系統(tǒng)的特點，通過建模工具繪制災備切換的流程模型，所述流程模型是一個靜態(tài)文件，是activity動態(tài)管理流程的基礎；

步驟2：根據(jù)步驟1設計的流程模型設計對應的業(yè)務邏輯，形成相對應的業(yè)務邏輯模塊；

步驟3：通過所述映射模塊配置所述流程模型和所述業(yè)務邏輯的映射關系；

步驟4：通過關鍵詞檢索最符合條件的流程模型，并啟動所述流程模型，activity流程引擎按照所述流程模型的邏輯控制遠端主機執(zhí)行切換操作；

步驟5：校驗并判斷所述切換結(jié)果是否成功，如果所述切換結(jié)果校驗為成功，則activity流程引擎繼續(xù)執(zhí)行下一個切換操作；如果所述切換結(jié)果校驗為失敗，則通知管理員檢查定位問題。

優(yōu)選地，所述步驟1具體包括如下步驟：

根據(jù)災備管理系統(tǒng)的特點，通過建模工具，拖拽出需要的BPMN圖形符號；

據(jù)實際業(yè)務關系使用連線將圖形符號按照順序、并行或排他邏輯關系連接起來；

使用業(yè)務流程執(zhí)行語言將基于圖形的BPMN圖形文件轉(zhuǎn)換成基于標記語言的XML文件；

activity流程引擎讀入模型文件，使用SAX從根節(jié)點開始依次解析XML模型文件中的各種標記，生成activity流程引擎內(nèi)部支持的數(shù)據(jù)結(jié)構(gòu)；

通過數(shù)據(jù)庫中間件實現(xiàn)流程模型的持久化。

優(yōu)選地，所述步驟3具體包括如下步驟：

操作頁面上選擇需要配置映射關系的模型；

操作頁面列出所選模型的所有任務節(jié)點；

操作頁面上選中模型中的一個任務節(jié)點；

操作頁面上選中業(yè)務邏輯集合中的一個業(yè)務腳本；

為已經(jīng)選擇的所述任務節(jié)點綁定所述業(yè)務腳本；

將映射關系結(jié)構(gòu)化存儲到數(shù)據(jù)庫。

優(yōu)選地，所述步驟4具體包括如下步驟：

根據(jù)災難場景輸入關鍵詞檢索符合條件的流程模型，并在WEB頁面啟動所述流程模型；

所述activity流程引擎接收到模型啟動事件后，通過任務接口啟動一個任務，從而生成一個任務實例；

所述activity流程引擎查找所述流程模型中的任務列表，并找到當前任務節(jié)點；

所述activity流程引擎查找當前任務節(jié)點與業(yè)務邏輯對應關系表，并找到當前步驟要連接的遠端主機和業(yè)務邏輯，通過遠程訪問模塊，控制遠端主機執(zhí)行業(yè)務邏輯。

本發(fā)明的有益效果在于：所述基于activity的災備管理系統(tǒng)和管理方法具有如下有益效果：

1、流程模型定義模塊引入了基于WEB的拖拽式圖形化流程設計方式，集流程圖設計、規(guī)則定制和代碼擴展、調(diào)試于一體，流程設計開發(fā)快捷高效。流程設計器采用可視化界面操作，所見即所得，用戶操作頁面上的控件，拖拽就可以完成流程的設計，即便是沒有開發(fā)經(jīng)驗的業(yè)務人員可以方便制作自己需要的流程。

2、由于業(yè)務模塊與流程模型可以靈活配置，使得流程模型能夠管理各種業(yè)務邏輯，擴展了管理平臺通用性，能夠支持適應多種廠家的多數(shù)設備。

3、由于引入了activity流程引擎，原來獨立的資源管理、人員管理、權(quán)限管理、業(yè)務邏輯有機高效的整合起來。利于災備切換過程中過程監(jiān)控、進度查看、任務分配；利于災備切換后回溯和分析。

4、引入自動化管理方法管理業(yè)務邏輯模塊，使得原來手工執(zhí)行過程，改為自動執(zhí)行，效率提升。災備中心共實現(xiàn)了35套災備系統(tǒng)115個節(jié)點在異地災備中心從存儲切換、系統(tǒng)掛載到數(shù)據(jù)庫、中間件以及應用程序啟停共計1300多項任務的自動執(zhí)行，避免了手工執(zhí)行的操作失誤。如此多的應用級災備系統(tǒng)接管生產(chǎn)需要大量的人員及時間成本。使得異地災備系統(tǒng)接管生產(chǎn)時間由原先5小時縮短到1小時內(nèi)，實現(xiàn)了災備多系統(tǒng)的快速切換。

5、切換過程中通過WEB監(jiān)控頁面可以實時監(jiān)控切換過程，層次化可伸縮的監(jiān)控方式，可以看到切換全景圖，管理員清晰地看到流程各個步驟是否執(zhí)行完畢；切換出現(xiàn)故障或者需要人工操作時，可以即時對切換進度施加人為影響。

附圖說明

圖1是本發(fā)明實施例提供的基于activity的災備管理系統(tǒng)的系統(tǒng)整體框架圖；

圖2是基于圖1所示基于activity的災備管理系統(tǒng)的管理方法過程示意圖；

圖3是圖2所示管理方法中步驟S1的流程示意圖；

圖4是圖2所示管理方法中步驟S3的流程示意圖；

圖5是圖2所示管理方法中步驟S4和S5的流程示意圖；

圖6是圖2所示管理方法中實現(xiàn)業(yè)務邏輯的流程示意圖；

圖7是某系統(tǒng)災備切換總流程示意圖；

圖8是某災備中心環(huán)境檢查子流程示意圖。

具體實施方式

為了使本發(fā)明的目的、技術方案及優(yōu)點更加清楚明白，以下結(jié)合附圖及實施例，對本發(fā)明進行進一步詳細說明。應當理解，此處所描述的具體實施例僅僅用以解釋本發(fā)明，并不用于限定本發(fā)明。

除非上下文另有特定清楚的描述，本發(fā)明中的元件和組件，數(shù)量既可以單個的形式存在，也可以多個的形式存在，本發(fā)明并不對此進行限定。本發(fā)明中的步驟雖然用標號進行了排列，但并不用于限定步驟的先后次序，除非明確說明了步驟的次序或者某步驟的執(zhí)行需要其他步驟作為基礎，否則步驟的相對次序是可以調(diào)整的。可以理解，本文中所使用的術語“和/或”涉及且涵蓋相關聯(lián)的所列項目中的一者或一者以上的任何和所有可能的組合。

本發(fā)明實施例提供的基于activity的災備管理系統(tǒng)100通過預先定義業(yè)務流程模型，并將傳統(tǒng)模式下，管理員需要手工執(zhí)行的操作封裝成固定的業(yè)務邏輯，從而通過activity流程引擎驅(qū)動每個業(yè)務邏輯按照預先定義好的流程執(zhí)行。也就是將activity開源工具包與主流BS結(jié)構(gòu)軟件框架整合，實現(xiàn)了基于Web 的災備管理系統(tǒng)；而且，還通過管理控制模塊添加各級組織部門、添加部門成員、指定成員角色。

具體地，所述基于activity的災備管理系統(tǒng)100將原本無法程序化管理的災備流程，抽象成一個個流程模型，流程模型將每個業(yè)務邏輯子模塊作為一個個的任務節(jié)點管理起來。支持為每個任務節(jié)點分配責任人、責任群組。流程模型定義完成后，流程引擎按照流程模型推動流程自動運行，推送相關任務到指定執(zhí)行人和指定群組。

而且，業(yè)務分析員在分析具體災備過程中，通過分析切換系統(tǒng)內(nèi)部各模塊之間的邏輯和依賴關系，確定系統(tǒng)內(nèi)各模塊的切換順序和執(zhí)行條件，并通過圖形化流程設計器定義流程模型。

請參閱圖1，是本發(fā)明實施例提供的是本發(fā)明實施例提供的基于activity的災備管理系統(tǒng)的系統(tǒng)整體框架圖。所述基于activity的災備管理系統(tǒng)包括依次順序連接的流程模塊10、映射模塊20、遠程訪問模塊30和業(yè)務邏輯模塊40。其中，所述流程模塊10用于定義業(yè)務流程模型，并通過activity流程引擎驅(qū)動每個業(yè)務邏輯按照預先定義好的流程執(zhí)行；所述映射模塊20用于記錄所述流程模塊中的每個任務節(jié)點與具體業(yè)務邏輯的映射關系；所述遠程訪問模塊30用于提供切換管理服務器到遠端主機的連接通道；所述業(yè)務邏輯模塊40用于模擬管理員對設備發(fā)送操作指令，并通過設備的回應消息或者設備狀態(tài)變化判斷指令的執(zhí)行結(jié)果。

其中，所述流程模塊10包括activity流程引擎模塊11、流程定義模塊12、管理控制模塊13和監(jiān)控分析模塊14，所述activity流程引擎模塊11分別與所述流程定義模塊12、所述管理控制模塊13和所述監(jiān)控分析模塊14相連接。

在所述流程模塊10中，所述activity流程引擎模塊11從所述流程定義模塊12獲得當前需要執(zhí)行的業(yè)務邏輯，并依次通過所述映射模塊20、所述遠程訪問模塊30和所述業(yè)務邏輯模塊40部署并執(zhí)行邏輯業(yè)務邏輯。

也就是說，所述activity流程引擎模塊11是所述基于activity的災備管理系統(tǒng)100中災備切換每個環(huán)節(jié)有序執(zhí)行的驅(qū)動引擎，在引擎的推動下每個災備步驟按照預先制定的預案有序推進完成。

所述流程定義模塊12負責提供拖拽式可視化B/S(Browser/Server)界面操作，用戶無需單獨按照客戶端，使用瀏覽器就可以設計定義業(yè)務流程，并且生成標準化文件，支持分支流程，并發(fā)流程等多種流程設計。

在本發(fā)明中，Activity提供了一個標準化圖形化流程編輯器，無需安裝插件，通過瀏覽器即可在線通過可視化的拖拽式設計方式進行流程定義。所述標準化流程設計器，支持順序、并行、排他、等流程控制方法，支持各種復雜業(yè)務流程。因此，所述流程定義模塊12的流程定義過程類似Visio軟件畫圖，方便存儲和維護。

在所述流程定義模塊12中，流程模型將切換過程的繁瑣的業(yè)務邏輯和參與者按照一定的規(guī)則組織起來，在流程引擎的推動下自動或半自動的完成災備業(yè)務邏輯操作。

定義好的業(yè)務流程模型結(jié)構(gòu)化存儲到數(shù)據(jù)庫，災難發(fā)生時，通過檢索模塊，快速找到設計好的流程，逐步實施災備切換過程。

而且，流程模型和業(yè)務邏輯分離，通過管理控制模塊配置流程模型和業(yè)務邏輯的綁定關系。當切換流程需要變更時，只需要更改流程圖，并重新綁定業(yè)務邏輯，而不需要更改業(yè)務策略本身。

所述管理控制模塊13負責災備過程管控和人員權(quán)限管理。具體地，所述管理控制模塊13為所有業(yè)務處理模塊提供統(tǒng)一的后端服務和全局配置。所述管理控制模塊13的功能包括但不限于：提供災備切換流程啟動和控制管理；提供組織、部門、崗位、角色等人員信息管理；提供各類復雜的權(quán)限管理，包括系統(tǒng)管理員、切換總指揮、主機管理員、網(wǎng)絡管理員管理等多種權(quán)限管理。

所述監(jiān)控分析模塊14負責流程運行進展的展示和監(jiān)控分析。具體地，災備切換時，相關人員通過瀏覽器能夠清晰的監(jiān)控災備切換流程的進展、當前任務的負責人及其所負責的作業(yè)。而且，所述監(jiān)控分析模塊14可以實現(xiàn)的功能包括但不限于：采用標準化主流前端展示技術，支持多種終端對災備流程的監(jiān)控；支持完整的數(shù)據(jù)記錄，記錄切換過程中每個任務耗時、執(zhí)行日期、執(zhí)行人，并提供數(shù)據(jù)的導出功能；支持圖形報表形式分析每個災備操作實際開始結(jié)束時間、實際操作結(jié)果、切換耗時，幫助管理員進一步優(yōu)化流程和業(yè)務處理邏輯。

所述映射模塊20記錄了流程模型中的每個任務節(jié)點與具體業(yè)務邏輯的映射關系。而且，所述映射模塊20是流程和業(yè)務聯(lián)系的紐帶，流程引擎執(zhí)行任務時，通過查找映射表，查找到遠端主機信息和綁定的業(yè)務邏輯。

所述遠程訪問模塊30提供了切換管理服務器到遠端主機的連接通道，通過所述遠程訪問模塊30控制遠端主機部署和執(zhí)行業(yè)務邏輯。

所述業(yè)務邏輯模塊40是一系列切換操作的集合，通常包括磁盤陣列操作、數(shù)據(jù)庫管理操作、中間件管理操作、應用程序管理操作。

而且，所述業(yè)務邏輯模塊40借助自動化運維的思路：模擬管理員對設備下發(fā)一些操作指令，通過設備的回應消息或者設備狀態(tài)變化判斷指令的執(zhí)行結(jié)果。傳統(tǒng)業(yè)務邏輯采用shell腳本方式，但shell腳本方式，無法將腳本執(zhí)行細節(jié)回傳給控制端，降低了控制端管理能力。

請參閱圖1，是基于圖1所示基于activity的災備管理系統(tǒng)的管理方法過程示意圖。所述管理方法具體包括如下步驟：

S1、在所述流程模塊10中，根據(jù)實際災備管理系統(tǒng)的特點，通過建模工具繪制災備切換的流程模型，所述流程模型是一個靜態(tài)文件，是activity動態(tài)管理流程的基礎。

具體地，在所述步驟S1中，通過所述流程模塊10定義業(yè)務流程模型，并通過activity流程引擎驅(qū)動每個業(yè)務邏輯按照預先定義好的流程執(zhí)行。請參閱圖3，所述步驟S1具體包括如下步驟：

根據(jù)災備管理系統(tǒng)的特點，通過建模工具，拖拽出需要的BPMN圖形符號；

據(jù)實際業(yè)務關系使用連線將圖形符號按照順序、并行或排他邏輯關系連接起來；

使用業(yè)務流程執(zhí)行語言將基于圖形的BPMN圖形文件轉(zhuǎn)換成基于標記語言的XML文件；

activity流程引擎讀入模型文件，使用SAX從根節(jié)點開始依次解析XML模型文件中的各種標記，生成activity流程引擎內(nèi)部支持的數(shù)據(jù)結(jié)構(gòu)；

通過數(shù)據(jù)庫中間件實現(xiàn)流程模型的持久化。

S2、根據(jù)步驟S1設計的流程模型設計對應的業(yè)務邏輯，形成相對應的業(yè)務邏輯模塊40。

S3、通過所述映射模塊20配置所述流程模型和所述業(yè)務邏輯的映射關系。

在所述步驟S3中，實現(xiàn)所述流程模型和所述業(yè)務邏輯之間映射關系的配置。具體地，請參閱圖4，所述步驟S3包括如下步驟：

操作頁面上選擇需要配置映射關系的模型；

操作頁面列出所選模型的所有任務節(jié)點；

操作頁面上選中模型中的一個任務節(jié)點；

操作頁面上選中業(yè)務邏輯集合中的一個業(yè)務腳本；

為已經(jīng)選擇的所述任務節(jié)點綁定所述業(yè)務腳本；

將映射關系結(jié)構(gòu)化存儲到數(shù)據(jù)庫。

S4、通過關鍵詞檢索最符合條件的流程模型，并啟動所述流程模型，activity流程引擎按照所述流程模型的邏輯控制遠端主機執(zhí)行切換操作。

具體地，請參閱圖5，所述步驟S4具體包括如下步驟：

根據(jù)災難場景輸入關鍵詞檢索符合條件的流程模型，并在WEB頁面啟動所述流程模型；

所述activity流程引擎接收到模型啟動事件后，通過任務接口啟動一個任務，從而生成一個任務實例；

所述activity流程引擎查找所述流程模型中的任務列表，并找到當前任務節(jié)點；

所述activity流程引擎查找當前任務節(jié)點與業(yè)務邏輯對應關系表，并找到當前步驟要連接的遠端主機和業(yè)務邏輯，通過遠程訪問模塊，控制遠端主機執(zhí)行業(yè)務邏輯。

S5、校驗并判斷所述切換結(jié)果是否成功，如果所述切換結(jié)果校驗為成功，則activity流程引擎繼續(xù)執(zhí)行下一個切換操作；如果所述切換結(jié)果校驗為失敗，則通知管理員檢查定位問題。

在所述步驟S5中，當所述步驟S4中業(yè)務邏輯執(zhí)行后，執(zhí)行結(jié)果回傳到操作頁面，如果當前任務執(zhí)行成功，引擎驅(qū)動流程執(zhí)行下一個任務，如果當前任務執(zhí)行失敗，則對當前步驟對應的主機環(huán)境和業(yè)務邏輯進行檢查，排除故障后繼續(xù)執(zhí)行下一個任務，依次類推，直到所有任務都執(zhí)行完成。

需要說明是，如圖6所示，在所述基于activity的災備管理方法中，實現(xiàn)業(yè)務邏輯的過程具體包括如下步驟：

引入ansible思路，將要執(zhí)行的業(yè)務操作按照YAML語法編排成playbook格式的*.yml文件，這種方式能夠?qū)⑷蝿占毠?jié)回傳到控制端；

根據(jù)映射模塊查找當前任務節(jié)點需要執(zhí)行操作的主機，將yml文件下發(fā)到遠端主機；

使用ansible中的command模塊控制遠端執(zhí)行playbook的每個任務。

但是，實際災備切換系統(tǒng)中的業(yè)務模塊眾多，需要分析業(yè)務邏輯，將同一功能層面的模塊定義到一個流程中。例如，如圖7所示的某系統(tǒng)災備切換總流程，總流程的每個任務包含了較多模塊，總流程的每個任務包含了較多模塊，例如圖8中的災備中心環(huán)境檢查包含了眾多子模塊，而且每個子模塊之間沒有先后順序，可以使用并行順序同時執(zhí)行所有子模塊。而且，在圖8所示的環(huán)境檢查子流程圖，每個子模塊并列執(zhí)行，可以提升檢查效率。

而且，通過配置流程之間的調(diào)用關系，將子流程嵌入到總流程中，增加了流程層次和視圖，便于不同層面分析流程，實現(xiàn)復雜多系統(tǒng)的流程設計，從而能夠適應復雜的實際切換環(huán)境。

相較于現(xiàn)有技術，本發(fā)明提供的基于activity的災備管理系統(tǒng)和管理方法具有如下有益效果：

1、流程模型定義模塊引入了基于WEB的拖拽式圖形化流程設計方式，集流程圖設計、規(guī)則定制和代碼擴展、調(diào)試于一體，流程設計開發(fā)快捷高效。流程設計器采用可視化界面操作，所見即所得，用戶操作頁面上的控件，拖拽就可以完成流程的設計，即便是沒有開發(fā)經(jīng)驗的業(yè)務人員可以方便制作自己需要的流程。

2、由于業(yè)務模塊與流程模型可以靈活配置，使得流程模型能夠管理各種業(yè)務邏輯，擴展了管理平臺通用性，能夠支持適應多種廠家的多數(shù)設備。

3、由于引入了activity流程引擎，原來獨立的資源管理、人員管理、權(quán)限管理、業(yè)務邏輯有機高效的整合起來。利于災備切換過程中過程監(jiān)控、進度查看、任務分配；利于災備切換后回溯和分析。

4、引入自動化管理方法管理業(yè)務邏輯模塊，使得原來手工執(zhí)行過程，改為自動執(zhí)行，效率提升。災備中心共實現(xiàn)了35套災備系統(tǒng)115個節(jié)點在異地災備中心從存儲切換、系統(tǒng)掛載到數(shù)據(jù)庫、中間件以及應用程序啟停共計1，300多項任務的自動執(zhí)行，避免了手工執(zhí)行的操作失誤。如此多的應用級災備系統(tǒng)接管生產(chǎn)需要大量的人員及時間成本。使得異地災備系統(tǒng)接管生產(chǎn)時間由原先5小時縮短到1小時內(nèi)，實現(xiàn)了災備多系統(tǒng)的快速切換。

5、切換過程中通過WEB監(jiān)控頁面可以實時監(jiān)控切換過程，層次化可伸縮的監(jiān)控方式，可以看到切換全景圖，管理員清晰地看到流程各個步驟是否執(zhí)行完畢；切換出現(xiàn)故障或者需要人工操作時，可以即時對切換進度施加人為影響。

對于本領域技術人員而言，顯然本發(fā)明不限于上述示范性實施例的細節(jié)，而且在不背離本發(fā)明的精神或基本特征的情況下，能夠以其他的具體形式實現(xiàn)本發(fā)明。因此，無論從哪一點來看，均應將實施例看作是示范性的，而且是非限制性的，本發(fā)明的范圍由所附權(quán)利要求而不是上述說明限定，因此旨在將落在權(quán)利要求的等同要件的含義和范圍內(nèi)的所有變化囊括在本發(fā)明內(nèi)。不應將權(quán)利要求中的任何附圖標記視為限制所涉及的權(quán)利要求。

此外，應當理解，雖然本說明書按照實施方式加以描述，但并非每個實施方式僅包含一個獨立的技術方案，說明書的這種敘述方式僅僅是為清楚起見，本領域技術人員應當將說明書作為一個整體，各實施例中的技術方案也可以經(jīng)適當組合，形成本領域技術人員可以理解的其他實施方式。