在复杂业务体系中DevOps理论及方法的实践

admin 9 月 20, 2023 256 0

文末有亮点

作者简介

胥峰
《Linux运维最佳实践》作者、《DevOps：软件架构师行动指南》译者
2006年毕业于南京大学，2011年加入盛大游戏，十年运维经验，曾参与盛大游戏多款大型端游和手游的上线运维，主导统一运维平台的产品功能设计和实施，拥有工信部认证高级信息系统项目管理师资格。《Linux运维最佳实践》作者、《DevOps：软件架构师行动指南》译者。

前言

本文来自于 GOPS 2017 深圳站的演讲“在复杂业务体系中 DevOps 理论及方法的实践”。分享分为 4 个方面：

初识 DevOps；

建构组织文化；

架构技术体系；

案例研究；

1、初识 DevOps

对 DevOps 有这样一个解释：“ DevOps 是一套实践方法，在保证高质量的前提下，缩短从提交对系统的变更到部署到生产环境的时间”，这是引用了我翻译的这本书里的概念。我们看一下这个概念里有哪些值得注意的关键点：

我们在部署系统的时候，质量是非常重要的。我们部署的系统，你不能因为变更的问题导致业务中断，这是不可接受的问题。
要求交付机制也是高质量的，就是你的交付过程。比如说你交付到测试环境，交付到生产环境里面，也应该是一个高质量的。
在里面规划了两个时间周期：一是开发完成的时间；第二是把代码开发完成到部署到线上的时间。
在这个定义里面强调了 DevOps 是一种以目标作为导向的，它并没有强调我们采取什么样的形式的实践，或者使用什么样的工具。
目标并不限于 DevOps 用于测试和部署的实践，它其实是把整个流程都包含在里面。

我们看到在 DevOps 的定义里面，最主要的一点还是讲到从代码开发完成到上线的过程。这也是行业内对 DevOps 理解比较多的一点。

这个图来自企业 DevOps 白皮书，这是对 DevOps 理解的一个扩展。相对于前面说的那个概念，它讲到从开发到部署的过程，但是在这个图里我们可以看到，它其实是把流程进行了前置和延伸。

比如说计划、需求、设计，以及后面的运维过程，它都把它纳入到 DevOps 流程里面去了。这其实是讲一个什么东西呢？一个产品或者一个业务有了想法之后，它就会进行下面这样的流程，从这个图里面我们看到，它强调的是价值交付的过程。

从产品和业务来讲，它开始有些想法在里面，怎么通过技术手段、流程，快速的把这个想法变成一个产品，变成在实际场景中投放给客户的产品，这是一个价值流的过程。

只有当你的想法真正投入到里面去的时候，它才产生价值，你做的计划也好，你做的开发代码也好，在没有投放到生产之前，其实对用户来讲是没有任何意义的。

上面这部分主要是讲这个流程，在下面我们可以看到，其实它核心的理论支撑是精益和丰田生产系统。我们在整个流程中需要非常关注的一点就是持续改进的过程，不管我们现在的流程是什么样的，或者说你已经做到什么地步了，其实都是有一些可以改进的方向，包括这个精益也是告诉我们要持续不断地做一些改进。

2、建构组织文化

在这里面我想强调一点，不管 DevOps 的定义是什么，它都是一个价值流的交付。从产品或者是业务的想法开始，把它快速地、高质量的交付给用户。但是在实现 DevOps 的过程中，很重要的一点是文化。不管组织的类型是什么，大部分组织都是惧怕变化的，所以采用 DevOps 这个新方法论可能是极具挑战的。

在构建组织文化的过程中，需要关注三个主要的原则：沟通、协作、集成。在这里面要强调一点，我们现在各个部门在协作过程中，可能还存在一些部门利益冲突的问题，这也是一个很现实的问题。

另外一个就是我们要倡导一种免责文化，大家都说运维背黑锅，这个其实是不对的，关键的一点是我们是以价值流交付作为一个整体的目标，倡导一种对事不对人的工作态度。

我们在构建组织文化过程中要注意四个方面：

第一是团队内的协作；

第二是团队之间的亲和性；

第三是要使用一定的工具来加速流程的落地；

第四是伸缩性，随着组织规模的扩大， DevOps 流程也要做相应的变化，

大家想想在我们的组织内部，是不是有这样的一些问题，我们在传统的开发、测试、运维过程中是什么样的情况？开发把代码丢给测试去测，测试测好之后，又把这个包丢给运维部署到现场，中间可能有相关的文档，这本身就是一种筒仓思维的表现。

筒仓思维的英文叫 Silo，它就像是在沙漠里面，或者是大型的场地里面有这样一个个存储物品的仓库，每一个都是独立、封闭的个体，它们之间是没有沟通的，它们的利益也都是有冲突的。

这里讲一个小故事，我们原来有一个同事是来自国企的，他是做财务的。有一天他跟他的领导说，我们现在很多的工作还是手动的，我们是不是可以引入一些自动化的计算机系统来做这些事情？领导就问他，这样做有什么好处呢？他说，我们可以节省很多人力。

领导说，节省人力不行，你节省人力了，我这事就没有人管了。大家有没有理解这个意思？就是说在体制内，领导比较关注他的权力的分配，而不是说从整体角度提高工作效率。

还有一个与之类似的例子，在上海有一家基金公司，我有个同事去那里应聘，当然级别也比较高，他发现他们在部署的时候还是手工去部署的，有几个同事专门做部署的工作。

他就想去推动这些自动化部署的工具，但是他的领导说，我们还是要手工去布，这样的话领导才会重视我这一块，你全自动化了，把我隐藏起来了，我这个经理就没用了，这就是很明显的筒仓思维。

包括我们在运营一些产品或者业务的时候会发现，开发和运维之间互相踢皮球的事情，这也是一种筒仓思维。比如说开发肯定是要求快速上线，而运维要求稳定，大家的利益产生了冲突，这必然会对我们的价值流产生负面的作用。大家可以想想我们生活中或者是在工作里面是否也有这样的筒仓思维的表现。

我们在构建 DevOps 的过程中，必须要打破这种筒仓，形成合力，让大家围绕价值流一致的目的共同努力。

3、架构技术体系

在构建组织文化过程中有三点：沟通、协作、集成。集成肯定是一种自动化集成，而不是说手工对接的过程。这就要求我们在开发、测试和运维整个链条里面，在每个环节上要能实现一定程度的自动化，不能说没有对应的运维自动化系统来对接前面的需求，完全是通过公开的形式去做发布、部署，其实是不符合快速交付这样一个理念的。

关于自动化运维这一块，我可以简单说一下我们盛大游戏是怎么做的。大家知道盛大游戏目前是国内比较领先的游戏发行公司，它创立的时间比较早，在1999年这个公司就成立了，到目前已经有18年的历史。

它现在面临的问题，在运营方面主要表现为几个：一是服务器操作系统异构；另外一个是我们的服务器数量特别多，在高峰期的时候，我们的服务器达到2万台的规模。

因为每一个游戏代理过来的时候，游戏的开发商（比如说美国、韩国、日本）服务器的偏好不一样，面对这样的挑战，我们在实现自动化集成的过程中，我们是怎么构建自动化运维平台的呢？

从这个图可以看到，我们有一台中央控制机器，它从 CMDB 里面读写数据，根据不同的服务器的类型和操作内容，把这个命令分发到对应的服务器上面去。

我们可以看一下这里面的几个特点：

第一，我们这个平台是采用 BS 架构的，不需要在电脑上装软件，现在在家里都可以操作，完成这个运维任务；

第二，我们使用的是通用的协议来管理着所有的异构系统，比如说我们在 windows 下面，大家知道以前管理 windows 是比较困难的，现在有很多公司在这一块也是依靠手工去操作的，这样会很麻烦，也有可能造成一些遗漏或者是错误的过程。

对于 windows 管理，我们也是采用了 SSH 的方法去做，这样就可以让所有服务器以相同的方式管理起来，比如说它们的安全策略，公钥和私钥的管理，另外还有一些审计，都可以内置在这个操作平台里面。

关于自动化运维平台这一块，还要注意做一些并发的设置，以及超时和重试的机制，都需要考虑到里面去，不能因为一些顺序的执行，某台服务器的故障，或者是连接服务器的问题，导致它无法连接，导致整个任务延迟。

现在我们在做另外一个系统是作业编排系统，如果知道 Ansible playbooks 的话，可以看一下它的方式和方法。我们知道 playbooks 是通过声明一些配置项，然后把它编排起来，把所有的人工分类的步骤做进一个配置里面，让它顺序执行。

比如说我们做游戏维护的时候：

第一步，是先把服务器上的游戏服停掉；

第二步，停数据库；

第三步，更新程序；

第四步，还要更新数据库的一些表结构；

第五步，把前面的游戏服务器启动起来，或者数据库启动起来；

通过一些作业编排，就能更大地减少这个运维的重复劳动的过程，它的理念其实是基于场景的自动化运维。我们可以想想在运维过程中有哪些工作可以串联起来，这样你就不需要对着一个文本的东西去做，因为你在对着它做的过程中很容易造成遗漏。

比如说你做游戏维护的时候，没有把前面的关闭，你就直接维护数据库了，这时候可能会导致玩家数据丢失的情况。通过 playbook 编排系统，就可以避免这个事情，它是固化的，没有办法绕过前面的步骤去进行后面的操作。

4、案例研究

刚刚说过，大家在不同的行业里面，在不同的业务里面，它对应的发布方式还不一样，我相信目前我们在座的，系统里面也有一些人是用手工发布的方法上线。我知道一个比较大的公司，它的部署也是很落后的方式，因为它前面有负载均衡，它布的时候还是要登一些脚本，把负载均衡上的东西剔除，然后再更新，它需要更新多个脚本，这是很浪费时间和精力的过程。

看看我们以前面临的问题。这是我们的某个平台，主要是支付相关的。大家知道我们除了游戏服务器之外，还有相关的登录、认证和计费的平台。我们第一个选取的案例是在支付平台这边做的一些 DevOps 实践。

随着公司业务的发展，日积月累，你这个模块可能会越来越多，部署了之后会有测试，测试了之后交给运维，但是测试的模块名和运维的模块名可能是不一样的，这里面存在一个协调的问题。因为有人工协调的过程，不然导致这个部署需要排期，原来部署和测试系统是割裂的，它们之间没有对应的关系。

我们是怎么改进的呢？现在已经做的工作是：

第一，我们建立在部署流水线上不同环节的模块对应关系，首先把它映射好。比如说测试和运维这边的部署系统，它们之间的对应关系要映射到数据库里面去，这样就可以实现从前端出发的部署动作。
第二，后端的部署系统，它需要提供对应的功能接口。比如说它需要上游的系统提供一个模块对应哪些服务器的接口，当上游需要部署某个模块的时候，它就知道在测试环境里面需要部署哪些服务器，在正式环境，灰度发布的时候需要先部署哪些，再部署哪些。
第三，建立对应的授权机制，我们可以把部分模块的授权前置给开发上线，或者是由运维从内部平台直接部署上线，取得的效果是非常明显的。在2016年12月份的时候我们做了一个统计，当时有900多次的部署，其中50%以上通过新平台自动部署，大约10%的模块可以由开发自主上线，不涉及到核心功能的，开发简单测试一下就直接上去了。非核心模块的部署，我们可以在5分钟内完成，不再需要一些配置管理员进行上线的排期和编排。

这是我们部署的系统的界面，它会选择对应的版本，选择你是灰度发布，还是部署到生产环节里面，这个动作很多情况下已经不需要运维去做了，直接测试完成之后就可以上线了，这时候就把运维的工作解放出来了。

这是我们的部署过程，对于自动部署，银行和金融机构有要求，开发和运维要分离，我们现在做的是让开发和测试都可以上线。

我们的底层部署是通过配置一些项目，比如说模块对应的目录、配置文件、执行脚本，对应的用户，这个用户主要是指启动程序时的用户，以及对应的某个模块在不同的服务器上的IP列表，这些都会在系统里面进行相关的配置，这样配置之后就可以对前面的系统进行相关调用。

这个案例也告诉我们一点，我们在进行部署设计的时候，暗含了对架构的要求。

这里简单介绍三点：

第一，模块化，可独立部署，微服务有一个类似的概念。如果你是一个大一统的体系，你很难集中发布这个东西，你还要协调很多资源，如果你做成模块化，你自己上线，不影响他人，通过接口去调用，对自动部署是非常有好处的；
第二，重试机制。作为一些后端的服务，它在部署的时候，不应该影响前端的调用服务，前端的调用服务必须有一些重试机制，失败的时候要能够重连，这应该集成在调用方的架构设计里面，如果没有重试机制，肯定是会影响业务的，这也没办法达到高质量交付的目的；
第三，负载均衡与多实例的应用。这里也讲到，如果你的某一个功能只有一个模块，你在部署的时候，不管它的时间窗口是什么，你必然会影响业务，有些请求会丢掉或者是失败。通过负载均衡和多实例的方法，就可以包括你在部署部分服务器的时候不影响前面调用的结果。