DevOps@BOC -- 器用之道，如琢如磨

豆沙包

作者简介

于洪奎
中国银行敏捷推广专家
系统分析师、CCEP、CSM、DevOpsMaster
14年软件开发经验，9年开发管理经验

今天跟大家分享以下四方面内容：

第一，和大家一起了解一下所谓的器用和DevOps，器用到底是什么？

第二，大家一起分享一下我们中国银行的DevOps，什么叫做我们的DevOps呢？我可能没有办法告诉大家我也不知道怎样是最好的，但是我可以告诉大家我们做的是什么样的。

第三，分享一些我们成功的东西，或者我们自认为比较成功的东西。

第四，会和大家一起开心一下、反思一下，失败总会让大家开心。

一. 器用与DevOps

首先，跟大家分享的就是这张图，这张图是DevOps成熟度调研网站入口。

为什么和大家分享这张图呢？这张图里面比较好的体现了我们去看DevOps这个词的时候，你到底希望得到什么？我们大家现在都在做DevOps，前段时间都在搞敏捷，到底你希望在搞什么？从这张图里面我认为可以看到两个词是我们希望从其中获得的，“frequent”和“reliable”。这两个词就是我们希望更高频的去发布我们的应用，希望发布的应用稳定，这个地方给大家说几个小故事。

第一个小故事，我在去年的时候给我们的业务门部发了一个调研问卷报告，这个问卷里面很简单，你认为我们作为中行的软件开发部门，我们在哪些方面最应该得到提升？第一个是我们交付的不够快；第二个是我们交付的不够多，你应该做更多；第三个是说我们交付的质量差；第四个是我们贵，同样的东西我们贵；第五个是我们的安全性差。我简称为多快好省安，我把这五个给我们的业务同事们让他们选一选，我说最多选两个，不能都不满意。最后得到的结果是什么呢？得到的结果是90%以上的都认为我们现在慢。我们金融行业做DevOps不能只学互联网，但是你要先学互联网，你没有学会快，你去做DevOps和敏捷，所有不能快的敏捷和DevOps都是耍流氓，首先你要能够快起来。

第二个小故事，就在前两天，我们和质量部门同事做了一个敏捷测试分享，大家都说我们敏捷之下质量得到了提升，那么和传统的开发比，我们到底有了哪些方面的提升？这个地方有一个现象，当我们开始做敏捷了，我们开始快了之后，你会发现我们的质量差了，你有感觉，你也有数据。

通过这两个小故事，我认为这个非常好的诠释了我们对DevOps的诉求。

说到DevOps的时候有几个概念，大家可能对敏捷、精益比较了解，或者最起码知道这些东西，它到底是什么关系，敏捷也好，精益也好，DevOps也好，从来都不承认它只关注一段，都说自己是全的，大家都是DevOps的8字环，精益也没有说它不管后面，敏捷也没有说它不管前面，但是我们要看看客观上来说最主要的？如果说从需求到后面的系统运维和监控的整个环上，让你选3段你选哪3段？这就是我第二个想和大家分享的，就是从概念上来说，我们这几个概念在我们的开发过程中就是下图这个样子的。

当我们在做DevOps的时候，我们更多的还是关注于DevOps从开发、测试到部署之间的打通、顺畅、稳定。给大家推荐两本书，叫做《精益创业》，还有一个叫做《精益数据分析》，从精益的角度上来说通过学习、构建和反馈过程来不断地探索商业价值和寻找商业价值。

敏捷大家都知道，它实际上从原则上，或者从源头上是一帮开发的大师发起的活动，他们更关注的是从源头上开发测试融合，他们一开始也说我们要交付客户价值、交付可工作的软件、响应变化，他们没有说我对其他的不关注，但是他们更关注什么？我点的是他们更关注的点。

说到了器用，器用这个词是个很古老的词，一开始的时候所谓的器是指武器，用是指容具，后来变成了工具使用，每个词放你会看到很多种解释，在这我引用这个器用就是指工具。这个就涉及到我们在理解工具的时候是怎么样的看法？

文化和行为，我们都知道文化会影响行为，行为会影响文化，但是当我们插入工具的时候，其实也是一样的，工具会影响你的行为，你的行为也会影响你对工具的使用。

二. 我们的DevOps

上面简单的说了一下DevOps和工具这两个概念，下面就是我们中国银行的DevOps，大家都非常关心，或者非常希望能够了解中行的DevOps到底是什么样子的，这里和大家一起去做一些分享。

2.1 工具的选择

我一直都在说工具的如琢如磨，我们来看一看我们在说工具的时候在说什么？

DevOps的工具链很多，这只是其中的一些，也并没有多全，现在有很多火车式、蜘蛛网式的。

这张图大家都认识，做DevOps还是要认识这张图，最起码当你说出工具的时候。这张图非常推荐大家去了解，从前面到后面中间每一环上有各种各样的领域，每一个领域下有一些它推荐的，或者觉得大家应该使用的开源工具。在这些开源工具里面，我们中行用了其中不少的工具。

这就是我们用的工具，我想告诉大家的是，其实用哪个工具并不重要，重要的是你在这个过程中怎么使、怎么选!

2.2 Devops工具链

上面这张图很复杂，但是你用的东西并不多，这个时候我们怎么选择？我们的过程是这样的，从前面的需求到后面的监控整个过程中我们大概使用了这些工具。这里需要和大家提一下的是，这个只是我们从X86这样的平台下看的视角。

三. 成功之经验分享

3.1 源代码

我们大家都知道业界关于SVN和Git之间有争论，有的说SVN好，有的说Git好，你认为SVN和Git之间的区别是什么？或者你拥护的是什么？

我们使用的是SVN，这其实有一些自己的思考。我在这个地方想和大家分享第一点，软件开发中的浪费。首先就是分支合并，在软件开发过程中有各种各样的管理，但是都很难逃避一个问题，就是经常会互相之间合一下，这个合并过程是不产生任何价值的，在敏捷、精益里面会说我们要产生价值，软件开发过程中的合并没有任何用户价值。

3.2 分支管理

上图就是我们曾经的分支，大家能想象吗？这个就是我们一个批次一个批次的投产，这个就是我们曾经的分支状况，我们为了这个分支状况有一个特别牛的项目经理画了一张表专门进行管理。

这个是我们认识到了这个问题以后，经过了半年以上的努力以后得到的清爽结构，我想告诉大家的是，它是可以做到的，它真的是可以做到。但是，它真的很难。

这个东西叫什么呢？就叫做主干开发。

我们看到主干开发的时候，业界很多人知道这个，但是到底什么是主干开发？所谓理想的主干开发，首先所有的代码都是提交到主干分支上的，然后你的发布随时可以从主干发布，这个能够做到非常困难，需要让你的主干一直保持非常的稳定，这需要你的团队足够的自律，每一个提交代码的人都足够的自律，你的持续集成都足够的健壮，并且维护的特别好。我们做的是一种现实的主干开发，就是你的提交依然提交到主干，但是你要发布，你要发布的时候会从这个地方拉出一个分支做release，release的时候会在分支不超过一个迭代的时候就投，投完之后这个分支就动了，我举了一个非常形象的模型，它像一棵树一样，它一直在长，这个就是我们现在做的主干开发的情况。但是，主干开发其实真的很困难。

上面这个图是业界经常用到的版本管理分支，我们以前也是这样的。这两种方法是决然不同的，它对于你带来的价值和效率的提升其实也是决然不同的。但是它有什么副作用？它的困难是什么？大家要想一想。我们经常会做同业的交流，大家都会说这个东西好，好你为什么不做？大家都会知道我们做不到。这个时候你要想到的是他为什么做不到？你怎么样可以做到？我和很多的同业交流的时候，特别是我们金融的同业，我们养成了一种DevOps有一个词，叫做习得性无助，就是说你在长时间的这样一个环境里面的时候很容易出现这样的状况，但是我们首先做DevOps的时候首先要意识到这样的问题，有的时候我们做了很多工作都是你能做的，其实并不见得是你该做的。

主干开发，想说爱你不容易

• 足够短的迭代周期(两周，可投产版本)
• 足够端的投产前置周期(三个工作日)
• 不顾一切保证需求串行

3.3 持续集成

持续集成是什么？

• 开发人员每天至少提交一次代码
• 代码提交后立即触发构建和测试
• 构建和测试失败后应尽快处理

这是我认为持续集成之后达到的效果。这几点最起码在我们内部做不到，我一般不称它为持续集成，你是不是每天都至少提交一次代码，我不知道你们有没有这种状况，有些人经常说自己在做持续集成，代码提交了之后要做触发构建，构建失败之后要尽快处理，尽快处理是什么意思？尽快处理就是仪表盘变红不下班，我们七部的每一个产品都是做到的，仪表盘变红了之后就不下班，我们就不会变红，你可以四点的时候把代码提交了，这个我们是允许的，我们不建议四点就提交代码，但是只有你把这条做到了，这句话才变得有意义，否则的话是没有意义的，什么叫尽快处理？我们会有持续集成的纪律，你要想做到这个，其实真的没有想象的那么简单，虽然它只是一句话。

怎么做到？我给大家说一下我们的做法，不一定适合大家，但是大家可以看一看。

我们有一个物理仪表盘，这个物理仪表盘搭建很简单，我相信你们只要有人研究一天半天就能搞，这个物理仪表盘放在那个地方之后就叫做仪表盘变红不下班才有意义，你想看不想看它都在那里，物理仪表盘的作用是什么？我们为什么要有物理仪表盘？就是希望告诉大家物理的东西有天然的信息辐射作用，就是你想看、不想看它都在那儿。仪表盘变红不下班，我们是做到的，2017年8月24日的晚上10点，我们有一个团队在西安做异地封闭开发，每天干6个小时，每天晚上到9、10点，大家到了9点半的时候，突然有一个人提交代码把仪表盘搞红了，然后大家都惊呆了，所有人都不干活了，首先要找到是谁才能改，完了之后赶紧改。

我想告诉大家的是，在这个过程中你想要做一件事情的时候，你一定要定义出这件事情到底想怎么做，过程中要给大家培训，这个过程中绝对不是说仪表盘变红不下班，这个过程中你要给大家培训，怎么样尽快的修复、定位问题，然后提供相应的培训，接着做一些事情强化这个行为，你要真的作为参与者参与到这个过程中，陪着大家一起度过了第一、第二个不下班的夜晚，就真的成为了团队的习惯。

3.4 自动化部署

自动化部署是大家的老大难：

• 生产环境权限管理融合难
• 生产环境配置参数收集难
• 生产环境资源变更联动难
• 增量、全量的支持统一难
• 自动组包标准贯彻落实难

你想到这个的时候，首先要自动化。

我们在2016年的时候在目标里面写到一条实现自动化组包，严禁手工组包，手工组包就是在浪费组织资源，所以我们在内部强烈的推了自动化组包，大家也愿意这个，只是有时候需要给大家做宣传和引导。然后是重复性组包，其实存在各种各样的问题。

我们的自动化部署，现在已经有20多个产品上了自动化部署，我们今年提的目标是100个，不知道能不能达到，但是已经有20多个产品已经实现了自动化部署，有X86等等各种各样的平台都有实现了自动化部署，手工部署的时间，自动化部署会变得很快，最主要的是自动化部署的时候你在喝咖啡，那个时候你这30分钟你在干什么？幸福感决然不同。自动化部署是我们做DevOps的时候应该努力去做的事情，但是我们在做自动化部署的时候，自动化组包，你现在的环境怎么管？你的参数管理、权限管理，如果你的数据中心和开发中心还是分开的时候，这些全都是你需要克服的点，这个太复杂了，我不细说了，我想告诉大家的是自动化部署是我们克服各种困难，或者引入外部资源要去做的事情。

四. 失败之回顾反思

自动化功能测试的苦难：

• 2016年多个产品集中编写了将近1000个面向UI的自动化功能测 试案例(Robot Framework)，半年后，全部废弃，没有再被运行过。
• 某产品编写的大量面向UI的自动化功能测试案例，全部运行一次 一般需要一到两周才能完成，有2-3名测试开发人员专职负责运行和编写，以及更新这些案例。

我们的现状并不特殊，我们和大家一样经历着我们的苦难，互联网公司给我们做了很好的榜样，但是很不幸的是它救不了我们，我们环境不一样，通过我的分享就知道，你的排期任务所有的这些流程和互联网公司决然不同，互联网公司产品经理弄个PPT秀一下就干了，它和我们完全不一样。

所以我们回到这个，这是我们在自动化测试上的一个苦难，苦难之后，我们有反思的。还是那句话，干该干的，别干那些容易干的，不一定有用，为什么？一般情况你觉得该干的和干不成的那些事都是应该干的，你应该历经千辛万苦好好的干自己的事。

我们发现在已经发布了一个高绩效组织和低绩效组织中间图里面找到一个点，我们每10天到100天发布一次，这是我们现在的现状，你会发现这个时候开发和测试人员共同去维护自动化测试案例，我们的自动化测试案例有的可能是开发自己写的，写完了之后扔那儿了，你没有作为共同的资产共同维护。

看到这个点的时候，当时对我的启发很大，我们要千方百计的让我们的测试和开发融合到一起，用自动化测试这个话题把它融合到一起。在这里面，我们做了一个纪律，你在增加自动化测试的时候，我有的时候是有纪律的增加自动化测试案例，你要保证你的自动化测试案例持续、有效、可用，怎么样叫持续、有效、可用？你要看看吧它定义清楚，什么叫做有效、可用？每天至少跑一次，跑不了一次就没用。每一次的成功应该是100%的成功，预期应该是100%，如果没有成功，一定是你的应用出问题了，而不是我的数据、环境又不稳定了，它的系统宕了所以我们宕了，你有一个案例满足这个条件就写一个，有本事写第二个，再有本事写第三个，写到第五个做不到的时候，你应该满足这五个的条件，这叫做有纪律可知的增加你的自动化测试案例，我们现在正在做这样的事情，我们经过了前期的失败之后，我们现在正在做这件事情，我们非常的可知，而且我们要求我们的测试融进我们的团队里面和我们一起去写自动化的测试案例。

在这个地方，单元测试有个原则叫做FIRST原则，功能测试的时候有的地方提交IR原则，我提炼成了SIR原则，什么叫SIR原则？你会发现没有F和T了。F是什么？F是Fast，你会发现你的单元测试是会Fast，你的结果测试就没有那么快。T是Test，你的单元测试是开发自己写的，但是你的功能类的测试、接口类的测试就没有那么快，你可能需要开发和测试融合起来自己写，这个就是我们经过这个之后自己的反思。

最后有个寄语，工具很重要，什么更重要？这个问题留给大家。