【编者的话】在新常态经济背景下，金融脱媒加剧，跨界融合和互联网金融的发展加速传统金融企业变革转型。传统金融 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：传统金融行业很多关键系统架构比较简单都为集中式架构，不好做横向扩展，不适合放到私有云上，这个问题有什么好的解决思路？Q：混合云如何解决多租户服务与金融行业监管要求物理隔离之间的矛盾？
A：从数据面和业务场景来细分，关键系统涉及客户资料、资金动账系统，仍然保留在传统集中式的主机平台，但是会将查询类交易下移到基于 X86 的私有云上。
Q：您认为迁移到云的步骤应该如何，哪些适合迁移到云
A：金融行业监管要求物理隔离在数据中心网络层面表现为“2 网分离”：办公网和业务网。 相对应的，混合云的多租户也细分出开发云、测试云和生产云租户。各租户的资源和操作严格进行隔离
Q：哪些业务适合使用云服务?云架构与传统架构肯定存在一个并行期，两套架构如何融合并存?
A：在实践中，先理清应用的家底。根据业务场景需要和云的能力、团队的技能成长、监管底线（上公有云的话）等维度进行评估，选择上云的应用。迁移步骤具体看是否要重构应用架构，相应迁移难度不一。
Q：云架构与传统架构肯定存在一个并行期，两套架构如何融合并存?
A：在私有云，云服务不是像公有云服务一样完备，建设是有个过程，所以前期内部管理类、和客户交互的渠道类业务适用上云。
Q：你指的混合云是以 Oracle、IBM、VMware 主导的商业软件公司提供的平台比如 O 记的数据库混合云，还是以开源软件为主的比如 OpenStack、KVM，上面跑基于开源的 Tomcat、MySQL ？
A：的确存在并行期，架构职能团队可以发挥较大作用，一个作用是架构管理团队各片区和开发团队设计角色管理好各产品的应用架构,另外一个作用组织人手开展云架构的设计、原型开发，引导产品的架构进行演进。
Q：传统金融的现有商业软件如何与开源平台结合？
A：我们理解的混合云是更广义，包括公有云和私有云领域，公有云例如 AWS、AZURE、阿里云等，私有云例如 vCloud、青云等。
Q：传统金融的 IT 运维能否自己支撑开源平台构建自己的混合云，从你的视角看中小型城市商行依靠自己的 it运维构建自己的混合云当前阶段是否切实可行？
A：以选择云平台的技术栈建设云服务，现有商业软件不是强求结合，结合成本太高或技术架构不合适就该舍弃。例如小机 WEB 应用上云，就会从 Was 换成轻量级的WEB 应用服务器，例如 Tomcat、JBoss。
Q：请问在云化的过程中，是已自行研发开源技术为主呢，还是使用较为成熟的商用软件为主。如何平衡成本与效率的关系
A：这要看单位的大背景，如果业务部门没有传导市场压力到 IT 部门，那么面对 IT 开发团队，由 IT 运维主导建设基于开源的混合云平台作为起点，也是一种可行的选择。我们的大背景是业务压力的传导，以及自我变革的高层压力，所以是由架构职能团队牵头规划设计，新建的云平台团队实施落地。
Q：如果是混合云的架构话不是应当考虑公有云和私有云一致性吗？，而刚才说的结合就变成了一种简单的去IOE，客户总不能生产跑 Was，公有云跑 Tomcat 吧，如果这样推动混合云那么是不是意味着先就要推动去 IOE，改造应用？
A：贴近应用的部分建议自研，例如开发框架、公共组件。基础设施部分需要稳定为主，例如虚拟化平台、对象存储服务、消息队列服务等，一般选择商用软件或开源软件企业版，有些加客户化定制。
以上内容根据2016年8月4日晚微信群分享内容整理。分享人罗文江，某传统金融IT架构师，关注和IaaS、Docker和云管理关联的技术。 DockOne每周都会组织定向的技术分享，欢迎感兴趣的同学加微信：liyingjiesz，进群参与，您有想听的话题或者想分享的话题都可以给我们留言。
A：这个问题可以细分 2 种层次来看，混合云架构设计对基础设施（VM、容器、镜像、网络等）是要进行抽象，达成这个层次上看私有云和公有云是一致 的。 另外混合云架构设计上，管理的另一个高阶层次是对应用架构的抽象，理想能够做到应用在不同云上进行无痛迁移。传统上在 IOE 上的业务系统，如果有开发框架的支持，且框架的架构做的好，则开发框架改造上云后，应用代码改造量很少。
有疑问加站长微信联系（非本文作者）
