前言

本文根据DevOpsDays北京站演讲记录整理而成，着重介绍 DevOps 在传统金融组织中的落地实践经验。

今天我给大家带来的演讲话题是传统金融组织DevOps落地实践。

我平常喜欢写代码，喜欢把中间的思考过程写成文章，我也喜欢研读国内外的优秀书籍，再翻译成中文，前后翻译五六本书。

业余时间我也是一个马拉松爱好者，以前跑42公里我都觉得了不起，但是去年开始尝试更长的距离，比如五十公里一百公里等。刚才看到还有一个爱好者，也是倍感欣慰。

背景介绍

我们先对这家金融组织进行一个简单的背景介绍，这家金融组织它是本土最大的金融资产集团，总资产1000亿美元，房地产行业市场份额做到全国前三，他们国家每一百个人中至少就有一个人买过他们的保险产品，这家集团旗下拥有银行、一般保险寿险等不限，市场上二十多个品牌。

因为随着近几年业务的发展，他不断的收购同业的公司累计起来的，由于它是一个金融组织，所以这就说明它本身不具备互联网基因。所以他们的组织体系可以分为两个部门，一个是业务部门，对接前面的消费者。第二个就是ID务部门，在背后为业务进行支撑。

我今天分享的DevOps落地实践主要是分享IT部门如何使显得。今天早上我相信很多人已经听了我们的其他演讲，在讲DevOpsleave也就是DevOps可以把业务领域涵盖进去的，当然这个业务不在我这次分享之内。

那年，它的困境

09年这家巨无霸的企业面临各种各样的问题，内忧外患，外部来说它是处于开放性的金融市场，他们的法律比较完备，市场竞争非常白热化，不仅要面临他们国内的保险行业银行行业的竞争，还要随时面临国外资本的入侵。

另外他们的产品创新法缺乏新的业务增长点，比如09年他们的在线销售保险系统其他的都不支持，任何的端点都没有他们的产品。从内部来说，由于他们在过去十多年间收购了很多家公司，就导致了他们的组织机构非常的效率低下。

举个例子，做卖保险大家可能很多人都听说过life400，像这样类似的系统在他们公司内部多达十几个，也就是所有的保单都分布在这十几个当中。内部还存在问题就是人员增长遇到瓶颈，人才流失严重，人才流失以后去到他们的竞争公司里了。

转型之路

所以从06年开始，他们其实已经启动了敏捷转型，整个软性的时间也是非常长的，从06到13年只是完成一个阶段，这里并不是说2013年以后说明敏捷转型成功，其实敏捷倡导持续改进，所以他们一直在改进当中。

那么在这么多年中，他们的敏捷转型主要是进行了三大部分的改进。

第一部分就是组织结构调整


从这里我们就可以看到敏捷改进其实是需要自上而下的，因为我们通常说屁股决定脑袋。组织结构调整包括企业统一化、组织统一化、运营合一化，以前我有十几个业务线，我们就要进行一些裁减合并。


第二部分就是遗留系统优化


我们根据抗非定律来说肯定会对IT系统进行调整，方式就是简化我们后台系统，比如说我们后台有个客户管理关系系统，当时他们客户关系管理系统就有七八个，随着遗留系统优化以后最后只缩减成了一个。还有他们的理赔系统也是，也由七八个缩减至一个。


另外一个很重要的IT改进就是它的统一数字渠道，也就是保险的售卖一般分为两个途径，一个途径就是通过各种各样的代理，通过他们的IT系统以及电话系统进行售卖。


还有另一种方式就是在线售卖，他们面临很多很多的品牌，很多的品牌再加上很多的数据系统组合起来对于IT部门的压力是非常大的，系统简化以后他们实现了一套规则，把他们所有的系统全部外部化。


通过外部的方式就可以使用，把他们的样式也给归一。这样既可以增加消费人员对于他们品牌的认同感，另一方面也简化了IT部门的开发工作量。


第三部分就是打造持续交付。


前面我把基础的差不多了，可以放开手脚干了，比如以前没有收益银行现在就可以做一个。比如我们要拥抱最新技术，12年的时候我们就有一个网站做了一个系统，不断的往里面存钱，看到的画面是不一样的。


到了13年我们就逐步想打造这样的持续交付流水线，13年很多功能都已经实现了。这个图我们可以看到我们核心的输入点是我们的白马控制库，我们会把我们所有的代码不放在里面，包括我们的应用代码还有测试代码包括构建脚本以及相应的部署脚本和环境准备脚本，全部放在我们的版本控制力。



产品团队交付流水线

我们再建立我们的持续集成服务，通过持续集成服务调动我们的构建脚本对我们的代码建立准入机制，把它全放在我的产出管理里。

我们通过一些工具实现我们的部署流水线，并在我们的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提供的，但是有了公有云以后你会使用它提供的服务替代。

另外一方面也可以减少自建收费中心的压力，比如说每一个数据中心要各自维护各自的服务器升级，以及我的数据库备份的问题，其实公有云已经对最基本的运维问题提出了一系列的非常简单的解决方案，也就是我运维再也不用考虑这些问题，我只要使用他们提供的就可以了。

对于开发人员的好处，第一个就是自服务机制，以前我记得有一段时间我刚加入一个团队的时候，我说我要有一台机器作为我的桌面，结果这个流程其实走了三周的时间，但是使用了公有云以后有一次我想创建一个虚拟桌面来进行验证一些问题，我只用了短短的十分钟就实现了。

这是因为我创建计算资源的时候我可以直接调用一些接口直接实现，中间不需要任何人的介入。带来的另一个好处就是直接带来了高可用的弹性伸缩，我们在设计产品的时候可以充分利用各种的资源。比如说我们之前一般的保险金融组织有一个计价模块，计价的时候我们需要把计价所有的日志全部记录下来，而这个日志每天产生的数据量大概是100G左右。

我们为了解决这个问题，当时伤透了脑筋，使用各种各样的磁盘阵列，不断的扩容我们的磁盘存储，想了很多方案，但是始终满足不了需求，最后使用公有云以后问题非常简单了。

我们直接使用他们提供的高可用的存储技术轻松的把我们这些日志全部存储上去了。其实公有云的整个过程不是一蹴而就的，我们前后花了三年多的时间才把大部分的服务迁移到公有云上，只剩下无法在云上运行的，还有一些核心的数据，比如客户的数据，还是存在自己的数据中心。

公有云迁移策略

那么在整个迁移的过程我们遵循一个原则是什么？首先我们要设计我们的公有云架构，我们如果把公有云当做我们的数据中心我们公有云应该具备什么样的设置？

我们根据workspace建立业务线资源隔离，里面又分为Non-prod和prod两套环境，设计这样的公有云架构以后我们就把现有的基础设施个公有云进行对接，比如我们现有的这十几个数据中心要和公有云对接，对接过程我们要考虑很多问题。

公有云里的私有云

第一点，公有云本身的认证方式和企业现有SSO的集成


那么我们实现的方式就是根据公有云提供的接口实现了和企业现有SSO的集成，也就是你想要访问某些资源你要申请一下就可以了，跟其他的数据中心资源一模一样。


我们企业都有自己的认证系统，我们不可能再在公有云设置一个认证系统，企业员工使用的时候在这两条系统之间进行切换，这样对企业用户来说是不友好的，对于企业的运维来说也是比较麻烦的。


第二点，实现公有云与现有设施的直连


比如我们的后端的某些数据库是我们本地的数据中心的，我们前端的一些服务还是在我们的云上的，那么为了不影响效率，我们就建立这种直连机制。


另外就是要实现公有云与基础设施的VPN连接，实现以后公有云创建所有的资源IP地址都是我们内网地址，我在使用它的时候和我使用其他数据中心的这些资源方式都是一模一样的，根本就不用进行任何切换。当然还有内部DNS服务的互通。


第三点，准备这些基础设施以后我们就可以进行应用程序的迁移


我们要遵循优先级，我们就要先迁移技术风险低业务价值高的，我们买保险的时候有保险介绍的页面，你是通过这些静态页面链接到购买系统和自服务系统的，对这样的应用来说迁移的难度最小，但是带来的价值最大。


迁移时尽量不涉及对应用程序架构的变更，所有服务仍然属于原有架构。我们谈迁移很多人就非常激动，他说我终于可以把以前老旧的换掉了，我可以使用一些收费便宜的甚至免费的数据库，但是如果你抱着这样的想法那你在迁移中无疑增加了难度，所以我们把应用程序的变动放在最后一步的，再进行应用程序的互换。


比如说我们把本地数据库替换成数据库服务，DES，然后我们本地的一些消息队列也替换成云上的消息队列，甚至是我们把非生产环境的操作系统全部换成一些免费的发行版，进一步减少花销。

我们是如何在公有云里面保证我们对数据的安全性呢？

其实我们采用了安全机制，比如公有云里面建立PC和私有云，所有的资源是不能直接 给外界的，在私有云我们又划分了若干子网，每个子网可以是一个公开访问的也可以是一个禁止公开的，在VPC和子网之间建立一个互联网网关，所有的互联网的都走的是我这个，在子网里面我们又可以划分不同的一些角色集群，比如我是应用程序集群，我数据库集群，我中间键集群，这些中间键开启相应的访问权限，把他们并不 给互联网。

共有云迁移Matrix

这里就是我们公有云迁移确定应用程序优先级的Matrix，分为两个维度，第一个横向的维度是技术风险，纵向的就是业务价值，通过这样的维度以后我们把每个应用程序放置在这样的象限里就可以选择对应用程序进行迁移。

第二步：调整部门组织结构-建立自服务机制

第二步进行公有云的迁移我们也进行部门组织机构的调整，建立自服务机制，大家看到右边这个图大家都笑了，今天早上乔帮主他们都同时说过一个问题不应该有Dev团队，就是你们自己要有而不是DevOps，我们为什么要在这里建立一个DevOpsteam，其实他讲了一个转型，而我们在做对这个金融组织进行DevOps转型的时候我们觉得创建DevOps是一个转型期，我们应该具备这样的团队，所以我们就组建了这样的团队。

事实证明它是收到非常好的效果。过去我们是中央运维团队处理各方来的请求，这样的特点就是我开发团队要部署了，比如双11之前我们要集中部署一大片服务，给运维团队发，他们都忙不过来。

审批是运维团队掌握生杀大全，我觉得你这个是不是通得过，我是等着你来。经过部门组织调整以后，我们就建立起了服务化的策略，也就是我基础设施平台和DevOps团队提供自服务的机制，就跟你去ATM机取钱，你想取多少都可以。

对应在我们运维的时候，比如我开发人员想在生产环境某台机器添加一个防火墙规则，以前是我发一个等待运维人员处理，那么现在是我们有一个界面你可以在界面上直接操作，我们也提供了相应的直接通过代码发的方式完成这个变更，整个过程都是全自动的。

有人就问万一我把恶意的IP地址加进去怎么办？是因为我们团队变成了一个审查制，你做了变更以后我们会审查你的变更是不是合理，如果不合理我们就会进行后续的处理，如果合理的话那么就被通过了。其实这样就建立了信用机制，开发团队要明白自己在干什么，运维团队把责任移交给了开发团队。

另一方面主动优化，今天下午听了一些讲师的分享，有个来自百度的运维专家说他们的团队50%的时间是处理日常性事物，50%的时间是在做一些优化和改进，他们觉得是不够的，因为谷歌团队只有30%的时间来进行日常的运维70%时间用来创新，建立这种服务化审查式的机制以后，其实运维团队很大程度解放了，就有时间来进行主动的优化。

DevOps团队承上启下

为什么要建立DevOps团队？因为我们想让DevOps起到一个承上启下的作用，就是既了解运维的难点又清楚产品团队的痛点，人们服务都提供API或命令行接口，向产品团队赋能，我们在谈论DevOps文化的时候经常会提到一点，就是同理心，我开发人员觉得你把这个包部署到那个机器上运行起来是非常简单的事情，你给我说要两分钟的时间。

为什么？运维团队说你的这个包有这个那个问题，为什么不早点改？因为他们没有建立同理心，没有通知我运维团队要进行一系列的操作才能真正的把这个运用程序运行起来。

运维团队也不知道产品团队很忙，要处理各种各样的事情，对于运维合规性一方面自身理解的不到位，另一方面也是没有时间，其实这些都是由于缺乏同理心的行为造成的。但是DevOps团队这些人一部分来自运维团队，一部分来自开发团队，所以两边的痛点和难点他们都是清楚的。

团队结构图

条业务线，DevOps团队我们有一个DevOps的部落，我们会有定期的活动，比如每个月进行一次活动，大家会分享一些知识和自己学到的东西，对遇到的问题也可以在这部落里找到答案，并且推广一些最佳实践。这样整个团队就会以一个不断前进的方式进行发展。

DevOps团队工作职责

DevOps团队职责分为四大块。

第一块是建立和维护持续交付生态圈


也就是我展示持续交付的一个流水线情况，其实那个图看起来简单。但是实现过程就是非常难的，因为对一个大型的组织来说他们的应用场景应用程序产品形态是非常不同的，你要为每一种不同类型的应用程序建立起这样的交付的生态环境还是需要很大量的工作量的。


第二块就是实验和实践在灾备方案和部署方案


我想到了前段时间有一个运维工程师在凌晨很晚的时候在执行运维工作敲错了一项命令，把数据库删了，结果DevOps号称有五重灾备机制，灾难恢复的时候他发现五重全部失效，最后他们再一个非常老旧服务器终於找到了数据库很久之前的备份，恢复以后至少有几千个信息是永远被丢掉了。


那么其实DevOps团队来设计这样的灾备方案并且验证这些方案，尤其是部署方案，比如说我们一直遵循我们想推广的部署，如下实现0级部署，我们的团队是需要进行学习的，需要进行研究的。


第三块是提升生产力


这里有一案例，我使用了24小时可以付24小时的费用，在很多公司来说当我们员工下班以后我们的开发环境其实是没有人在用的，我们就可以把它关闭。


第二天上班之前再把这些激起来，他们就做了一个公寓，你在创建任何一台结算节点的时候就会自动的打一标签，这个标签可以填上你希望它运行的时间，我们用另外一款工具会定时的观察这些集群的态势地级市的关闭或打开这些节点。


最后一块，就是向开发人员赋能

在这样的团队我们有各种各样的角色，有业务分析师、运维人员等等，在这样一个一个团队我们如何保证团队不同的角色技能达到要求，那么我们可以通过DevOps团队，由他们向这些产品团队进行一系列的培训，促使产品团队的技能达到快速的提升。

第三步：建立基础设施即代码的实践

基础设施即代码是一种释永信的技术来管理动态基础设施的方式，把基础设施、工具和服务以及对基础设施的管理本身作为软件系统，采纳软件工程实践以结构化的安全的方式管理对系统的变更。

基础设施即代码-使用DSL描述环境

我们如何采纳基础设施及代码？最观点的一点就是用领域特定语言描述环境，在这里在座的各位有没有人喜欢函数式编程？为什么很多人喜欢？也就是我想要什么直接写出来，DSL也是要达到这个目的，也就是我想要一个机器，即席里面要具备这样的东西，你写出来就可以了。

DevOps团队可以提供这样的DSL模板，传统团队使用这模板一演示的创建CI、SYS、UAT等环境，比如我的磁盘容量需要多少，需要预装哪些软件，你只需要写一个文件就可以了。环境自动与CD的流水线集成起来，生成持续交付流水线。

我点一个按纽就可以跟刚才那位老师讲的代码受限一样，我在创建正环境过程不需要任何人介入，只不过它已经进入Docker来创建环境和测试环境阶段，我们目前做到的可以通过代码了创建真正的一些实例。

基础设施即代码-一切都纳入版本管理

所以我们产品团队把产品代码测试代码构建脚本和数据库变更脚本和自动化的部署脚本都放在版本管理的时候，又可以有环境定义脚本，我拿到了一个应用程序的代码仓以后我想运行它，我只需要调一些命名来调用里面的环境定义脚本就可以了，再部署脚本就可以部署进去，所以中间不用问任何人，不需要问应用程序都需要哪些依赖，因为都是在一库里面。

第四步：建立平台化服务

最后一步就是建立平台化服务，也就是我们要真正的实现持续交付，必须要把生态圈建立起来，其实是非常重要的，比如我在大型公司做技术资讯和DevOps资讯的时候我发现开发人员的痛苦就在于我真想学习新技术，我在公司里是没法学的，不是有人阻止你。

我在产品开发过程我要使用一些日志服务，在我的磁盘上我看这些日志的时候需要登录一台机器，这些事情都说明了你的持续交付生态圈没有建立起来，我要建立起第三方架包的代理和对APM代理，我能不能方便的让开发人员轻松的获取这些。

另一方面我在开发软件的过程能不能很方便的使用各种各样的工具来把我们的一些运维工作提前的集成起来，比如日志管理平台等等，能不能方便的和产品集成起来，这是非常关键的。

所以说这就需要DevOps团队来统一提供一些平台，让产品团队自助的使用。金融组织在实现这些平台的时候我们给他建议不要自己研发，你是金融行业，你不是做工具的，做工具和产品是不一样的，你最好买一些商用的软件或者使用一些开源性的软件使用。

有些人有就说了我的需求不一样，我觉得这些工具满足不了我的需求，我就问他你的需求为什么不一样你没有仔细想过，这些好多人都采用了，为什么到你这玩不转了，是不是你的需求过于奇葩？是不是你的需求就不是你要解决的问题所在。

经过这样的反思以后我们就可以发现我们在采纳一款工具的时候就会更容易。这里列出了统一日志管理平台，DevOps平台需要提供相应的日志管理接口，高可用的日志查询引擎与企业内部其他系统集成。

产品团队需要建立起符合规范的日志，还有接入日志管理平台和定制日志管理需求，我们团队要建立中心式调度平台以及提供构建包调度中心，提供依赖库管理，他们只需要创建Slave接入调度平台，配置继续交付管道。DevOps团队需要提供统一系统级监控平台，通用性应用层监控和运营分析提供等。

建立平台化服务-准则

建立平台化服务的准则第一个是要提供最专业级出色的服务，也就是DevOps团队不要提供自己研发的不好的项目，第二个就是要契合开发团队的痛点，你要抓住关键的瓶颈，而不是自己想一些功能对开发团队带来帮助，最后就是优化再优化，比如我的日志搜索平台，开发人员觉得很慢，你就得优化。

总结-DevOps落地的核心要素

最后总结我们DevOps落地的核心要素主要三条。

• 第一个，就是建立自服务的审查式的机制；
  
  

• 第二个，就是Automation，一切自动化；
  
  

• 第三个，就是Sharing，让每个人都具备相应的技能；
  
  

DevOps并不是银弹

最后DevOps并不是银弹，在座的各位来到这个会上一定抱着各种各样的问题来的，但是DevOps真的不能解决你的所有问题，但是考虑DevOps落地的时候我们可以从五个方面着手，这是优先级，人、准则、时间、产品、流程。

因为一百多年前工业时代，其实他们更注重流程，那个时候产品比较匮乏，用户对产品的质量要求不高，最后才是人，因为你只要机械的进行操作就可以了。但是在如今我们已经进入了知识经济的时代，我们需要人来创造知识进行创新，我们创新的过程也要遵循一定的准则，就不能跑偏了。

第三个就是实践，也就是我要做的事情，我们要不断的优化改进，第四个是产品，我们IT部门做事情的时候要以对待产品的态度来做事情，而不是以对待项目来做。

这个是什么意思？如果我是以做产品的态度来做事情的话，那么我自然会考虑我的运维问题，但是以做项目的方式来做，做完以后扔给运维团队就可以了地这样质量怎么提高？

最后才是流程，就像早上我分享的时候有一个讲师说他们在谷歌是没有流程的，因为流程固化到工具里面了，所以我们的流程是可以变的，只要我们建立一致的目标。

原创：黄博文

前言

本文根据DevOpsDays北京站演讲记录整理而成，着重介绍 DevOps 在传统金融组织中的落地实践经验。

今天我给大家带来的演讲话题是传统金融组织DevOps落地实践。

我平常喜欢写代码，喜欢把中间的思考过程写成文章，我也喜欢研读国内外的优秀书籍，再翻译成中文，前后翻译五六本书。

业余时间我也是一个马拉松爱好者，以前跑42公里我都觉得了不起，但是去年开始尝试更长的距离，比如五十公里一百公里等。刚才看到还有一个爱好者，也是倍感欣慰。

背景介绍

我们先对这家金融组织进行一个简单的背景介绍，这家金融组织它是本土最大的金融资产集团，总资产1000亿美元，房地产行业市场份额做到全国前三，他们国家每一百个人中至少就有一个人买过他们的保险产品，这家集团旗下拥有银行、一般保险寿险等不限，市场上二十多个品牌。

因为随着近几年业务的发展，他不断的收购同业的公司累计起来的，由于它是一个金融组织，所以这就说明它本身不具备互联网基因。所以他们的组织体系可以分为两个部门，一个是业务部门，对接前面的消费者。第二个就是ID务部门，在背后为业务进行支撑。

我今天分享的DevOps落地实践主要是分享IT部门如何使显得。今天早上我相信很多人已经听了我们的其他演讲，在讲DevOpsleave也就是DevOps可以把业务领域涵盖进去的，当然这个业务不在我这次分享之内。

那年，它的困境

09年这家巨无霸的企业面临各种各样的问题，内忧外患，外部来说它是处于开放性的金融市场，他们的法律比较完备，市场竞争非常白热化，不仅要面临他们国内的保险行业银行行业的竞争，还要随时面临国外资本的入侵。

另外他们的产品创新法缺乏新的业务增长点，比如09年他们的在线销售保险系统其他的都不支持，任何的端点都没有他们的产品。从内部来说，由于他们在过去十多年间收购了很多家公司，就导致了他们的组织机构非常的效率低下。

举个例子，做卖保险大家可能很多人都听说过life400，像这样类似的系统在他们公司内部多达十几个，也就是所有的保单都分布在这十几个当中。内部还存在问题就是人员增长遇到瓶颈，人才流失严重，人才流失以后去到他们的竞争公司里了。

转型之路

所以从06年开始，他们其实已经启动了敏捷转型，整个软性的时间也是非常长的，从06到13年只是完成一个阶段，这里并不是说2013年以后说明敏捷转型成功，其实敏捷倡导持续改进，所以他们一直在改进当中。

那么在这么多年中，他们的敏捷转型主要是进行了三大部分的改进。

第一部分就是组织结构调整


从这里我们就可以看到敏捷改进其实是需要自上而下的，因为我们通常说屁股决定脑袋。组织结构调整包括企业统一化、组织统一化、运营合一化，以前我有十几个业务线，我们就要进行一些裁减合并。


第二部分就是遗留系统优化


我们根据抗非定律来说肯定会对IT系统进行调整，方式就是简化我们后台系统，比如说我们后台有个客户管理关系系统，当时他们客户关系管理系统就有七八个，随着遗留系统优化以后最后只缩减成了一个。还有他们的理赔系统也是，也由七八个缩减至一个。


另外一个很重要的IT改进就是它的统一数字渠道，也就是保险的售卖一般分为两个途径，一个途径就是通过各种各样的代理，通过他们的IT系统以及电话系统进行售卖。


还有另一种方式就是在线售卖，他们面临很多很多的品牌，很多的品牌再加上很多的数据系统组合起来对于IT部门的压力是非常大的，系统简化以后他们实现了一套规则，把他们所有的系统全部外部化。


通过外部的方式就可以使用，把他们的样式也给归一。这样既可以增加消费人员对于他们品牌的认同感，另一方面也简化了IT部门的开发工作量。


第三部分就是打造持续交付。


前面我把基础的差不多了，可以放开手脚干了，比如以前没有收益银行现在就可以做一个。比如我们要拥抱最新技术，12年的时候我们就有一个网站做了一个系统，不断的往里面存钱，看到的画面是不一样的。


到了13年我们就逐步想打造这样的持续交付流水线，13年很多功能都已经实现了。这个图我们可以看到我们核心的输入点是我们的白马控制库，我们会把我们所有的代码不放在里面，包括我们的应用代码还有测试代码包括构建脚本以及相应的部署脚本和环境准备脚本，全部放在我们的版本控制力。



产品团队交付流水线

我们再建立我们的持续集成服务，通过持续集成服务调动我们的构建脚本对我们的代码建立准入机制，把它全放在我的产出管理里。

我们通过一些工具实现我们的部署流水线，并在我们的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提供的，但是有了公有云以后你会使用它提供的服务替代。

另外一方面也可以减少自建收费中心的压力，比如说每一个数据中心要各自维护各自的服务器升级，以及我的数据库备份的问题，其实公有云已经对最基本的运维问题提出了一系列的非常简单的解决方案，也就是我运维再也不用考虑这些问题，我只要使用他们提供的就可以了。

对于开发人员的好处，第一个就是自服务机制，以前我记得有一段时间我刚加入一个团队的时候，我说我要有一台机器作为我的桌面，结果这个流程其实走了三周的时间，但是使用了公有云以后有一次我想创建一个虚拟桌面来进行验证一些问题，我只用了短短的十分钟就实现了。

这是因为我创建计算资源的时候我可以直接调用一些接口直接实现，中间不需要任何人的介入。带来的另一个好处就是直接带来了高可用的弹性伸缩，我们在设计产品的时候可以充分利用各种的资源。比如说我们之前一般的保险金融组织有一个计价模块，计价的时候我们需要把计价所有的日志全部记录下来，而这个日志每天产生的数据量大概是100G左右。

我们为了解决这个问题，当时伤透了脑筋，使用各种各样的磁盘阵列，不断的扩容我们的磁盘存储，想了很多方案，但是始终满足不了需求，最后使用公有云以后问题非常简单了。

我们直接使用他们提供的高可用的存储技术轻松的把我们这些日志全部存储上去了。其实公有云的整个过程不是一蹴而就的，我们前后花了三年多的时间才把大部分的服务迁移到公有云上，只剩下无法在云上运行的，还有一些核心的数据，比如客户的数据，还是存在自己的数据中心。

公有云迁移策略

那么在整个迁移的过程我们遵循一个原则是什么？首先我们要设计我们的公有云架构，我们如果把公有云当做我们的数据中心我们公有云应该具备什么样的设置？

我们根据workspace建立业务线资源隔离，里面又分为Non-prod和prod两套环境，设计这样的公有云架构以后我们就把现有的基础设施个公有云进行对接，比如我们现有的这十几个数据中心要和公有云对接，对接过程我们要考虑很多问题。

公有云里的私有云

第一点，公有云本身的认证方式和企业现有SSO的集成


那么我们实现的方式就是根据公有云提供的接口实现了和企业现有SSO的集成，也就是你想要访问某些资源你要申请一下就可以了，跟其他的数据中心资源一模一样。


我们企业都有自己的认证系统，我们不可能再在公有云设置一个认证系统，企业员工使用的时候在这两条系统之间进行切换，这样对企业用户来说是不友好的，对于企业的运维来说也是比较麻烦的。


第二点，实现公有云与现有设施的直连


比如我们的后端的某些数据库是我们本地的数据中心的，我们前端的一些服务还是在我们的云上的，那么为了不影响效率，我们就建立这种直连机制。


另外就是要实现公有云与基础设施的VPN连接，实现以后公有云创建所有的资源IP地址都是我们内网地址，我在使用它的时候和我使用其他数据中心的这些资源方式都是一模一样的，根本就不用进行任何切换。当然还有内部DNS服务的互通。


第三点，准备这些基础设施以后我们就可以进行应用程序的迁移


我们要遵循优先级，我们就要先迁移技术风险低业务价值高的，我们买保险的时候有保险介绍的页面，你是通过这些静态页面链接到购买系统和自服务系统的，对这样的应用来说迁移的难度最小，但是带来的价值最大。


迁移时尽量不涉及对应用程序架构的变更，所有服务仍然属于原有架构。我们谈迁移很多人就非常激动，他说我终于可以把以前老旧的换掉了，我可以使用一些收费便宜的甚至免费的数据库，但是如果你抱着这样的想法那你在迁移中无疑增加了难度，所以我们把应用程序的变动放在最后一步的，再进行应用程序的互换。


比如说我们把本地数据库替换成数据库服务，DES，然后我们本地的一些消息队列也替换成云上的消息队列，甚至是我们把非生产环境的操作系统全部换成一些免费的发行版，进一步减少花销。

我们是如何在公有云里面保证我们对数据的安全性呢？

其实我们采用了安全机制，比如公有云里面建立PC和私有云，所有的资源是不能直接 给外界的，在私有云我们又划分了若干子网，每个子网可以是一个公开访问的也可以是一个禁止公开的，在VPC和子网之间建立一个互联网网关，所有的互联网的都走的是我这个，在子网里面我们又可以划分不同的一些角色集群，比如我是应用程序集群，我数据库集群，我中间键集群，这些中间键开启相应的访问权限，把他们并不 给互联网。

共有云迁移Matrix

这里就是我们公有云迁移确定应用程序优先级的Matrix，分为两个维度，第一个横向的维度是技术风险，纵向的就是业务价值，通过这样的维度以后我们把每个应用程序放置在这样的象限里就可以选择对应用程序进行迁移。

第二步：调整部门组织结构-建立自服务机制

第二步进行公有云的迁移我们也进行部门组织机构的调整，建立自服务机制，大家看到右边这个图大家都笑了，今天早上乔帮主他们都同时说过一个问题不应该有Dev团队，就是你们自己要有而不是DevOps，我们为什么要在这里建立一个DevOpsteam，其实他讲了一个转型，而我们在做对这个金融组织进行DevOps转型的时候我们觉得创建DevOps是一个转型期，我们应该具备这样的团队，所以我们就组建了这样的团队。

事实证明它是收到非常好的效果。过去我们是中央运维团队处理各方来的请求，这样的特点就是我开发团队要部署了，比如双11之前我们要集中部署一大片服务，给运维团队发，他们都忙不过来。

审批是运维团队掌握生杀大全，我觉得你这个是不是通得过，我是等着你来。经过部门组织调整以后，我们就建立起了服务化的策略，也就是我基础设施平台和DevOps团队提供自服务的机制，就跟你去ATM机取钱，你想取多少都可以。

对应在我们运维的时候，比如我开发人员想在生产环境某台机器添加一个防火墙规则，以前是我发一个等待运维人员处理，那么现在是我们有一个界面你可以在界面上直接操作，我们也提供了相应的直接通过代码发的方式完成这个变更，整个过程都是全自动的。

有人就问万一我把恶意的IP地址加进去怎么办？是因为我们团队变成了一个审查制，你做了变更以后我们会审查你的变更是不是合理，如果不合理我们就会进行后续的处理，如果合理的话那么就被通过了。其实这样就建立了信用机制，开发团队要明白自己在干什么，运维团队把责任移交给了开发团队。

另一方面主动优化，今天下午听了一些讲师的分享，有个来自百度的运维专家说他们的团队50%的时间是处理日常性事物，50%的时间是在做一些优化和改进，他们觉得是不够的，因为谷歌团队只有30%的时间来进行日常的运维70%时间用来创新，建立这种服务化审查式的机制以后，其实运维团队很大程度解放了，就有时间来进行主动的优化。

DevOps团队承上启下

为什么要建立DevOps团队？因为我们想让DevOps起到一个承上启下的作用，就是既了解运维的难点又清楚产品团队的痛点，人们服务都提供API或命令行接口，向产品团队赋能，我们在谈论DevOps文化的时候经常会提到一点，就是同理心，我开发人员觉得你把这个包部署到那个机器上运行起来是非常简单的事情，你给我说要两分钟的时间。

为什么？运维团队说你的这个包有这个那个问题，为什么不早点改？因为他们没有建立同理心，没有通知我运维团队要进行一系列的操作才能真正的把这个运用程序运行起来。

运维团队也不知道产品团队很忙，要处理各种各样的事情，对于运维合规性一方面自身理解的不到位，另一方面也是没有时间，其实这些都是由于缺乏同理心的行为造成的。但是DevOps团队这些人一部分来自运维团队，一部分来自开发团队，所以两边的痛点和难点他们都是清楚的。

团队结构图

条业务线，DevOps团队我们有一个DevOps的部落，我们会有定期的活动，比如每个月进行一次活动，大家会分享一些知识和自己学到的东西，对遇到的问题也可以在这部落里找到答案，并且推广一些最佳实践。这样整个团队就会以一个不断前进的方式进行发展。

DevOps团队工作职责

DevOps团队职责分为四大块。

第一块是建立和维护持续交付生态圈


也就是我展示持续交付的一个流水线情况，其实那个图看起来简单。但是实现过程就是非常难的，因为对一个大型的组织来说他们的应用场景应用程序产品形态是非常不同的，你要为每一种不同类型的应用程序建立起这样的交付的生态环境还是需要很大量的工作量的。


第二块就是实验和实践在灾备方案和部署方案


我想到了前段时间有一个运维工程师在凌晨很晚的时候在执行运维工作敲错了一项命令，把数据库删了，结果DevOps号称有五重灾备机制，灾难恢复的时候他发现五重全部失效，最后他们再一个非常老旧服务器终於找到了数据库很久之前的备份，恢复以后至少有几千个信息是永远被丢掉了。


那么其实DevOps团队来设计这样的灾备方案并且验证这些方案，尤其是部署方案，比如说我们一直遵循我们想推广的部署，如下实现0级部署，我们的团队是需要进行学习的，需要进行研究的。


第三块是提升生产力


这里有一案例，我使用了24小时可以付24小时的费用，在很多公司来说当我们员工下班以后我们的开发环境其实是没有人在用的，我们就可以把它关闭。


第二天上班之前再把这些激起来，他们就做了一个公寓，你在创建任何一台结算节点的时候就会自动的打一标签，这个标签可以填上你希望它运行的时间，我们用另外一款工具会定时的观察这些集群的态势地级市的关闭或打开这些节点。


最后一块，就是向开发人员赋能

在这样的团队我们有各种各样的角色，有业务分析师、运维人员等等，在这样一个一个团队我们如何保证团队不同的角色技能达到要求，那么我们可以通过DevOps团队，由他们向这些产品团队进行一系列的培训，促使产品团队的技能达到快速的提升。

第三步：建立基础设施即代码的实践

基础设施即代码是一种释永信的技术来管理动态基础设施的方式，把基础设施、工具和服务以及对基础设施的管理本身作为软件系统，采纳软件工程实践以结构化的安全的方式管理对系统的变更。

基础设施即代码-使用DSL描述环境

我们如何采纳基础设施及代码？最观点的一点就是用领域特定语言描述环境，在这里在座的各位有没有人喜欢函数式编程？为什么很多人喜欢？也就是我想要什么直接写出来，DSL也是要达到这个目的，也就是我想要一个机器，即席里面要具备这样的东西，你写出来就可以了。

DevOps团队可以提供这样的DSL模板，传统团队使用这模板一演示的创建CI、SYS、UAT等环境，比如我的磁盘容量需要多少，需要预装哪些软件，你只需要写一个文件就可以了。环境自动与CD的流水线集成起来，生成持续交付流水线。

我点一个按纽就可以跟刚才那位老师讲的代码受限一样，我在创建正环境过程不需要任何人介入，只不过它已经进入Docker来创建环境和测试环境阶段，我们目前做到的可以通过代码了创建真正的一些实例。

基础设施即代码-一切都纳入版本管理

所以我们产品团队把产品代码测试代码构建脚本和数据库变更脚本和自动化的部署脚本都放在版本管理的时候，又可以有环境定义脚本，我拿到了一个应用程序的代码仓以后我想运行它，我只需要调一些命名来调用里面的环境定义脚本就可以了，再部署脚本就可以部署进去，所以中间不用问任何人，不需要问应用程序都需要哪些依赖，因为都是在一库里面。

第四步：建立平台化服务

最后一步就是建立平台化服务，也就是我们要真正的实现持续交付，必须要把生态圈建立起来，其实是非常重要的，比如我在大型公司做技术资讯和DevOps资讯的时候我发现开发人员的痛苦就在于我真想学习新技术，我在公司里是没法学的，不是有人阻止你。

我在产品开发过程我要使用一些日志服务，在我的磁盘上我看这些日志的时候需要登录一台机器，这些事情都说明了你的持续交付生态圈没有建立起来，我要建立起第三方架包的代理和对APM代理，我能不能方便的让开发人员轻松的获取这些。

另一方面我在开发软件的过程能不能很方便的使用各种各样的工具来把我们的一些运维工作提前的集成起来，比如日志管理平台等等，能不能方便的和产品集成起来，这是非常关键的。

所以说这就需要DevOps团队来统一提供一些平台，让产品团队自助的使用。金融组织在实现这些平台的时候我们给他建议不要自己研发，你是金融行业，你不是做工具的，做工具和产品是不一样的，你最好买一些商用的软件或者使用一些开源性的软件使用。

有些人有就说了我的需求不一样，我觉得这些工具满足不了我的需求，我就问他你的需求为什么不一样你没有仔细想过，这些好多人都采用了，为什么到你这玩不转了，是不是你的需求过于奇葩？是不是你的需求就不是你要解决的问题所在。

经过这样的反思以后我们就可以发现我们在采纳一款工具的时候就会更容易。这里列出了统一日志管理平台，DevOps平台需要提供相应的日志管理接口，高可用的日志查询引擎与企业内部其他系统集成。

产品团队需要建立起符合规范的日志，还有接入日志管理平台和定制日志管理需求，我们团队要建立中心式调度平台以及提供构建包调度中心，提供依赖库管理，他们只需要创建Slave接入调度平台，配置继续交付管道。DevOps团队需要提供统一系统级监控平台，通用性应用层监控和运营分析提供等。

建立平台化服务-准则

建立平台化服务的准则第一个是要提供最专业级出色的服务，也就是DevOps团队不要提供自己研发的不好的项目，第二个就是要契合开发团队的痛点，你要抓住关键的瓶颈，而不是自己想一些功能对开发团队带来帮助，最后就是优化再优化，比如我的日志搜索平台，开发人员觉得很慢，你就得优化。

总结-DevOps落地的核心要素

最后总结我们DevOps落地的核心要素主要三条。

• 第一个，就是建立自服务的审查式的机制；
  
  

• 第二个，就是Automation，一切自动化；
  
  

• 第三个，就是Sharing，让每个人都具备相应的技能；
  
  

DevOps并不是银弹

最后DevOps并不是银弹，在座的各位来到这个会上一定抱着各种各样的问题来的，但是DevOps真的不能解决你的所有问题，但是考虑DevOps落地的时候我们可以从五个方面着手，这是优先级，人、准则、时间、产品、流程。

因为一百多年前工业时代，其实他们更注重流程，那个时候产品比较匮乏，用户对产品的质量要求不高，最后才是人，因为你只要机械的进行操作就可以了。但是在如今我们已经进入了知识经济的时代，我们需要人来创造知识进行创新，我们创新的过程也要遵循一定的准则，就不能跑偏了。

第三个就是实践，也就是我要做的事情，我们要不断的优化改进，第四个是产品，我们IT部门做事情的时候要以对待产品的态度来做事情，而不是以对待项目来做。

这个是什么意思？如果我是以做产品的态度来做事情的话，那么我自然会考虑我的运维问题，但是以做项目的方式来做，做完以后扔给运维团队就可以了地这样质量怎么提高？

最后才是流程，就像早上我分享的时候有一个讲师说他们在谷歌是没有流程的，因为流程固化到工具里面了，所以我们的流程是可以变的，只要我们建立一致的目标。

原创：黄博文