大家好，我会从偏行业角度来谈一下DevOps在金融行业去落地的时候会遇到的一些问题。
首先我们先看一下挑战，实际上如果大家有印象的话，在2013年的时候，余额宝诞生了，实际上这只是过去很短只有五年发生的事情。
在这个过程中，实际上我会发现互联网对传统的银行业和保险行业造成了非常大的影响。
在今天，很多客户会谈重要的一件事就是转型，从去年四大行和BATJ形成战略合作，其实我们可以看到互联网的领域情况下，传统企业到底和互联网公司谁在前排谁在后排其实并不是像以前那种情况。
消费升级里面会有很多场景性的消费是需要金融企业参与其中的，红帽曾经在澳洲帮助澳洲一家客户实现了和uber的重要的项目集成，在uber去打车的时候，我们可以通过银行的信用卡积分支付打车的费用，同时在客户到达目的地的时候，uber会推荐这个客户周边和银行卡合作的商户有哪些优惠内容。
所以我们会发现，在这种新的业务场景化消费的时候，企业的服务边界不再像以前传统的中间业务，银行比如说站在电信的前面完成全部的交易过程，很多交易环节全部是开放的。
在以往的银行的核心建设的时候，大多数采用这种集中式的建设，通过服务总线服务化，去实现服务的提供。
在现在的新的情况下，我们会发现不可能会有一个团队，能够了解全部银行的新兴业务。这些都是我们可以看到，在互联网经济的情况下，实际上在业务方面，对银行产生的冲击。
在另一方面，恰好我在过去的一段时间参与过几家创业公司，在互联网创业公司里面会发现，最有挑战性的事情就是几乎我们的团队每天都要上线新的系统。
为了配合各种互联网活动，要不断推出新的模块。
新的系统模块bug全部都是交织在一起。这种情况下，必然会催生我们在银行业的项目的变化。
系统的上线周期，虽然在银行不可能每天不停去进行持续的发布和上线。但是我们传统六个月或者是三个月的项目周期，在银行发生巨大的变化。
在持续转型的过程中，我们会发现目前我们有很多的不同的技术手段，分别解决我们刚才看到的业务挑战，通过一些服务化的暴露，可以让服务具有更好的灵活性。
我们通过微服务的方式，可以让应用开发变得更为灵活，通过IT自动化可以去大幅度地提升我们IT交付时候的交付能力。
包括容器化使得我们在面对这些业务弹性的时候，有更好的适应能力。在以往的银行比如我们以建行为例，建行的核心业务系统会制定比如一万个TPS作为它的一个目标。
但是我们现在知道，一个普通的股份银行在我们前端做业务的时候，可能在做理财产品的销售，在做一些互联网的秒杀业务的时候，它需要几万甚至十几万TPS的能力。这些都会对我们的技术转型造成影响。
如果我们仔细分析，会发现在这些单一的技术的前面，其实是有一个抓手的，这个抓手就是我们现在看到的DevOps。从过去的一年多来说，DevOps的发展非常迅猛。
这种变化其实不仅是我们的各项技术的进步和业务需求达到了DevOps能够去普及的程度，同时我们看到很多银行客户，他如果不进行这种弹性化转型，要么就接受原有的这种比较僵化的体系，要么付出很高的人力成本实现在互联网经济情况下的弹性需求。
下面我们看一下红帽在过去的一年多帮助从招行到一些股份银行和保险公司都实现了DevOps的过程。
在这个过程中，我们也和很多的合作伙伴一起合作。主要从三个方面去帮助客户进行DevOps平台的落地。
第一方面我们会提供云环境的应用基础设施，通过建立一种平台稳定的基础架构来支撑DevOps落地的执行。
第二方面我们会提供快速的、弹性的伸缩，依靠在红帽的OCP容器的框架基础之上，能够帮助从应用到DevOps的环境两者之间都能够提供很好的动态的扩容和部署。
第三个比较重要的目标是关于应用的快速迭代，也就是完成DevOps的整个CI/CD的流程的落地。
其实对于金融客户来说，我们在落地DevOps的时候，不仅是一个技术方面的工作，比如说从整个DevOps的开发到运维的工作的协同上打通，到深层次垂直方面的CI/CD的工具链集成，会有和金融客户相关的特定的事情，我们是需要去考虑的。
我们可以看到从差不多过去十年，开源软件得到了大范围的应用，特别是随着大数据、人工智能和区块链的引入，开源的引入，给我们的企业客户带来了很多创新的能力。
在这个过程中，对于开源的软件的使用，其实我们在DevOps的过程里面，是需要从源头开始去保证金融客户的应用环境的安全。
对于金融企业在使用传统软件产品时，会设置产品基线，比如用到数据中心会指定某一个版本作为这一段时间的数据库版本，会设定几年为周期进行版本的升级。
在开源的使用过程中，我们会发现管理过程变得十分困难，我们无法要求每一家软件供应商使用的每一项开源的版本是被统一化的。
在这种情况下，意味着我们在DevOps落地的时候，就需要对所有的开源的环境和相关的内容有所管理。那么通过标准化的镜像进行统一的版本。在DevOps中，通过它的元数据管理所有的开源软件版本的依赖的关系和它整个的生命周期。
对于金融客户我们会发现为了实现分布式架构，我们会用到大量的比如宏观的AMQ，会用到大量的内存缓存的产品，也会用到很多分布式的微架构。
在这种情况下，都会导致整个应用的部署非常复杂，部署一套应用功能需要很多不同的组件协同工作。在这种情况下，往往只有通过DevOps的过程，才能为我们带来更好的运维效率。
对于银行来说，我们会经历很多项目的从SIT到UAT的过程，任何一个业务系统往往不是单系统的测试和验证，我们需要大量的周边系统的配合。
这种周边系统配合，在以往我们在项目实施的时候，对于整个运维部门来说是非常繁重的工作负担。而且在执行这种SIT或者UAT系统部署的时候，往往不是一个项目只部署一套系统，往往是需要有大量的不同的阶段、不同的版本部署。
这一部分其实也是我们在进行DevOps落地的时候，是需要充分去考虑到的。
另外一点对于银行来说现在大量地使用外包人员进行项目的基础交付的开发，对于外包人员来说，他的使用会为我们很多客户带来非常大的好处。因为传统的四大行，我们需要维系非常大的IT团队，去做大量的基础性工作和业务性开发。
通过DevOps的引入，实际上会使我们的很多股份银行和中小型客户，在IT能力上找到了一个能够弯道超车去追赶我们大型企业的能力，能够帮助我们实现整个IT软件的生产装配的过程，其实这是我们在银行业如何实行DevOps来看，其实具备的最大的价值。
这里我们看到红帽这边关于整个DevOps过程的方案的架构，这里我们看到其实DevOps的过程本身还是蛮复杂的。从参与层面，从产品经理、开发、运维、测试到业务运营人员，都是和这个流程有关系的。
在这里面，其实还有一个非常重要的角色，就是敏捷教练。敏捷教练非常大的作用，就是在整个DevOps的执行过程中，能够去指导和改变我们传统在软件开发中的很多不良过程和习惯，同时能够让DevOps过程能够有反馈的闭环。
之前曾经有一个客户找到我们，提到能不能派一个工程师到我们现场来一天把CI/CD的环境建立起来，这样他就可以和开发部门一起去立项，然后在企业内部推行DevOps过程。实际上我对客户讲，这对于我来讲是非常困难的事情，因为DevOps并不是简单的工具链的集成，里面是有大量的过程设计和验证。
红帽，我们现在是有一个全球的创新实验室，能够帮助我们的企业客户在实现DevOps的时候进行验证，并且和我们的客户形成联合团队，一起工作。
在工作过程中，可以手把手地指导在DevOps过程中的哪些环节是关键，该去对哪些问题进行验证，然后通过我们这个实验室中的一站式创建比如容器的环境等等，通过Ansible的脚本，快速能够把DevOps的流程能够构建起来。
刚才我们提到在DevOps构建的时候，是不是一上来就要去建立这样的一个DevOps的门户，能够快速看到各项任务的执行情况，比如说快速进行分析。其实这一方面对于红帽来说，我们有一个比较便捷的手段，基于Ansible做的各种的编排的内容，我们可以通过Ansible
Tower快速对所有的任务进行统计，快速去分析。这一部分的能力，目前来说是可以快速获得的。
同时在Ansible里面，我们可以支持上千种不同设备的集成，从网络设备到物理设备和很多环境的管理和对接。
通过快速的一些配置性脚本，就能够实现很多对于资源的操作和配置的更改，也包括对标准镜像到和我们运行环境的二进制代码做混合镜像，然后把它比如放到最后我们的镜像库里去，所有这样过程都是可以通过Ansible的产品快速整合到一起。
我们可以看到不同的产品，是红帽预制了很多镜像，便于我们在DevOps部署的时候快速拉起来相关的CI/CD能力。其中就包括像S2I源代码编译的一些能力等等，能够快速实现。
在这里面为什么红帽会做大量这样的工作呢？实际上我们可以看到，DevOps本身如果你把它看成一个生产线的话，实际上我们通过把这个生产线装到了容器里面，就能够实现集装箱卡车的方式，能够快速让企业第一快速部署，另外可以让这个能力变成一个可以输出的模型。
因为很多时候一个企业里面的DevOps的流程不是单一的流程，因为开发语言还有系统原因，往往需要多套不同的流水线，通过容器化的方式，可以让我们在构建DevOps流水线的时候变得更为灵活和弹性。
红帽还有专业服务团队和合作伙伴，针对DevOps制定了很多的规范性的内容，便于我们客户在进行DevOps实施的时候，项目能够快速落地。从前期的需求的一些指南，到集成的一些问题分析，Git管理规范到一些发布规范，这些都是我们在客户项目里面形成的。
其实对于DevOps来说，我们在做DevOps的过程里面，不一定一定要做容器化，这些内容实际上对于客户来说是因客户而异的。
我们根据客户当前发展的实际情况和需求，对整个项目他所需要的建设阶段进行规划和设计。但是我们也会发现，如果对一个企业来说，它能够把微服务、能够把容器、把DevOps结合在一起，会得到1+1+1>3的效果。
如果一个企业大量地使用微服务，微服务化虽然能够带来非常好的服务的划分、服务的交付的灵活性。
我们也看到现在混合型部署，未来会成为非常重要的趋势。我们有一项统计，就是在全球的客户里面，会有50%的客户存在公有云和私有云的混合型部署，在这种情况下容器肯定会成为更为有利的一个解决方案。
同样对于DevOps和容器本身，刚才我们也提到如果DevOps过程里面，因为它有大量的编译和资源的需求，将Jenkins以容器方式部署，编译的时候可以充分利用这个资源。
提到DevOps，我们肯定要看一下技术架构层面。其实谈DevOps，我们还是需要从多个维度去看这些问题，至少需要从三个维度，第一个维度关于DevOps的基础设施层面，第二个维度是DevOps流程如何实现，第三个层面是DevOps在搭建好流程以后，它的产出的软件和产出物可以是什么。
在整个DevOps流程里，实际上对于红帽最终会形成一个贯穿，从基础设施一直到服务提供一个全程的解决方案和交付。在基础设施层面，可以使用虚拟化、物理机、云技术的方式。
在IaaS和PaaS层面，实际上我们可以通过容器化的技术，对于比如镜像仓库、持续集成包括对应的中间件服务和发布编排提供支撑。在统一的云管平台，实现自助化的交互，最终实现各种对于服务能力的交付。
这里我们看到的是一个功能架构，实际上这个功能架构看起来比较像我们传统的软件功能。这里其实我们有一种观点，就是对于一家企业来说，未来可能它最重要和最核心的一个系统，就是DevOps系统。
为什么这么讲呢？实际上DevOps系统它会是一条最终软件能力的生产线，对于我们的IT部门来说。
它会整个贯通从我们的IT人员到基础设施到我们的开发规范，把整个企业中需要重复去操作的事情，需要存在高风险的操作的内容，把它固化下来，然后形成企业的生产过程。
我们可以想在传统软件工程里面，经过发展，实际上都是通过各种指导规范，通过弹性的指导性的方式，让人这种不确定性的这种生产工具去生产最精确的软件产品。
通过DevOps的过程，实际上我们可以把中间它最困难的部分，把它固化下来，固化下来以后我们可以形成这里面的各个层次的功能，从底层的大量的资源的管理维护到PaaS平台上的中间件的环境持续集成的过程，各种基础性的软件服务，不管是从管层、消息队列还有数据库和镜像的仓库，都形成IT部门的基础服务。在这之上，形成整个所有从开发团队到运维管理人员它的工作界面。
对于一个企业级的DevOps流程来说，不只是打通开发部门和运维部门之间的边界，在这里面会有非常复杂的CI/CD工具的集成过程。因为一个大型的DevOps项目，往往需要至少几十个不同的工具进行集成，才能得到最终的弹性生产线。
在生产过程里面，在什么环节去设定它的二进制的代码库，在二进制代码库形成以后如何能够得到和基础环境混合在一起的运行镜像，那么这种运行镜像如何去部署到不同的SIT或者UAT的环境里面，因为每个环境的配置都是不一样的。
对于我们来说，实际上需要形成从二进制代码库，我们举个例子，比如从二进制代码库形成容器的标准编译的结果，然后通过这个容器拉起的时候，我们可以通过S2I生成最终的运行镜像。
对于DevOps的落地来说，应用的弹性扩充融也是非常重要的一个环节。其实刚才我们提到了在国外有大量的客户，他会要求在混合云的情况下，进行企业级的规划和设计。
这里面就少不了在混合云管理时候需要的各种比如计费功能，混合云的自动化的跨云的部署，权限的管理、安全的审计和监控功能。
对于DevOps的落地来说，应用的弹性扩充融也是非常重要的一个环节。其实刚才我们提到了在国外有大量的客户，他会要求在混合云的情况下，进行企业级的规划和设计。这里面就少不了在混合云管理时候需要的各种比如计费功能，混合云的自动化的跨云的部署，权限的管理、安全的审计和监控功能。
在这里，红帽的OPENSHIFT SERVICES会提供和DevOps有关的基础性服务，以内嵌的方式，会放在容器的运行环境里面。
在这之上，会有针对不同环境的容器内的支撑，包括从Jenkins的运行环境，到微服务的框架，我们也有一个充分的认证，包括OSS等等。
除此之外因为DevOps不可缺少的是和开发人员的交互和关系，同样我们会在对于开发人员部分有相应的开发工具，便于在容器化的环境中去进行容器的开发和部署。在管理方面，会有相应的容器内的APM的工具和管理的工具。
下面简单介绍一下我们在国内的股份银行实施DevOps的一些收益，首先我们帮助客户梳理了整个中间件服务器的环境，在这个基础上做了基础镜像和相应的模板，便于客户在进行不同项目部署的时候，可以从基础镜像库里面快速拉起来中间件的一些集群。
对于底层的JDK和一些服务器的版本制定不同的版本，会在运行环境中进行相应的合规性的控制。
在应用发布的时候，原本一次发布需要很多认购执行过程，现在我们可以做到一键点击之后部署流程自动化，部署的过程整个所有的部署任务都是可视化，能够知道部署的进程达到什么阶段了。
在最早的时候部署一套应用大概需要三十分钟的时间，现在整个部署时间可以缩短到分钟以内，大概是秒及十几秒的水平。
在整个所有版本的回溯的时候，我们提供了相应的支撑。因为所有的部署内容，全部都来自于二进制的运行库和相应标准的镜像库。对于整个git的管理，在项目中对不同环境做了相应的一些适配。
对于红帽来说，我们的DevOps过程可能和传统环境中最大的区别，就是会大量地使用容器的技术，来实现客户的DevOps的落地。
我们要对客户的整个应用环境中所用到的中间件进行标准化的切分，形成标准的镜像库，同时将用户的应用向容器里面做迁移性的认证，因为我们知道容器现在它是无状态的技术，会对整个容器迁移的过程中有一些影响，比如有很多的配置，这个时候我们需要进行一些适应化的改造。
在这个基础上，其实后续的整个CI/CD的过程，和我们在传统环境上做DevOps的过程并没有特别大的区别。还有会在CI/CD之后额外多一个环境是我们有镜像的制度过程，还有不同环境在部署的时候，部署参数的源数据管理。
最后稍微占用大家一点时间，红帽是一家扎根于开源，服务于企业的这么一家公司。在过去的时间里面，红帽收购了非常多的开源和闭源的产品，把它贡献到开源的社区，包括像现在我们Ansible、Ceph、CoreOS等，都是红帽在过去一段时间，在向开源社区做的贡献，也是为了支持我们未来所有企业客户的需求能够从传统的IT架构向云架构去做迁移。感谢大家！（说 明：本文根据 DevOps 国际峰会 2018 北京站红帽方浩老师（ 红帽金融行业解决方案经理）的演讲整理而成。
