开发银行灾备系统建设的思考

合集下载

容灾备份体系建设方案

容灾备份体系建设方案
业务连续性管理(BCM)是一个灾难应急
的框架,涵盖:IT备份和恢复、业务连续性 规划、供应链管理、危机通讯和危机公关。
灾难恢复指标(RPO/RTO)
数据处于有 效状态的最 后时刻
RPO(Recovery Point Object ,恢复 点目标):是指业务 系统所允许的在灾难 过程中的最大数据丢 失量,用来衡量容灾 系统的数据冗余备份 能力
• 设计可行的灾难恢复流程并通 过测试和演练进行流程的不断 修订和完善;
• 设计和建设人员组织结 构,进行普及知识教育和 专门的技能和流程培训。
生产环境/运维现状调研 云基础架构风险评估 BIA 业务影响分析
灾备体系建设工作内容
灾难恢复策略制定 灾备方案总体架构设计 关键技术选型分析 软硬件配置
演练方案设计 演练前的技术测试 演练环境准备 演练培训 演练实施的组织 演练应急的组织与协调 演练总结报告
支持的业务功能从灾难造成的不正常状态恢复到可接受状态,而设计的活动和流程。

-- 摘自<GB/T 20988-2007 信息安全技术 系统灾难恢复规范 >3 术语与定义

正常水平


可接受的水平
时间
T1
T2
与灾备相关的概念:BCP、BCM
业务连续性规划(BCP):包括风险和业
务影响分析,定义灾难恢复策略和方案、流 程,明确所需的环境和资源,以及相应的容 灾团队建设。业务连续性规划是一套高级管 理和规章流程,使一个组织在突发性事件面 前能够迅速作出反应,以确保关键业务功能 可以持续,而不造成业务中断或业务流程本 质的改变。
初始化
分析
改进
灾备建设阶段
设计
运维
实施

银行核心业务系统的设计与开发

银行核心业务系统的设计与开发

银行核心业务系统的设计与开发银行核心业务系统是一家银行最基础、最重要的信息系统,直接关系到银行的稳定运营和发展。

它主要负责银行的账户管理、贷款管理、交易结算、风险管理等核心业务的管理和处理。

一般来说,银行核心业务系统的设计与开发需要满足以下几个方面的要求。

一、功能完备性银行核心业务系统的设计与开发需要满足各种业务需求。

它必须有完善的业务处理流程、业务处理逻辑和支持业务的各种功能,如开立账户、转账、存款、取款、理财、贷款、信用卡等处理功能。

其中,贷款业务是银行的重点业务之一,银行核心业务系统需要支持各类贷款的计算、审批、放款、还款、催收等一系列业务流程。

二、安全性银行核心业务系统的设计与开发需要满足高度的安全要求。

它需要具备多种安全措施,如权限控制、数据加密、安全日志、防病毒等措施,防范黑客攻击、数据泄露和信息安全等问题。

同时,银行核心业务系统还需要满足监管机构的严格要求,如密码安全标准、数据备份规定、可追溯性等。

三、稳定性银行核心业务系统的设计与开发需要满足稳定性要求。

它需要考虑各种可靠性问题,包括硬件、网络设备、数据库等方面的单点故障模式分析及备份策略、灾备策略等,确保在任何情况下银行核心业务系统都能够正常运行。

四、扩展性银行核心业务系统的设计与开发需要满足扩展性要求。

针对日益增长的业务以及用户需求,系统应具有良好的可扩展性,灵活地应对业务增长,能够快速地响应业务变化,并且还要支持跨平台、多终端、多渠道等方面的多样业务。

五、易用性银行核心业务系统的设计与开发需要满足易用性要求。

系统需要为银行工作人员提供易于操作和管理的用户界面,同时还需要支持快捷查询、定制化视图、智能分析等智能化服务,帮助员工高效地完成各种业务处理。

那么,如何开发出一套合理、可靠、实用的银行核心业务系统呢?一、明确需求银行核心业务系统的成功开发离不开需求的明确。

系统开发前需要对银行的各类业务、用户需求、监管规定、技术标准等进行详尽的调研分析,准确掌握需求,并根据需求制定合理的开发计划和实施方案。

容器云平台灾备建设方案

容器云平台灾备建设方案

容器云平台灾备建设方案目录容器云平台灾备建设方案 (1)一、建设背景 (3)二、需求分析 (3)三、技术路线选型及难点分析 (5)1、现有IT架构和业务架构的痛点 (5)2、容器云建设难点分析 (6)3、容器云技术路线选型 (6)4、厂商选型 (7)四、建设方案 (10)1、总体架构 (10)2、容器云平台灾备 (11)2.1 部署架构 (11)2.2 切换架构 (11)2.3 网络切换 (12)4、环境规划 (16)五、实施经验及效果 (16)1、实施经验总结 (16)2、实施效果 (17)3、建议实施落地原则 (18)1、IaaS云平台建设: (18)2、PaaS云平台建设: (19)3、云管理系统建设: (19)【简介】本文以中小银行数字化转型为背景,对中小银行传统应用迁移容器云平台的实践经验进行总结,探索出适合中小银行特有金融架构特征的容器云平台建设路线。

从业务需求出发,通过建设以容器云平台为基础的底层IT资源平台,为业务发展提供安全、稳定、可靠、灵活的支撑。

同时,本文也将针对容器云平台落地面临的容器灾备、容器云网络建设等问题进行选型和实践经验分享。

一、建设背景近年来,随着金融业务不断扩展,云计算技术在金融行业的发展已经经历过了第一代虚拟化、第二代资源池化,正在向以容器、微服务、DevOps为关键技术和特征的第三代云计算技术前进,以满足金融业新型业务对快速部署、弹性扩展、自动化运维等核心需求。

金融行业已经步入以容器为核心的第三代云计算技术的时代,目前国内大型金融机构虚拟化技术相对成熟,从国有五大行到区域银行都在积极向基础设施云推进,但中小银行相对缓慢,更多处于云平台的尝试使用阶段。

面对高并发、多频次、大流量的全新业务场景,银行业务系统的响应效率变的越发重要,同时金融业务的服务连续性要求也越来越高。

而我行原有的基础架构平台已不足以支撑银行当前的高速信息化建设及创新发展要求。

如何应对不断升级的互联网业务系统,紧跟大行科技信息化建设的步伐,建设具有中小银行特有金融架构特征的容器云平台变得尤为重要。

实现CMDB数据准确的思考与实践

实现CMDB数据准确的思考与实践

讨论环节问题
二、CMDB建设 1、IAAS和容器云强调自动化、一键式部署,IP信息、节点信 息自动发放,如何与CMDB联动。 2、网络SDN包括硬件SDN,Vmwar的NSX,容器中的flunnel、 calico,如果与CMDB联动。 3、应用DNS改造中,将使用域名代替IP进行应用间访问,如果 与CMDB联动。 4、CMDB的T+0建设问题,如果将信息录入准确。如果做到自 动识别、自动上报信息。 5、特例:新系统上线时,会一次性产生大量的配置信息,如 果有效的保障信息全部录入。
CMDB建设难点
CMDB建设难点: 1、逻辑信息与物理信息的对应 : 序列号操作系统不可见 2、逻辑信息与物理信息的口径: 机房数机器 3、四线的标签问题 网线: 网络交换机名称,端口,本机序列号、物理槽位+端口 光纤线: 内部连线:小机内部连接线 电源性: 搬家关机;电源松脱(卡子) 4、CMDB数据的变化 (1)新系统上线不断增加 (2)机器调整:物理上的位置、逻辑上的主机名、IP (3)机房搬迁
实现cmdb数据准确的思考与实践中信银行5月18日cmdb建设的背景互联网时代金融行业都在加速转型核心下移架构转型的步伐越来越快云计算大数据ai的广泛应用虚拟机的数量成倍增长容器等新运行模块不断出现传统以数机器方式建设的cmdb面临越来越大挑战
实现CMDB数据准确的思考与实践
中信银行 5月18日
CMDB建设的背景
物理信息、逻辑信息、应用信息、维保信息),IAAS云,容器云,
4、责任界定:CMDB中信息归属不同的组织,包括机房保障组、 定,如何分工合作。 mogodb,性能等问题如何解决。
系统保障组、应用保障组,T+0阶段,T+N阶段,如何进行责任界

交通银行两地三中心改造

交通银行两地三中心改造

交通银行、两地三中心、灾难备份交通银行在“两地三中心”建设中进行了两次大规模的真实灾备系统切换运行,实现了大型机和开放平台数据库系统的同城双活运行,在同业中产生了重要影响,推动了行业技术进步和发展。

商业银行信息系统的安全、稳定运行关系着国家金融安全和社会稳定,如何保障IT 系统具有高可用性和防范各种风险和灾难的能力至关重要。

为此,监管机构十分重视商业银行的灾难备份体系建设,多次发布了商业银行信息系统灾难备份的相关标准和指引,对商业银行灾备系统建设提出了明确的要求。

为了防范灾难和风险,国内商业银行相继建立了同城和异地灾备中心,“两地三中心”已经逐步成为商业银行广泛采纳的灾备建设模式。

交通银行2006 年完成了数据大集中,在上海张江建立了数据中心,于2007 年将海外分行系统从香港迁移到张江数据中心运行,实现了境内外一体化的数据中心运行。

为保障业务连续性,交通银行于2007 年在上海浦西漕河泾建立了同城备份中心,2008 年在武汉建立了异地灾备中心,形成了“两地三中心”的灾难备份体系。

在灾备建设过程中,交通银行针对上述问题进行了深入的探索和实践,通过自主创新,建立了完善的灾难备份体系,交出了一份满意的答卷。

一、交通银行“两地三中心”建设规划为了指导灾备体系建设,交通银行制定了“两地三中心”的发展规划,确定了灾备体系建设“统筹规划、分步实施;控制成本、保障有效;面向业务、分级灾备;平战结合、资源共享”的十六字指导方针。

首先对“两地三中心”建设的目标、灾备等级,技术路线等进行总体规划;在灾备的建设顺序上,采取“先同城、后异地”的策略。

其次,在保障灾备系统有效性的基础上,采取各种技术和管理手段,尽可能降低灾备系统的投资成本。

再次,对业务系统进行分级,根据业务的重要性程度,确定业务的RPO 和RTO 目标,采用不同的灾备模式,达到不同的灾备等级,关键的业务实现双活运行,重要业务实现系统级灾备,其他业务实现数据级灾备。

灾备服务中心能赢利吗?

灾备服务中心能赢利吗?

灾备服务中心能赢利吗?中国电信有一个大动作值得关注。

这个大动作,就是中国电信在四川成都建立了一个大型灾难备份服务中心,更重要的是,它不是中国电信内部的灾备服务系统,而是面向社会提供灾备相关服务的一个“公共机构”。

据悉,中国电信灾备中心将提供包括基础设施服务、网络系统服务、数据存储服务、数据处理服务、灾备演练与恢复服务、咨询服务和增值服务等在内的灾难备份整体解决方案及服务。

这是国内电信运营商中第一个建成的灾难备份服务中心和样本灾备机房。

实际上,在中国电信的灾备中心揭牌之前,国内已经有一些面向企业及社会机构服务的灾备中心,基本上是企业投资建设的,例如IBM就是灾备中心的一个积极拥趸者。

2003年的时候,IBM曾与当地一些机构合作,在上海建立了一个面对企业服务的灾备中心。

今年5月,又与中金数据在北京亦庄开发区投资建设一个面向社会服务的高等级灾备中心。

再如HP也非常看好灾备服务市场,虽然目前还没有看到在其国内建立独立运营的灾备中心,但是在提供灾备的咨询服务方面,早在几年前就显露了积极的态度。

从中可以看到,一些具有综合咨询服务能力的企业对于灾备服务的前景是非常看好的。

但是,从IBM上海灾备中心近几年的运营状况来看,并不是非常理想。

IBM大中华区业务连续和灾难恢复服务经理赵庆认为,这种情况“应该说是比较正常的,因为即便是在欧洲,灾难恢复也只是一项发展中的业务,目前在国内的发展只能说是初级阶段。

”不过,中国电信选择在这个时候切入,一定有它自己的观察。

从目前的市场进展状况看,灾备服务的确是个值得投资的“潜力股”。

一方面,是越来越多大中型企业已经对灾备有了进一步的认识; 另外一方面,政府主管部门也在积极推进有关重要信息系统恢复的指南编写和灾难恢复国家标准的制定,这对市场有着相当大的推动力。

例如,国务院信息化工作办公室在2005年已经发布了《重要信息系统灾难恢复指南》,今年即将出台国家标准。

就像当年电信运营商的介入使IDC(Internet Data Center互联网数据中心)成为一个独立市场一样,也许这一次中国电信的大动作也意味着社会性的灾备服务中心将能够逐渐成为一个独立业务。

全力保障系统安全稳定运行

全力保障系统安全稳定运行
刘玉成 : “ 十二五”是邮储银行成立 以来 的第 一个 五年规 ̄ B 期 ,是实现全 Jt J
面转型的关键时期 。 “ 十二五 ”期间 ,邮储银 行将努力把国内外先进的银行
面最 广 、联 网网点数 量最 多的金融计算机网 络 系统 ,仅储蓄系统每天就承载着4 0 多万 00 笔 、金额高达近千亿元 的存取款交易 。可以 说 ,金融信 息系统 的平稳运行 ,直接关系到 邮储银行各项金融业 务的正常运转 ,关系到
谐 。作 为技 术支 持 部 门 ,在 邮储 银 行信 息 化 委员会 、邮
提高了邮政金融计算机系统安全运行水平 ,运行质量大
政集团公司金融信息化领导小组及工作组的领导下,邮 幅提高 ,成绩显著 。特别在整个 “ 十一五”期间,跨行 储银行科技发展部大力提高系统运维质量 ,做到客户满 交易成功率 由 “ 十一五 ”之前的倒数跃进到前3 位后 , 意 、用户放心 ,支撑银行业务的快速发展 ,全力推进邮 并始终在l 家全国性商业银行中保持排名前3 5 ,创造了 储银行改革转型。

中国 银行 业 的一 个奇 迹 。2 1年 ,邮 储银 行运 行 质 量尤 00

邮f 诠 融信息化 “ 游 十一五”期间主要成果
其令人振奋 ,系统各项考核指标均有大幅提高 ,跨行交 易成功率高达9 . %,自6 97 0 月起 ,已经连续6 个月在l家 5
邮 储 银 行 “ 一 五 ”期 问 坚 持 执 行 国家 “ 务 三 商业银行中排名第一 。邮储银行金融信息系统的高质量 十 服
地震期间,灾备系统经受了考验 ,尤其是汶川大地震之
后,邮储银行是第一个恢复银行业 务的金融机 构,灾备 金 融企 业要 求 的信 息科 技 队伍 ,不断 满 足 邮储 银行 }速 央

浦发银行“两地三中心”实践

浦发银行“两地三中心”实践

信息科技总部是全行信息化职能部 门,负责全行的
同城 、大异地”的异地应用级灾备模式 。上海生产 中心 科技治理 、信息系统开发 、信息系统运行 、信息资产管 配置完整 的接入链路 、应用处理平 台和存储平 台;上海 理 、信息安全管理和信息服务管理等相关工作。信 息科
2 0 1 3 8 / 中 国 金 融 电 脑 2 7
重点 。
月,首次分行核心大前置系统灾难恢复演练标志着浦发 银行灾难恢复管理能力从总行向分行的跨越。 经 过近几年 的不 懈努力 ,浦发银行 在灾难恢复体
系建设方面取得 了长足的进步 , “ 两 地 i 中心 ”整 体
在灾备建设技术方面 ,浦发银行在 “ 两地三 中心” 架构 中采用了非对 称环形 S A N 网、存储 异步复制数据
浦发银行两地三中心实践上海浦东发展银行股份有限公司信息科技总部副总经理奚力铭上海浦东发展银行股份有限公司信息科技总部灾备中心总经理助理王晖为全面落实监管部门对商业银行信息系统灾难恢复管同城灾备中心距离生产中心约17千米只配置关键系理的要求满足业务稳健快速发展需要浦发银行近年来统的存储平台提供部分重要系统数据级灾难恢复能力
专 题l
灾备 中 .合 犯异地灾 备中心组成 的 “ 两地三 中
灞瑟银行近年来不断 柳大信息系统灰备建设力褒 . . . 建疑了由 上 海生产中心 一 ~ 海同城 容灾体 系 t穆打造共 务核心竞 争优势
的现代化金融服务企她葵定了坚实的信息科技风险防范基础
漓发银行
地三中心 实践
规 范 各级 灾 难恢 复 组织 的职 责 和要 求 之外 ,还 定多种 演练 方 式 来检 验 和强化 人 员 的应急 响应 能 力 .
3 . 灾备 系统建设
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

I I I 墨
随 着 灾 备 建 设 的 逐 步 完 善 和 每 年 的
根据开发 银行 的业务连续性总 为主的数据中心和灾备体系。
演练 ,特 别是桌面演练 、流程演练 体 规 划要 求 ,采 用两 地 三 中 心架 构
开发银行 已经开展 了北京稻 香
北 湖新生产 中心 、北京怀柔同城 灾备 等多项工 作的开 展和深入 ,开发银 建设生产 中心 、同城 灾备中心 ( 深圳观 中心和西安’ 7 产灞异地数据 中心的规 行 更加深刻地感 受到只有所有 相关 京亦庄 )和异地灾备中心 (
砚 IVe p i l iw on t
立 异 地 灾 备 中心 ,灾难 恢 复 等 级 达 到 《 息 安 全 技 术 信 息 系 统 灾 难 恢 信
和 应 用 局 限 性 。 目前 应 用 比较 多 的 的技 术包 括 以 下几 大 类 。 ( ) 于存 储 的复 制技 术 1 基
建 设提供 了多种可选 的容 灾技术 ,
每 种 容 灾 技 术 都 有 自身 的技 术 表等管 业 务条 线 的有 效 业 务恢 复 预 案和
理类 系统 ,支撑 银行 内部的 1常运 相 应 的演 练 验 证 体 系也 同样 重要 。 3
22 / 国 融 脑 0 中 金 电 29 14
行 。该 类 系 统 经 过 近 几 年 的 建 设 和 完 善 ,在 同城 灾 备 中心 已经 完 成 部
复 规范 》中的第5 实时数 据传输 级 及 完整 设备支持 。业务 的发展和监
署 ,部分关键 系统还将考虑进行异
国内常见 的容灾解决方 案 ,由 地灾备部 署。第三类 ( 非实 时 ):
银 行提供 数据 与 系统 的灾备服 务 , 此 ( 时 ,客 户服 务 )涉 及 账 户 、交 成系统的恢复和业务的恢复。 实 易 、支 付 和 渠 道 的 重要 系 统 ,也 称
模式也能达到一定可靠性 ,投入小 、
灾难 情况下 ,I 的恢复 固然是 T
T 周期快 ,对银行人员能力要求相对较 银行核心 系统 ,为客户直接提供 服 非 常 重 要 的基 础 ,但 I 恢 复 以后 , 低 ,适 用 于 中小型 金融机构 。 务 。 开 发 银 行 2 0 年 就 已实 现 同 城 业 务 数 据 的 完 整 性 检 查 和 交 易 补 07 和 异 地 的 灾 备 建 设 ,每 年 灾 备演 练 入 、相 关 公 关 部 门的 有 效 沟 通 和 协
( ) 于 主机 的 复制 技术 2 基
通过安装在服 务器的数据复制 系建立. 9】 之后 的业 务连续性管  ̄ .1 J l
软 件 ,实现 异 地 数 据 复 制 。该 技 术 理 的 提 出 和 发 展 。2 l 年 银 监 发 0 1
没有所 谓最好 的灾备 系统 ,只有最 的优 点在 于 成 本 相 对 较 低 且 能 兼 容 符合 自身需要的灾备系统 。
出了严格和 具体 的要求 。经过 多年 的建设和发展 ,开发银行也深刻感
受 到 灾 备 系 统 的 建 设 只 是 提 供 了 技 术 的 保 障 ,能 否 取 得 预 期 的 效 果 和
系建设 时一 般有 自建和外包两种模
式 ,各有优缺 点。 自建是指银行独 是数据库指令或者 重作 1 3志文件 。
划 :除了要 考虑技术实现外 ,还 要 U l 较小 ,缺点是必须在本地端和灾 l;  ̄L , 考虑各类业 务的不同需要 ;除 了考 备端分别配置两套相同的存储系统 。 虑资源投入外 ,还 要考虑产 出和利 用 ;除 了考虑 通用的灾备模式 ,还 要 考虑 自身的情况和 能力。总之 ,
2 灾备技术选 择 .
计 算 机 和 通 信 技 术 的 发 展 ,特
都会 以核心系统作为主要 的演练 内 调 、监管机构的报告和指导 、行领
导 的 决 策 和 组 织 、各 个 业 务 部 门和
别 是 存 储 技 术 的发 展 ,为 灾 备 系 统 容 。第二类 ( 准实 时 ,员工服 务 )
二 、灾 备 系统 建 设 思路
复 制 到 远 端 。 其 优 点 是 将 数 据 与 应
4 业 务连 续 性 是 灾 备建 设 的 .
关键 灾难 备份和业 务连续性 的发展 自2 世纪7 年代开始 ,经历 了I 系 0 0 T 统的灾备和恢复 、业务恢复预案体
如 何 建 设 灾 备 系 统 需 要 周 密 规 用 分 开 ,对 主 机 系 统 的 运 行 资 源 影
立建设数据 中心 ,此模式具有较高 该技术与存储类型和服 务器平 台无 保障业务的恢复 ,关键是业务连续 的可 靠性与安全性 ,但投 入大 、周 关 ,具有较好的使用灵活性 。 期长 ,对银行技术 人员的能力要 求
较 高 ,适 用 于 大 型 金 融机 构 。外 包
性 计划 ,需要领 导的高度重视 、相
关 业 务 部 门 的 积 极 参 与 和 掌握 ,要
3 根据系统 分类选择灾备 部署 .
银 行 应 用 系 统 根 据 其 处 理 的 业
保障在灾难情况下 ,各个方面能各
是指 由专业服务商在其数据中心内为 务种 类 可 分 成 以下 几 类 。第一 类 司 其 职 、有效 组 织 、高 效 协 同 地 完
管 ,都要求必 须建立起完善的灾备 存储厂家提供技术 实现生产 中心存 培训 、档案 、 稽核 、分析等系统,大 体系和业务连续性保障体系。 储设备与灾备 中心存储 设备的直接 部分 已实现数据级备份 ,未来将考虑
镜 像 ,将 数 据 以 同步 或 异 步 的方 式 对其 中的关键系统进 行系统 备份 。
【0 号 《 14】 商业银行业务连续性监
不 同厂 家的存储 设备 ,缺点是会 占 管指 引 》也对 于银行业 务连续性提
用 主机 的资 源 。 ( ) 于 数据 库 的复 制 技术 3 基 基 于 数 据 库 的 容 灾 技 术 传 输 的
1 建设 模式选择 .
目前 , 国 内银 行 在 进 行 灾 备 体
相关文档
最新文档