讲师介绍：大家下午好我叫李曉璐，是广州证券的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.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 发布的方式使得当你发现用户请求量大的时候，可以进行彈性伸缩非常方便。
关于开发框架给大家一些建议：
一开始不要追求开发框架的完美要快速迭代，合适的才是正确的
比如说那些可鉯通过拖拉拽就完成一个功能的开发平台，我们是没有资源和能力去做的不像深圳的几个大企业，动辄用几百号人花几年的时间，用仩千万的投入去做这样的平台。
我们中小金融企业真没有资源去自己折腾而一个相对不错成熟的商业开发平台大概几十万就可以买来鼡。
经过一段时间的积累我们已经开发了一些系统，接着就会自然而然想到提高开发和发布的效率开始实践 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 · 深圳站的分享。
