2020年度大型平臺技術架構與設計規(guī)范

大型平臺技術架構

與設計規(guī)范

文檔僅供參考

XX股份有限公司

內部門戶網(wǎng)站采購項目

技術建議書

3月

文檔僅供參考

目錄

1XX公司簡介..........................錯誤味定義書簽。

1.1基本情況..........................錯誤!未定義書簽。

1.2業(yè)務范圍..........................錯誤!未定義書簽。

1.3資質和榮譽........................錯誤!未定義書簽。

1.4技術實力..........................錯誤!未定義書簽。

1.5主要客戶..........................錯誤!未定義書簽。

2需求的理解...........................錯誤味定義書簽。

2.1系統(tǒng)名稱..........................錯誤!未定義書簽。

2.2建設目標分析.....................錯誤!未定義書簽。

2.3系統(tǒng)建設原貝！I...............................................錯誤!未定義書簽。

2.3.1兼容開放性原貝!J................................................錯誤!未定義書簽。

2.3.2先進性和靈活性原則.....................錯誤!未定義書簽。

2.3.3實用性原則.................................錯誤!未定義書簽。

2.3.4高效性原則.................................錯誤!未定義書簽。

2.3.5可擴展性原貝IJ.....................................................錯誤!未定義書簽。

2.3.6可靠性的原貝IJ.....................................................錯誤!未定義書簽。

2.3.7安全性原則.................................錯誤!未定義書簽。

2.3.8經濟性原則.................................錯誤!未定義書簽。

2.4系統(tǒng)需求分析.....................錯誤!未定義書簽。

2.4.1總體業(yè)務架構..............................錯誤!未定義書簽。

文檔僅供參考

2.4.2業(yè)務流程說明.....................錯誤!未定義書簽。

2.4.3非功能性需求.....................錯誤!未定義書簽。

3總體架構設計.........................錯誤!未定義書簽。

3.1設計原貝!)....................................錯誤!未定義書簽。

3.2體系架構.........................錯誤!未定義書簽。

3.3邏輯架構.........................錯誤!未定義書簽。

3.4應用架構.........................錯誤!未定義書簽。

3.4.1整體功能框架.....................錯誤!未定義書簽。

3.5數(shù)據(jù)架構.........................錯誤!未定義書簽。

3.5.1邏輯數(shù)據(jù)架構.....................錯誤!未定義書簽。

3.5.2數(shù)據(jù)層次戈IJ分.....................錯誤!未定義書簽。

3.5.3數(shù)據(jù)容量估算.....................錯誤!未定義書簽。

3.6技術架構..........................錯誤!未定義書簽。

3.6.1J2EE分層設計....................錯誤!未定義書簽。

3.6.2邏輯技術架構.....................錯誤!未定義書簽。

3.7備份與恢復.......................錯誤!未定義書簽。

3.7.1備份目標..........................錯誤!未定義書簽。

3.7.2備份的范圍及流程.................錯誤!未定義書簽。

3.7.3恢復的范圍及流程.................錯誤!未定義書簽。

3.7.4備份與恢復的分類.................錯誤!未定義書簽。

3.7.5日常備份與恢復的方式.............錯誤!未定義書簽。

文檔僅供參考

3.7.6日常備份與恢復的周期..................錯誤!未定義書簽。

3.8系統(tǒng)安全....................................錯誤!未定義書簽。

3.8.1安全需求....................................錯誤!未定義書簽。

3.8.2安全系統(tǒng)設計原則........................錯誤!未定義書簽。

3.8.3系統(tǒng)安全架構..............................錯誤!未定義書簽。

3.8.4安全策略....................................錯誤!未定義書簽。

4系統(tǒng)部署說明...................................錯誤!未定義書簽。

4.1整體部署架構..............................錯誤!未定義書簽。

4.2網(wǎng)絡架構....................................錯誤!未定義書簽。

4.2.1網(wǎng)絡拓撲結構..............................錯誤!未定義書簽。

4.2.2總體網(wǎng)絡需求..............................錯誤!未定義書簽。

4.2.3網(wǎng)絡流量分析..............................錯誤!未定義書簽。

4.3軟硬件配置建議...........................錯誤!未定義書簽。

4.3.1軟件配置建議..............................錯誤!未定義書簽。

4.3.2硬件配置建議..............................錯誤!未定義書簽。

5概要設計說明...................................錯誤味定義書簽。

5.1網(wǎng)站管理....................................錯誤!未定義書簽。

5.2欄目管理....................................錯誤!未定義書簽。

5.3信息采編....................................錯誤!未定義書簽。

5.4在線調查....................................錯誤!未定義書簽。

5.5財務速遞....................................錯誤!未定義書簽。

文檔僅供參考

5.6統(tǒng)計分析..........................錯誤!未定義書簽。

5.7系統(tǒng)管理..........................錯誤!未定義書簽。

6項目實施方案.........................錯誤!未定義書簽。

6.1項目實施方法.....................錯誤!未定義書簽。

6.1.1項當前期準備..............................錯誤!未定義書簽。

6.1.2業(yè)務需求調研..............................錯誤!未定義書簽。

6.1.3信息調研....................................錯誤!未定義書簽。

6.1.4系統(tǒng)基礎架構規(guī)劃........................錯誤!未定義書簽。

6.1.5應用方案設計..............................錯誤!未定義書簽。

6.1.6系統(tǒng)開發(fā)和實施...........................錯誤!未定義書簽。

6.1.7變更管理流程..............................錯誤!未定義書簽。

6.1.8測試和驗收.................................錯誤!未定義書簽。

6.2項目實施計劃.....................錯誤!未定義書簽。

6.2.1實施范圍....................................錯誤!未定義書簽。

6.2.2實施計戈IJ...................................................錯誤!未定義書簽。

6.2.3項目各階段提交文檔.....................錯誤!未定義書簽。

6.3項目資源計劃.....................錯誤!未定義書簽。

6.3.1項目組織架構..............................錯誤!未定義書簽。

6.3.2項目角色職責..............................錯誤!未定義書簽。

6.3.3用戶方人員要求...........................錯誤!未定義書簽。

6.3.4項目核心人員簡歷........................錯誤!未定義書簽。

文檔僅供參考

6.4項目管理方案.....................錯誤!未定義書簽。

6.4.1項目管理思路..............................錯誤!未定義書簽。

6.4.2項目管理框架..............................錯誤!未定義書簽。

6.4.3項目管理內容..............................錯誤!未定義書簽。

6.4.4項目計戈ij與過程控制.....................錯誤!未定義書簽。

6.4.5軟件開發(fā)活動管理........................錯誤!未定義書簽。

6.4.6項目培訓....................................錯誤!未定義書簽。

6.5項目測試方案.....................錯誤!未定義書簽。

651測試目標及需求..........................錯誤!未定義書簽。

6.5.2約束性條件...........................錯誤!未定義書簽。

6.5.3測試方法與策略.....................錯誤!未定義書簽。

6.5.4測試范圍..............................錯誤!未定義書簽。

6.5.5測試資源..............................錯誤!未定義書簽。

6.5.6測試管理方式........................錯誤!未定義書簽。

6.5.7測試交付物...........................錯誤!未定義書簽。

6.5.8測試與開發(fā)的約定..................錯誤!未定義書簽。

6.5.9測試風險管理........................錯誤!未定義書簽。

6.6項目驗收方案.....................錯誤!未定義書簽。

6.6.1驗收目的....................................錯誤!未定義書簽。

6.6.2驗收對象....................................錯誤!未定義書簽。

6.6.3項目驗收的前提條件：.................錯誤!未定義書簽。

6.6.4驗收方法....................................錯誤!未定義書簽。

文檔僅供參考

6.6.5驗收步驟.........................錯誤!未定義書簽。

6.6.6驗收依據(jù).........................錯誤!未定義書簽。

6.6.7驗收內容.........................錯誤!未定義書簽。

6.6.8驗收結論.........................錯誤!未定義書簽。

6.6.9項目交接.........................錯誤!未定義書簽。

7售后服務體系........................錯誤!未定義書簽。

7.1售后月艮務月艮務目標..................錯誤!未定義書簽。

7.2售后服務服務原則.................錯誤!未定義書簽。

7.3售后月艮務方式.......................錯誤!未定義書簽。

7.4售后服務支持流程.................錯誤!未定義書簽。

7.5售后服務內容.....................錯誤!未定義書簽。

8相關應用案例.........................錯誤!未定義書簽。

8.1門戶網(wǎng)站案例截圖.................錯誤!未定義書簽。

8.2公司其它成功案例清單............錯誤!未定義書簽。

9相關附件.............................錯誤味定義書簽。

9.1項目開發(fā)和管理工具...............錯誤!未定義書簽。

9.2人員簡歷表.......................錯誤!未定義書簽。

文檔僅供參考

1XX公司簡介

1.1基本情況

XX公司是XX的直屬局級單位，XX技術開發(fā)中心（對內

稱：XX軟件開發(fā)中心）是XX公司全資子公司。

XX技術開發(fā)中心承擔XX主要業(yè)務系統(tǒng)、管理信息系統(tǒng)以及總

行支付科技司的其它軟件項目開發(fā)；承擔所開發(fā)的軟件以及XX

有關應用軟件的測試工作；負責所開發(fā)的項目的管理維護和推廣

工作；承擔XX分行等所委托的應用系統(tǒng)的開發(fā)；跟蹤、研究國

外金融電子化技術的最新成果，積極在XX內部推廣應用。

1.2業(yè)務范圍

XX公司當前主要職責是承擔XX軟件開發(fā)、系統(tǒng)集成、網(wǎng)

絡建設與運行維護、測試、技術培訓、技術支持、信息安全、標

準化服務以及組織金融技術暨設備展覽、出版發(fā)行《金融電子

化》雜志、數(shù)據(jù)備份中心，開展信息化交流和有關宣傳。秉承立

足人行、服務金融、面向社會的宗旨，經過20年的開拓建設，

發(fā)展成為集軟件開發(fā)、系統(tǒng)測試、系統(tǒng)集成、數(shù)據(jù)中心運營及備

份、網(wǎng)絡建設、信息安全、技術支持、科技培訓、標準化、科技

信息交流與金融信息化宣傳等服務于一體，技術實力雄厚、信譽

度高、管理規(guī)范、服務完備的國家金融系統(tǒng)信息化龍頭企業(yè)。以

XX軟件開發(fā)、金融系統(tǒng)測評、災難數(shù)據(jù)中心、中國國際金融

文檔僅供參考

展、金融電子化雜志社等多個主營服務平臺為依托，服務領域遍

及XX、銀監(jiān)會、政府部門、金融機構和財政稅務等各個領域。

1.3資質和榮譽

?軟件企業(yè)認定證書

?高新技術企業(yè)證書

?國家信息安全測評授權培訓機構資質證書

?國家信息安全測評信息安全服務資質證書

?ISO9001-證書

?計算機信息系統(tǒng)集成企業(yè)（二級）資質證書

?獲得國家高技術產業(yè)發(fā)展項目專項支持

?至，獲軟件著作權共20項

?榮獲了10多項XX科技發(fā)展進步獎

?XX頒發(fā)的國家征信系統(tǒng)、央行金融統(tǒng)計監(jiān)測系統(tǒng)等系統(tǒng)建設

全國先進集體

1.4技術實力

?XX技術策略和金融行業(yè)技術標準制定的參與者

?建立具有國際先進水平的金融信息化服務“五個能力體

系”：建立了以國際CMMI最高五級標準為基礎的軟件

開發(fā)過程管理體系；基于CNAS（國家認可委）標準規(guī)范

建立了國際化的測試質量保障體系；基本建立以ITIL、

文檔僅供參考

ISO為標準要求的IT服務管理體系；初步建立以

IS027000為標準的信息安全管理體系；初步形成以美

PMBOK標準規(guī)范為要求的，符合XX科技特點的項目管

理知識體系。

?系中國承擔全國性大型金融信息化項目最多的IT服務提供

者。承擔XX及金融系統(tǒng)重大信息化建設項目任務，開發(fā)

建設了中國企業(yè)、個人征信系統(tǒng)、國家貨幣金銀管理系

統(tǒng)、財稅庫行橫向聯(lián)網(wǎng)系統(tǒng)、聯(lián)網(wǎng)核查公民身份信息系

統(tǒng)、人民幣賬戶管理系統(tǒng)、金融統(tǒng)計監(jiān)測系統(tǒng)、國庫會計

數(shù)據(jù)集中核算系統(tǒng)、人民幣跨境支付信息管理系統(tǒng)等二十

多個大型業(yè)務應用系統(tǒng)和管理信息系統(tǒng)，榮獲了多項XX

科技發(fā)展進步獎。

?擁有2萬多平方米的現(xiàn)代化大型軟件開發(fā)基地、上千平方

米的國家A級數(shù)據(jù)機房，設立“XX同城災備中心”和

“中小金融機構災備外包服務中心”，建有XX網(wǎng)絡安全

運維中心、面向XX業(yè)的技術支持中心，并全面承擔著銀

監(jiān)會系統(tǒng)運維工作。

?系國內信息化價值鏈最完備的綜合信息服務商。形成集軟

件開發(fā)、數(shù)據(jù)備份、系統(tǒng)檢測、標準化、網(wǎng)絡安全、集成

運維等為一體的全方位、多渠道的高端IT服務平臺。為

20()余家金融機構提供了完備、快捷、優(yōu)質、高效的信息

文檔僅供參考

化服務，服務領域遍及XX、銀監(jiān)會、政府部門、金融機

構和財政稅務等各個領域，贏得了合作伙伴和客戶的高度

贊譽。

?主辦亞太地區(qū)規(guī)模最大、規(guī)格最高、在國內極具影響力的

國際高端展覽平臺：中國國際金融（XX）技術暨設備展

和中國國際金融服務展示展覽

1.5主要客戶

?XX公司的主要客戶涵蓋XX總行及各分支行、國有XX、

股份制XX、城市商業(yè)XX、外資XX、等各類金融機構。

經過十多年不懈的努力，XX公司與各個層面的客戶建立

了緊密的合作關系。

?國有XX（中國XX、農業(yè)XX、工商XX等）

?股份制XX（中信、光大、華夏、興業(yè)XX等）

?城市商業(yè)XX（南京XX、上海XX、寧波XX等）

?外資XX（東亞XX、渣打XX、匯豐XX等）

文檔僅供參考

2需求的理解

2.1系統(tǒng)名稱

本系統(tǒng)的名稱為：XX股份有限公司內部門戶網(wǎng)站，以下簡

稱門戶網(wǎng)站。

2.2建設目標分析

經過門戶網(wǎng)站的建設，實現(xiàn)XX內部各級部門之間辦公信息

的收集與處理、流動與共享；建立起以工作流引擎為核心的業(yè)務

流程處理，以公告、論壇、即時通訊和郵件為基礎的多渠道信息

共享，提供考勤、人事、個人門戶、日程安排等個性化的自助式

服務，以提高辦公效率和提升公司的信息化水平。

門戶網(wǎng)站建設主要目的是構建門戶基礎架構，同時能夠與已

有的應用系統(tǒng)集成，實現(xiàn)原有業(yè)務的不間斷運行，該網(wǎng)站為XX

內部網(wǎng)站，使用者為XX內部員工。內網(wǎng)網(wǎng)站必須滿足以下目

標：

1.系統(tǒng)能夠建設成為單一信息化工作平臺，成為XX未來發(fā)

展的基準Web工作平臺，實現(xiàn)統(tǒng)一的信息展現(xiàn)。實現(xiàn)對

辦公系統(tǒng)、郵件系統(tǒng)以及各業(yè)務系統(tǒng)的集成，經過單點登

錄技術，使系統(tǒng)成為員工工作的門戶入口。

2.系統(tǒng)能夠建設成為統(tǒng)一的信息整合平臺。將XX現(xiàn)有的應

用系統(tǒng)、數(shù)據(jù)資源進行整合，打破信息孤島，為領導提供

文檔僅供參考

決策支持。

3.及時、準確、客觀地反映市場變化和主要客戶的情況，并

為XX提供決策支持，降低決策風險。

4.系統(tǒng)可靈活定制、擴展。要實現(xiàn)網(wǎng)站的各欄目及子欄目的

增減，同時欄目的內容也可靈活增減。另外系統(tǒng)可提供通

用的接口，可根據(jù)業(yè)務需要，在未來與某單位新建的業(yè)務

系統(tǒng)有效集成。

5.業(yè)務系統(tǒng)維護實現(xiàn)分布管理，非集中管理。由于系統(tǒng)信息

發(fā)布內容來自XX多個部門及分支機構，不同部門及分支

機構維護各自發(fā)布的信息，因此系統(tǒng)應能夠實現(xiàn)分布管

理，由各個部門及分支機構自己管理各自負責的信息。

6.實現(xiàn)用戶的統(tǒng)一管理、權限的統(tǒng)一管理、用戶的統(tǒng)一認

證。

7.實現(xiàn)統(tǒng)一的信息展現(xiàn)，展現(xiàn)的信息包括集成系統(tǒng)的統(tǒng)一待

辦事宜、公告信息、數(shù)據(jù)、圖標等。

8.業(yè)務系統(tǒng)維護形象直觀、操作簡便，無需專門的技術人

員。由于業(yè)務系統(tǒng)信息經常發(fā)生變化和變化的信息需要及

時發(fā)布出去，需讓XX員工掌握，因此系統(tǒng)維護必須形象

直觀、操作簡便，無需專門的技術人員。

9.實現(xiàn)針對用戶常見功能定制小應用。

除上述目標外，該系統(tǒng)從設計方面，應兼顧穩(wěn)定性、操作

性、擴展性、先進性、可維護性、安全性等重要原則，在穩(wěn)定、

文檔僅供參考

安全的基礎上能夠隨著業(yè)務的發(fā)展逐步擴展。

2.3系統(tǒng)建設原則

2.3.1兼容開放性原則

能夠兼容主流的服務器和操作系統(tǒng)；能兼容現(xiàn)有的辦公PC

環(huán)境。

2.3.2先進性和靈活性原則

采用當前主流的先進的技術、方法，滿足系統(tǒng)不斷增加和調

整的業(yè)務需求；經過修改流程的相關配置文件實現(xiàn)流程的發(fā)布或

更新，縮減系統(tǒng)改造周期。

2.3.3實用性原則

系統(tǒng)應具有良好的用戶界面，操作簡單方便。充分考慮錄入

人員特點，使數(shù)據(jù)處理工作簡單、方便、快捷，業(yè)務流程清晰，

符合常規(guī)業(yè)務處理習慣；對于常見的信息查詢操作，系統(tǒng)提供靈

活多樣的查詢和統(tǒng)計檢索方式，滿足不同層次的用戶需求。

2.3.4高效性原則

系統(tǒng)應保證響應速度，并滿足系統(tǒng)在用戶量和信息量不斷增

加的需求。

文檔僅供參考

2.3.5可擴展性原則

所選用的系統(tǒng)軟硬件平臺具有良好的可擴充能力，支持系統(tǒng)

規(guī)模的擴大和業(yè)務范圍的擴展，能夠滿足今后業(yè)務發(fā)展的需要。

在不更改系統(tǒng)整體架構的前提下，方便的支持系統(tǒng)擴充。

2.3.6可靠性的原則

系統(tǒng)具備容錯能力，并有相關的容災、數(shù)據(jù)備份及恢復方

案。

2.3.7安全性原則

系統(tǒng)必須建立在成熟穩(wěn)定的硬件環(huán)境和應用軟件基礎上，經

過完善的備份恢復策略、安全控制機制、運行管理監(jiān)控和故障處

理手段來保障系統(tǒng)的安全、穩(wěn)定。

2.3.8經濟性原則

綜合考慮系統(tǒng)的性能、價格、實施和服務，保證系統(tǒng)具有較

高的性價比。充分利用各種技術保護投資。

2.4系統(tǒng)需求分析

2.4.1總體業(yè)務架構

依據(jù)XX內部門戶網(wǎng)站的需求，系統(tǒng)分為網(wǎng)站管理、欄目管

文檔僅供參考

理、信息采編、信息審批流程、統(tǒng)計分析、在線調查、專題管

理、通訊錄、金融動態(tài)、財務速遞、電子公告以及系統(tǒng)管理以及

對外接口等功能。

下圖為門戶網(wǎng)站總體業(yè)務架構分析：

2.4.2業(yè)務流程說明

1.網(wǎng)站管理：

超級管理員能夠對網(wǎng)站設置進行管理。

首頁展現(xiàn)：系統(tǒng)預設幾種首頁框架結構和主題配色方案，由

超級管理員選擇，應用于所有終端用戶的首頁顯示。

超級管理員能夠指定在進行信息采編時附件文件的大小、格

文檔僅供參考

式。

如果與IBMPortal集成，采用虛擬門戶技術，能夠實現(xiàn)子站

點的創(chuàng)立和管理。

2.欄目管理：

欄目管理采用分級管理，超級管理員能夠進行全站所有欄目

增、冊人改、授權、排序操作；超級管理員指定各一級欄目的欄

目管理員、欄目的業(yè)務類別，欄目管理員能夠維護本一級欄目下

的所有子欄目（增刪改、排序），各欄目管理員還能夠定義每個

欄目的展現(xiàn)風格。欄目內信息發(fā)布的權限限制到人員。

在進行欄目展現(xiàn)設置時，系統(tǒng)預設幾種欄目展現(xiàn)框架結構，

由各欄目管理員自主選擇自己欄目的展現(xiàn)結構，配色方案自動與

首頁配色相一致，應用于所有終端用戶的顯示。

3.信息米編：

可進行信息的錄入、編輯、發(fā)布。由于信息具有多樣性的特

點，需要在信息采編過程中提供充分的系統(tǒng)支持，方便操作。

單篇文檔的錄入、編輯、預覽、修改、刪除、撤銷發(fā)布。

批量文檔的刪除、引用、移動。

支持多種格式的文檔采集，包括WORD文檔、EXCEL表

格、PDF文檔、HTML頁面?？芍苯釉诤笈_選擇需要錄入的源文

檔，將源文檔導入到系統(tǒng)中；也能夠從源文檔中直接拷貝段落、

文字、表格等部分內容。

可視化編輯。實現(xiàn)類似word編輯器功能，支持文字大小、

文檔僅供參考

字體、顏色、加粗等、段落的間距、位置等格式修改，支持圖

片、視頻、音頻、表格及一些特殊對象的插入，支持各種文檔內

容、對象的混排，保持所見即所得的編輯效果，可對編輯文檔進

行預覽。、

支持文檔附件上傳、下載，對附件的文件格式可進行控制。

由超級管理員指定上傳文件大小、格式。

除普通類型文檔外，還應支持鏈接類型文檔，這種文檔具有

標題，但具體內容為空，僅指向一個指定鏈接地址，在發(fā)布后的

頁面上體現(xiàn)為：在點擊該類文檔標題后，直接跳轉至指定鏈接。

可直接將某篇文章置頂、推薦

可跟蹤單篇文章的點擊次數(shù)，便于今后統(tǒng)計。

設定所發(fā)文章的用戶訪問范圍：公開訪問；機構部門、角

色、個人。針對每篇文章，信息發(fā)布人可設置開通評論或者不開

通。

4.信息審批流程：

審核流程非必選，由用戶自己決定。審核采用多級審核，由

信息發(fā)布人在信息審核人的范圍內選定審批人員，接到申請的審

核人能夠直接審核經過發(fā)布，也能夠再上報給其它人審批，或者

退回讓擬稿人重新擬稿。

5.統(tǒng)計分析：

能夠對不同欄目的文檔進行統(tǒng)計，按用戶或組織（中心和部

門）統(tǒng)計工作量，生成相應的統(tǒng)計圖表（餅狀圖、柱狀圖等）并

文檔僅供參考

支持結果導出。

6.在線調查：

調查問卷模塊主要包括設計發(fā)布問卷、回答問卷、數(shù)據(jù)統(tǒng)計

等功能。該模塊同時適用于網(wǎng)絡答題和網(wǎng)絡投票。主要功能包

括：新增問卷、設計問卷、發(fā)布問卷、結束問卷、查詢問卷、瀏

覽問卷、查看問卷結果、刪除問卷、打印問卷、導出問卷。

7.專題管理：

包括專題欄目創(chuàng)立、專題內容采編、專題實現(xiàn)模板的可視化

設計，允許用戶在重大營銷活動或其它專項活動時，快速建立一

個屬于自己的專題，并根據(jù)事件的特征設計專題頁面的顯示布

局，以及在布局中添加相應的資源塊，在資源塊中添加相應的文

章和圖片等，從而發(fā)布到內網(wǎng)上。

8.通訊錄：

提供通訊錄管理以及查詢功能，在進行查詢時，能夠按照姓

名、拼音首字母、拼音全拼、部門等方式進行查詢，查詢結果包

括：姓名、部門、單位電話、手機、郵箱等內容。

9.金融動態(tài)：

由辦公室人員從各種信息渠道采集、加工的每日財經資訊和

金融市場訊息。為員工提供金融行業(yè)的形勢分析及熱點、看點

信息。此欄目能夠經過欄目管理創(chuàng)立。

10.財務速遞：

主要以圖表的方式展現(xiàn)全行財務信息，包括：個人存款余

文檔僅供參考

額、對公存款余額及增長率、比年初、比上月、比上日的匯總情

況，點擊可查看其詳細情況，按照部門、分行、支行進行排序并

統(tǒng)計。

11.電子公告：

電子公告管理模塊提供給公告管理員用于發(fā)布公告。在公告

發(fā)布范圍內的用戶能夠查看公告。還能夠與0A等其它系統(tǒng)集

成，顯示相關系統(tǒng)的公告信息。

12.系統(tǒng)管理

系統(tǒng)管理提供給管理員使用，設置有機構與部門管理、用戶

管理、角色管理、參數(shù)設置、欄目管理、日志管理、數(shù)據(jù)字典管

理等功能。

綜上，經過對門戶網(wǎng)站主要業(yè)務處理的分析與歸納，提取共

性需求，引入架構管控的思路，搭建門戶網(wǎng)站；經過配置方式實

現(xiàn)通用需求，從而讓門戶網(wǎng)站隨需而變和可持續(xù)發(fā)展，達到降低

成本、縮短開發(fā)周期和提高軟件質量的目的；并輔以通訊錄、財

務速遞、電子公告等公共服務應用，將員工的日常事務、管理與

業(yè)務活動等有機地結合起來；經過底層基礎框架，構建統(tǒng)一的綜

合辦公桌面，實現(xiàn)統(tǒng)一的工作平臺。

2.4.3非功能性需求

2.4.3.1.系統(tǒng)性能要求

系統(tǒng)的查詢子系統(tǒng)針對單一條精確查詢數(shù)據(jù)時間應小于2

文檔僅供參考

秒，支持100個用戶同時查詢同一信息；數(shù)據(jù)記錄數(shù)大于1萬

時，信息檢索時間應小于3秒。系統(tǒng)初期能夠支持100人的并發(fā)

訪問，在將來能夠擴展到支持500人的并發(fā)訪問。

2.4.3.2,數(shù)據(jù)存儲期

系統(tǒng)數(shù)據(jù)聯(lián)機存儲5年，超過5年的采用脫機存儲。

2.4.3.3.系統(tǒng)容量要求

數(shù)據(jù)空間的需求按照每人年1G計算能滿足未來5年的數(shù)據(jù)

需求。

2.4.3.4.系統(tǒng)冗余要求

系統(tǒng)應提供備份支持。

2.4.3.5.系統(tǒng)備份和恢復要求

系統(tǒng)應提供數(shù)據(jù)備份及恢復方案。系統(tǒng)應能在災難發(fā)生時，

在24小時內恢復。

2.4.3.6.信息安全要求

系統(tǒng)應根據(jù)《XX信息系統(tǒng)信息安全等級保護標準規(guī)范》三

級要求進行建設。

文檔僅供參考

2.4.3.7.界面設計要求

系統(tǒng)頁面應簡潔美觀；功能操作簡便且銜接自然；各子系統(tǒng)

風格色調一致。

2.4.3.8.用戶幫助要求

用戶登錄系統(tǒng)后，系統(tǒng)應能給出關于系統(tǒng)的有關幫助說明。

系統(tǒng)交付后，提供詳細的用戶手冊。

2.4.3.9.兼容性要求

系統(tǒng)應兼容XX現(xiàn)有辦公電腦和軟件環(huán)境。

文檔僅供參考

3總體架構設計

3.1設計原則

■總體架構在著重考慮實施要求的同時，需要為后續(xù)階段進

行規(guī)劃，以保證項目最終能夠達到目標架構的設計；

■總體架構設計架構時充分考慮與現(xiàn)有系統(tǒng)或網(wǎng)絡基礎設施

的兼容，充分利用已有成果，避免重復開發(fā)和建設。

■總體架構設計過程中應遵守相關的IT管理規(guī)程，保證最

終的系統(tǒng)能夠順利的部署并移交給運行維護部門。

3.2體系架構

DDDDD0D0DDD0000D/DD00[]DD/000D

D0D0D0D0DDD0M0DDD0DODD

文檔僅供參考

圖3-2系統(tǒng)體系架構

采用業(yè)界最為流行的SOA（面向服務的架構）框架，遵循

統(tǒng)一技術路線，架構設計注重層間的松耦合與層內的高內聚，經

過對業(yè)務的抽象、映射實現(xiàn)業(yè)務對象組件化和統(tǒng)一的服務調用，

充分考慮了系統(tǒng)的可擴展性、可復用性、可配置性，降低開發(fā)和

維護成本使得系統(tǒng)能夠隨需而變，快速靈活滿足業(yè)務變化的需

要。

3.3邏輯架構

根據(jù)對業(yè)務需求的整體分析與梳理，XX內部門戶網(wǎng)站系統(tǒng)

的整體邏輯架構采用縱向分層方式分為數(shù)據(jù)層、服務層、應用層

和用戶層。如下圖所示:

000

000

］。0。U000000D00D00D00D0000DD0D00

DD0go000°

D000000

00匚W00D000000

D000000

000

0DDD0

文檔僅供參考

圖3-3系統(tǒng)邏輯架構圖

3.4應用架構

oooo00000

0000

0000口口?？贒DDD0000

0D0000DDDII||oooo-

D0

OAO000000000000000000DDDDDD

0DDDDDD000000

⑥⑥⑥

圖3-4應用架構

系統(tǒng)的應用架構能夠劃分為三個層次，分別是組件層、服務

層與應用層，其中組件層是系統(tǒng)業(yè)務對象的組件化抽象和最低粒

度的組裝，服務是對相關業(yè)務組件的集成與更高粒度的封裝，服

務面向具體的業(yè)務應用；提供標準的調用接口供具體的業(yè)務應用

直接調用；應用層包括了本系統(tǒng)業(yè)務與管理層面需要實現(xiàn)的具體

應用。

文檔僅供參考

3.4.1整體功能框架

圖3-4-1整體功能框架

系統(tǒng)整體功能包括7大模塊，分別是網(wǎng)站管理、欄目管理、

信息采編、在線調查、財務速遞、統(tǒng)計分析、系統(tǒng)管理。

文檔僅供參考

3.5數(shù)據(jù)架構

3.5.1邏輯數(shù)據(jù)架構

圖3-5-1邏輯數(shù)據(jù)架構

系統(tǒng)邏輯數(shù)據(jù)架構是對系統(tǒng)業(yè)務對象的邏輯分類，本系統(tǒng)涉

及的邏輯數(shù)據(jù)對象包括業(yè)務數(shù)據(jù)、字典數(shù)據(jù)、管理類數(shù)據(jù)、定義

類數(shù)據(jù)。

文檔僅供參考

3.5.2數(shù)據(jù)層次劃分

A

應用層

/?面向各功能模塊

?按需制定接口視圖

基礎層

/?存放業(yè)務數(shù)據(jù)

?存放非結構化數(shù)據(jù)

緩沖層

/?緩存數(shù)據(jù)讀取

?緩存數(shù)據(jù)更新

數(shù)據(jù)源層

/-數(shù)據(jù)的來源

圖3-5-2數(shù)據(jù)層次

系統(tǒng)的數(shù)據(jù)層次能夠劃分為數(shù)據(jù)源層、緩沖層、基礎層、應用

層。

?數(shù)據(jù)源層是系統(tǒng)的原始數(shù)據(jù)，包括字典數(shù)據(jù)、管理類數(shù)據(jù)和

定義類數(shù)據(jù)；

?緩沖層做為對數(shù)據(jù)庫數(shù)據(jù)處理的有效補充，減少對數(shù)據(jù)庫的

直接操作請求，負責對字典數(shù)據(jù)、部分管理類數(shù)據(jù)和部分定

義類數(shù)據(jù)進行內存的緩存存儲，依據(jù)各個子系統(tǒng)的性能和業(yè)

務的綜合考慮來確定是否需要將數(shù)據(jù)庫數(shù)據(jù)緩存到緩存層

中；緩存層的數(shù)據(jù)在對應來源數(shù)據(jù)變更時實時更新。

?基礎數(shù)據(jù)層保留所有提交的歷史業(yè)務數(shù)據(jù)，包括表單數(shù)據(jù)和

流程流轉的實例數(shù)據(jù)。

文檔僅供參考

?應用層為面向各功能模塊提供統(tǒng)一的接口視圖。

3.5.3數(shù)據(jù)容量估算

按照數(shù)據(jù)空間的需求為0.2G每人年，且系統(tǒng)要滿足未來5年

的需求

1年數(shù)據(jù)按1000用戶計算為200G

5年后=2OOG*5=1T

文檔僅供參考

3.6技術架構

3.6.1J2EE分層設計

/

UID

00D0DDD

DD00DD0

圖3-6-1架構分層設計圖

1本系統(tǒng)軟件架構設計采用松耦合、分層設計的原則，主要

分為UI(UserInterface)層、服務層、業(yè)務處理層、數(shù)據(jù)

訪問層。

2UI層指用戶界面，是用戶訪問本系統(tǒng)的入口。UI層主要采

用JSF/Flex框架來實現(xiàn)。

文檔僅供參考

3服務層是本系統(tǒng)提供對外業(yè)務服務的功能。該層將服務接

口和實現(xiàn)分離，實現(xiàn)松耦合。同時，服務層主要采用

【Service接口來實現(xiàn)。

4業(yè)務處理層是指公共業(yè)務處理組件，主要用來處理服務層

所共有的業(yè)務處理規(guī)則、流程等內容。業(yè)務處理層采用普

通的Java對象來實現(xiàn)。

5數(shù)據(jù)訪問層是指提供對數(shù)據(jù)庫數(shù)據(jù)訪問的接口，被業(yè)務處

理層或服務層直接調用。數(shù)據(jù)訪問層主要經過系統(tǒng)技術平

臺的SQLExecutor和Mybatis來實現(xiàn)。

6公共組件指按照規(guī)范統(tǒng)一實現(xiàn)的公共組件，包括用戶管

理、組織機構管理、權限管理、日志管理等模塊。

7事務處理指事務的處理機制，事務開始于服務層，采用數(shù)

據(jù)庫的事務管理器對服務層的相關服務進行事務控制處

理。

3.6.2邏輯技術架構

文檔僅供參考

圖3-6-2邏輯技術架構設計圖

系統(tǒng)邏輯技術架構包括四個層次：分別是用戶層、訪問控制

層、應用服務層和數(shù)據(jù)存儲層。訪問控制層包括了網(wǎng)絡的物理隔

離設備與Web服務器，是系統(tǒng)訪問和請求轉發(fā)的第一層。應用

服務層是業(yè)務處理中心，負責對用戶提交的操作請求進行業(yè)務處

理。數(shù)據(jù)存儲層包括共享存儲設備、數(shù)據(jù)庫和相應的數(shù)據(jù)備份設

備。

3.7備份與恢復

3.7.1備份目標

備份與恢復的目標在于：

?保證對數(shù)據(jù)的及時有效恢復。

?最低程度地降低數(shù)據(jù)丟失。

?盡量提高數(shù)據(jù)備份過程的效率。

3.7.2備份的范圍及流程

＞備份的范圍

按備份的內容分，備份的范圍主要包括：

?應用程序與配置

?系統(tǒng)元數(shù)據(jù)

?業(yè)務數(shù)據(jù)

文檔僅供參考

按備份的系統(tǒng)分，備份的范圍主要包括：

?數(shù)據(jù)庫

?Web服務器

?應用服務器

＞備份的流程

備份一般在備份策略制定后，對備份系統(tǒng)和工具進行配置，

由工具定期自動完成，只是在特定情況下（系統(tǒng)升級、遷移等）

由手工完成。應定期檢查備份日志，以確保備份按照預定設置正

確完成。備份管理的流程如下圖所示：

1制定策略配置工具備份執(zhí)行日志檢查

3.7.3恢復的范圍及流程

（一）恢復的范圍

恢復的范圍主要包括：

■對給定時間點能對系統(tǒng)數(shù)據(jù)庫進行完整的數(shù)據(jù)

恢復

■將Web服務器恢復到最新狀態(tài)

■將應用服務器恢復到最新狀態(tài)。

（二）恢復的流程

恢復工作并不是日常進行，而是在故障和災難發(fā)生時進行。

文檔僅供參考

因此，應持續(xù)監(jiān)視系統(tǒng)情況，選擇恢復時機?；謴偷膱?zhí)行一般由

人工干預完成，完成后應形成日志記錄存檔待查?；謴凸芾淼牧?/p>

3.7.4備份與恢復的分類

備份任務按內容分類包括：

■對應用程序和配置的備份。

■對數(shù)據(jù)的備份，既能夠分別備份不同的內容，又能夠

同時備份所有的內容。

在各種備份的內容中，操作系統(tǒng)和應用程序及配置發(fā)生變化

的頻率很低，數(shù)據(jù)變化的頻率很高，因此建議對不同的內容

分開備份，這樣能夠減少備份的時間，方便恢復操作。

備份任務按工作進行的周期分類包括：

■日常備份

■硬件升級更換的備份

■增加節(jié)點的備份

■用戶定制備份等

在各種周期的備份中，日常備份最為重要。在各種備份的內

容中，數(shù)據(jù)是核心內容。因此，備份策略的核心是日常數(shù)據(jù)備

文檔僅供參考

份。

3.7.5日常備份與恢復的方式

日常數(shù)據(jù)備份的方式一般可分為增量備份、全備份和完全備

份。

■增量備份

增量備份是指對所選定的對象，在前一次備份的基礎上

只對變化的部分進行備份，恢復時則需要一個全備份和此后

的每次的增量備份才能對所選定的對象進行恢復。

■全備份

全備份是指對所選定對象進行完整備份?；謴蜁r，僅依

靠這一個備份就能對所選定的對象進行恢復。一般，這里說

的全備份意味著不是對整個系統(tǒng)，而是對系統(tǒng)中特定的一部

分對象進行備份。

■完全備份

完全備份是指對一個系統(tǒng)中的所有對象進行完整備份。

恢復時，僅依靠這一個備份就能夠整個系統(tǒng)或系統(tǒng)中的指定

的對象進行恢復。

■異地備份

將數(shù)據(jù)在異地產生一份可用的副本，災難發(fā)生時，能在

24小時內異地恢復系統(tǒng)。

在本系統(tǒng)中，一般采用增量備份、全備份、異地備份相結

文檔僅供參考

合的方式進行備份，并對數(shù)據(jù)進行異地備份處理。

3.7.6日常備份與恢復的周期

業(yè)務數(shù)據(jù)每天進行全備份。

對于應用程序及配置的備份，建議在有變動時每月做一次全

備份，在沒有變動時無需備份，這樣當操作系統(tǒng)或程序被損壞

時，能夠將操作系統(tǒng)或程序恢復到最新狀態(tài)。

在災難發(fā)生時，使用異地備份進行恢復，確保系統(tǒng)運行。

3.8系統(tǒng)安全

3.8.1安全需求

門戶網(wǎng)站的安全管理應堅持安全與效率平衡的原則，方便操

作、便于管理。系統(tǒng)存儲和處理的信息重要而敏感，系統(tǒng)應在網(wǎng)

絡、數(shù)據(jù)、系統(tǒng)訪問等方面提供充分的安全保障，建立多層次的

安全保障體系，包括授權/認證機制、存取權限與執(zhí)行控制、口

令保護機制等多種安全保障機制，作好系統(tǒng)內權限分級管理，提

供從數(shù)據(jù)庫、文件集合、單個文件等不同的安全保證。

1.用戶認證

用戶登錄門戶網(wǎng)站時，系統(tǒng)對用戶登錄機器賬號、密碼信息

進行驗證，驗證經過后方可允許系統(tǒng)用戶登錄系統(tǒng)。

2.數(shù)據(jù)安全

文檔僅供參考

門戶網(wǎng)站數(shù)據(jù)存儲安全的目標是保證數(shù)據(jù)存放時的可靠性、

完整性、保密性。為此，系統(tǒng)應采取以下措施：

(1)業(yè)務數(shù)據(jù)無論是數(shù)據(jù)庫或者文件形式保存的，均應采

取完備的用戶權限策略避免非法訪問。

(2)系統(tǒng)應保證數(shù)據(jù)存儲的高度可靠性，應采用高可靠服

務器來存儲數(shù)據(jù)，防止數(shù)據(jù)損壞和丟失。

(3)應采用可靠技術手段保證后臺數(shù)據(jù)的安全性，確保非

系統(tǒng)用戶無法訪問到系統(tǒng)后臺數(shù)據(jù)。

(4)系統(tǒng)應提供完整和方便的數(shù)據(jù)備份策略，保證數(shù)據(jù)損

壞時及時恢復。系統(tǒng)數(shù)據(jù)備份策略應支持以磁盤介質方式備份指

定工作日的業(yè)務數(shù)據(jù)和日志，并提供自動備份功能。備份數(shù)據(jù)應

以加密形式存儲。

3.運維安全

應用系統(tǒng)設計應支持服務器故障備份與切換等冗余技術。各

節(jié)點不應具有故障單點，具有足夠的設備容錯能力，可用性指標

應大于99.9%o當正在運行的系統(tǒng)出現(xiàn)故障，備份系統(tǒng)可接替故

障設備并恢復正常的業(yè)務處理。若系統(tǒng)發(fā)生災難時，應能在24

小時內在異地恢復系統(tǒng)。

3.8.2安全系統(tǒng)設計原則

1.最小影響

文檔僅供參考

安全方案的建設應當盡可能小地影響系統(tǒng)和網(wǎng)絡的正常運

行，不能對網(wǎng)絡和業(yè)務運行產生顯著影響，特別是不能造成業(yè)務

系統(tǒng)性能明顯下降、網(wǎng)絡擁塞、服務中斷、目標系統(tǒng)數(shù)據(jù)的破壞

和泄露等問題。

2.整體性

系統(tǒng)安全方案所涉及的范圍和內容應當盡可能地整體、全

面，應當包括安全涉及的各個層面，避免由于遺漏而造成未來的

安全隱患。

3.標準性和規(guī)范性

安全方案的設計和具體實施應當依據(jù)國內和國外的相關標

準、規(guī)范以及理論模型，避免雜亂無章、無序建設。

4.先進性

安全方案的設計起點要高，應當采用成熟、先進、高效的軟

硬件平臺和技術，保證安全系統(tǒng)具有長久的生命力。

5.易用性

系統(tǒng)的安全措施最終要由人來完成，如果安全措施過于復

雜，對操作人員的技術要求過高，反而可能造成安全隱患，因此

易用性也是非常重要的一個原則。

3.8.3系統(tǒng)安全架構

經過對安全需求的分析，保障系統(tǒng)安全需要從應用和信息安

全、基礎架構安全以及整體安全管理三個層面出發(fā)，系統(tǒng)安全架

文檔僅供參考

構示意圖如下:

flfl0000D000

0000

圖3-8-3系統(tǒng)安全架構

信息與應用安全是系統(tǒng)安全保障的核心，直接保障系統(tǒng)信息

的可靠性、完整性、機密性、抗抵賴性和真實性以及應用系統(tǒng)自

身安全，主要由應用系統(tǒng)自身或與應用系統(tǒng)耦合性較強的專用安

全系統(tǒng)或安全技術來實現(xiàn)。

基礎架構安全是保障系統(tǒng)所運行的系統(tǒng)環(huán)境、網(wǎng)絡和客戶端

的安全，起到為系統(tǒng)提供運行環(huán)境保障的輔助安全作用，主要由

與應用系統(tǒng)沒有關系的通用安全系統(tǒng)或通用安全技術實現(xiàn)?；A

架構的安全是信息與應用安全的基礎。

安全管理為信息與應用安全、基礎架構安全提供安全配置指

導，并提供嚴格、規(guī)范的安全管理體系，以形成系統(tǒng)正式運行后

的安全管理規(guī)章制度，主要由各種安全規(guī)范、安全規(guī)章制度等組

成。

文檔僅供參考

3.8.4安全策略

3.8.4.1.信息數(shù)據(jù)安全策略

3.8.4.1.1.數(shù)據(jù)存儲安全

所有的數(shù)據(jù)和文件的操作必須是使用經過授權的系統(tǒng)功能進

行操作，否則不能進行訪問。

3.8.4.1.2.數(shù)據(jù)存儲可靠

系統(tǒng)應保證數(shù)據(jù)存儲的高度可靠性，應采用高可靠服務器來

存儲數(shù)據(jù)，防止數(shù)據(jù)損壞和丟失。采用專門的備份服務器對數(shù)據(jù)

進行備份，既實現(xiàn)增量備份，也實現(xiàn)全備份。

3.8.4.1.3.SSL傳輸安全

Web服務器端能夠啟動SSL傳輸配置，如有必要，能夠要求

客戶端連接時使用SSL協(xié)議。

3.8.4.2.應用安全策略

3.8.4.2.1.身份認證

系統(tǒng)采用有效賬號、密碼方式確保登錄用戶的合法性

用戶第一次登錄系統(tǒng)時必須修改系統(tǒng)已賦予的初始密碼，否

則不予登錄系統(tǒng)

應經過設置密碼有效期（可配置）強制用戶對密碼進行定期更改

文檔僅供參考

連續(xù)失敗登錄多次后應鎖定賬號。連續(xù)失敗登陸次數(shù)可配置

用戶密碼要求加密后存儲，加密算法可應采用MD5

用戶登錄時，輸入的密碼加密后傳輸。

3.8.4.2.2.訪問控制

系統(tǒng)設計一套具有較強可擴展性的權限管理，需要建立用

戶、角色和權限等數(shù)據(jù)庫表，而且建立相互之間的關系，具體實

現(xiàn)如下：

文檔僅供參考

說明:

用戶僅僅是純粹的用戶，用來記錄用戶相關信息，如用戶

名、密碼等，權限是被分離出去了的。用戶要擁有對某種資源的

權限，必須經過角色去關聯(lián)。

角色是使用權限的基本單位，擁有一定數(shù)量的權限，經過角

色賦予用戶權限

權限指用戶根據(jù)角色獲得對程序某些功能和數(shù)據(jù)的操作，例

如對某個模塊的操作、或者對某個模塊中某時間、機構數(shù)據(jù)的查

詢、修改和刪除功能。

用戶登錄

判斷用戶是否合法是》根據(jù)功能權限

顯示相應模塊

否選擇模塊

依據(jù)數(shù)“據(jù)權限

退出系統(tǒng)

或重新登錄

展示模塊數(shù)據(jù)

執(zhí)行相應操作

3-8-4-2-2訪問控制圖

說明:

文檔僅供參考

用戶登錄時，首先驗證是否為合法用戶，只有合法用戶才允

許訪問系統(tǒng)；驗證經過后，從用戶權限表獲取用戶的功能權限，

進入相應的功能模塊，在功能模塊中再判斷用戶的數(shù)據(jù)權限，如

讀/寫數(shù)據(jù)權限，查看某個時間段數(shù)據(jù)權限等等。為方便用戶設

置數(shù)據(jù)權限，數(shù)據(jù)權限采用和功能權限一致的控制方式，即權限

分配到用戶組（即角色）。一般情況下可經過功能權限控制用戶

對功能模塊的訪問。

3.8.4.2.3.服務器端證書

能夠使用服務器端數(shù)字證書方式，實現(xiàn)對來源方的認證。

3.8.4.2.4.系統(tǒng)審計跟蹤

系統(tǒng)實時記錄用戶操作日志，建立完備的審計跟蹤機制，便

于日常管理、故障處理和事后稽查。

用戶涉及到對信息數(shù)據(jù)的操作均要記錄審計日志，審計日志

記錄的需求如下：

1.系統(tǒng)重要操作（如更改口令等）必須自動記入審計日志，

審計日志應統(tǒng)一納入業(yè)務數(shù)據(jù)保存期限管理；

2.對于系統(tǒng)運行過程和異常情況，必須自動記錄審計日志；

3.對系統(tǒng)功能操作記錄操作時間、操作人所在IP、操作內容

4,對任務動作操作記錄發(fā)起人、發(fā)起時間、中間經辦人、經辦

文檔僅供參考

時間、任務狀態(tài)。

3.8.4.2.5.運行監(jiān)測

使用運維監(jiān)控系統(tǒng)提供的重要業(yè)務處理狀態(tài)的監(jiān)測功能，用

戶能夠查看業(yè)務的當前處理狀態(tài)，以便能夠及時發(fā)現(xiàn)異常業(yè)務，

并進行相應的處理。

3.8.4.2.6.信息過濾

只處理約定格式的文件，拒絕處理規(guī)定格式之外的任何文件

和信息，以杜絕某些節(jié)點產生的信息垃圾或不良行為，對這些信

息不做任何處理和響應。

在程序中應檢查經過人機接口輸入或經過通信接口接收的數(shù)

據(jù)格式或長度是否符合系統(tǒng)設定要求，防止惡意攻擊，過濾數(shù)據(jù)

中的危險代碼。

3.8.4.2.7.備份與恢復

提供專用備份服務器，提供自動備份調度程序，按照備份策

略自動備份到備份機磁盤介質上，備份策略如下：

備份備份類保留

類型備份內容備份周期

頻度型時間

數(shù)據(jù)庫系統(tǒng)主要每季度最后一

三個月全備份三個月

配置文件和參數(shù)天22：00

數(shù)據(jù)庫

數(shù)據(jù)庫中的所有

服務器B全備份一個月每日22；00

數(shù)據(jù)

數(shù)據(jù)庫