感谢大家！今天我跟大家分享的话题是在大型的互联网公司做金融项目DevOps转型实践。首先做个简单的自我介绍，我叫张乐，之前一直在百度的工程效率部负责百度的战略产品和重点项目的敏捷和DevOps转型工作。我的工作重点是推动很多研发模式相对传统的团队和项目去拥抱敏捷、拥抱DevOps的方式，提升其工程的能力和效率。目前我是DevOps时代和高效运维社区的合伙人，主要做DevOps方向。
一、DevOps转型的背景
在开启正式的话题前，想用一点时间来和大家分享我们为什么要做DevOps转型。因为在一些稍微传统的企业，以及一些互联网公司，其实有不同的IT项目管理方式。近两年，很多的论坛、大会等不同的场合、朋友圈的文章都在转很多与DevOps相关的技术话题。那么我们首先要深入理解为什么需要DevOps，为什么需要进行转型。
今天到场的是非常资深的，在银行、保险行业的一些专家。其实我们一直在想一个问题，之前很多年，我们在做项目管理、软件研发的过程中用了很多传统的经典模式，如软件工程的方法，CMI、PMP等方法，这些方法在当前的时代背景下继续运行时有哪些挑战和问题，为什么我们必须要拥抱敏捷化、向DevOps转型，都是值得考虑的问题。
上图的名称为IT演进路线图。从图中可以看到，其实我们在做的很多相对传统一些的软件研发模式来自哪里？大概数十年前，1960年代首次提出了软件工程的概念。随着个人计算机和软件的发展，需求日益复杂，我们做项目时的成功率会越来越低，比如我们经常会碰到延期、预算超支，虽然投入了很多精力，但项目的质量、功能没有保障。因此，当时提出了一个软件工程的方法，强调通过一个系统化、工程化的方法帮助我们规范化整个软件研发过程。其中便提出了一些关键点，比如流程是重管控的，我们所说的包括瀑布式模型等方法都是重管控、结构化的方法，这是之前我们用的比较多。
时代是不断向前发展的，在2000年时互联网爆发，2010年是移动互联网的时代，到目前大家谈的比较多的是人工智能或AI、物联网。那么在这个时代背景下能否用比较传统的方式去管理软件研发过程？这里提出一个比较大的挑战。其中有一个小的图，即总结我们所处的新常态的特点，这里用“VUCA”四个英文字母，分别代表着易变性、不确定性、复杂性和模糊性。我们在当前的环境中可能都非常感同身受，尤其是在互联网公司中，我们的环境其实是瞬息万变的，我们的用户需求是多种多样的，包括一些政策的约束、监管的要求，变化的频度的是非常快的。在这个充满不确定性、变化性的环境里面如果再用相对比较传统的方式，基于预测性、基于管控的方式去做整个软件研发、做IT服务的话，会面临非常大的挑战。例如传统的方法在一定情况下可能会尽量避免或拒绝变更，以原来的一个计划为例，当时本想按照这个计划完成，那这个项目可能是成功的。实际上在这个过程中有新的需求，这个需求如果是合理的，我应该拥抱这个变化，且尽量适应这种变化。因此在目前的场景中，尤其在VUCA这个新常态下，我们做一个系统、软件，IT应该是强调以下几点：适应性、快速交付价值、灵活响应变化。这些也是我们为什么谈了什么多敏捷、精益，DevOps主要目标就是这个。所以今天首先有一个大的背景来跟大家做个说明，就是说我们需要去适应变化，而且任何做软件研发的方法，包括DevOps方法其最主要的目标还是要支持业务的最大化产出。我们不是说追求有很多新的技术、方法，而是说用了这个方法后IT的支撑能力是否更强了，真正使IT变成业务的一种竞争的优势。比如我可以比别人更快地发布软件、可以更快地响应市场需求，这样我的竞争能力会有很明显的提升。因此，这是我们做DevOps的一个大的背景。
二、面对目标，如何转型
1.研发模式
不论是企业内部还是很多的项目内部都开始做敏捷的转型工作。由于“敏捷宣言”提出已经有十多年的时间了。如果做敏捷转型，基本都要做两件事情，第一件事情是整个研发模型可能会有变化。比如在原来的模型更倾向于严格的阶段划分，每个阶段严格控制准入准出。比如瀑布模型，从需求到设计、实施、验证、维护，一个个步骤下来，每个步骤都有严格的研制、流程的遵守，它是非常偏重流程的。在传统的软件研发过程中，如果你觉得某个阶段有问题，你可能更倾向于使这个流程变的更重，这是稍微偏向传统的一种模式。
就敏捷的方式而言，其中有很多的流派，上图便是一种敏捷研发的方式。它有几个很重要的观点：第一，它是一个大家协作的最简化模型，比如我们的需求不再以一个很重的文档去表示，而是以一个需求列表去表示。人员做到最大程度的精简，分了三种角色，分别为产品负责人、团队以及项目经理三种角色。这些人在一起协作，每天都要同步其进度。这是在做比较标准的敏捷转型基本都会做的事。
2.组织结构
组织结构可能会有一个变化。比如原来更倾向于在开发、设计、测试、运维等不同的部门有不同的职能线，每一个部门是偏竖井的模式，每个职能线分工是非常细化的，它是通过各种深耕有一个专业化运作。但这种模式也有一些的问题，比如缺少整体的目标感，对于一个系统开发而言，它需要穿透所有的部门，在部门间的交接会占据很大的代价。
因此在偏向敏捷的方式中，我们更倾向于右边的组织结构的模型，即跨职能团队，也就是说根据系统、服务、需求，每一个需求可能拉出一个横向的跨职能团队，其中包含了不同的角色，有产品人员、开发、测试、运维，不同的人员在一个小的团队中运作，这样他通过一个统一的目标驱动，能减少相互交接的损耗，变为一个自主的团队。
上述的两种模式，基本任何一个做敏捷转型的企业或团队基本都会来做。但这其实不是我想讲的重点。我想讲的重点是什么呢？在经历了很多的项目、团队之后，我们会发现你采用了以上的两种技术，很有可能得到的效果其实没有预期好，或者说你花了很大的代价做敏捷转型，你可能请了一个外部的顾问帮助你运行了很长时间，但你会发现端到端的效果不是很明显，研发周期还是很长，部门墙可能有一部分打破了，但响应最终用户需求周期还是非常漫长的。是什么问题导致的这么一个问题呢？比如我们都是国内很大型的系统，有一百个系统，然后在做一个整体大的项目时倾向于在这个项目前期的时候有一个集中化的部门，比如PMO或PMO及Finance部门，去做市场调研、确定项目的章程。然后由PMO部门去做整体项目高阶的计划。随后将这个计划分解到很多的子系统中做相应的软件研发，那每个子系统中可是用刚才提到的敏捷方式，如果我们是一个小团队的运作，以不同迭代的方式去做研发的过程。但大多会有一个集中化的QA、集中化集成的阶段，将这些子系统集成在一起，因为只有这些系统集成在一起的时候才能对最终用户产生价值。这里会有一个特别有意思的点，看上去每个团队可能都说我很敏捷了，但对端到端的效果、对用户的感知是非常不明显的。由于有一个整体的集成点，这个点很有可能变为全局的阻塞点，我们没有真正做到并行、端到端的敏捷。
三、实际案例
1.问题现象
有四五十个系统，如果其中的两三个系统出了比较严重的问题，时间没有保证，整体进度都会受到很严重的影响。因此我们只做局部的优化是无法帮助我们端到端获得价值的。于是我们希望用一个更好的方法帮助我们来解决这个问题。
上图是我在去年去辅导的项目群，做敏捷转型和DevOps实施中的一个真实场景。当时遇到的问题是说大概有涉及到不同的6个以上的部门，大概有300个人员的规模，大概涉及到的系统有50个。可能在座的各位领导觉得这个系统规模不算很庞大，但对于一个互联网公司而言，做这种金融项目，这个规模还可以。当时遇到的问题是，在之前已经开始做敏捷方面的转型了，但效果不是很明显，整个交付周期还是很长。从领导的角度来讲，这里给了一个不是很量化、很定性的描述，整个研发周期还太长，经常被业务部门投诉说产能不足，IT跟不上业务的发展，有的时候一个月才能发布一个大的版本。大家知道，在一个互联网公司每月发一个版本，还是比较挑战的事情。还有很多线下出现的问题，会消耗很多精力来去排查。
2.问题分析
那么我们做整个改进时，定性的问题还不够，需定量分析，于是我就用精益里的方法，比如说作业成本分析法，分析整个研发周期中每个部分的组成是什么。这里会有不同颜色的区分，比如灰色的部分，多个团队多个系统在并行开发，大概有两周多的时间12天。然后有5天的时间做一个整体的集成，有8天的时间做端到端的验证、验收和测试，8个小时做整体的上线。上图其实已经能看出问题，向领导汇报时，实际上只有46%的时间是有效的增值时间，而54%的时间是什么呢？是非增值但必要的时间，比如做集成、测试。这部分时间对你的业务价值交付是无效的，因为它是非增值时间但又是必要的。从精益的角度来看，我们需要最大化增值的活动，尽量减少非增值但是必要的活动，也就是橙色和黄色的部分。
3.问题定位
思路确定后，下一步我们再将这个问题进一步分解，为什么这两部分的周期中花了这么长的代价、时间。这里又细分出三个问题：
第一个问题是系统架构是紧耦合，有相互影响和阻塞。比如多个子系统看上去都很敏捷，但它们还是绑着腿一起跑。我们讲牵一发动全身，如果一个系统出现了问题，可能整个版本都会阻塞，这是一个大的问题，这是架构的问题。
第二个问题是对于质量过程中控制的问题。我们经常会发现，为什么后面的周期这么长，会发现说我在A系统中的问题，通过B系统排查，B系统排查完后觉得是C系统的问题，而C可能是个通道，最后是D系统的问题，这样导致整个的排查链路很长、解决问题的链路也很长，你在最底层的系统解决问题时，前面所有的系统都在等待，因此这个周期也是导致后面很长的原因。
第三个问题是整个环境交付，比如没有做到容器化、线上线下不一致。环境没有问题，在线上可能会有一些故障出现，包括整个上线的过程也很痛苦。看起来半个小时做一个整体的上线还好，但经常会发现一个问题，因为我们这个系统也是一个金融系统，我们也不倾向于有很长时间的停服，会发现我们在夜间上线时是一个串性的，可能排在最后一个上线系统到凌晨5点还没开始上，这对大家来讲是非常难受的一个事情。因此，我们看到这些问题就在想通过什么样的方式帮助我们解决这个问题，通过什么方式帮助我们端到端的去提升其能力。
四、DevOps的实施
DevOps这个词有很多的说法和理解，它其实就是两个词拼起来的，一个是Dev，指开发或开发+测试，Ops是指运维。DevOps最粗浅的理解是开发和运维一体化。那么我们再用一句话去说明DevOps到底是什么，我们可以认为它是一个构建IT交付的供应链。就是端到端的，从需求、设计、开发到测试、上线、部署，最后交到用户手中，将整个过程认为是一个供应链的方式去存在，是完全自动化和高效的。我们提出了三个大的方向去实施DevOps：一是全局化视角；二是系统化思考；三是最佳实践的导入。每一块其实都有非常多的内容。我们现在将每一块来跟大家做个简要的介绍。
一、全球化视角
其实很多人在问，敏捷和精益到底是什么关系，和实际交付是什么关系。这张图我是截自于DevOpsMaster白皮书。实际上我们看上面的部分是整个软件的研发周期，从计划、需求、设计、开发、部署、上线的整个过程。在敏捷的项目管理中更注重从计划、需求到设计和开发部分，它主要作用于这个部分去增强效率。像持续交付是注重开发、部署到运营部分。ITSM其实更多是在运营个阶段。这是三个主流的方法。下面一个很关键的内容便是精益思想，它不是一种技术，而是一种贯穿于整个研发流程的一种思路。比如这里提出了单件流、JKK，有很多思路。后面我们再结合一些实例跟大家去看，这些思路如何帮助我们真正做到端到端的优化。因此上图至少帮助我们分析一个思路，我们做一个端到端的优化你要考虑这些点。这些点都做到了，才能帮助你端到端的产生价值。
刚才谈到精益，上图画了一个比较形象的示意图。比如我们去看病，图中女士去看病，她初次去是去社区医院，社区医生说看不了，需要去一个三甲医院，然后她去排队。大家知道在北京看病，尤其是比较好的医院，需要提前很长时间预约。她等待了几天时间到这个医院的影像和超声科做挂号和预约拍片子，而这个医院的医生推荐她去专科医院看病，然后她又等了很长时间来到专科医院，专科医院说要做一个深度的检查，做生理切片的检查，又等了很长时间，一周后这个结果终于出来了，她要返回到专科医院去做进一步的治疗。大家看到整个的周期，从初次接触到整个确诊大概是42天的周期。我们都去医院，我们会发现医生是非常繁忙的，去一个医生的办公室在门口排了很多队，基本医生连写字的时间、喝水的时间都不够，他们很忙，但从我们患者来讲这个体验不是很好。
那么映射到做IT的，我们的业务部门很忙，开发部门很忙，测试部门很忙，每一个部门的利用率都是100%、120%，每天都在加班，但从需求的角度来看，整个周期还是很长。因此这表现出一个问题，即我们追求了片面的资源利用率，但不代表这个事情做得很好。
还有一个更好的方式是什么呢？比如我们去体检中心，基本年度体检半天就能做完。是不同的科室在一起，是一站式的方式。这样两小时就完成了初次接触到确诊。刚才谈到一个精益的思路，其中有一个很核心的点是指我们的关注点不要只放在资源的利用率，而是逐步的调整到价值的流动效率。这便是这张图给我们的启示，单纯追求某一部分的资源利用率不利于整个价值的交付。因此我们要看流动效率时，要进入到第二个关键点，即系统化思考。
2.系统化思考
我之前在百度负责公司DevOps转型的，我设计了一个在DevOps和持续交付领域的一个模型。这里有四个部分：业务、流程、组织和技术。核心就是我画的红框部分。最终我们要形成一个IT交付的流水线，我们叫可靠可重复的流水线。其实我们就相当于汽车生产过程的一个流水线，每个部件在流水线上面运过来，工人做协作，通过高度自动化的方式，快速生产出一辆汽车。这在工业生产领域是一个非常大的改进。我们做IT的也可以借鉴在工业生产领域的模式，我们能否从需求确认到代码提交、测试验证、部署运维，所有过程变成一个全自动化的和自助式的流水线，通过流水线的运作帮助我们将任何机器能做的，计算机能做的，让它们自动去做，人只做决策。我们刚才说从资源利用率到流动效率，流动效率最终具化变成流水线，这是我们一个主要的核心思路。
当然配合这个思路的达成还要做很多事情，比如管理维度的精益和看板的方式是否可与工程技术维度的流水线结合。工程技术维度流水线要有一些基础架构，比如容器云、PaaS平台、应用架构的微服务架构和配置化架构，将这些东西支撑起来整体去运作可能会带来一个比较好的效果。这是第二块。
3.最佳实践导入
这个听起来稍微偏技术一些，这里给了一个很好的总结，就是说如果我们3个月才能做一次软件的发布，和一天能做多次的软件发布相比，在你整个项目运作过程中每个部分应如何转换。比如分支模型、测试组织、架构、基础设施数据库等每个部分都如何管理。作为一个项目而言，所有的部分都是需要做管理的，只不过说我们在不同的发布频率和周期中所采用的实践是不同的。
五、百度金融项目展示
1.架构的演进
上图为一个示意图，原来我们的整体式服务架构变成一个单体式服务架构，进而转换成微服务架构。之前我们系统架构是基于Dubbo的框架，它更多是网状的点对点服务模式，虽然它有服务的注册和发现，但这种服务的耦合度是非常高的，不利于动态优化。于是我们转换成了右边的基于服务网关的解决方案，也是基于这个服务的注册和发现机制，但由于所有服务的过程调用都是通过服务网关，因此服务网关可以做很多动态的路由策略调整和动态优化，做到动态服务治理。服务治理的结果最终返回给Docker平台做动态容量的调整，其实在架构上就充分的解耦，并且架构解耦过程中我们要考虑服务治理的因素。
2.组织的演进
以上图为例，首先要有一个跨职能的产品线团队，但这个跨职能产品线团队有三个关键点是必须要保持的：一是要用端到端的目标去驱动。比如我们并不是说衡量产能，看他有多少行代码、测试了多少缺陷，这些局部的产能不是我们优化的目标，而是说端到端，你将这个功能没有问题的交付给用户，这是你的目标。二是我们说每个人最好是一个叫T型的人，有横有竖，竖的话比如做开发，自己的领域是非常专精的，但我要懂一些运维。但做运维的人可能要懂一些系统架构，这样的T型人会帮助我们。三是大家要物理的集中在一起。
在上图的基础上还有两个关键的部分要去支撑。第一个部分是变革的推进小组。其实这个词大概也比较熟悉，我们做任何事情，比如任何一个变革的话，其实大家都有一个惯性继续往前走，但我们需要有一个小组领导我们。比如在百度，需要找高层做变革小组的Sponser，下面的变革的推进小组就是所有的相关经理。然后实施的团队，通过整个变革小组去向不同的跨职能产品线发布我们变化的方式、整个时间的同步以及防止大家走偏，这是第一个补充的组织。第二个补充的组织就是工具的职能和服务的平台。比如原来的测试是一个部门，他有很多测试平台、测试工具，现在我们将测试打散到每个团队中，这样原来服务的平台当然也是需要有人去负责的，比如研发的工具链平台、测试平台、运维平台，这些平台是一个服务式的方式为上面所有的跨职能团队提供一个很好的服务。这是组织上第二个变化，当然这个组织也是汇报给整个推进小组。
3.建设可靠可重复的交付流水线
这部分看起来更像端到端交付流水线。刚才谈到了自动化的交付流水线能帮助我们最大化业务的产出，它是一个强调自助式的操作和自动化流程。我们可将整个软件的生命周期流程划分为不同的阶段，每个阶段叫做一个Stage。比如它是编译和单测阶段，如模块测试阶段、系统和验收测试阶段、生产灰度阶段等，你可以自己按照组织的目标定义不同的阶段。每个阶段中有很多的作业，我们叫job，job间是可以串行和并行的关系，它是做一个具体的事情，比如部署、验证。但阶段和阶段间一定是递次晋级的，比如这个阶段没有过，我们不能晋级到下个阶段。这样就保证整个的研发是一个标准化的、可靠的流程。
4.配置管理及代码协作工作流
百度有1.2万研发人员，我们如何让这些研发人员更好的相互协作，我们有一个代码控制工具，以及在代码控制工具之上的一个代码协作的工作流。主流是主干开发、分支发布模式，这点比较偏技术。但我们不仅是将大家物理的聚在一起，还要有一个流程去规范的，并且要将这个流程固化在一些平台上，进而帮助大家做一个更深入的协作。
我们说一个流水线不是画出来的，而是实际做出来的。像很多主流的公司都在定义自己的流水线平台。比如之前我与阿里、腾讯、华为沟通，包括百度自己也有自己的流水线平台。有一个说法是“测试它不是一个阶段，而是一个贯穿于每个阶段里的实践”，我们不能再依赖于测试中心、测试部门去发现所有的问题，而应将质量有保证的工作放到每一个不同的职能中。比如从开发来看，你在开发阶段要用单元测试的方式去保证开发的质量。当然测试本身要保证质量，最终部署上线时要保证其质量。比如工业用的净水器如何过滤杂质，可能有沙网、小石子、海绵、活性炭等多个分层，每层过滤掉不同的问题，映射到开发过程中也是，我们对于控制质量要分层的，使用分层的测试模型，每层过滤它特定的问题，这才是最优的方式。
流水线中，之前提到它是按照阶段划分的，比如提交编译、各级测试、线下线上部署、镜像的制作到发布的环节。这个流水线本身做这个事还是很容易，只是把大家物理的拉在一起，但真正发挥价值的是流水线的每一个过程都效率最优。假如说测试，测试了自动化能够做得很好，这个过程是做Docker镜像，那么Docker镜像过程能否有一个平台然后自动做标准化的封装和镜像的构建。比如这个步骤是一个线上的部署，你能否以自动化的方式、一键式的方式去帮助你将整个全国不同的集群能给部署上。每个单点优化再配合流水线的串联，将所有东西搞在一起才是真正做到端到端的功能化的优化。
5.环境管理
在环境管理中，纵向强调环境相互隔离，横向强调按照场景、模块灵活的在一个界面上动态生成不同的环境，所有过程都是完全自动和自助的。
6.部署解耦与灰度发布
上图是我们的一个灰度发布的系统，上线时如果说作为热部署能够短时间停服的话我们要通过蓝绿部署和灰度发布的方式来帮助我们通过渐进式的方式降低整个的风险。
7.习惯培养及度量数据驱动改进
在互联网其实认为数据是非常关键的，我们做任何一个事情希望是数据驱动的方式。做敏捷、做DevOps，到底是有什么样的价值，任何一个改变都有投入，比如资源的倾斜、模式的改变。我们在内部就建了一个数据分析平台，将研发过程中所有数据做一个抽象和提炼，整体在数据挖掘平台上，这样可以看到所有的趋势与分布。我们在做了一段时间后，比如说一个月、两个月的改进，我们会看你的研发周期是否缩短、发布频率是否提升、过程质量有无保证、覆盖率是否上升，所有的驱动方式反过来告诉我们说下一步的改进目标。这是数据驱动模式。
我们这个项目改进的效果，大概半年的时间也是非常明显的。原来我们发布的方式是整体串行，改变后因为系统做了很好解耦，它是独立并行的方式。原来发布的打包格式是一个程序包，之后更多是镜像的模式。原来我们迭代周期是按月发布，现在基本可以按周发布，每周都有新的版本发布，如果有小的变更可以每天有多次的上线。前置周期是从需求、提交到上线，现在基本是分钟级，已做到非常优化。因此这可能才更像一个互联网产品应该具备的发布能力。
最后做一个总结，我们说DevOps，不论大家对于这个概念如何理解。我们说做好DevOps的转型，从我的经验来讲基本上有几个部分：首先是有三个大的方向，一个方向是全局化视角，我们要考虑敏捷、持续交付、ITSM、精益，把所有的东西从一个更高的视角去考虑。第二是要系统化的思考，核心是持续交付的流水线，配合以相关的实践，最佳实践导入。还有下面两个追加的部分，一是痛点驱动渐进式的变革。即我们在一个公司内部，你要告诉他改变的是为什么，比如从研发产能的提升到周期的缩短，这些东西是痛点所在，基于痛点去驱动渐进式变革，可能这个变革才更有可能成功。最后一块就是数据驱动持续化改进，包括结果指标和过程指标的度量，通过度量反推我们应该做什么样的事情。
这就是今天主要的分享内容，大型互联网公司金融项目的一个案例，如何通过相对传统的交付模式转变为DevOps模式，以及最终达到的效果。希望对大家有些启发。谢谢！
抢沙发
