当前位置:首页>>新闻 > 观点 > >牢握风险防范的核心命题【中国银联信息总中心副总经理 施跃跃 】

牢握风险防范的核心命题【中国银联信息总中心副总经理 施跃跃 】


文 \ 中国银联信息总中心副总经理 施跃跃 


银行业数据中心无论是在传统的集中式系统架构阶段,还是在逐步向云计算、大数据、分布式技术架构转型的当前阶段,运行风险防范始终是必须牢牢把握的核心命题。衡量数据中心风险防范能力,则要衡量其技术架构是否安全可靠、管理防线是否严密可控。基于银联的多年实践,笔者对于风险防范部分技术和机制进行简要综述,与同行探讨。

 

 
 

系统架构设计

 
 

 

自银联一代新系统建设开始,在二代系统建设中延续发扬,到目前云计算架构阶段,银联应用系统在架构规划、设计、开发、测试、运营、持续优化的全生命周期里均严格遵循“高可用、高性能、高可扩展、高安全、高可管理”这“五高”要求和标准。核心联机系统可用性超过99.999%。

 

图 灾备模

 

1.核心架构高可用。目前银联核心联机系统已实现本地双中心双活、异地辅中心热备的主辅架构。在一个中心的系统内部,从底层基础架构到应用节点、子系统、模块、服务、进程做到全冗余和自动故障隔离,主要包括以下技术。

 

双中心通信接入:在异地两个中心部署轻量级的通信接入层,成员机构通过双线路连接接入位于异地双中心的通信接入层,由通信接入层模块判断业务的处理中心,当核心业务系统发生本地乃至异地切换时,可以做到对外部接入系统透明和无感知。

 

应用级的数据转移:实现交易的实时数据同步,以此完成数据库切换或者应用中心切换的数据同步,从而规避存储级和数据库级数据复制的一些技术限制。另外还设立了数据完整性检查功能,在主备库切换或中心级切换的情况下实现自动数据完整性检查。

 

业务级健康检查:与联机业务配套建立健康检查系统,通过模拟业务实现业务级、应用级的健康探测,以全业务链路角度、多层次探测机制,快速发现系统中任一应用服务、节点、数据库等故障,并通过既定的规则实现自动故障定位以及高可用切换。

 

多层级的高可用:从硬件层、应用层、数据库层、本地中心层、跨中心层五个层面设计高可用机制,从环境、安全、系统、网络到应用系统,各层级无单点,切换全自动化,分层实现,最小范围隔离故障点。从硬件层的设备板卡故障切换 1~20秒,到最复杂的中心级异地切换 100秒,形成了一个金字塔型的高可用切换时间模型。

 

2.自主可控云计算架构。银联自 2009年开始对国内外云计算发展趋势进行前瞻性研究,2011年通过国家云计算示范工程项目,启动了具有银联特色的云计算平台建设。现相关成果已全面转化应用,基本完成了银联私有云基础配套体系主体部分的建设,目前有 200多个业务系统部署在云计算平台。银联云架构在高可用、弹性扩展、大规模部署、故障自愈、自助化等方面进行强化设计并不断完善。

 

考虑云平台单节点的低可靠性,对应用、存储、服务器、集群交换网络等方面进行的高可用部署,实现任一单点故障对应用无影响。支持大规模区域化部署,通过数据库主主半同步、软负载均衡方式实现平台自身的高可用设计;平台提供物理机宕机故障迁移及虚拟机宕机故障自愈,快速实现应用故障的隔离与恢复;网络层面通过大二层虚拟化堆叠方式实现 IP的快速切换。业务应用设计实现可横向弹性扩展及无状态化,并能根据业务类型进行业务降级及限流设置,在面向互联网、营销等业务突发增长时可以快速进行扩容或限流应对。

 

优化和强化运营支撑平台,提升标准化、自动化、自助化、可视化程度,应对云计算带来的大规模运维工作量,通过场景化方式固化运维操作,避免人工操作错误,提升工作效率,快速响应部署需求。

 

在新技术和开源软件的运用上,按照“概念(提出技术概念,了解业界状况)→评估(对技术进行评估、测试、验证)→试用(在测试环境、非核心生产环境进行试用)→成熟(逐步推广运用至核心生产系统) ”的路径进行,稳妥处理新老技术的过渡及并行。

 

3.灾备架构。由于银联的业务特性要求 IT系统提供 7 x24小时不间断的服务 ,银联始终按照最高标准进行灾备架构的设计和实施,并不断优化。从发展历程看,银联自成立就积极设计并实现了异地灾备,成为较早落地两地三中心 IT架构的企业,目前已经实现了两中心双活的分布式架构。通过多年的灾备建设,目前已形成一套灾备架构标准模式,针对不同的业务系统的RTO、RPO要求,应用不同的灾备架构。

 

为了尽可能减少灾难引发的系统不可用时间,银联自研了“容灾管理平台”,实现了按照预先设定的判断逻辑,自动执行相应的灾备切换固定流程,减少人工干预。

 

 
 

运营管理与规范

 
 

 

基于ITIL、ISO20000的运营管理体系和流程,以及 ISO27001的信息安全管理体系,已广泛被金融业数据中心运用和落地。变更、事件、问题等管理机制已逐步成熟,同时也有一些领域还需要不断探索和积累。如通过制定和落实运营技术规范,从细节上防控风险;应对互联网快速发展和大规模营销活动,容量管理的重要性尤为突出;应急管理需要通过常态化的演练得以落实。

 

1.运营技术规范。通过回顾运营故障事件,总是会发现问题往往出现在一些细节的人为失误上,如某个参数设置有误、某个监控项有遗漏、某项检查未落实等。因此有必要将日常运营过程的具体技术要求和参数配置形成一套须严格遵循的标准和规范,涵盖应用、系统、网络、安全、环境各方面,运用在系统开发、测试、部署、变更、监控等过程中,进而采用自动化手段完成配置和检查,实现整个技术架构的稳定可控,有效规避人员操作风险。

 

通过剖析应用和基础架构全环节所涉及的高可用点,对高可用配置要求进行提炼和总结,形成高可用规范。通过监控规范,将各层级需要的监控指标、阈值、标准进行明确;制定上下线规范,将系统上线、上下线过程中的每个技术点进行标准化并定义完整的输入输出,防止造成技术上的遗漏而导致带问题上线。通过基本运营需求,提出保障业务应用运行所必备的高可用、性能、可靠性、安全性、管理性等非功能需求,开发方在实现业务功能的同时实现运营方面要求。

 

2.容量管理。制定容量管理机制,对上线前测试阶段、运营阶段、重大活动及节假日、营销日、以及日常容量管理活动进行规范;通过业务场景关联技术架构指标,建立容量模型,日常进行性能容量的预测分析与评估,保障业务高峰期的运行稳定。

 

针对大规模营销活动,根据活动内容、力度、规模,评估业务系统的影响和业务峰值预测情况,结合容量模型配套进行资源配备,对计算资源、节点数量、数据库资源、存储空间等方面进行评估和扩容工作,通过活动后回顾机制对容量模型进行优化完善。

 

通过管理工具实现容量建模,采用数据拟合算法,结合业务量进行容量趋势预测,配套建立故障容量模型,在部分节点故障、中心切换的情况下,启动容量配置预案。容量模型与业务数据、监控系统、配置管理、性能测试、生产关键参数取值等动态相关,与变更等流程活动密切相关。对运营数据进行合理的加工、整合,丰富数据挖掘和智能化分析模型,通过容量驱动,实现自动化资源伸缩,是容量管理的目标。

 

3.应急管理机制。依据国务院印发的《国家金融突发事件应急预案》、人民银行的《信息安全技术 信息系统灾难恢复规范》(GB/T 20988-2007)、《银行业金融机构信息系统风险管理指引》等政策、标准、规定,配套建立应急管理机制。

 

应急演练常态化,每年实战演练 500余次,跨中心演练数十次,大部分演练由一线值班人员自行按手册完成。通过演练发现系统的高可用问题、手册问题,提高值班人员应急技能。通过演练平台化,案例相关问题和信息可以得到记录并反复使用,自动收集事件、变更、工单等信息,自动发出演练报告。

 

应急预案平台化,实现手册全局搜索和统一修订,可将事件告警与预案故障现象相结合、手册与配置项相结合、操作步骤与自动化任务相结合,从而实现应急预案智能推送、应急步骤自动执行。

 

预定义应急通知报告策略,根据不同的故障业务影响性规定时限及范围,应急平台进行自动化的短信及电话通知,平台自动判断故障升级时间并进行提醒。

 

推行双中心一体化运营方案,两中心使用同一流程以及同一流程管理平台,值班岗位互备,拥有对方系统的账号登录权限。灾备切换演练以及重大变更时两中心共同实施,相互配合,实现双中心有效联动,保证业务连续。

  分享到:
360网站安全检测平台