基于 Python 的企业级运维平台开发实战!

2018年3月21-22日，由中国信息通信研究院主办、中国通信标准化协会支持的”OSCAR云计算开源产业大会”在国家会议中心举行。

随着云计算技术的日益发展，并开始进入“深水区”，开源技术与云计算融合的程度进一步加深，并开始成为产业发展的重要支撑。”OSCAR云计算开源产业大会”将邀请行业内多位大咖与权重人物共同探讨、交流云计算开源技术、研发、治理、产业化方面的经验，探索开源与云计算的创新发展新路径。

2018年3月21日下午，在DevOps论坛上，华图教育技术总监郭宏泽发表演讲《〈Python 三十六计〉之企业级运维平台开发实战》。以下为演讲全文。

作者简介：

12年IT行业经验，曾任职于易车网，中国电信，跟谁学等公司，现任HPE顾问讲师。擅长超大规模路由交换网络设计与运维，大规模Linux集群运维管理，Mysql集群解决方案。目前专注于私有云、Devops、数据库领域。

前言

很高兴到 DevOps 论坛给大家做一个分享，我这次分享的是我开发的一个运维管理工具，这次分享中介绍一下我开发这个工具的心得体验和一些想法，希望这些能给大家带来帮助。

运维发展的很长时间，从十几年前的运维到今天已经有了很多改变。今天的角度来看运维站在十字路口，前面有很多方向，很多新的任务和分享需要我们去做，有很多问题需要我们解决，有很多我们要勇于尝试的技术和探索。

这么多年来看运维从手工运维转到脚本运维，转到自动化运维，今天我带来的是在运维过程中总结的一些经验和我们如何去从零开始开发一套基于 Python 的运维平台。

企业运维面临的挑战

在运维工作中会遇到很多问题，首先是系统架构变得越来越复杂，由云计算的出现，出现了 IaaS，原来直接在物理服务器上装一个操作系统就能交付的，变成得有云管服务器再加上物理服务器，还有基于容器这种云计算的管理方式，再容器之上我们还要搭一套部署流水线，也就是运维工具，还得发到我们线上去。

这样系统越来越高，我们在工作中每多一个组件和功能都会多一个故障点，很多公司说我们的运维现在基本在失控的边缘，甚至经常性的失控，我们的运维工作被日常的事物给羁绊住了，我们没有时间抽出来考虑更长远的问题，我们只能是来什么挡什么，我们的工作研发一直在增加、架构一直在变化。

因为我们在很多历史过程中，留下了很多技术问题和债务，所以我们的架构越来越复杂，我们技术债务变得越来越沉重，到最后技术债务是有力气的，我们的能力无法应付技术债务导致的利息导致故障频发，最终导致客户的应用体验不佳。

管理者最害怕的就是关键性的人物离职，这个人离职对整个系统不稳定性的概率直线增加。他原来管理的东西会留下好多的问题。他在的时候他清楚，但是他交接的时候交接不清楚，产生很多雷，这个雷后面的人一接手在踩上了，然后就炸了，然后我们被挨了一顿批，这种事屡见不鲜。

战略规划：我们的运维很复杂很难，没有什么战略规划，有什么来什么，后来整个系统像一锅论炖。

所以整个来说我们传统的运维在今天那种思维和思路不能支撑目前的业务了，是我们比较大的一个瓶颈。

运维平台的发展

我们运维的发展大家也都很清楚，从手工运维到脚本，到流程，IT服务治理。然后我们开始在流程治理了运维之后，我们发现流程耗费了我们大量时间，一个运维任务要走好长时间，要处理好多环节。所以我们要把原来传统的这些东西，手工的没有自动化的过于复杂的流程需要去解决它。那也就是我们的DevOps理念。

DevOps理念落地的时候有很多方向，我们的运维自动化平台就是方向其中之一，它主要是面向于运维日常的任务管理，部署流水线面向的是我们的端到端的交付。运维平台，所以我们今天的主题就是如何在企业中构建这个平台。

构建平台有两种方式，一种是自建一种是买。以前我们可能都喜欢买，省事不用招那么多人，但是买了工具发现这个工具跟公司业务匹配度不好，二次开发难度较大，一个需求变更还要协商合同问题等等，导致这个系统让我们很痛苦。

所以我在管理运维团队，进行我的运维的工作之中，我总结出来了，我们最终必须要掌握这种开发能力来开发一套适合自己企业的适合自己工作流程的这样一套平台。

平台开发理念

我们说开发这个平台，第一个考虑这件事就是理念的问题，大家都是运维人员，运维人员根深蒂固的运维思维，这个比较实用。我们在开发的过程中我也见过很多团队他们一个问题的点是，他们搞了很多看似是平台的东西，但不是平台，是工具WEB化，也就是把每一个运维原来脚本和工具搞一个WEB，用WEB调它，最终导致结果就是，这个平台原来有多少个运维工具就出现多少个前端界面、接口，没有调理，流程也不标准，整个开发的持续性、迭代等都会出现问题及

总结一下，说明我们在运维平台开发的时候没有真正开发一个平台而是在原来基础之上给它加了一个可视化。

所以第一我们要开发这这个平台必须要进行软件工程的管理，我们运维开发平台是要和业务开发流程和模式是一样的，我们要转变到软件工程思维，也就是敏捷开发。

用敏捷开发这一点很重要，有很多开发的运维团队上来搞个大而全的，肯定不行，我们要从一个最简单的功能，最简单的点开始，不断的迭代优化它，最终根据我们实际工作中的反馈，和我们功能不断的迭代让我们系统逐渐变得更强，而不是一开始就搞一个大而全的。

我见到所有想把平台设计的很完美，功能很齐全上线的运维平台都是失败的。为什么？因为它没有成长的过程就不能变得强健。我们要用敏捷的开发方法，用快速迭代迭代我们的功能，有问题立刻修改我们的平台，把它的功能让它更贴近我们的运维工作。

模块化开发不断重构：这就是我们的理念，整个运维工具定义一个边界，应该模块化开发，而不是整个代码都杂在一起。

不断重构就是我们运维平台开发那天就要有一个理念，这个平台将来是要重写的，我要给重写留好接口，给重写考虑好路径。因为你永远不可能再一个时间之内构建一个完美的系统，你的系统永远是不完美的，所以要有不断重构和迭代的理念在里面。

我们运维平台是一个经验的累积，这点很重要。重要到什么程度，很多运维公司起不来运维平台就是大家每天说我想建一个平台就是不知道从何入手。我们想想开发平台是为了什么开发，就是为了能够方便，我们为了方便就要总结我们在工作中遇到的问题。

把我们的工作这些问题抽象成我们的语言可描述的东西把这些东西再总结成知识，把这些知识再去结合我们的经验把它看看有没有办法软件化和工程化，然后我们才能开发这个平台。

运维平台功能纵览

我们开发这个平台一个运维平台核心是什么，其实就是CMDB。然而企业都在CMDB这儿卡住了，CMDB这个东西不是你想开发就能开发出来的，你在开发之前想好了它的数据条木是什么样的，表关系是什么样的，这种任务在表关系中应该怎么体现。

所以这块把咱们难住了。因为我们缺乏把具体事物转换化软件工程的能力。一开始我也没有，但是我们要去总结原来的经验和知识然后把它用一个最小的范围实现，最初我就想所有的表格全部软件化，一开始就从自己的需求入手，先解决自己的问题。

所以我们运维平台第一个任务就是来做CMDB。简单来说要拆成硬件管理和应用管理。主要是资产管理，比如服务器、服务器属性、带宽、IP和机房，这些硬件相关的信息。应用配置主要是软件信息，比如这是属于什么业务，开发框槛是什么，使用哪些服务器，业务属性是什么，包括软件包括它的配置文件在哪里。

资产管理面向的是原来的资源管理，我们应用管理将来CMDB要提供给前面的业务来使，比如我的部署系统去部署一个东西，它的源代码在哪儿，要部署到哪些机器上去，开发框槛是什么，配置文件在哪里，咱们CMDB就是存在这些信息。

我们建了CMDB以后要给其他的模块来服务。就讲一个运维模块，比如自动化的数据，我们在自动化运维数据库里面，监控的数据、条目数据，在CMDB里删除就可以了，我们运维模块调来了，我们做部署的自动化，作业轮检，这些信息都通过CMDB的开发接口查询里面的内容这让我们整个运维体系是一盘棋，所有数据是一致的，这样调的时候不会出现这里面删除了一个内容，那个里面还留着呢，我在系统中下线一个服务器了，还给我报了一堆的警，这样的事可以避免。

另外运维安全这些机器谁可以访问，它的权限是什么样的，我们的流程管理，一个流程对应着哪些任务？我们的运营模块，这些合同对应的是哪些资源，都可以在最终扩展上扩展出来。

大家一定要记住，不要拿来以后，马上这些东西都要搞，我们先搞CMDB再搞运维模块，这些完全成熟再搞监控、安全、流程，一个一个往后走。如果你的CMDB没搞就不能搞这个，这个没搞就不能搞下一个。

你说我的能力很强，能想清楚下一个，继续开发也可以。

后台技术选型

技术选型，这个是由Python+Diango的方式开发的，这不一定是最好的，但是在我们的团队中是最合适的。这个世界上有我的学生经常问我用哪种语言好，我觉得能够解决问题的语言就是好语言，不用说我找一个万能完美的语言，不存在这种语言都有问题。你的团队也可以用Java开发，也可以用Python开发，但是咱们本地用的是Python+Diango。

DjangoMTV极速开发

在Python里面我们有一个概念就是MTV，转化到软件工程里面就是MVC，也就是模块化开发。我前面在Python里面，用户请求以后我通过UL分发器分发到我的不同功能模块上，由功能模块总的管理逻辑器调用我数据库的增删改查模块，和前端页面的模块，最终形成一个给用户返回的结果。我决定使用Diago的原因解决它内置丰富的应用和模块，不用我再花大力气开发，我们所有核心的这些战略资源全部放在如何实现我的业务之上。

前端资源

我们在前端选型上，我们怎么做？选择什么？Python、Diango很简单，但是前端很难搞，特别是搞JS，我们前端的选型使用了一个HTML框架，我自己手写一个HTML可以吗，可以，太丑。

我很多运维团队都是自己手写的，根本没有平台感，后面给领导一看太难看，会说知道你技术很厉害，我们开发运维平台不光自己用，还要给别人用，比如财务调一个信息，他会下载整个资产的信息，领导会看资源利用率、再用数量、盘点我们在全国有多少个点，每个点有多少台机器。

资产管理

所以咱们要有一个好的前端界面，咱们选择adminlte，条目选Bootstrap，特效用Jquer，标准字体Font-Awesome，弹窗组建用Layer，监控图表用Echarts这些确定以后就要做一个整合后端提供数据，前面监控图走起来，数据转起来了，表格也就出现了。

CMDB 表设计

我们展示的是资产管理的模块。我们构建CMDB的时候不是想如何构建这个图，是如何构建表关系，我们在CMDB设计第一个考虑，我们难点就是不知道如何构建表关系，这个很简单，我有多少对象，这些对象都应该放在我们的数据库里，比如我的对象是服务器有吧，这样服务器一个表，机房有吧，机房一个表，机柜一个表，业务组一个表，这样四个表出来了，表关系怎么做？服务器属于谁？服务器属于机柜，服务器和机柜是什么关系，一个机柜多个服务器，就是一对多的关系。

我的机柜属于谁？机柜属于机房，那我的机房和机柜又是一对多的关系，这三个表之间的关系就打通了，我们以后在这里调，调机房查询的时候，一点机房下面关联的机柜和关联服务器，通过我们的表关系一键查询把所有的数据查询出来了，这是非常简单的。我们把这个东西抽象的东西，现实、具像的东西抽象化成我们数据库的二维表，这样整个CMDB的底盘就有了。

说了表设计，再有服务器、组、所在机房机柜、资产类型和资产状态，资产类型里有服务器、交换机等等。我们在外面展现的时候，只要在前端调属性的时候，一调它的资产类型，那某一种类型数据马上就出来了，咱们做一个漂亮的图标显示我全网有150个交换机，1280个服务器，咱们资产状态在用的，停用的，故障等等这种状态一列就列出来了，不需要我们总拿一个表格去盘点去对。

在应用里面我们都应该加什么呢？应用表设计也很简单，我们想想，我们在公司里面，第一个我们应用的团队要有一个产品线，它属于哪个产品线的，产品线下面还有工程，是前端的还是后端的还是中间件还是消息对列，我们把都它都工程化了，每一个里面都有负责人，再给他加一个认证，也就是产品线里面还有我们的服务器里面需要权限需要密码的时候咱们给他加一个认证。

这个最小的盘子就出来了，将来多了说需要加一个证书的表，那么证书都列进去，属于哪个产品线，密钥是什么，都可以往里加，加的时候考虑好它和其他表的关系，将来我们如何查询它。

基于 CMDB 的应用配置信息

我们刚才说了表，我们用一个基本的盘子把这个东西做出来了，如何调用呢？这个界面是我们的部署界面。以前我们部署的时候通常是怎么做的，写一个脚本，里面写上地址，再写上我发向哪些服务器的IP，再写上什么什么的。

这样的话，这种东西都在脚本里面，久而久之，脚本变得特别的多，不易于维护和管理，我们刚才说建了应用的表了，再用前端写上界面以后，上面有很多信息，这里面保存上我们的源代码或者是生产的构建库的地址，写上配置文件地址，属于哪个产品线，负责人是谁，这个项目部署到哪些服务器上，这个应用部署完，后台自动化部署的模块直接调这些信息，开始进行部署。那个模块也不用写死了，而是写成一个通用的，大家都去调后台的任务就可以了。

CMDB 整合 Ansible

刚才说了应用管理在系统中的场景，这是CMDB和Ansible的整合，这个建立起来要解决数据一致性的问题，大家知道管理Ansible数据库的东西就是它的Host文件，每加一个机器里面写一个条目，这样增删改查都要修改一个Ansible条目，成本非常高，没有什么好办法，只能用编辑这个。

CMDB以后，我们在CMDB里面查询出刚才资产服务器里被管服务器的信息，这样每当服务器变更，自动发现、]自动同步到Ansible里面去，这样Ansible就永远是一个有效的自动化运维工具。它的数据库都是有效的，不用考虑数据不一致性的问题。

我做咨询的时候很多企业CMDB失败了，因为做了以后大家不消费CMDB的数据，都习惯于自己的数据，为什么不敢消费它的数据，因为它的数据有效性是有问题的，因为CMDB是纯手工维护的，仅仅用于我们资产上的管理，前端部署、自动化运维都不敢用纯手工的，CMDB因为底下的被管对象是自动发现的，这样才能保持CMDB的数据有效性，而不是纯人工维护的。

当然我们的人工维护也是需要参与的，这样我在Ansible进行部署的时候，我可以选择主机、选择Ansible的组，我把写好的Role是放到一个指定配置分间路径中，这样部署任何东西都点下拉框，所有可部署类型就出来了，一点这一批机器执行过去了，不再需要登录到SSH里面去了。

比如最来了一个初级应用工程师，直接让他上Ansible的机器靠谱吗？不敢，因为那台机器一旦出错，你的业务回收影响。但是我们给他开放一个可查询的方位，这样错误率就大大降低了。