大家好，我叫刘洋，现在负责北京银行系统平台方面的运维管理工作，今天和大家介绍的是北京银行的“可信云”之路，主要分为四个部分：自主可控之路、分布式存储云之路、tidb分布式数据库和未来的发展。
银监会提出“十三五规划”，要在“十三五”末期将互联网场景主要信息系统尽可能迁移到云计算平台。整个行业背景就是银行业部分业务系统面向互联网场景，尽可能迁移到云计算的架构上面，各大行还有一些股份制银行的态度也是从研究观望转化到实质规划和实施阶段。
目前商业银行面临的问题和挑战主要有以下三大方面：
系统可用性要求日益严格，运维风险日益突出，包括基础设施故障、突发业务压力、频繁变更上线都给运维带来很大压力，同时考验IT服务质量。数据中心针对外部基础设施、外部技术和服务依赖性不断增加，尤其是近期网络安全问题凸显。
技术路线仍然在受制于人，因为大家都在去IOE，商业银行在技术实施、支持和保障很大程度上依赖于IOE厂商。数据中心基础设施规模不断扩大，相应的数据中心建设成本不断攀升，出于安全生产和降低IT成本的双重要求，商业银行都在探寻自主可控的解决方案。
传统IT基础设施无法高效支撑银行创新业务，现在互联网化、移动发展趋势、近期提出的利率市场化要求，商业银行提出金融互联网、大数据、电子商务以及客户体验等等新的战略目标，这些目标需要的海量信息处理能力、快速交付能力都是无法通过传统IT基础设施解决，也要兼顾新的业务需求、建设成本以及响应速度，探索和采用新的技术已经成为一种必然的选择。
北京银行针对私有云的项目需求也是借着顺义新数据中心建设的契机，打算在顺义新数据中心建设私有云IaaS平台，纳入各类异构虚拟化平台，分布式存储、全产业资源，向上提供计算和存储资源，同时包括数据库、中间件的自助申请服务。
我们设计的初衷相当于从稳态和拟态两种思路出发，针对稳态是传统业务追求稳定和安全，传统IT架构也是以安全稳定为目标，生产使用的虚拟化平台以及传统网络，拟态IT资源主要是以互联网业务快速发展为出发点，新的IT架构是以敏捷性和灵活性为主要目标，未来我们使用的容器SDN以及现在正在用的峰值数据库和分布式图谱资源。
现在我们基础环境面临的压力从服务器的层面来看，运行的主要应用和核心数据库，硬件架构包括Power6、Power7和Power8，X86同样运行一些核心应用系统，包括非核心的应用系统以及部分数据库。
目前应用面临的压力主要是这样几个方面：
资源储备时间较长，目前行业内资源准备和资源分配是两个比较独立的过程，没有一个统一的工具。
硬件设备投资很大，因为现在系统建设初期大家都是采用传统建设结构，上线之初到单独购买服务器网络，甚至需要购买一些存储资源。
资源变更非常烦琐，现在数据中心面临大批老旧硬件设备替换的问题，前期的实施方案准备经历的时间比较长，往往需要一些业务的提升。
资源交付标准化的程度较低，虽然现在操作系统和应用软件堡垒级别Agent安装都可以依赖于自动化平台进行，但是操作系统的安装和软件的安装，这些环节都是独立开来的，没有一个统一的流程化管理工具，这种操作也是应用管理牵头实施，沟通成本非常高。
计算资源利用率比较低，系统建设之初都是出于高可用性的考虑，基本上都是配置双机，每台机器都有独自承担生产压力的能力。
基于以上这些问题，我们云数据中心的转型已经迫在眉睫，整个云数据中心的建设目标也是针对刚刚提出的几点，包括标准化、自动化、可视化、高安全、高可靠等等。
这是我们私有云平台的整体规划方案，底层是云管平台的方案，上层是云服务的方案，进行X86领域和小机的统一纳管，IBM PowerVM虚拟化平台，纳入所有X86 PC Server，通过自带接口纳入VMWare虚拟化平台，底层采用传统存储，CNWare是和分布式存储相结合，然后和行内一体化监控平台和自动化运维平台通过接口进行对接，调取一体化监控平台的日志，调取自动化运维平台自主软件安装和自动配置检查的服务，未来也要纳管其它的虚拟化产品。
这是顺义私有云平台的整体技术架构，通过HMC连接Power小机和PowerVM虚拟化平台，后台连接高端全闪存，部署在生产区，纳管超融合架构，通过CNWare Center，后端也是连接高端全闪存资源，对接的一部分是后端连接存储资源部署于外联网，也就是第三方的支持。
这些基本上都是部署应用和通讯类的虚机，数据量的要求小于500G，业务评价小于10的数据库打算在VMWare虚拟化部署，CNWare平台打算运行运维管理工具，包括自动化运维和一体化监控。
接下来向大家介绍我们应用的分布式存储，主要采用的是云宏WinStore，也是基于Ceph正式推出的方案，通过在技术方面做了以下优化和增强，比如易用性、可用性、磁盘空间优化处理、IO流量控制，增加原数据可靠性的优化，磁盘错误的识别和踢盘。
介绍一下我们行应用的TiDB分布式数据库，这是2018年3月在北京银行上线，现在运行已经有一年多的时间，这些就是TiDB的技术架构，调动管理器是在TiDB当中的PD，通过数据寻址调取搜索引擎，存储引擎在TiDB当中就是TiKV，现在我们银联物卡支付、网联系统都是运行在TiDB之上。
这个是我tidb两地三中心多活模式部署架构，底层就是刚才所说的PD层面，也是跨地区的分布式调度集群，上面就是刚刚说的存储引擎，也是跨地区的分布式存储集群，最上层就是搜索引擎层面，叫做TiDB。西安中心也有部署一套从集群，和主集群进行日志同步。
最后一部分就是北京银行对未来容器云统一纳管的思路。现在大家逐渐从传统的瀑布式开发模式向新型的敏捷开发模式转变，传统软件架构都是采用瀑布式开发模式，就是分阶段分步骤进行，强调安全和稳定，但是周期比较长。因为现在互联网业务的快速发展，大家对小版本迭代和交付的需求也是特别强烈，每次交付都有一个增强和改进，而且交付方式周期都非常短。
这种IT开发测试面临的难度其实是有很多的，这里主要列举了几个方面：传统架构向弹性架构转变，弹性架构需要分布式的部署、水平的分层、可弹性的扩展，新的业务上线有的已经缩短到小时级，相信很多同行都深刻体会到了频繁上线对运维的压力非常之大。没有手工操作，代码到线上环境的持续集成，提高开发和测试以及版本迭代的速度，缩短业务的升级周期等等。敏捷开发带来的风险也是越来越多，比如AD测试都是打破了传统瀑布开发的分阶段模式。普遍运维人员头疼的问题就是测试和生产不一致，很多上线出现问题的环节也都是在这里。
我们做运维面临的难题也是非常之多，面对脉冲型的业务突发增长，需要提前做好应急预案，需要快速保障这种新型应用的安全稳定，包括在线灰度的升级以及资源如何异构扩展，刚才介绍过了虚拟化平台各式各样，包括VMWare和CNWare，以后也会有其它异构虚拟化平台，资源利用率也是需要大大提升的。
关于容器北京银行在2017年就做了一个课题，当时也是拿了银监会的一等奖，当时主要是把基于WAS的应用打包部署到容器上。开发测试和运维现在每个阶段都交付着不同的内容，比如开发人员交付代码，测试人员交付测试包，运维人员部署运行环境。未来如果我们使用容器云平台，也要遵循相应的流程，然后把一些标准化能够交付的东西尽量都放到平台上面进行统一纳管。
我们的主要目标是以应用为核心，推动IT全面转型，同时也要考虑如何更好地和现在的监控手段相融合。
北京银行私有云平台的发展主要分为三大阶段：2019年底完成顺义新数据中心私有云平台的部署，一期是将重要系统迁移到私有云平台之上，一期迁移以后还有二期，主要就是非重要的业务系统迁移上云，逐步扩大云数据中心的资源部署能力，远期我们也会吸引同业部署在托管云之上，西安灾备中心就是对外提供托管服务，同时西安灾备中心的私有云平台已经运行一年多。未来顺义新数据中心是作为主数据中心提供服务，西安灾备中心仍然是以异地灾备中心的角色对外提供服务，这样的管理模式将是未来的趋势，相当于横向的概念，纵向我们也会继续发展和探索，希望各位专家和领导能够和我们行多多交流。