正文
产品团队交付流水线
我们再建立我们的持续集成服务，通过持续集成服务调动我们的构建脚本对我们的代码建立准入机制，把它全放在我的产出管理里。
我们通过一些工具实现我们的部署流水线，并在我们的JCK上面展示出来，通过一键式按纽就可以把你的构建产出部署到不同的环境，比如我们的int之类的测试环境。也分为A环境和B环境。
当我们把我们的构建产出部署到环境以后并不是说流水线就完成了，我们的区域交付流水线是一个闭环，我们会在我们所有的环境加入相应的监控与告警机制还有一些用户的度量分析，通过可视化的仪表盘把这些数据展现出来。
比如我们在每一abb内置了短路应用，通过可视化的仪表盘可以轻松的看到我们微服务每一应用的调用频率是什么，失败率是什么，时间是什么，就可以把系统的可用性轻松的可视化出来。
大规模持续交付仍需要解决的问题
-
第一个问题，如下兼顾稳定和吞吐量
，传统的运维流程比如发布深比实践支持等和方法手动操作和夜间部署已经越来越难以适应当今产品不断缩短的变更周期，同时又要保障系统运行稳定性的要求。
-
第二个问题，如何建立关注业务和用户价值的文化
其实我们开发产品目的是什么？目的是为了赚钱，那怎么才能赚钱呢？
肯定是要讨用户的欢心，但是其实大部分团队里面我们开发人员和运维人员是不知道用户开不开心的，他可能知道用户不开心，比如我服务器宕机，用户操作不良肯定不开心，但是用户是不是满意他是不知道的。
特性发布后用户的反馈抱怨和给业务实际带来的收益反馈到业务和开发这个过程有大量的信息丢失，速度太慢，难以真正对特性所带来的价值进行验证。
-
第三个问题，就是如何控制IT系统不断增长的复杂性
业务开发运维分段式交付模式前端不会充分地考虑堆砌的功能和设计决策给整个IT系统，导致IT运维成本越来越高，反过来导致长期的交付变得越来越困难。
一个典型的例子
这里就举一个非常典型的例子，也就是我一个开发团队开发一个微服务的时候想申请一系列的机器，这些机器一部分用来做我的构建环境，一部分测试环境，一部分产品环境。
这上面可以看出在这个几大步骤中，通过打造持续流水线已经实现了自动化，拿到我的机器以后就可以通过自动化布置脚本，轻松的把部署到中间件。
运维人员有能力以后再进行相应的服务器的配置，不仅要配的东西非常多，要安装操作系统配制IP、防火墙，配置好这些机器以后还要装上运行所必要的中间件，比如shall。
什么是DevOps？
在2013年的时候，这家组织的CEO和CTO参加了很多大会，和很多DevOps专家都有深刻的讨论，他们讨论以后觉得DevOps可能解决他们的问题，就是什么是DevOps？左边的这个图今天早上演讲中已经展现了，而右边对DevOps的介绍是我从百科上摘抄出来的。
DevOps落地实践
那么在说DevOps的过程究竟这家金融组织怎么做的？我大概总结了一下，分为四大部分，从13年开始直到现在。
-
第一部分是引入动态基础设施。
-
第二步是调整IT部门的组织结构。
-
第三部分是采纳基础设施即代码的实践。
-
最后一步是平台化战略。
第一步：引入动态基础设施
那么第一步我要引入动态基础设施，是什么意思？举例子，你在创建资源的时候这个资源是指我们的运行所需要的资源，包括运行的机器、计算节点，所需要的附带均衡器，它所需要的网络，所需要的IP，这些资源是可以通过多种方式创建的，你也可以使用HTP远程调用的方式创建，也可以写代码，通过引入一些SDK创建，这些资源你是随时可以创建使用销毁的。
其实它就是我们所说的云计算。大家有个疑问说我是金融组织，对数据的宝贵性要求比较严，你用公有云我们不放心，他们当时的CEO也有这样的担心，他们亲自飞到美国和共有云的CEO进行了深度交流，交流以后他们发现其实这些都不是问题，我们可以把公有云当成我们的数据运行，我刚开始公有云作为一个数据中心，把一些不是很重要的系统放上去，来进行运作，不就可以了。其实我们发现数据放在公有云其实更加安全。
公有云彻底解放生产力
经过公有云的迁移以后，对Ops团队来说我们减少了成本，可以减少85%的灾备成本，其实这家金融组织有一些自己的收益衷心地但是大部分的都是租的，那些运维人员很多都是winer提供的，但是有了公有云以后你会使用它提供的服务替代。
另外一方面也可以减少自建收费中心的压力，比如说每一个数据中心要各自维护各自的服务器升级，以及我的数据库备份的问题，其实公有云已经对最基本的运维问题提出了一系列的非常简单的解决方案，也就是我运维再也不用考虑这些问题，我只要使用他们提供的就可以了。
对于开发人员的好处，第一个就是自服务机制，以前我记得有一段时间我刚加入一个团队的时候，我说我要有一台机器作为我的桌面，结果这个流程其实走了三周的时间，但是使用了公有云以后有一次我想创建一个虚拟桌面来进行验证一些问题，我只用了短短的十分钟就实现了。
