从 0 到 1：中小金融企业如何开心玩 DevOps

分享：李晓璐

编辑：白凡

讲师介绍：大家下午好，我叫李晓璐，是广州证券的IT架构师。

在开始之前，我们先把分享的题目稍微修改一下（原标题为“开心玩转DevOps”），把“玩转”去掉，改成“开心玩 DevOps”——因为 DevOps 涉及的内容特别广，我曾看到过一张 DevOps 的生态图，图上围绕着 DevOps 的工具就有上百种，它的理念和方法就更丰富了，比如精益、敏捷、持续改进等等。

DevOps 不仅仅是工具、平台，也可以说是一种文化或者信仰。所以，玩转 DevOps 比较难，我们只要开心地玩一下就好了。

另一方面，我们在公司内部践行 DevOps 的过程原本就是抱着试试看的心态，玩玩技术，然后持续改进和丰富 DevOps 的过程和内容。

好，言归正传，我分享的内容有三个部分，这也是我们在实践 DevOps 过程中经历的三个阶段:

第一个阶段是我们花了 6 个多月的时间构建了集中运维平台。接着呢，运维平台出来了，大家就会提出一些精细化的需求，因此我们构建了一个开发框架，并基于此做了一些小系统。目前我们处于第三阶段，我们搭建了 DevOps 持续集成和持续交付的系统，走向了开发运维。整个分享过程中，我会跟大家讲一些心得体会，也会讲到一些技术细节。希望既有干货，也能分享到经验和方法。

进入正题之前，有两个原则性的东西要说明一下，后面讲的内容都是围绕这两个原则展开的，脱离了这两个原则，我们一些经验和方法就不再适用了。

• 第一个原则是“适当性”。 “适当性”是证券行业的一个通用术语，它说明一个投资者进行投资活动的时候，证券公司有义务和责任告诉投资者：根据他的投资历史背景、投资习惯，包括现有资本、资金等因素，对投资者的风险承受能力做评估，给投资者适合进行哪些类型金融产品的投资提出建议。
• 同样这个原则也非常适合企业的 IT 建设。前面有位同学谈到一个困惑，说他的领导认为 DevOps 中他们的 Dev 都没做好还做啥 OPS ？ 其实我是有点认同这种看法的，因为我们的确应该要看清自己到底具有哪些资源和成熟度，然后再做建设。不然，即使我们看得特别远，但资源、资金、成熟度都不够，做事只能可望而不可及，往往收到的效果没那么理想。 我是 2017 年加入广州证券的，之前服务于一些比较大的企业，比如：华为、招行、广发等，对这些公司有一些了解，所以，下面我参考这些企业从五个维度来说明根据企业特点进行 IT 的适当性建设：
  • 第一个维度是人力和资金。这方面金融大企业的优势明显，同样类型的项目，金融大企业的资源投入是我们中小企业的5倍之多；互联网大厂反而会少一点，一般他们会投入更多的人力去做，而不是投入更多的资金。而我们中小金融企业，人力和资金的投入相对来说都很小——这是我们要认清的现实，后面不管是做 DevOps 还是其它建设都要以现状为基础。
  • 第二是规模量级。很显然互联网的环境规模量级最大，动辄是十几万、几十万 OS 规模的环境，交易的并发量也很大，其次是金融大企业。那么对于我们中小金融企业来说，规模就小很多，我们只有互联网大厂的几十分之一，不过这恰恰却是我们的优势所在：规模量级不大，就意味着我们做某些系统的时候反而容易成功。举个例子，我之前工作过的那个大厂，当时做运维平台的时候，考虑最多的问题是性能优化，因为要管理的机器很多。而对于现在中小企业来说，规模比较小，不用太考虑性能问题，很多工具、产品拿来就用，而且用得还不错。
  • 对于项目周期来讲，金融大企业它的项目周期比较长，往往是一年甚至两年的时间做一个项目（稳态为重）。那么互联网企业呢，时间要求就比较高，所以互联网公司加班严重。
  • 然后决策效率这一块。互联网大厂的高效是毋庸置疑的。举个例子，有个朋友去了阿里，刚去的时候他很不适应，有一回给团队成员发了个邮件，说要实现什么什么功能，两天后此同事没啥反馈，他就跑到这位同事跟前去问，这位同事很诧异地看着他，说这个需求已经昨天编码完成，今天上线了——这就是互联网的效率，它是不一样的。
  • 最后是创新驱动力。互联网大厂希望自己能引领技术的发展，所以会有绩效驱动，创新是其一个重要的目标。

上面就是传统中小金融企业 IT 建设的特点。我们要认清自身的优势，然后基于现状去做 IT 建设。有了这个前提，接着就是“企业特点决定思维方式”。这就要求中小金融企业采用“工具化的建设思路”。那么，工具化和工程化的区别是什么？

工具化不是说要我们搞很多开源和商业的工具，形成一个个工具竖井，而是保持工具的原生态和纯粹性，我们不要轻易修改工具的源码，而是用“黏合剂”把工具都串接起来，形成一个个平台。

• 第二个原则是“工具化建设思路”。
  • 先说说工程化的思维模式。这种模式下，因为资金、人力资源比较充分，大企业一般会找一些靠谱的厂商根据企业自己的需求创建工具或者系统；互联网大公司会招聘一些技术大牛自力更生自己来实现。这种模式下的优势特别明显： 长期看容易达到比较高的用户满意度；缺点也很明显，就是总体费用和成本比较高，周期也比较长。
  • 工具化的特点是拿来主义。我们不要自己造轮子，现成的工具有很多，选合适自己的那些，注意偶合性的设计，不要轻易修改源代码。要克服满足太多个性化需求的欲望，尽量去适应这些工具。 我个人的理解是：好的工具它本身就是很多经验方法的沉淀，是前人的最佳实践，一般不要轻易去推翻它，先尝试去适应，在这个过程中你会发现它可能是有道理的。

简单总结一下，“工具化的建设思路”就是找到好用的工具，按照2/8原则，投入20分的精力收获80分的结果。对于工程化的思维方式，是用丰富的资源，实现90分甚至95分以上的目标。

1. 从0构建运维平台 —— 先解决温饱问题

1.1 构建背景

刚到广证的时候，我花了三个星期的时间，做了一些访谈，然后做调研分析。

我发现当前最薄弱且大家最关心、最怕出问题的就是核心业务系统的稳定性。所以，要先把监控做好，让业务系统运行有保障了，我们才有精力谈提高效率、谈自动化、谈规范化等等。

1.2 一体化监控平台的构建

那时候我们的监控是这样的： 只有几个彼此独立的小工具，比如机房监控，还是买设备送的；还有两个系统级别的监控，监控的内容很简单，比如IP/端口的通断、进程是否存在、CPU/内存利用率等，监控覆盖面很小，参数调整也非常麻烦，需要硬编码。

此外，因为监控策略比较简单，所以经常会造成误报（比如闪断的情况下）；数据的整合就更不用说了。大家的感觉基本就是凑合着用，甚至说监控系统可有可无。

本着先解决运维温饱（监控）这个基本需求出发点，我们开始构建一体化监控平台。这个平台包含3个子系统，其中开放平台监控采用 Zabbix；然后核心业务系统监控采用金正的 KCMM；另外采用TM工具通过抓包分析做了业务交易性能分析。

目前为止，涵盖了我们所有基础设施、基础架构范围的监控，包括存储、网络、操作系统、中间件、数据库、应用、业务等。

除了3个监控子系统工具，我们还构建了最核心的监控平台集成模块，把所有的告警、性能全部整合到一起。其中告警从各系统产生到大集中延迟只有0.5秒，性能从获取到集中控制在1-10秒。

下面这张图是监控平台的技术架构，分四个部分：

所有开放平台的监控都用 Zabbix，包括网络监控、机房设施监控、系统、应用、业务监控等等；

对于核心业务的监控，我们是集成了商业工具KCMM系统，用它来监控我们的核心业务系统，如集中交易、两融、柜台等。

最重要的是集中模块，这里汇聚了所有被管对象的告警信息、性能数据，以后还会汇集配置信息。短期的数据放到ElasticSearch中存储，存放一个月的数据量，长期数据入到Hadoop平台，数据汇集策略是T+1。

然后所有的告警信息通过Omnibus进行汇聚。集中展现模块，我们通过UMP集成了Grafana、TM、Kibana、自开发页面、报表页面等，实现了统一认证和单点登录。

1.3 谈谈工具的选择

还是参照前面讲的那两个原则，不刻意修改工具，我们只做黏合剂，把工具串联起来。

• 开放平台的监控，我们当时考虑了很多种工具，最后在Zabbix和Prometheus之间选择了Zabbix。其实 Prometheus 不比 Zabbix 差，但它有个不足，它监控策略的定义主要是以 API 的形式提供的，没有一个友好的界面可以做复杂的策略定义，而我们也没有资源去开发一个完善的监控策略定义的UI，所以最终选择了Zabbix。
• 对于时序数据库的选择其实也有很多，比如InfluxDB、OpenTSDB等，我们最后选择了ElasticSearch。原因是InfluxDB高可用版本收费，另外我们也更看重 ElasticStack 一直以来颇具活力的技术生态。
• 然后展现这块用了Grafana，因为它对接的数据源非常丰富，灵活性也足够高，基本上是不二的选择。此外，有些Grafana做不到的视图，我们会用eCharts自开发作为补充。
• 再说下报表。其实一开始我们自行开发了一些报表，大概做了两个月，后来发现效果不好，果断stop，采用了Tableau。因为Tableau是公司已有的工具，有好的工具为什么不用呢？最后用Tableau大概花了一个多月的时间（包括学习时间），所有的报表就出来了，挺好用，拖拉拽，写不太复杂的sql就可以完成报表开发。
• Omnibus vs 自开发系统，这块不用多说，Omnibus是很多金融单位都在使用的商业事件管理工具，反正未来两到三年内，还找不到更好的替代品。

1.4 有几个问题需要探讨

• 是否值得开发统一的监控策略定义界面来对接不同的监控工具？对于我们中小企业来说，我觉得没有必要，因为有些监控系统是很封闭的，不提供接口，无法对接。另外，监控策略是否会经常调整？不一定！尤其是中小企业。
• 通知管理这块，事实证明使用微信是一种更好的方式，它的时效性和表达能力比短信和邮件要强。
• 最后一点很重要：重视推广。DevOps 平台也好，监控平台也好，任何一个新系统对传统使用习惯的改变，多少都会受到内部的一些抵触，这时候我们应该花点时间做内部运营。比如我们会经常走到不同团队 leader 身边，坐下来问他们：这个平台用得怎么样，哪些功能模块用得不舒服，是否需要修改，要改哪里？按照这种方法，最后完成的系统一般大家是满意的。
• 还有一点就是我们永远会比需求的提出者多做一些功能，比大家想的远一点、超前一点，让系统的每次发布都会有一点点的惊喜，这样你的系统才能够被大家所喜欢。

2. 基于微服务的运维开发框架 —— 满足精细化要求

前面运维的温饱问题解决的差不多了，精细化的需求就会提出来。而系统需求的实现都需要通过一个开发框架来完成，我们可以使用厂家产品自带的开发框架实现，但这些框架有限制性，不灵活，而且后续支持也将强依赖于厂家，所以为了自主可控，需要自己攒一个开发框架，此外，内部的技术沉淀也是一个重要因素。

这个框架给大家简单介绍一下：它是一个Web开发框架，我们给它起了一个名字叫做Ado。它采用前后端完全分离的设计。前端用Vue，后端使用了SpringCloud的一些组件。前后端分别运行在不同的容器中，通过 Docker 或者 docker Swarm发布。

我们用Ado开发框架做了很多小系统，比如告警大屏、每日开机、清算辅助等等，甚至还有培训辅助系统等。有一些通用的公共功能我们把它做成了微服务，如认证服务、通知服务等。

简单说说这个框架下系统的运行时。每个小系统的最前端是一个负载均衡的实例，所有的请求先转发到HAproxy，再到 NginX 前端，然后到 Tomcat，所以至少有三个点运行在3个不同的容器中。通过 Swarm 发布的方式使得当你发现用户请求量大的时候，可以进行弹性伸缩，非常方便。

关于开发框架给大家一些建议：

一开始不要追求开发框架的完美，要快速迭代，合适的才是正确的。

比如说那些可以通过拖拉拽就完成一个功能的开发平台，我们是没有资源和能力去做的，不像深圳的几个大企业，动辄用几百号人，花几年的时间，用上千万的投入，去做这样的平台。

我们中小金融企业真没有资源去自己折腾，而一个相对不错成熟的商业开发平台大概几十万就可以买来用。

3. DevOps 持续集成 —— 走向开发&运维

经过一段时间的积累，我们已经开发了一些系统，接着就会自然而然想到提高开发和发布的效率，开始实践 DevOps。这个过程不是领导要求的，而是有自发的实际需求。

简单说一下我们做 DevOps 的理由：

• 首先要做开发，就要有代码管理，我们选择 Gitlab。
• 再就是容器化部署，一开始我们就决定要做容器化布署应用。但这个过程是两个阶段完成，第一个阶段没用容器，先把框架做好、做稳定，应用按照传统部署方式，然后大概花了2周时间再把全部系统通过容器进行了部署。
• 还有就是我们需要统一的开发和发布管理交互界面，希望在同一UI里做程序的打包、上传、编译，以及发布到测试环境去。
• 然后是快速&可靠的部署。用上容器了以后，你就会发现部署工作变得很容易，甚至使用容器会上瘾。有一个观点是说DevOps可能会让一些运维人员失去工作，这种说法有一定的道理，那些在企业内只做发布和部署的工作会减少。
• 另外是生产环境和开发测试环境的隔离，通常是安全和稳定性的考虑，我们需要分别构建生产和测试的程序发布库。
• 最后是运行环境的一致性，这也是容器带来的优势，容器屏蔽了生产环境和测试环境的差异性，使得部署过程不受环境影响，稳定性和效率得以提高。

提到 DevOps，我们都会想到一个重要的概念“流水线”，如下图右边“过程2”是我们一开始用的 Pipeline，它比较简单，所有的工作都是在Master分支完成的，包括打包成镜像，把它发布到镜像仓库，从镜像仓库拉取完成测试环境的部署。

当时这样的流水线对我们来说是适用的，但用了一段时间了以后，有人提出能不能做得更好一点，把代码扫描和单元测试加进去？于是，我们改进了这个流水线，加上了代码扫描，同时做了一些管控，如下左图。

DevOps 涉及的理念很多，而类似这种过程的持续改进，我们在不断的实践着，它也是 DevOps 的精髓之一。

下面这张图是我们现在的CI过程：先把代码提交到 Git 的 Dev 分支，触发CI-Runner，它会从Git服务器上拉取代码进行编译，然后使用 SonarQube 进行代码的局部扫描，即对你本次提交的代码进行扫描。扫描完成之后会把结果反写到 Gitlab 上，告诉你代码存在哪些问题。

比如这里提示“空指针异常应该被抛出”等等。当系统模块开发的差不多了，开发组长就提交一次Merge请求触发另一个Pipeline。

接着 SonarQube 按照既定的流程进行全量代码的扫描和分析，并生成报告，当分析代码没有严重问题，CI-Runner 就把代码打包成镜像文件，并推送到镜像仓库中。

下面讲讲这个 DevOps 系统的组件和架构。代码管理是用 Gitlab，CI/CD过程使用CI-Runner，它可以跑在容器里，也可以是虚拟机和物理机，根据需要构建，比如大量的代码进行编译，选择IO比较好的运行时环境，如果跑测试，选择内存和CPU比较好的环境。

镜像仓库我们是用VMWare开源的Harbor，按照某种策略在生产和测试镜像库之间同步镜像文件。容器的监控和管理使用Portainer。最后部署使用Docker单节点和Docker Swarm两种方式。

关于某个应用系统 DevOps 的详细过程就不展开了，关键点说一下：

在构建每个应用的时候都会建立一个项目群组，包括前端项目、后端项目，还有整体应用发布的项目（一共3个项目），前面两个用于开发前后端不同的模块，并打包推送到镜像仓库，后面那个项目用于发布测试环境，其中打的Tag会作为每次发布的版本号。

最后说说我们在 DevOps 实践过程中的体会。

传统中小金融企业 DevOps 的驱动力因为其体量小、工程师文化不足（或者是工程师资源不够），这时候如果采取自上而下通过文化建设的方式是行不通的，你想推动 DevOps，但其他人不配合或者没时间配合，反倒是你构建了一些工具能够帮助大家提高开发、测试和上线的效率，从这个点出发可能才是 DevOps 的驱动点。

另外，适当裁剪 DevOps 的过程：不是每个企业、每种业务（尤其是传统业务）都适合 DevOps，还是前面提到的适当性原则，从实际效率需求出发才能让新的技术、理念和模式得到普及。

还有，为什么不选 K8S？跟前面一样，K8S 很好，但需要更多的投入。所以我们不是不选，而是我们的需求还没达到成熟度，目前从我们容器的规模体量和对容器化应用的需求看，使用Docker Swarm 已经够用了。同时，我们也在研究 K8S，可能晚些时候会用 K8S, 也可能是通过 Rancher 间接地使用。

最后感谢一下我的团队。我们虽然一开始不是打着 DevOps 的旗帜做运维平台和开发，但通过大家持续不断地改进，用代码优化过程，结果是提高了开发和运维的效率，这恰恰就是 DevOps 的核心思想之一。

说明：以上为广州证券 IT 架构师李晓璐在 DOIS 2018 · 深圳站的分享。