自动化运维平台开发实践--赵班长

贾晨

作者简介
赵舜东，昵称“赵班长”，高效运维社区核心成员，GOPS 全球运维大会金牌讲师，阿里云 MVP，中国 SaltStack 用户组发起人；《 SaltStack 入门与实践》、《运维知识体系》和《缓存知识体系》作者；现任速云科技CEO，专注于 DevOps 和自动化运维。

我给大家分享的主题是《自动化运营平台的设计实践》。在这大概一年多的时间里，我一直在做自动化运营平台的设计。那我也是高效运维社区的老朋友了，可能也有第一次听我分享的。

我之前在武警部队做运维工作，08年退役之后一直从事运维。现在目前有一个团队在做自动化运维产品相关的工作。

我今天分享的一个主题主要有三个方面，一、做一个自动化运维平台设计的一些理念；二、在开发过程中我们选择了哪些工具；三、最后我们拿一个 CMBD 的案例讲一下我们到底实现了什么样的功能。

1.自动化运维平台的理念与设计

我把我们做的这个平台叫作 OpsAny，意思是希望运维在任何时间任何地点都可以能够快乐的去做运维工作。可能大家已经听过很多做自动化运维平台的设计，大家听过以应用为核心的理念比较多。那我个人的理念是分层，就是我把整个运维平台分成了两层，在最下面一层是以资源为核心，也就是站在运维对象的维度来讲，都有哪些功能？比如资源平台，那这个就是CMBD，那么站在资源为中心的维度，我首先需要把我们所有的资产都录入到CMBD中来进行管理，然后通过管控平台可能需要给它安装 agent，我们现在主要是用的 SaltStack 去取得 agent，然后通过 Ansible 来支持 SSH 协议；通过作业平台来进行作业的执行和编排；通过监控平台来进行监控数据的采集；通过日志平台进行日志的采集、搜索和告警。这些都是站在以资源为中心的维度上。

上面这一层是站在以应用为核心的基础上，可以看到应用平台其实是基于资源维度的资源作业、监控、日志、管控，站在应用的维度去把它做一个统一的展示而已。

我们现在也在尝试做敏捷研发的平台和持续交付的平台，代码托管主要是Gitlab，这里我们没有做过多的开发。然后我们用到了一个开发中心，我等一下会讲到。公有云目前对接了阿里、腾讯、微软和AWS；私有云对接了vmware，openstack，物理机主要就是靠安装 agent 来实现，容器主要对接了Kubernetes。

好，那我们来想一下，我相信很多听这次分享的都是做运维开发人员或者运维工程师，站在运维的维度上说，一个CMBD到底应该怎么做？

可能很多人说做一个CMBD，首先看看别人都怎么做的，去了解一下业界的情况。但是我其实最早不是这么干的，做一个CMBD，我认为从需求出发，我不管别人做的CMBD是什么样子的，我站在我自己管理的服务器的需求出发。第一个，那我要管好我现在企业的it资产，我管好他，我要掌握什么呢？同时要掌握容量的信息和成本的信息。

很多人觉得做一个 CMBD，不就把这个资产录入了就可以了吗，那你录入的本质是什么？其实我要知道，我当前的 IT 资产容量够不够，如果有做一些活动，我要不要扩容？然后还有一些成本数据，比如说我用了阿里云和腾讯云，那我每个月的成本到底是用了多少？我是CDN占用的多，还是云主机占用的成本比较多等等，那这些数据，便于我长期的去做一些规划，包括去做一些成本的优化等等。

好，那么所以说我建议，咱们做任何的平台，一定要从需求出发，而不是我就是要做一个CMBD出发，有人说你为什么要做，反正别人都有，我们就要做，那这样的话你可能是做不好的。

那么首先作为运维工程师，我第一次学的，从我个人的角度，我第一次学的，看了一本书就是用户故事地图，就是我有非常多的需求，我要开始入手去做一个平台，那么我肯定得有方法论，我就学了用户故事地图，什么意思呢？我会按照一个 CMBD 的业务流程，你的所有的需求点按照用户故事的方式去把它排列出来，然后做一个价值的优先级的排序，就是你最先价值比较高的放在上面，价值比较低的放在下面，然后我们会进行多次版本的发布和迭代。

那么首先我们会做一个最主要的一个版本，那么就是通过用户故事地图的方式来进行一些顺序，包括产品需求的一个规划，那这个我是要推荐大家可以去买一本《用户故事地图》来看一看。再推荐一本书，那就是你可能要学习比如何勉老师的《精益软件开发》、《精益创业》里都提到了 MVP，即最小可行性版本，并不是说 CMBD 一下子做得非常的复杂，这是很容易失败的。那我们一般先做一个 MVP 版本。

那最基本的一个 CMBD 该怎样设计？比如设计一个 CMBD 替代 Excel，那首先要设计表结构、数据的录入、数据的导入和导出，比如支持公有云导入，Excel 导出；数据的自动采集，比如通过一个 agent 去自动采集数据等等，也就是说要先把一个最主要的功能去实现。就是要先发布一个 mvp 版本。

2.DevOps 与工具选择

首先在在团队协作上，我们选择了 Leangoo 作为团队协作。
它是一个敏捷开发的工具，主要是看板功能符合轻量级团队的一个需求，这个我推荐大家去使用，因为个人版本是免费的，我可以通过 Leangoo 去做一些产品故事地图、基于 scrum 的敏捷研发，都是可以实现的。

运维开发平台这一块，我选的是腾讯蓝鲸的 bk-PaaS。 很多同学可能用过腾讯蓝鲸的社区版。其实很多人不知道，蓝鲸已经把自己的开发中心已经开源了，就是 bk-PaaS。它可以理解为是一个运维开发的框架，在这个框架里集成了统一登录、统一权限，ESB 企业服务总线和 API 网关，还有基于 Django 做二次开发的后端的开发框架。这样的话，你在写代码的时候就特别方便。

我们目前主要是基于这个 bk-PaaS 去做二次开发，来把它改造成我们内部的一个专门给运维开发使用的开发框架。

文档部分，我们有两份文档。第一份文档是要求所有研发使用 Swagger UI 去写这个API文档，那我们的研发模式可能也比较，对于很多人来说比较奇葩。刚开始必须先把前端和后端的接口写完，前端后端不能一上来就开始写代码，应该是先讨论，把接口定了，然后用 Swagger 文档把接口写完，然后分别前后端去做这种开发，然后分别自己，比如说前端，自己也可以做一些 Mock 测试，他自己去造一些数据，然后自己来测。然后最后去做集成。那么通过这种方式，我们前后端的集成的时间差不多是以小时为单位的，因为我见过很多前后端分离的开发模式，周一到周四写代码，然后周五一天做集成，有的时候一天都还集成不起来，各种改，我是用这种方式来做的。

第二份文档是在 bk-PaaS 的 ESB 企业服务总线上，也有一份 API 文档，但两份是不一样的。

然后我们目前用到的开发组件，用 vscode 做 IDE工具，集成了sonarlint 去做代码质量的提醒。目前前端用的是 vue.js，然后用到 AntDesign for VUE 的版本。后端主要就是 Python+Django，因为我们用的 bk-PaaS 的框架是基于这个 Django 的。

3.CMDB 落地案例

好，我们来看一下如何去规划资源平台。通过一个案例，看我是怎么设计的。因为我也从事 10 多年的运维，最早期其实我们就是用 Excel，后来用这个 PHP 写的一些管理的软件，再到后来现在自己去做一个相对完善的 CMDB。

首先先看最外层的接口层，那就是要符合标准 rest API。对前后端都做了这个要求，不能什么都是post和get。查询可能get，创建post，更新put，删除delete，按照标准的 restful API 去设计所有的接口，然后编写标准的 Swagger 文档，然后我们集成了 API Gateway。

这里我要强调一下，是因为 bk-PaaS 它只有一个ESB 叫做企业服务总线，目前的版本是没有 API Gateway 的功能的，我们是在上面基于 lua 写了一个最简单的 API Gateway 的继承，做统一的鉴权、日志等等，还集成了一个简单的 waf 的一个功能。

一个 CMDB 主要有哪些功能？一个是模型管理，那么我认为做一个 CMDB，你肯定需要支持在线去编辑模型的，要不然的话和 Excel 感觉就没有太大的区别了，那就是一个简单的增删改查，对吧？然后支持自定义分组和自定义模型。

关系拓扑这一块，主要做了两种关系，一个是从属关系，一个是连接关系。这个等一下我们也可以讲到。然后我设计了一个关系标签的管理，就是通过打标签的方式来进行关系相关的搜索和展示。当然还有关系拓扑图的展示。

资源仓库，首先你要支持手工录入，然后自动导入，自动导入目前我们主要是使用了 SaltStack 的 agent 去做自动导入。

自定义采集器，比如你在主机上装了一个 agent，如果我会去跑我用 Python 写的脚本。我举一个最简单的脚本写法，比如先获取所有的进程ID，然后去寻找对应的名字，我们有一个规则列表去过滤，比如说看见机器上有没有跑 MySQL、Tomcat、Weblogic，然后用 lsof 命令去获取到进程的 PID ，拿到进程相关的东西，一点一点去过滤并最终发现所有的数据，大概是这样的一个结构。

当然也支持 k8s 的资源导入，经常就会有人问，那我做一个CMDB 去管理k8s，那它的颗粒度到底管理到哪里？那我们的颗粒度管理到控制器这一层，比如可能管 deployment、控制器、service put 不管，因为put在k8s里面，它的变化太快了。

视图展示的话其实就是两个树，一个是资产树，一个是业务树。物理机架和应用拓扑。

数据安全这一块，因为我们底层是用的 SaltStack，我就可以用 SaltStack 去做数据的一个校验，然后日志审计，用 SaltStack 的 agent 去跑自动盘点等等。数据库用的是MongDB。

那么首先我们有资源模型，在资源模型里分为了三类：资产模型、业务模型、管理模型。资产模型就是大家理解的传统的CMDB的资产，业务模型主要是我们有业务，有应用服务，这样的一个组织结构，包括你的公司部门、小组、员工。

管理模型主要是用管理表单的一些自定义的组合，那么所有的模型都是在线编辑的，所以我觉得你如果做一个CMDB 你不能在线支持模型的编辑，那肯定不对。不能说加一个字段要去改一个 Django 的模型，那肯定就不太合适。

内置的常用的模型，比如物理机、虚拟机和云主机，这种常用的模型内置好。其实我也在想，目前整个运维圈没有一个统一的模型，我也希望有人能去做这样的一些事情。

那后面我也愿意把我自己内置的一些模型，以 Excel 的方式分享给大家，这样的话你就不用说每个人都要去做一套模型，其实很多东西是可以参考的。

大家可以看到，一个模型里面有字段，字段支持字段分组，比如说是基本属性、关系属性、系统信息，这是自动采集的。然后我就可以给一个模型去添加不同的字段，这就类似于你在线去做一个表结构的设计。

还有我内置的字段，因为我有很多的字段是和我的agent采集是有依赖关系的，不能让用户就随意删除，所以说我可以把它标志成为一个内置的字段，那用户是无法删除的。

然后字段类型，主要有这么几个，字符串、整数，比如内存交换分区，这是一个整数，因为整数是有单位的，是兆。

日期类型，比如机器采购时间，BIOS，这样日期的一个类型。还有一富文本，一般像一些复杂的描述信息，我们会用富文本来进行表示。

下拉菜单一般用于做选择，比如机器有品牌，例如惠普、戴尔、IBM，像这种数据的话，你可以定义成一个下拉菜单，然后用户在做数据录入的时候很方便。

引用，这个引用的意思是关系，我们把关系称之为一种引用。

还有一种是复合数据，那么这个复合数据是指的什么意思？举个例子，比如采集了一个磁盘使用率，另一个是你有很多个分区，那么你采集到磁盘，每个机器做发现，你发现的东西是不一样的，你这个东西你这个字段你就不太好定义了，对吧？所以说我们把这个东西称之为是一个复合数据，那么agent采集到的，你可以理解为agent采集到，就是一个json，前端拿到这个json，它会做一些定制的展示，这是复合数据的作用。

对于通用的属性用字段表达。所谓的通用属性就是每一个实例都会有的，比如云主机，你可能100台云主机，那么大家都可能有的一个东西，把它定义成一个字段。然后个性化的怎么办呢？就是非通用的属性，使用标签来进行表达。复杂的属性就是用复合数据。那么你看到这个词，如果你了解 Kubernetes 的话，你会发现这个词就是模仿 Kubernetes，因为在 Kubernetes 里面有标签，还有注解。那么用标签来去对一些非标准的一些对象打上标签，用注解去做一些复杂的数据的表示。

再来看自动导入。截图上已经显示做完了腾讯云和阿里云的自动导入，你只要去输入腾讯云和阿里云的相关的API的ID和key，然后就可以自动的去进行导入，这有一个测试账号，导入了一个区域，有7台云主机。

还支持管控平台导入，管控平台主要是基于 SaltStack 封装的管控平台，你可以从公共云导入，然后去管控平台装 agent，针对物理机来说，就是你先在管控平台把主机装上 agent，然后就自动的可以导入到CMDB中，双向都可以。

因为我看过很多这种 CMDB的产品，它是单向的，它就只能装 agent 往里面倒，那我其实是双向的。

这是导入之后的数据的一个展示，可以看到这是阿里云的主机，虚拟化类型，操作系统版本，这些都是通过 SaltStack 的 agent 获取到的。

当然其实同时我们获取到了像开放端口，资源关联，这个资源关联主要指的是资源和资源之间的关联关系，比如说一个虚拟机运行在哪个物理机上，这个物理机放置在哪一个机柜上，机柜放置在哪个机房的哪一层的哪一个区域里边，那么在资源关联里，在这个资源关联里面都可以看到整体的一个关联，包括你这个云主机属于哪一个业务的哪一个应用的哪一个服务，那么在这里有一个多维度的一个关联，变更记录，这应该很容易理解，就是所有的资产的变更记录，然后进程信息，我把一些进程信息也采集到了，这个的话我做了一个刷新按钮，你每刷新一次，我就给你获取一次。

还有一些关键文件的变化，就是 Linux 里面有很多的关键文件，如果这些文件发生一般很少发生变化，如果发生变化可能会有问题，这里也做了一个这样的一个操作。

我们做了这个标签管理，这个标签管理你会发现，其实很多的公有云全部都有标签管理，就是你可以去创建一个标签，可以看到我这里，我创建了一个什么APP标签，env的一个标签，那么有标签描述，创建完标签之后，你就可以绑定标签，把这个标签绑定到某一类资产的某一个具体的实例上，那这样的话你在标签搜索里边就可以进行标签的搜索了，这样就比较灵活。

我看有的CMBD的做法是它有一个环境的概念，开发、测试、生产。那这种环境的概念的话，你要做的很灵活，那么标签是一个特别好的方式。因为你这样做环境管理的话，如果你又有一个项目，它环境多了，虽然说可能本质上只有开发、测试、生产，那可能有 dev 环境，有sat环境，有 uat 环境，有pat环境，有paod环境，这样的话你可能就涉及到改代码了。所以后来我就以为说，所有无法用属性表达的，全部通过标签来实现。那么这个其实也是参考的 Kubernetes，你可以看到，Kubernetes 很多东西是依赖于标签的。你比如说服务的发现，它都有这个标签选择器来进行选择，包括你做一些调度，可能做一些亲缘性、非亲缘性、亲和性、非亲和性的调度，可能都要依赖于这个标签。

好，那么视图这一块的话，就是这个是资产视图，可以看到我这个账号有华东1H区，华东二A区，这是阿里云的可用区，获取到了一个详情，当然可以转移。 然后这是一个业务视图实例，ID名是阿里云自动生成的，我后面会有一个主题名，如果你不改的话，它也是阿里云自动生成一个ID名，然后我们会把一个主机分配到某一个业务下，那么分配到业务下，会到业务的资源池里面，那么有默认是分配到空闲区的资源池里面。如果一个机器故障了，它会自动到故障机，注意会自动到，这个它是否故障是依赖于监控平台，判定它为故障，那么它就会到故障机这边，同时会发送消息提醒。好，这是标签和视图这一块的一些功能。

好，然后资源关系这一块的玩法是这样的，大家可能也看到了很多开源的一些实践，包括商业的一些实践，其实我之前在高效运维社区举办的 GOPS 大会上也做过相关的分享，其实我觉得关系做得复杂了，那CMDB一定会失败。我之前举过例子，比如说我见过很多产品的这种关系，运行在依赖什么，依赖于，放置在，有很多这种层，但这种层就很奇怪，就会产生让用户不会使用。

我举个例子，比如说一个虚拟机和物理机的关系，有人说这个可能是运行在，好像没问题，对吧？那你说我说，虚拟机和物理机是依赖于，你觉得有问题吗？好像也没有问题。当然可能你会觉得运行在可能更合适，但我说依赖于好像也没问题，放置在可能很多人觉得，放置在可能不合适，但有的人觉得放置在也合适呀，你会发现这种关系多了，就意味着什么？意味着那就乱了，那你这个 CMDB 可能在关系这一层，你一下子就失败了。

那我的理念是这样的，我的资源只有两种关系，要么是父子，要么是连接。简单的说要么就是父子，资源a是资源b的父亲，资源c是资源b的爷爷，资源a的爷爷，就这样父子的一个关系，祖先的一个关系，要么就是连接。所以说简单的如果映射到社会关系上，就是要么你就是有直接的血缘关系，要么剩下的都可以称之为朋友。这个连接关系你可以理解为是这个朋友，那么朋友你有很多类的朋友，对吧？有朋友有同事，同事也算是一种朋友，有这个同学，同学也是一种朋友，还有什么？男朋友、女朋友、好朋友，不是那么好的朋友，或者怎么样，总之无所谓。总之对我来说都是连接关系，都是朋友，然后你可以通过关系标签，给一个关系打上标签。

举个例子，比如说虚拟机和物理机，这明显是一个父子关系，没有恶意性，对吧？一定是一个父子，虚拟机一定会运行在一个物理机上，它不可能凭空跑出来。像这种的话就是严格意义上的父子关系，你一个服务一定会运行，要么运行在虚拟机，要么运行在物理机上，这也是没有恶意性的，一定是父子关系。

什么是连接关系？举个例子，物理机和交换机有可能是连接关系，物理机和交换机，你看物理机的某一个端口，可以连接到交换机上，这是一个链接关系。然后你怎么去分这个链接关系呢，给它打一个标签，比如说这个关系叫做网络连接，ok，就可以了。你以后我查看关系的时候，我可以只查看父子，只查看网络连接，只查看什么？再举个例子，比如说物理机和员工之间什么关系？有人说这是一个父子关系，不对，这是个连接关系，就是除了父子，都是链接，那么员工和物理机肯定不是父子关系，那也是链接关系，那这个可能叫做管理链接，因为它这个连接关系随时可以变的。我就举这么几个例子，好，就是通过两种关系来表达所有的一切。

但这样的话是这样的，对于用户来说简单了，但是后端设计其实还挺复杂的，我尽量把这个复杂的在后端设计去解决掉。对用户来说，你要么父子要么连接，然后你给连接起一个标签的名字，就这样。我觉得这才是运维能用明白的这个东西。

因为我之前其实做过失败的CMDB关系做的超复杂，图、数据库什么玩意都弄上了，超级复杂，然后最终发现，可能有一个五六年工作经验的运维他都用不明白。那你想，你要让一个普通的运维工程师，他怎么可能用的明白？所以说关系这一块我觉得，两个极端吧，其实底层你可以很复杂，那么底层用图数据库，没有问题，可以做的很复杂，但是展现给用户的时候不要做的复杂，那么做的复杂就是失败的开始，然后通过关系标签来进行搜索和聚合。好，这里其实图简单，但是设计的话我们花费了非常长的时间，所以这一块我罗嗦的时间比较长。

然后所有的接口都注册到这个ESB上。那么大家目前看到的其实就是我们用bk PaaS，可以用一个ESB企业服务总线，我们会把常用的接口全部注册到ESB上，其实ESB是SOA面向服务的架构里边提出来了这个概念对吧？很多人就问我， SOA和现在流行的微服务什么关系？我个人以为，其实微服务其实就是SOA的新的一个版本，可以就是说在SOA的基础上确实是增加了很多新的特性，包括 API Gateway， 那么其实 API Gateway 其实就是ESB的升级版本，它只是在原有ESB企业服务总线的功能上又增加了很多其他的功能，所以我觉得这样理解起来可能会比较好理解，并不是说全新的一个东西。

那么有了这个ESB，它的好处是什么呢？我所有的平台，大家可以看到我最早的整体的一个架构，那么我所有的平台都可以把接口注册到ESB上，你可以理解是API Gateway，这样的话平台相互之间就可以通过接口来进行调用。

那么最后再讲一下我们管控平台的实现。管控平台主要是一个节点管控一个功能，那么目前我们主要是用说stack来实现。当然其实做了 SaltStack ，但是因为管理的节点比较少，那么我们基于 SaltStack 大概是这么玩的，我们这是多控制器管理，每一个控制器你可以理解是一个SaltStack 的集群，可能是 master/agent 的结构，或者是 master （34:01） agent 的结构。

单控制器大概我们的测试可以支持5K+的主机，就是不做过多的优化，大概能支持5K+的主机，然后可以通过增加控制器去做横向的扩展。三个控制器那就是15,000台机器。当然有人说你说我有20万机器怎么管？不好意思不知道，因为没管过20万台服务器，实话实说，咱这水平也就管个几万台，20万确实没管过。

好。然后支持这个分组管理，那其实就是对agent来进行分组。然后节点管理其实就是界面去装这个agent，然后与资源和作业去做集成。集成的方式其实就是 SaltStack API 全部注册到 ESB 上，这样的话作业平台就可以通过 ESB 去调用管控平台的 api，去执行相关的就是命令，大概是这样的一个设计的逻辑。

堡垒机，我们在管控平台上去内置了堡垒机的功能，就是我们没有把堡垒机单独的去做，因为按照我的理念，我认为堡垒机不应该单独存在，为什么？因为堡垒机有权限，那么你的CMDB上或者其他上面也有权限，而且它资产相关的东西可能都是对应起来的，那我们是在管控平台上来实现堡垒机的功能。那主要我们通过h5来实现SSH、VNC、操作审计等等。其实很多人觉得说这个堡垒机感觉特别的高大上，其实堡垒机的实现有两种，一种是装插件，就是你可能需要装一个浏览器的插件或者装一个agent。另外一种就是完全基于h5的，那我选择是后面的，就完全基于h5的，不需要装插件的 Ok。 这是这样的一个实现。

控制器这一层，你看我注册的SaltStack的API，我一般主备我会注册两个API，然后默认会有一个local master，就是本地控制器，然后你可以去加控制器，然后你可以随便去新建控制器。

节点管理可以给添加节点，我这里没有截图，你可以不同的控制器管理，不同的节点，然后在在调用接口的时候，我自己会判断这个节点归于哪一个控制器管，然后去调某一个控制器的接口去执行相关的这个作业，目前这么实现的。

然后分组的话就是对这个节点进行分组，目前我们支持了静态分组和动态分组，如果你用过 SaltStack 或 Ansible ，应该可以理解这个动态分组，那么动态分组根据采集到的主机的一些属性来进行分组，比如说 CentOS 6.5 的主机创建一个动态分组，CentOS 6.6 创建一个动态分组。

其实你看我讲的还挺细的，我把主要的一些功能都讲完了，有人说为什么你要讲？因为未来我这个东西我要开源，现在不开源的原因是我觉得做的不够好，自认为做的不够好，确实不够好，还有很多可以优化的地方，那么当逐步完善，比如说到年底或者到明年年初，我可能也计划把整个CMDB，然后管控平台一大部分就完全把它开源出来，这样的话就大家可以去使用。因为很多东西其实也来源于网络，我也学习了不同的商业化的产品，学了很多开源的产品，也买了很多书，也看了很多的文章，其实我觉得学习，因为我都是通过互联网学习到了，那我可以把这个东西再分享出去，让别人再去学习。

管控平台目前其实就基于 Apache 的开源项目去做的，其实很多人不知道，很多你特别流行的这种开源的软件，就是说堡垒机甚至商业的，它底层都是用的软件来做的，那么它就是通过h5来实现，VNC、RDP、SSH.我建议大家关注一下，你学完之后你会发现，我靠原来做一个堡垒机，当然其实有难度，但是也没有那么难，难度是因为你可能做一些前端的控制，说实话，真挺费劲的，尤其是你做一些什么软键盘什么的，超级复杂。但是说实话，最核心的东西你不用做，因为你直接通过（39:08）就可以后端来进行通信。

好，那么我们还做了很多我没有展示出来的功能，包括架构图上也看不到的功能，就是这种管控面板，管控面板，大家可能对面板这个词，尤其是很多入门的小白用户，他刚入门运维行业，那么它可能用到了很多这种面板，就傻瓜式的。其实我对面板的追求最早就来源于，大家可能知道 phpMyAdmin，就各种这种管理工具，那我就在想，那到底要不要给这种通用的开源的服务都做一个管理面板，于是我们就开始尝试，比如说oracle我做一个管理面板，我可以在线去安装 Oracle，去管理 Oracle 相关的东西，MySQL 做一个管理面板，我可以在线的去创建 MySQL 的实例，然后去做配置模板，然后对 MySQL 的相关的东西进行管理，但这在做一种探索吧。我不知道大家有没有兴趣。

如果这个东西开源，就有没有人愿意说，我们一块把这个每一个都做一个完整的管理面板，这样每个人都不用自己写了，比如说有人去做 Oracle、MySQL、Kafka、Redis等等，这样的话我们以后都不用自己再去做了，大家这样一集合，这种开源的这种批量的管理面板全部都有了。这是个人的一个想法，当然这个路很长。

最后的话其实我想聊一个东西，就是我今天分享的自动化运维平台，但我觉得不管是各种媒体文章，把自动化运维、AIOps、SRE 炒得过热了。我觉得运维有时候要回归一个本质，即聚焦于业务连续性，不管你是一名基础设施运维，还是应用运维，我认为业务连续性永远肯定是第一位的。

智能化做的再好，但是就宕机了，自动化运维平台也好，最终都没能解决宕机这个问题，我认为整个团队的很多的东西可能就是失败的，不管你很多时候做的再好，但是如果产生宕机，宕了半天没起来，那你之前所有的努力都白费，所以说我也呼吁大家在做智能化自动化的同时，能够多多聚焦于这个业务连续性，OK，那么我今天的分享就到这里。

也欢迎大家来提问，也可以加我的个人微信。