运维还在刀耕火种？拒绝低效，开启你的自动化之路

云栖号资讯：【点击查看更多行业资讯】
在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！

本次分享分为六个部分：

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

再解读 DevOps 是什么

在分享之前，我在想说一下不要做成纯技术的分享，这也是我之前做分享的主要的一个方向，因为纯技术分享其实比我厉害的人很多，我觉得这个没有太大的意义。第二我希望做的分享结合公司实际情况，这样大家有更多参考，之后会过多讲一下在实际落地中遇到的坑，以及怎么解决这些问题的。

DevOps 有很多年了，像一千个人眼中有一千个哈姆雷特一样，我觉得十个人眼中可能有大于十个对 DevOps 的理解。DevOps 到底是什么？大家有一些困惑，到底是一种精神还是工具平台？看过很多文章，也参加了很多分享，还是不知道是什么。我深入思考过这个问题并做了一个可能比较让大家容易理解的，对落地有指导意义的总结。

我的理解是它是一种工作方式，是打通从业务需求到项目管理，从开发→测试→部署→运营一系列节点而形成的闭环的工作方式。在这个闭环里，所有涉及到对KPI或个人成长没有价值的人工操作都应该尽可能自动化。这样对大家实际落地的指导有参考，我觉得以这样的方式让大家更容易落地一些事，如果你只是想知道代码如何开发、测试，生产环境流转，CI/CD如何配置，那我可能讲得跟你有点差异。

刀耕火种的手工时代

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

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

拒绝低效！开启自动化之路

思考之后我觉得要做出一些改变，刚才提到招商基金的IT资源有限，但面对的问题已经很明显，这时先选痛点比较突出的做起来，当时对我们来说最痛的两个点，一个是自动化的发布，二是中间件的安装。2017年只是开发提交的版本变更大概就有2200多个，全是手工完成，所以这一块是我们很大的痛点。

中间件的安装也全是基于手工，把机器申请下来再安装，也很慢，所以当时就像我们公司现在一样，或者很多公司打算用 Jenkins，我们用它做了一个自动化发布的工具，然后有专职的同事对它进行开发，然后去配置去分批跟自研的运用系统对接。

2017年的时候有一个问题，就是在此之前标准化做得不够好，导致很多应用的安装路径不统一，配置文件放的位置不统一，工程命名不规范，所以当时一个同事来专门做这个成本很高，一年下来当时的资源系统也没有全部对接完。中间件安装用了最多的两个工具是Resin和Apache。

随着 IT 系统建设，对资源的需求量也越来越多，采用敏捷开发模式，迭代速度加快，版本的变更频率进一步提升。现在还进行了微服务拆分，需要配置自动化，变更任务的数量也就进一步增加。

技术栈的引入也对中间件的需求类型增加，优雅变更的效率进一步提升。因为招商基金的电商部门与蚂蚁金服、腾讯、京东、苏宁有一些合作，他们对变更要求稳定性很高，所以在优雅变更这一块有进一步的提升。

资源增加后日常工作量也相应增加，这个是什么？比如资源增加之后我们维护 CI/CD 人工的数据量也增加，对于这一类操作，人工的投入量很大。最后就是说到刚开始的问题，就是支持的人力资源有限，所以这也是我们后面面临一系列的问题。

自研还是合作？

那我们在想选择自研还是合作落地 DevOps ？自研有优点，就是技术栈完全可控，本地性的适用性很好，原先做的工作和成果可以保留，可以按需自定义。

省钱为什么是个问号？现在大家有思想转变了，因为以前大家觉得自己建设省钱，我不这样认为，比如说一个公司花五十万招人，但是实际上投入的不仅仅五十万，但是这个人一年时间来做 DevOps 工具，不是 DevOps 这件事，而是纯粹工具链，又能做出什么效果？其实不知道的，所以说省钱我觉得这别并不是自研的优点，但是这点大家会慢慢接受了。

缺点就是人力资源投入过多，没法预期；第二就是整个链条中所涉及到的诸多能力，如果都需要自建的话，其实是不可预见的，不知道会建成什么样。

第三对实际的目标和效果没有可预见的预期，因为没有一个参考的目标，你想做高大上的不可能，同行业自研的参考很少，所以这就是尴尬的一点。

另外说外购，它的优点是不用重复造轮子，实施的效果预见性很强，这个需要看合作的厂商案例的情况，包括从合作的层面对一些需求点和能力点进行约束，这些可以预见的；可以节约部分的人力资源。

缺点也有，比如厂商依赖，现在有很多厂商宣传是基于开源做的，甚至有甲方说用开源做了什么东西，可以自主可控，但自主可控我觉得有一种是伪开源。当公司发展到一定阶段，对开源能力的掌握实际上是依赖于某几个人的能力，而当能力达不到时，即使给所有的源代码也不能发挥应有的效果。所以公司在一定的规模时完全使用开源软件，我不目前认为一定是自主可控，同时做自定义开发会投入更大的成本。

还有本地的自定义适应性较差，因为产品不可能根据本地的情况做很好的适应，这个肯定有问题。

另外还有贵，贵和便宜其实是相对概念，相当于我们采购一个产品或一个平台、工具，我们会怎么对比？我们首先对比在行业里面大家基本是什么价格买。其次考虑如果这个东西我们自己开发，需要投入多少人力，所以这样算下来之后才能评估外购的东西是便宜还是贵。

涅槃之力，朱雀翱翔

既然已经考虑了上面这些，我们在思考是否要根据公司现状引入一个合作伙伴走合作的路线，当时正好赶上公司科技化浪潮，我们就想以此为一个契机，去建设一个以 DevOps 为切入点适合我们公司的 PaaS 平台。

当时考虑几个点，第一我们是一家基金公司，对于基金公司来说业务价值是第一位的，所以要考虑业务价值优先第一。第二就是对于一个金融行业肯定还是求稳，但是又要做一些创新，还要在行业里面做一些能够领头的事，所以就是稳字当头、拥抱创新。

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

名字的由来

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

为什么叫朱雀？因为我们公司之前有一个自研的TA系统叫盘古，做基金和证券的应该对TA比较清楚，TA系统外购很贵，当时我们内部研发团队评估了之后觉得可以自建，当时就起名叫盘古。

第二，我之前是阿里系的，阿里系的人都比较喜欢给平台和系统起名，所以当时我也想给 PaaS 平台起个名字，因为盘古是属于东方系的命名方式，自然要沿用这样的方式，当时想到朱雀，因为朱雀代表涅盘重生，之前在 DevOps 或者 PaaS 都是属于没有，也希望用凤凰代表一种寓意。

合作的伙伴的思考

这一部分是合作伙伴的选择与思考，根据我们公司的现状，我 2017 年来的时候公司IT的正式员工只有 30 多人，运维是六七个人，现在公司IT 部门70多人，基础架构运维十来个人，这种人数决定了我们不可能完全自建，所以还是选择一家合作厂商，但是怎么合作？我们是有一些考量的。

首先觉得要达到的是一个合作供应共同发展的路径，而不是说像传统的你就是服务商，我买你的东西你把东西卖给我就可以，这不是我们想要的，也不是新时代的合作模式。我们想我们的需求目标和规划方向和这个厂商的发展方向、产品的迭代思路方向保持一致，同时大家也是想一起平等把这件事做好，这是我们第一个转型的思考。

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

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

那要做 DevOps 或者 PaaS 平台，很重要的前提是标准化，如果没有标准化一切都是空谈。所以当时做这个事我也是推进我们公司标准化的建设，当时提出几个：

• 主机的标准化
• 代码打包制品的标准化
• 口径术语的标准化
• 部署与发布标准的标准化
• 中间件的标准化

主机的标准化比较好理解，参考公有云的方式，提供几种标准的机器规格，申请的时候基本上就是套用规格来申请，如果有特殊的需求可以自定义，但是要给出一个详细的说明，经过我们认可以后才可以。

第二是提供标准操作系统模块，比如说我不是说要什么操作系统我们都给，这个也不是不可以的。

第三个是操作系统有参数，我们把这些操作系统参数做了标准化之后会打好机器里面去。

代码有代码的管理标准，还有打包工具的使用，打包之后的路径，打包路径的标准化，制品名称的标准化。因为我们还有招商基金、招商财富，招商财富是我们的子公司，所以我们会把公司的前缀加上每个组的打到里面还有版本的标准化，主要为了方便我们回馈。

口径术语的标准化，就是在公司内部统一什么叫平台，什么叫应用，它们之间是什么关系，好处就是可以让业务、开发、运维的数据保持一致。

部署与发布的标准化，首先我们有灰度发布，优雅发布、启动和停止脚本的标准化，还有权限的标准化，还有状态检测的标准化，包括二进制包、配置文件、日志、行为目录的标准化，中间件标准化就是为外部容器提供标准化，你想要外部容器提供哪些，其他的不可以，JVM容器我提供哪些，其他不可以，缓存提供哪些，数据库提供哪些，这些我们都做了一系列的标准化。

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

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

说到 PaaS 和 DevOps 一个很重要的点就是 CMDB，CMDB 其实大家都在做，也用了很多年，但是往往立了一个 CMDB 项目，一段时间就废了，这里面有很多问题。但 CMDB 怎么让除了 IT 以外更多的人理解？

我记得有一次和业务部门分享，我说 CMDB 就像行军打仗的地图，可以让你在这里面找到需要的要素，那这个要素有什么用？就是关联影响分析，这是我认为是 CMDB 建设中非常重要的收益点。就是建成 CMDB 不是把一个表格里的记录录到CMDB里。我记得去年参加上海 GOPS 大会的时候有一个嘉宾说的一句话，他说他们到了很多地方调研，问你们有没有CMDB？说有。那你们公司查询信息用什么？用excel。这就很搞笑，所以其实很多地方没有把CMDB用起来，那么CMDB用起来以后，关联影响分析是非常重要收益点，这里面又有两条非常重要，一个是对基础架构的设计优化，一个是对故障影响分析。

我分享我们公司实际的例子，因为我们现在的CMDB系统可以自动生成系统拓普关系图，生成之后一方面可以从这个图里清晰地看到目前的架构设计是不是有什么问题，还有什么优化点，这是其一。

其二因为我们现在是有架构评审的环节，各个项目组会对他的架构进行评审，那评审之后可能会有问题，比如架构评审认为是要A这样，那落地时是B这样，这就违背了架构评审所承诺的。那我们通过这种方式做一个check，通过check可以在项目交付时看看现在的真正情况和当初在架构设计上或架构评审的时候要求是否一致。

故障影响分析也是收益点。比如有时候做一些文件服务器迁移，第一可以从文件服务器查到哪些机器是否有连接，第二可以通过CMDB查到哪些机器和它有连接，这样双方做一个双向检查，有遗漏点的问题就降到最低。

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

CMDB 还有一个问题就是准确性，很多人用不好CMDB就是因为觉得准确性不行，准确性不行的话怎么办？因为越不准确的东西越没人要，所以我总结出来CMDB的准确要做好就是几块，第一是消费，只有把数据用起来才有可能越来越准，因为用起来才是一个流动。第二是数据的准入把关，不是什么数据都可以进来。第三是模型数据的审核审计。

举个例子，就像家里平时你穿的衣服或者东西，日常用的就是手边的东西，其实日常手边用的就是那一些，你用得很顺手，你也知道用这个东西会有什么效果，那实际上是什么？就是消费，因为这些东西你一直在用，你知道是对的是准的。第二数据准入的把关就是只有家里的主人才可以把外面的东西拿进来。模型数据审核就是像定期做大扫除一样。

那以应用为中心和 DevOps 是直接相关的，因为应用在我们公司就是一个部署的最小单位，也是DevOps工具落地进行操作的最小单位。以应用为中心的 CMDB 可以起到一个承上启下的作用，因为应用对上是业务系统，业务系统恰恰是开发和业务部门最感兴趣的东西，那对下可以涉及到环境、集群、主机、负责人，这又恰恰是运维所关心的点。所以通过以应用为中心的CMDB很好把开发运维串联起来。

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

评审这一块是怎么标准化？我之前在群里看到，有人说他们压力很大，说开发引入什么东西他们就要用，怎么办？之前的时候我们没有架构组的时候，我们是运维前置，当时运维在前面审核，如果明确告诉你，引入中间件我们没有技术栈，交给运维，出了问题我们不负责的，因为我们就这么多人，就这么多人力。

后面引入架构组以后，架构评审的环节会做这样的事，因为架构组里面有负责技术的，有负责技术栈的，有负责数据的，有负责运维的，所以这个层面大家会做这个事，那大家要想到一个点，你怎么样才让开发认可你说的话，这个其实很关键，其实在我看来，运维侧提出的标准不能是强制要求人家你只能用这些，第一你要告诉人家我提供给你用这些，为什么提供这些，你要给一个说明。

第二会告诉你用我提供这些东西会给你什么好处，包括资源交付，后续稳定的维护和升级，这样开发才会在一定的情况接受你说的内容，然后配合你做这样的事。这边就提到一个智能化，智能化的前提是自动化，自动化的前提是标准化，你看云平台现在为什么这么火？因为是极度标准化的东西。

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

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

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

刚才全生命周期就是打通，打通之后从开发到测试到生产全流程，这是一个全流程的方式。自定义举个例子，前面也有讲过，现在有和第三方机构，苏宁银行和京东、腾讯和蚂蚁等等都有合作，他们就要求我们变更是无损变更，优雅变更。我们之前是怎么做的，就是通过人工的方式在F5上把后端节点摘掉，等一段时间之后等业务跑完以后，再进行变更，变更完之后再恢复，这样的一个过程。

整个过程如果由人工操作，我们当时试过，就算做得快，整个过程也要十几分钟的时候才能做完变更。那现在上了流水线以后，我们整个变更基本上就是会很快，就是四五分钟的时间，消耗的时间点仅仅是在我们自己去等待业务跑完人工设定的时间。

现在说一下监控，因为我觉得也是DevOps非常重要的部分，因为监控才能知道当前变化对系统有没有什么影响，所以监控这一块传统意义上会进行分层。

重点说几个部分，第一是健康检查，这在互联网公司用了好多年了，但在金融行业这一块用得还不是很多，我觉得健康检查恰恰是真正能够反映问题发现的方式，现在很多系统在做检查的时候怎么检查的呢？是看它的端口在不在，进程在不在，但是很多时候进程在，端口在，服务就是不好，所以服务拨测形成健康检查这种方式值得现在很多企业去考虑，但是这个里面有一个问题，就是你的拨测点很重要，我们现在就分了很多拨测点，首先有外部的拨测，直接从互联网打进来的，这是一种。

第二我有一种内部发行的拨测，也分在不同的位置上，比如说我是在代理之前的，还是在代理之后的直接打服务的，这些都有，这样有什么好处？如果哪天收到一个报警，是外部拨测发现你的系统不可用，但是我的内部拨测全是好的，那问题就很好解决，说明是线路上可能有问题，或者接入的切换机有问题，就是这个意思，我们可以比较方便定位这个问题。

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

DevOps 未来规划

未来发展规划主要要增加安全扫描的模块，主要是增加代码扫描和开源扫描。第二是完全和需求管理平台打通，真正实现需求到编码到安全到测试到部署完全打通的方式。第三是双模统一部署，因为我们现在有基于虚拟机的容器，但是现在实际上管理可以在一起，但是最终部署的时候还是要分开的，后面这块要把部署打通；

最后一部分是变更包的溯源，大家知道每年基本有六七次高危的代码包、第三方插件包有问题，其实这个就要求我们可以快速找到，这些包我们变更的时候有没有引入进来，引入进来了以后到底是在什么位置，所以这个时候我们需要快速能够找到变更包所在的位置来进行回溯，进行安全处理。

打通之后就形成这样的一张图，我们左边的业务部门提出需求，由IT的 PO 来承接业务部门的需求，PO拿到需求后会对需求进行分解，分解完之后进行落地，现在大家看到第一部分的需求和变更管理工具，这个部分跟后面没有完全打通，有点离散，但是这是今年可以搞定，后续的像持续集成测试、配置部署、检测提炼，这些是可以在一起。

图里面可以看到蓝色的两块，就是我们目前还不完善的。配置管理这块的配置中心，目前其实是处于一个混合阶段，就是一些是用阿波罗另一些用传统文件，全部往阿波罗配置中心这个方向去转。

再回到刚才的 CMDB，如果是 DevOps 的工具链发生改变，那就在 CMDB 或者系统架构做演进，第一会坚持业务导向，因为毕竟是基金公司，不是IT公司，所以一切要以业务为导向，真正实现IT价值和业务的协调一致发展。说到这点又想到一点，就是 DevOps 的核心就是指业务需求。

第二就是运用互联网技术和思维结合我们的行业情况，对现有进行改造取长补短。其实我会发现有一些人比较喜欢把互联网这套东西生搬硬套进其他的行业，但是每个行业有自己的特殊性，完全硬套可能有些问题。

第三个是自动运营，以前有一个大神写的文章叫做用户向运营的转变，我觉得写得很好，如果运维只做基础资源交付这一块，那很有可能未来会被代运维掉，或者被云资源越来越多之后他价值就越来越小，所以要往运营的方向发展。

那我们在做的就是从业务的视角统计出每一个业务资源的使用情况，便于进行费用分摊，或者统一出每一个业务系统对基础资源的消耗，这里面包括你的CPU内存、硬盘包括监控的需求量，包括变更的次数，全会在这里面进行统计。

最后是强化用户体验，我们要梳理清楚我们的服务对象是哪几类，每类用户的真正需求是什么，有针对性的有的放矢，这样才能把我们有限的资源为业务部门或者其他前台部门贡献价值的方向。

【云栖号在线课堂】每天都有产品技术专家分享！
课程地址：https://yqh.aliyun.com/zhibo

立即加入社群，与专家面对面，及时了解课程最新动态！
【云栖号在线课堂 社群】https://c.tb.cn/F3.Z8gvnK

原文发布时间：2020-04-28
本文作者：王洋
本文来自：“高效运维公众号”，了解相关信息可以关注“高效运维”