DockOne微信分享(七十四):传统金融 IT 对混合云管理的一些思考

本文讲的是DockOne微信分享(七十四):传统金融 IT 对混合云管理的一些思考【编者的话】在新常态经济背景下,金融脱媒加剧,跨界融合和互联网金融的发展加速传统金融企业变革转型。传统金融 IT 需要积极面对以互联网、云计算、大数据为代表的新技术带来的机遇与挑战,主动进行架构转型。本次交流分享在落实企业云计算规划工作中的一些思考。

一、 传统金融 IT 的行业特点

受行业特点所限,传统金融 IT 需要接受银监会的多项监管要求,重要的包括:

  • 在《商业银行信息科技风险管理指引》的推动下,建设信息科技管理(由 IT部门负责)、风险管理(由风控部门负责)、审计(由审计部门负责)“三道防线”体系。
  • 在《商业银行数据中心监管指引》的推动下,建设生产数据中心和灾备数据中心,后续有演进为“2地 3 中心”架构。
  • 在《商业银行业务连续性监管指引》的推动下,建设业务连续性管理组织体系。
  • 在《商业银行信息科技外包监管指引》、《银行业金融机构信息科技外包风险监管指引》的推动下,建设外包管理体系。

以下以一个概览图来小结:

业务连续性:保证信息系统稳定、持续地提供服务,通俗地讲就是系统“不能断”。安全性:保证数据的保密性、完整性、可用性,通俗地讲就是数据“不能丢”。

二、传统金融 IT 的转型背景

经济步入新常态背景下,中国发展仍处于重要战略机遇期,也面临诸多矛盾叠加、风险隐患增多的挑战,银行业经营环境更加复杂。另外,金融脱媒加剧,跨界融合和互联网金融的发展加速传统金融企业变革转型。传统金融 IT 作为金融机构的核心竞争力,需要积极面对以互联网、云计算、大数据为代表的新技术带来的机遇与挑战,主动在包括在数据治理、系统架构、风险管控、基础设施建设、系统开发、运行维护等领域进行架构转型。传统金融 IT 转型的主要领域之一是云计算。在 2014 年 9月的《关于应用安全可控信息技术加强银行业网络安全和信息化建设的指导意见》的影响下,传统金融 IT 普遍启动了自主可控和小机向 X86 服务器、云平台调研等转型工作。最近在 2016 年 7 月的《中国银行业信息科技“十三五”发展规划监管指导意见(征求意见稿)》中,提出在“十三五”末期,面向互联网场景的主要信息系统尽可能迁移至云计算架构平台的目标,这更加坚定了传统金融 IT 向云计算的转型信心,也利于全员对云计算达成共识和加速推动云计算的相关工作。

三、传统金融 IT 混合云管理面临的问题

传统金融 IT 在银监会的监管要求下,形成了信息科技管理、开发、数据中心管理(含运维)等专业部门的职责分工,各部门专业性建设,各自配置对应的专业管理团队和专业人员的管理体系。这个管理体系下的规章的制定、人的考核和流程的设计是倾向于稳态和安全,从而在向云计算转型的道路上需要面对很多的问题,问题解决难度的挑战性也较强。

例如存在以下的较普遍问题:

  • 对云计算的共识不一。传统金融 IT 因为专业分工的特点,员工普遍存在知识广度不足的现象。另外,云计算技术的演进速度很快,外界解读不一,造成人员对云计算的理解不一致,难以全员达成共识形成合力。
  • 管理体系刚性强。传统金融 IT 的管理体系中,研发管理采用 CMMI、运维管理采用 ITIL,人工控制节点、流程合规性和安全审计等刚性需求较强,而敏捷管理、自动化程度略有不足。管理口径是对所有业务应用系统统一管理,粒度较粗,这种方式对 Top n高风险系统是合适的,但是对面向互联网业务场景的业务系 统就存在对业务部门的 IT 交付慢等问题。因此,管理体系的强刚性,造成了应用上云要触及变革的问题较多,解决的难度也较大。
  • 存在部门墙。同样是因为专业分工的原因,传统金融 IT 存在较为严重的部门墙现象,包括人工协作流程复杂、管理信息资产流动不足、规范落实难、计量统计口径不一致等问题。
  • 监管要求的技术条例滞后。传统金融 IT 受到的监管要求中,其中涉及的技术条例是针对传统技术。云计算的技术特征和引起的业务应用架构的变革的特征尚未修订到监管要求中,略显滞后。

四、传统金融 IT 对混合云管理的一些思考

向云计算转型的工作思路是开展云计算架构规划,制定云计算标准,探索构建私有云平台,建立银行业金融公共服务行业云,同步开展应用架构规划,重构出与云计算基础设施相适应的应用架构,从而构建私有云与行业云相结合的混合云应用。在转型道路上,如何走得稳和准,个人思考有以下几点可以分享:

  • 目标:定位建设混合云平台根据监管要求,细分出对安全、SLA的要求不同的非关键应用和高风险关键应用,将非关键应用部署到公有云上,高风险关键应用部署在自建数据中心的私有云,与公有云资源形成混合云。
  • 战略:明确 IT 转型路径,持续保障投入要结合到企业战略,匹配到业务转型目标,明确 IT 转型路径,接地气地逐项落实。从 CIO 高层到中层骨干到各职能岗位员工,能够对转型路径达成共识,保障人、财、物的持续投入。
  • 组织:建设立体式的云平台团队和采购传统技术产品的模式不同,云计算的技术繁杂、演进程度不一,传统金融 IT 要确保转型道路走得稳和准,不走错技术路线。所以云平台的建设策略是要自主可控,团队的 建设是要立体化,从架构规划、技术跟踪和调研、产品试用和POC 测试、招标和项目实施等领域有专人或专门角色负责。
  • 实施策略:架构规划先行,以点带面结合业务目标,在架构规划过程中,找到有突破点代表意义的项目,充分论证技术方案,成熟一个实施一个。以项目为点,逐个解决在实施过程中发现管理体系中暴露的问题,摊平流程,培育人员,达到以点带面的效果。快速分步小走,复杂项目按分期进行实施,在迭代中演进云平台的建设。
  • 混合云管理平台建设策略:迭代演进,分期实施作为传统金融混合云的基础设施,混合云管理平台承担了和现有管理体系“双轨”演进的角色,既有部分功能是双方融合对接,也有部分功能是独立发展,整体建设目标是消融部门墙,提升给 IT 交付业务的速度和质量。典型的混合云管理平台的架构图如下所示:

Q&A

Q:传统金融行业很多关键系统架构比较简单都为集中式架构,不好做横向扩展,不适合放到私有云上,这个问题有什么好的解决思路?

A:从数据面和业务场景来细分,关键系统涉及客户资料、资金动账系统,仍然保留在传统集中式的主机平台,但是会将查询类交易下移到基于 X86 的私有云上。

Q:混合云如何解决多租户服务与金融行业监管要求物理隔离之间的矛盾?

A:金融行业监管要求物理隔离在数据中心网络层面表现为“2 网分离”:办公网和业务网。 相对应的,混合云的多租户也细分出开发云、测试云和生产云租户。各租户的资源和操作严格进行隔离

Q:您认为迁移到云的步骤应该如何,哪些适合迁移到云

A:在实践中,先理清应用的家底。根据业务场景需要和云的能力、团队的技能成长、监管底线(上公有云的话)等维度进行评估,选择上云的应用。迁移步骤具体看是否要重构应用架构,相应迁移难度不一。

Q:哪些业务适合使用云服务?云架构与传统架构肯定存在一个并行期,两套架构如何融合并存?

A:在私有云,云服务不是像公有云服务一样完备,建设是有个过程,所以前期内部管理类、和客户交互的渠道类业务适用上云。

Q:云架构与传统架构肯定存在一个并行期,两套架构如何融合并存?

A:的确存在并行期,架构职能团队可以发挥较大作用,一个作用是架构管理团队各片区和开发团队设计角色管理好各产品的应用架构,另外一个作用组织人手开展云架构的设计、原型开发,引导产品的架构进行演进。

Q:你指的混合云是以 Oracle、IBM、VMware 主导的商业软件公司提供的平台比如 O 记的数据库混合云,还是以开源软件为主的比如 OpenStack、KVM,上面跑基于开源的 Tomcat、MySQL ?

A:我们理解的混合云是更广义,包括公有云和私有云领域,公有云例如 AWS、AZURE、阿里云等,私有云例如 vCloud、青云等。

Q:传统金融的现有商业软件如何与开源平台结合?

A:以选择云平台的技术栈建设云服务,现有商业软件不是强求结合,结合成本太高或技术架构不合适就该舍弃。例如小机 WEB 应用上云,就会从 Was 换成轻量级的WEB 应用服务器,例如 Tomcat、JBoss。

Q:传统金融的 IT 运维能否自己支撑开源平台构建自己的混合云,从你的视角看中小型城市商行依靠自己的 it运维构建自己的混合云当前阶段是否切实可行?

A:这要看单位的大背景,如果业务部门没有传导市场压力到 IT 部门,那么面对 IT 开发团队,由 IT 运维主导建设基于开源的混合云平台作为起点,也是一种可行的选择。我们的大背景是业务压力的传导,以及自我变革的高层压力,所以是由架构职能团队牵头规划设计,新建的云平台团队实施落地。

Q:请问在云化的过程中,是已自行研发开源技术为主呢,还是使用较为成熟的商用软件为主。如何平衡成本与效率的关系

A:贴近应用的部分建议自研,例如开发框架、公共组件。基础设施部分需要稳定为主,例如虚拟化平台、对象存储服务、消息队列服务等,一般选择商用软件或开源软件企业版,有些加客户化定制。

Q:如果是混合云的架构话不是应当考虑公有云和私有云一致性吗?,而刚才说的结合就变成了一种简单的去IOE,客户总不能生产跑 Was,公有云跑 Tomcat 吧,如果这样推动混合云那么是不是意味着先就要推动去 IOE,改造应用?

A:这个问题可以细分 2 种层次来看,混合云架构设计对基础设施(VM、容器、镜像、网络等)是要进行抽象,达成这个层次上看私有云和公有云是一致 的。 另外混合云架构设计上,管理的另一个高阶层次是对应用架构的抽象,理想能够做到应用在不同云上进行无痛迁移。传统上在 IOE 上的业务系统,如果有开发框架的支持,且框架的架构做的好,则开发框架改造上云后,应用代码改造量很少。

以上内容根据2016年8月4日晚微信群分享内容整理。分享人罗文江,某传统金融IT架构师,关注和IaaS、Docker和云管理关联的技术。 DockOne每周都会组织定向的技术分享,欢迎感兴趣的同学加微信:liyingjiesz,进群参与,您有想听的话题或者想分享的话题都可以给我们留言。

原文发布时间为:2016-08-08

本文作者:罗文江

原文标题:DockOne微信分享(七十四):传统金融 IT 对混合云管理的一些思考

时间: 2024-10-22 09:14:56

DockOne微信分享(七十四):传统金融 IT 对混合云管理的一些思考的相关文章

DockOne微信分享( 八十九):恒生金融交易系统的Docker化实践

本文讲的是DockOne微信分享( 八十九):恒生金融交易系统的Docker化实践[编者的话]Docker可以显著改善企业软件研发流程.提升企业DevOps效率.借助Docker,企业可以对现有IT系统进行一次梳理,解决IT软件系统部署.升级难的顽疾,重新释放企业生产力,降低企业成本.本次分享介绍了恒生电子运用Docker技术,加上自研配套工具,实现金融交易系统配置.部署.运维自动化的心得,包括: Docker的优势以及我们为什么要使用Docker: 恒生Docker运用现状: 恒生金融交易系统

DockOne微信分享(一四二):容器云在万达的落地经验

本文讲的是DockOne微信分享(一四二):容器云在万达的落地经验[编者的话]容器生态是现在非常火热的技术生态之一,个人认为它主要囊括着四个方面的技术栈:一是容器核心技术栈(包括 Docker.rkt 及第三方公司自主研发的容器 Engine 等):二是容器基础技术栈(包括容器网络.存储.安全及服务发现等):三是容器编排技术栈(包括 Mesos/Marathon.Swarm.Kubernetes 及 OpenShift 等):四是容器应用技术栈(主要包括 CI/CD.监控.日志及微服务框架等).

DockOne微信分享(一二四):轻松筹监控系统实现方案

本文讲的是DockOne微信分享(一二四):轻松筹监控系统实现方案[编者的话]监控系统是服务管理最重要的组成部分之一,可以帮助开发人员更好的了解服务的运行状况,及时发现异常情况.虽然阿里提供收费的业务监控服务,但是监控有很多开源的解决方案,可以尝试自建监控系统,满足基本的监控需求,以后逐步完善优化.这样既可以更灵活的满足自身业务的监控需求,也可以为以后自建机房提供技术积累.通过以下7个方面来建设监控系统. [3 天烧脑式 Docker 训练营 | 上海站]随着Docker技术被越来越多的人所认可

DockOne微信分享(一四零):Serverless云函数架构精解

本文讲的是DockOne微信分享(一四零):Serverless云函数架构精解[编者的话]继虚拟机,容器技术之后,无服务器化成为新的行业热点,无服务器云函数可以让用户无需关心服务器的部署运营,只需开发最核心的业务逻辑,即可实现上线运营,具备分布容灾能力,可依据负载自动扩缩容,按照实际调用次数与时长计费.本次主要分享腾讯云无服务器云函数在技术实现上的挑战及架构实现原理. [烧脑式Kubernetes实战训练营]本次培训理论结合实践,主要包括:Kubernetes架构和资源调度原理.Kubernet

DockOne微信分享( 八十八):PPTV聚力传媒的Docker与DevOps

本文讲的是DockOne微信分享( 八十八):PPTV聚力传媒的Docker与DevOps[编者的话]DevOps是2009年前后提出的一个概念,提倡开发(Development)和运维(Operations)这两个领域的高度协同.从而在完成高频率部署的同时,提高生产环境的可靠性.稳定性.弹性和安全性.本次分享介绍了PPTV聚力传媒以Docker技术为支撑,在DevOps方面做的优化,包括: DevOps简介 Docker在PPTV的应用 DevOps与Docker的结合 实现方案 DevOps

DockOne微信分享(一四三):FreeWheel基于Kubernetes容器云构建与实践:应用编排与服务质量保证

本文讲的是DockOne微信分享(一四三):FreeWheel基于Kubernetes容器云构建与实践:应用编排与服务质量保证[编者的话]随着公司业务不断发展以及逐渐向微服务的转变,我们借助于Kubernetes容器化解决方案来标准化和简化应用发布的整个流程,使原来需要大量人工维护和干预的工作变为自动化.本次内容主要是FreeWheel现阶段基于Kubernetes容器化经验和实践的总结,目标是提供一个持续.稳定.高效的容器云平台. 服务健康检查与自我恢复 对线上业务来说,保证服务的正常稳定是重

DockOne微信分享(一三四):国内某大型酒店管理集团基于Kubernetes的实践

本文讲的是DockOne微信分享(一三四):国内某大型酒店管理集团基于Kubernetes的实践[编者的话]随着业务的增长,架构变得越来越复杂,服务器和应用数量越来越多,随之应用的管理,配置的管理,后期的运维都受到了极大的挑战.之前通过人工进行服务器配置,后期运维通过监控平台发现故障,人工恢复的模式已经无法适应业务的需求.我们借助Docker+Kubernetes打造的新的容器云平台,将之前90%以上需要人工维护部分的工作变成了自动化,一切变得so easy. [3 天烧脑式基于Docker的C

DockOne微信分享( 一零二):基于容器的日志管理实践

本文讲的是DockOne微信分享( 一零二):基于容器的日志管理实践[编者的话]业务平台每天产生大量日志数据,为了实现数据分析,需要将生产服务器上的所有日志收集后进行大数据分析处理,Docker提供了日志驱动,然而并不能满足不同场景需求,本次将结合实例分享日志采集.存储以及告警等方面的实践经验. 2013年以来Docker迅速火了起来,它的理念带来了非常大的便利性,不过实际应用中会发现还有监控.日志.网络等问题尚待解决,本文会结合实例分享数人云做容器日志系统的经验. 基于ELK的日志管理系统架构

DockOne微信分享(一零六):乐视云基于Kubernetes的PaaS平台建设

本文讲的是DockOne微信分享(一零六):乐视云基于Kubernetes的PaaS平台建设[编者的话]本次分享主要介绍乐视云两代PaaS平台的变迁过程,着重介绍第二代PaaS平台LeEngine的架构设计和遇到的问题. 背景 2014年乐视云开始尝试Docker的推广和使用,我们的团队开始开发第一代容器云平台Harbor (分享网址:http://dockone.io/article/1091 ).(在这里提醒一下,这与VMware公司中国团队为企业用户设计的Docker Registry e