招商基金 DevOps 从0到1实践之路

未分类

王洋：各位大家好，非常感谢高效运维社区提供这样一个平台和机会，有机会和大家分享一下招商基金在DevOps从0到1建设之路的问题，因为这个时间点，所以大家可能还有休息的习惯，我尽量讲得不让大家感觉催眠。下面开始，个人介绍不说了，之前社区也有做了一些宣传，今天直接切入主题讲一下。

分享分为六个部分，

• 第一个再解读DevOps是什么，
• 第二个部分是刀耕火种的手工时代，
• 第三个是拒绝低效开启自动化运维之路，
• 第四部分是向左转、向右转，自研还是合作，
• 第五是涅盘之力，朱雀翱翔，
• 第六是DevOps未来发展的规划。

1. 再解读 DevOps 是什么

在做分享之前，我在想说一下我觉得我不要做成纯技术的分享，这也是我之前做分享的主要的一个方向，就是不希望作为纯技术分享，因为纯技术分享其实比我厉害的，比我们公司厉害的公司和个人都非常多，我觉得这个没有太大的意义，这样雷同性很高。第二我希望我做的分享都是结合我们公司实际情况的分享，这样大家有更多的参考，之后会过多讲一下在实际落地或者工作遇到的坑，还有我们怎么解决这些坑和跳过这个坑。

DevOps 这个事有很多年了，像一千个人眼中有一千个哈姆雷特一样，我觉得十个人眼中可能有大于十个对于 DevOps 的理解。那 DevOps 到底是什么？大家有一些困惑，到底是一种精神还是工具平台？看过很多文章，也参加了很多分享，还不知道是什么。那我也有深入思考这个问题，我自己做了一个可能比较让大家容易理解的，我认为它是对落地实际指导有一定意义的总结，所以我的理解是它是一种工作方式，是打通从业务需求到项目管理，到开发到测试到部署到运营一系列节点而形成闭环的工作方式。在这个闭环的过程中所有涉及到对KPI或者个人成长没有价值的人工操作都应该尽可能自动化。这样对大家实际落地的指导有参考，这只是我觉得以这样的方式让大家更容易落地一些事，如果你只是想知道代码如何开发、测试，生产环境流转，CI/CD如何配置的话，那我可能讲得跟你有点差异。

二、刀耕火种的手工时代

第二部分，我是2017年到招商基金，刚来的时候，我们以下的内容基本全是手工操作，包括主机创建、应用配置、版本管理、监控配置、日志清理、信息周知、中间件安装、变更发布、优雅发布等等，这些事当时基本是手工维护，而且我相信包括在现在，大家肯定目前这里面还有很多还是通过手工的方式在进行维护。这些事情当时也占了我们大把的工作时间，因为我们一个基金公司IT部分不像互联网公司是主要部门，所以我们信息技术部的运维组也没有多少人，

那我在想一个问题，你做手工的重复工作有没有意义，对你个人的KPI有没有意义，对个人的成长有没有意义，好像答案都是否定的，难道运维只需要关注基础架构的稳 定性和安全就够了吗？那我觉得这样的运维可能会被时代抛弃，或者只是说公司提供这样的岗位解决市场的就业，所以我们要思考这样的事。

思考之后我觉得要做出一些改变，就要解决低效开启自动化之路。那刚才提到我们公司的IT资源有限，但是面对的问题已经很明显，这个时候你必须做出改变那就只能先选痛点比较突出的先做起来，当时对我们来说最痛的两个点，一个是自动化的发布，第二个就是中间件的安装。2017年的时候我们当时发布的数量，一年统计过只是开发提交的版本变更，大概2200多个，当时全是手工做，所以这一块是我们很大的痛点。第二部分关于中间件的安装，也全是手工，把机器申请下来再安装，也很慢，所以当时就像我们公司现在一样，或者很多公司打算用Jenkins，我们用它做了一个自动化发布的工具，然后有专职的同事对它进行开发，然后去配置去分批跟自研的运用系统对接。

背景大概说一下，因为我们公司IT分为两类，一类是自研，一类是外购，我们现在其实也是在往纯自研的方向走，投入很多人力和物力，因为自研现在是主潮流，包括头部的基金公司都在自研投入很大的人力和物力，但是当时2017年的时候有一个问题，就是在此之前很多东西不规范，标准化做得不好，就导致很多应用的安装路径不统一，配置文件放的位置不统一，工程命名不规范，所以当时一个同事来专门做这个成本很高，一年下来当时的资源系统也没有全部对接完。中间件安装我们用了最多的两个，一个是（14：20不清），这两个现在基本已经不用了，但是当时确实是在2017年的时候用得最多。

这个是我当时兼职抽出一点时间做中间件的安装。随着我们公司IT资源的投入和对资源的追求，我们系统建设的规模开始越来越大，对资源的需求量也越来越多，采用敏捷开发模式，迭代速度加快，版本的变更频率进一步提升，现在我们还进行了微服务的拆分，需要配置自动化变更任务的数量也就更进一步增加。第四部分随着技术栈的引入，对中间件的需求类型增加，优雅变更的效率进一步提升，因为这里面我们的电商部门包括和蚂蚁、腾讯和京东、苏宁都有一些合作，他们对变更要求稳定性很高，就是不能影响服务器稳定，所以在优雅变更这一块有进一步的提升。还有资源增加之后日常工作消耗量增加，这个是什么？比如说资源增加之后我们维护CI/CD人工的数据量也增加，对于这一类操作，人工的投入量很大。最后就是说到刚开的问题，就是支持的人力资源是有限的，所以这也是我们后面面临一系列的问题。

那我们在想选择自研还是合作做DevOps这件事？自研有优点，就是技术栈完全可控，另外本地性的适用性很好，原先做的工作和成果可以保留下来，而且可以按需自己自定义。省钱为什么是个问号？现在大家有思想转变了，因为以前大家觉得自己建设省钱，我不这样认为，比如说一个公司花五十万招人，但是实际上投入的不仅仅五十万，但是这个人一年时间来做DevOps工具，不是DevOps这件事，而是纯粹工具链，又能作出什么效果？其实不知道的，所以说省钱我觉得这别并不是自研的优点，但是这点大家会慢慢接受了。缺点就是人力资源投入过多，没法预期，第二就是整个链条中所涉及到的诸多能力，都需要自建的话，其实你是不可预见的，你不知道会建成什么样。

第三点对实际的目标和效果没有可预见的预期，因为你没有一个参考的目标，你想做高大上的不可能，你同行业看自研的参考很少，所以这就是尴尬的一点。另外说外购，它的优点不用重复开始造文字，实施的效果预见性很强，这个可以看我要合作的厂商案例的情况，包括可以从合作的层面对一些需求点和能力点进行约束，这些可以预见的，另外可以节约部分的人力资源。缺点也有，比如说厂商依赖，现在有很多厂商说自己基于开源做的，甚至有甲方自己说用开源做了什么东西，可以自主可控，但是其实自主可控这个东西我觉得有一种是伪开源，在公司发展的一定阶段，你对开源能力的掌握实际上是依赖于某几个人的能力，当你这些人的能力达不到的时候，我即使给你所有的元代码又能怎么样，所以公司在一定的规模的时候完全用开源的东西我不目前认为一定是自主可控，如果你拿到这些想做自主可控去发挥这些元代码更大的功能做自定义开发可能会投入更大的成本，所以说这里面就是一个伪开源的概念。

还有本地的自定义适应性较差，因为产品不可能根据本地的情况做很好的适应，这个肯定有问题。另外还有贵，贵和便宜其实是相对概念，相当于我们现在采购一个产品或者一个平台、工具，我们会怎么对比？我们首先对比在行业里面大家基本是什么价格买。其次考虑如果这个东西我们自己开发，需要投入多少人力，这个大概多少钱，所以你这样算下来之后才能评估你外购的东西是便宜还是贵，所以这是相对的概念。

现在既然已经考虑了，那我们在想，根据公司的现状我们可能还是要引入一个合作伙伴走一种合作的路线，那当时正好赶上我们科技化开始，那三年科技化开始的时候不想说DevOps这个工具还是平台也好，所以当时我们就想以此为一个契机，去建设一个以DevOps为切入点的适合我们公司的PaaS平台。当时考虑几个点，第一我们是一家基金公司，那对于基金公司来说业务价值是第一位的，所以我们要考虑业务价值优先第一。第二就是对于一个金融行业肯定还是求稳，但是我们又要做一些创新，又要在行业里面做一些能够领头的事，所以就是稳字当头、拥抱创新。

第三点小步快跑、敏捷思维什么意思呢？敏捷其实是开发团队的人用得最多，但是我觉得这个恰恰也可以用在运维，为什么运维方面的平台或者工具一定是瀑布式的？没有人说过，我也可以去迭代和发展，就像在BAT的大厂的工具组也是做迭代性的发展，所以说这种敏捷思维我觉得同样可以运用到自研，我们这种规模的企业里面去也可以。

那要做好这个事怎么办？就是借着科技化的事情，大家用心用力，每个人的担当树立起来，所以这个时候就是立了这样的方向，我们以DevOps这个事作为切入点，准备建设我们公司的PaaS平台。这个PaaS平台叫什么名字？就是朱雀，题目也是涅盘之力，朱雀翱翔。

为什么叫朱雀？是这样的，首先我们公司之前有一个自研的TA系统，叫盘古，如果做基金和证券的应该对TA比较清楚，TA系统外购很贵，当时我们内部研发团队评估了之后觉得我们可以自建，所以就自建了这样的TA系统，所以当时就起名叫盘古，那起到盘古名字以后，因为我之前是阿里系的，阿里系的人都比较喜欢给平台和系统起名，所以当时我也想给PaaS平台起个名字，因为盘古是一个属于东方系的命名方式，所以我自然要沿用这样的方式，所以当时想到朱雀，因为朱雀是个凤凰，代表涅盘重生，之前在DevOps或者PaaS都是属于没有，或者属于很LOW的状态，那我们也希望用凤凰这种寓意代表重生。

第二部分是合作伙伴的选择与思考，根据我们公司的现状，我们公司现在已经比较多，当时我2017年来的时候公司IT的正式员工只有30多人，运维是6.7个人，现在我们公司IT70多人，基础架构运维十来个人，这种人数决定了我们不可能完全自建这个事，所以我们还是要选择一个合作厂商一起做，但是合作怎么做？我们是有一些考量的。第一首先我们觉得要达到的是一个合作供应共同发展的路径，而不是说像传统的你就是服务商，我买你的东西你把东西卖给我，就可以，这不是我们想要的，也不是新时代的合作模式。我们想我们的需求目标和规划的方向和这个厂商它的发展方向、产品的迭代思路方向保持一致，同时大家也是想一起平等把这件事做好，这是我们第一个转型的思考。

第二个就是案例，首先当然你在行业有很多案例是很好的参考，但是案例同时也有另外一个问题，就是有的时候有一些好的东西它未必在行业里面目前有人有，就是要有第一个吃螃蟹的人，就是相当于我们平时工作也好上学也好，你总像第一名学习，你永远成不了第一，你可能只是第二或者第三，只有向跨界的学习，更高端要求自己，你才有可能成为第一名，所以我觉得案例大家不必纠结，如果认为这个东西就是很好，它就算在本行业没有，大家也可以考虑尝试成为第一个吃螃蟹的人。

第三个是小细节点，但是是我非常在意的点，我们知道作为甲方经常会跟厂商有一些交流，那大家一定会遇到一种情况，当时一定甲方提出一些问题，厂商在交流会上他是没法完全回答你，他会告诉你我回去确认一下，这个情况我相信大家遇到过，那遇到这种情况的时候我会考虑，我会看看我抛出这个问题之后，他多久给我响应，如果响应的时间越长，可能厂商根本看不上我们，觉得我们小公司，也给不了几个钱，不太重视，这是其一。第二可能会反映出这个公司内部的流行运转有问题，所以这两点会成为我选择合作伙伴的参考因素。

那要做DevOps或者PaaS平台，很重要的前提是标准化，如果没有标准化所说的一切都是空谈。所以当时做这个事我也是推进我们公司标准化的建设，当时提出几个，第一是主机的标准化，第二是代码打包制品的标准化，第三是口径术语的标准化，第四是部署与发布标准的标准化，还有是中间件的标准化。那主机的标准化比较好理解，我们就是参考公有云的方式，提供几种标准的机器的规格，你来申请的时候基本上就是套用我的规格来申请，如果有特殊的需求可以自定义，但是要给出一个详细的说明，经过我们认可以后才可以。第二是提供标准操作系统模块，比如说我不是说要什么操作系统我们都给，这个也不是不可以的。

第三个是操作系统有参数，我们把这些操作系统参数做了标准化之后会打好机器里面去。代码这有代码的管理标准，还有打包工具的使用，打包之后的路径，打包路径的标准化，制品名称的标准化，因为我们还有招商基金、招商财富，招商财富是我们的子公司，所以我们会把公司的前缀加上每个组的打到里面还有版本的标准化，主要为了方便我们回馈。口径术语的标准化，就是在我们公司内部标准统一什么叫平台，什么叫应用，他们之间是什么关系，就是把所有的系统归到这个里面，不能超出之外的东西，好处就是可以让业务和IT运维和IT开发的数据保持一致，不然大家交流的时候就是你说你的他说他的，根本不知道是什么。还有部署与发布这边首先我们有灰度发布，优雅发布、启动和停止脚本的标准化，还有权限的标准化，还有状态检测的标准化，包括二进制包、配置文件、日志、行为目录的标准化，中间件标准化我们就是提供外部容器提供标准化，你想要外部容器提供哪些，其他的不可以，JVM容器我提供哪些，其他不可以，缓存提供哪些，数据库提供哪些，这些我们都做了一系列的标准化。

下面我左下角有一句话叫做，为了推行标准化贵公司是怎么做的呢？这个大家可以先想一下，我后面还会讲到，从一个中间件的点剖析一下或者分享一下我们公司怎么推广这个事。因为我实际发现，平时我在群里也有看到大家的交流，在有一些地方推行标准化这个事有点难。

这个全局的图就是我们公司朱雀平台的现状，大家可以看到由CMDD贯穿，分为五大模块，运维自动化、DevOps工具、监控、调度与其他容量管理。这里面DevOps我写了工具，因为我对DevOps的理解在前面说了，所以后面会提到仅仅是DevOps的工具。橘黄色的部分就是我们已经覆盖和实现的能力，没有橘黄色的就是今年或者今年做不了稍微往后放一放。

说到PaaS平台，说到DevOps其实一个很重要的点就是CMDB，CMDB其实大家都在做，也用了很多年，但是往往立了一个CMDB项目，一段时间就废了，又立了又废了，里面有很多问题。但其实CMDB怎么让更多的除了IT的人或者业务的人理解？我记得有一次和业务部门分享这个事的时候，我说CMDB就像行军打仗的地图，他可以让你在这里面找到你所需要的要素，那这个要素有什么用？就是关联影响分析，就是我认为是CMDB建设中非常重要的收益点。就是你建成这个CMDB，难道说你就是把一个表格里面记录的录到CMDB里面去了吗？我记得去年参加上海产品大会的时候有一个嘉宾说的一句话，他说他们到了很多地方调研，问你们有没有CMDB？说有。那你们公司查询信息用什么？用excel。这就很搞笑，所以其实很多地方没有把CMDB用起来，那么CMDB用起来以后，关联影响分析是非常重要收益点，那这个里面又有两条非常重要，一个是对基础架构的设计优化，一个是对故障影响分析。

我分享我们公司实际的例子，因为我们现在的CMDB系统可以自动生成系统拓步（音）关系图，那生成图之后一方面我们可以从这个图里面比较清晰地看到这里面目前的架构设计是不是有什么问题，是不是有什么优化点，这是其一。其二因为我们现在是有架构评审的环节，那各个项目的组他们会对他的架构拿出来做评审，那评审之后就有一个问题，比如说他架构评审认为是要A这样，那落地的时候是B这样，这样就违背了架构评审所承诺的东西。那我们就可以通过这种方式做一个take（音），通过take的方式就可以在项目交付的时候看看它现在的真正情况和当初在架构设计上或架构评审的时候要求是否一致。

故障影响分析也很明显，比如说有的时候要做一些文件服务器的迁移，第一我可以从文件服务器查到哪些机器是否有连接，第二可以通过CMDB查到哪些机器和它有连接，这样双方做一个双向检查，这样可能会有遗漏点的问题就降到最低。第二我相信大家基本都用虚拟化，那有一个问题就是速度机故障，那影响的就是速度机故障了，上面的虚拟机做漂移，任何事都没有，但是很多时候我们为了稳妥起见，还是会告诉大家，比如说我这个周末我的速度机因为什么问题可能要更换一些配件，或者不可知的这个速度机故障，那这个时候要快速有一个列表能够让我知道哪些机器受到了影响，这样便于开发人员或者运维人员确认漂移之后有没有产生真正的影响，其实这个理想情况大家都觉得好像没有，但是实际上还是会有一些问题的，这两点也是我们在故障影响分析里面非常重要的。

CMDB还有一个问题就是准确性，很多人用不好CMDB就是因为觉得准确性不行，准确性不行的话怎么办？因为越不准确的东西越没人要，所以我总结出来CMDB的准确要做好就是几块，第一是消费，只有把数据用起来才有可能越来越准，因为用起来才是一个流动。第二是数据的准入把关，不是什么数据都可以进来。第三是模型数据的审核审计。举个例子，就像家里平时你穿的衣服或者东西，日常用的就是手边的东西，其实日常手边用的就是那一些，你用得很顺手，你也知道用这个东西会有什么效果，那实际上是什么？就是消费，因为这些东西你一直在用，你知道是对的是准的。第二数据准入的把关就是只有家里的主人才可以把外面的东西拿进来。模型数据审核就是像定期做大扫除一样。

那以应用为中心这个事，其实这些东西和DevOps都是有直接相关的，因为应用的话实际上在我们这边就是一个部署的最小单位，就是DevOps工具落地进行操作的最小单位，那以应用为中心的CMDB的好处就是可以起到一个承上启下的作用，因为应用对上是业务系统，业务系统恰恰是开发和业务部门最感兴趣的东西，那对下可以涉及到环境、集群、主机、负责人，这些东西又恰恰是运维所关心的点，所以说通过以应用为中心的CMDB很好把开发运维串联起来，所以说我觉得一个CMDB好不好，至少在我看来以应用为中心比较重要。因为我们也做过CMDB，当时都是以底层架构驱动，要录机房的信息，服务器的信息这些东西，你说重不重要？它也重要，但是它有一个很大的前提条件，如果有一些流程不够完善的话，我第一次初始化以后数据是不准的，但是后面可能因为我电源换了PDO，换了插头以后没人通过流程维护这些东西，因为不准，因为它的消费属性太低，所以就会造成失准。那以应用为中心就是对应前面说的消费，可以把数据流动起来，活起来。

运维自动化这一块主要实现以RPA、中间件标准化创建、场景化运维、自动化巡检、故障辅助定位、全流程剧本化。RPA主要是一些开试和配试的工作，这一块应该也有同行做得挺多。我借中间件说一下标准化问题，我们目前支持标准化创建的东西有apache nginx，rcsin，rcdis，zookeeper，kafka activemq，tomcat，我们所谓的中间件标准化创建，并不像现在市面的标准化中间件，只是帮你把中间件安上去，但是我们不是，我们这个是贴合我们业务场景的，也就是说所有需要的业务属性信息，在我的中间件安装输入的时候会作为参数打进去，这样的话我的中间件安装好以后不需要运维，也不需要开发人员在上面配置就可以直接拿来使用。

那么说到评审这一块是怎么标准化？我之前在群里看到，有人说他们压力很大，说开发引入什么东西他们就要用，怎么办？所以说其实之前的时候我们没有架构组的时候，我们是运维前置，当时运维在前面审核，如果我们明确告诉你，你引入中间件，我们没有技术栈，交给我们运维，出了问题我们不负责的，因为我们就这么多人，就这么多人力。后面引入架构组以后，我们架构评审的环节会做这样的事，因为架构组里面有负责技术的，有负责技术栈的，有负责数据的，有负责运维的，所以这个层面大家会做这个事，那大家要想到一个点，你怎么样才让开发认可你说的话，这个其实很关键，其实在我看来，运维侧你提出的标准不能是强制要求人家你只能用这些，第一你要告诉人家我提供给你用这些，为什么提供这些，你要给一个说明。第二我会告诉你你用我提供这些东西我会给你什么好处，包括资源交付，包括后续稳定的维护，包括后续的升级，这样开发才会在一定的情况接受你说的内容，然后配合你做这样的事。这边就提到一个智能化，智能化的前提是自动化，自动化的前提是标准化，你看云平台现在为什么这么火？因为是极度标准化的东西。

这一张图是我们平台的截图，现在能够做的，也是最近做的自动化安装的截图，大家看一眼就好。还有场景化运维的东西，就是我们目前做的主要有Dubbo应用优雅重启，springboot环境初始化，log用户创建，磁盘扩容，对象存储上信息查看，那这些场景其实来源几个方面，第一我会去观察平时开发在工作过程中有哪些点是让我看起来很低效的点，我会帮他做这样的事。第二运维在平时工作中有哪些内容我觉得是重复做的事，而且这些对个人成长和KPI没有意义，所以我会收集这些做自动化的场景。这些场景我们也有一点一点在做，这块内容在我们公司是在平台上开了一个模块叫开发者服务模块，一个月左右就更新一些内容在上面。

今天说了半天没有说到DevOps，但是我觉得我一直都是在讲DevOps，因为我从来不觉得只有讲工具才是DevOps，所以现在重点讲DevOps工具这一块我们目前DevOps工具实现的是有开发、测试、生产全流水线打通，而且这里面引入了两种模式，因为我们想知道哪种模式更适合我们。第一是拆成三条，开发一条、测试一条、生产一条，中间通过制品绑定，也就是说开发测试完的通过制品包升级，然后到测试，测试用前一个制品包，依此类推多生产。第二种模式是我们打通一条流水线，把开发、测试、生产全打通，也是通过制品包升级，但制品包升级的话是需要每一个节点的负责人来进行负责的，这个等会给大家看个图就知道什么意思了。

第二个是历史版本的回退，因为我们现在的DevOps工具是完全支持，只要是全量发布，那么历史版本可以快速回退，只要选择之前的版本就可以快速回退。第三个就是自定义流水线，这一块就是我可以通过我的自定义流水线，我去对接其他第三方提供API接口的工具也好，平台也好，来实现更多更强大的功能。第四块就是优雅和灰度发布，这个要看业务部门和开发部门的需求进行相关的配置。发布时健康检查，就是现在CD的动作是由运维在做，那运维做完之后怎么才算应用发布成功？这个地方是要开发确认的，所以用健康检查的方式，相当于我跟你约定好，你的健康检查通过，你这个就是成功的，这个是边界约定的事。还有数据库脚本变更我们今年刚开始做，在开发测试环境通过，但是生产环境要逐步做，这一块属于刚起步。

这个就是刚才说的全生命周期就是打通，打通之后从开发到测试到生产全流程，这是一个全流程的方式。自定义举个例子，前面也有讲过，现在有和第三方机构，苏宁银行和京东、腾讯和蚂蚁等等都有合作，他们就要求我们变更是无损变更，优雅变更。我们之前是怎么做的，就是通过人工的方式在S5上把后端节点摘掉，等一段时间之后等业务跑完以后，再进行变更，变更完之后再恢复，这样的一个过程。整个过程如果由人工操作，我们当时试过，就算做得快，整个过程也要十几分钟的时候才能做完变更。那现在上了流水线以后，我们整个变更基本上就是会很快，就是四五分钟的时间，消耗的时间点仅仅是在我们自己去等待业务跑完人工设定的时间。

现在说一下监控，因为我觉得也是DevOps非常重要的部分，因为你监控才能知道你当前的变化对系统有没有什么影响，所以监控这一块传统意义上大家会进行分层，我不详细说，我重点说几个部分。第一是健康检查，这个在很多互联网公司用了好多年大家觉得很正常的事，但是实际上在金融行业这一块用得还不是很多，但是我觉得健康检查恰恰是真正能够反映问题发现的方式，现在很多系统在做检查的时候怎么检查的呢？是看它的端口在不在，进程在不在，但是很多时候你的进程在，断口在，服务就是不好，所以服务拨测形成健康检查这种方式我值得现在很多企业去考虑使用的方式，但是这个里面有一个问题，就是你的拨测点很重要，我们现在就分了很多拨测点，首先有外部的拨测，直接从互联网打进来的，这是一种。第二我有一种内部发行的拨测，也分在不同的位置上，比如说我是在代理之前的，还是在代理之后的直接打服务的，这些都有，这样有什么好处？如果哪天收到一个报警，是外部拨测发现你的系统不可用，但是我的内部拨测全是好的，那问题就很好解决，说明是线路上可能有问题，或者接入的切换机有问题，就是这个意思，我们可以比较方便定位这个问题。

第二点关于中间件监控，其实现在大家都知道中间件监控都是获取很多监控指标，也有很多人认为我的监控指标越多越好。但实际上监控指标重不重要？重要，它可以帮助我们排查中间件的性能问题和可能性的问题，但是有一种场景就是中间件各种指标看上去就是好的但是我们就是用不了，那这个时候怎么办？其实我还是推崇于，其实这个思路是来自健康检查的思路，就是我要一个模拟访问。所以我们这边的像卡夫卡这类的中间件基本都做了模拟访问，就是我会用最简单的一个程序来跑一个简单的来检测我的中间件自身的一个可能性。

未来发展规划我们要增加安全扫描的模块，主要是增加代码扫描和开源扫描，第二是完全和需求管理平台打通，真正实现需求到编码到安全到测试到部署完全打通的方式，第三是双模统一部署，因为我们现在有基于虚拟机的容器，但是现在实际上管理可以在一起，但是最终部署的时候还是要分开的，后面这块我们要把部署打通，最后一部分是变更包的溯源，大家知道每年基本有六七次高危的代码包、第三方插件包有问题，其实这个就要求我们可以快速找到，这些包我们变更的时候有没有引入进来，引入进来了以后到底是在什么位置，所以这个时候我们需要快速能够找到变更包所在的位置来进行回溯，进行安全处理。

然后打通之后就形成这样的一张图，首先我们左边的业务部门提出需求，由IT的PO，我们这边是由PO来承接业务部门的需求，那PO拿到这些需求之后会对需求进行分解，分解完之后进行落地，现在大家看到第一部分的需求和变更管理工具，这个部分跟后面没有完全打通，有点离散，但是这是今年可以搞定，后续的像持续集成测试、配置部署、检测提炼，这些是可以在一起。那在这里面可以看到蓝色的两块，就是我们缺乏的，今年准备把它补进去的。配置管理这块的配置中心，目前其实是处于一个混合阶段，就是我们现在有一些是用阿波罗的配置中心有一些用传统文件，但是我们全部往阿波罗配置中心这个方向去转。

除此之外还说到刚才说的CMDB，如果是DevOps的工具链要发生改变，那就是我公司在CMDB或者系统架构做的演进，第一我们会坚持业务导向，因为毕竟我们是基金公司，不是IT公司，所以一切要以业务为导向，以业务为第一要务，真正实现IT价值和业务的协调一致发展。说到这点我又想到一点，DevOps Master里面说到一点，就是DevOps的核心就是指业务需求。第二点就是用互联网技术和思维结合我们的行业情况，对现有进行改造取长补短。其实我会发现有一些人比较喜欢把互联网这套东西生搬硬套进其他的行业，但是每个行业有自己的特殊性，完全硬套可能有些问题。第三个是自动运营，以前有一个大神写的文章叫做用户向运营的转变，我觉得写得很好，如果运维只做基础资源交付这一块，那很有可能未来会被代运维掉，或者被云资源越来越多之后他价值就越来越小，所以要往运营的方向发展。

那我们在做的就是从业务的视角统计出每一个业务资源的使用情况，便于进行费用分摊，或者统一出每一个业务系统对基础资源的消耗，这里面包括你的CPU内存、硬盘包括监控的需求量，包括你变更的次数，全会在这里面进行统计。最后是强化用户体验，我们要梳理清楚我们的服务对象是哪几类，每类用户的真正需求是什么，有针对性的有的放矢，这样才能把我们有限的资源为业务部门或者其他前台部门贡献价值的方向。

最后我补一个小广告，这个地方我刚才讲到叫朱雀，我们公司还有一个系统叫做玄武，更多是IaaS层的东西，大家如果有兴趣在今年的6月份深圳站的DevOps产品大会上我会分享更全面的PaaS和IaaS的事情，今天主要是分享DevOps方面的内容，谢谢大家，我的分享完了。