首页手记再出发，如何将Devops真正落地(篇1-总结篇)

再出发，如何将Devops真正落地(篇1-总结篇)

标签：

Python Linux 设计基础

最近准备主导重构一套Devops工程，一直忙于筹建中，所谓再出发，一定是建立在之前的基础上，去重新沉淀并总结。所以这篇文章，我想分两篇文章（分别为总结篇、计划篇）来写，这篇的总结，主要是总结问题，所以欢迎大家能给我提出一些宝贵的建议和想法。我的邮箱是（jeson@imoocc.com）

IMOOCC工程总结篇

伴随当前云技术、自动化等多项技术的成熟及大规模应用，当今小公司更倾向于在用云平台底层架构上来构建并支持自己应用业务服务，而中型、大型公司等高速发展的企业则更多需要通过更多自动化运维方式提高工作效率，同时也能通过自动化的工作来减少人员不断开支。

那么，我们的Team也一直在致力于打造行业内更为功能完善、自动化程度更为高效的devops工程，最终希望我们开发的这套类型的产品能在行业内部有所价值，其中“Imoocc”工程正式我们开发出的其中的一款产品中的一个版本，为什么要叫"imoocc",其实当初有个有意思的想法:

首先、就是这个工程我希望将其中的一个版本开放出代码出来，吸引更多的对Devops开发感兴趣的朋友加入进来，提供给更多的工程师们一个项目演练，所以我在git上开放了这一套代码（git地址见文章最后）。并选择了慕课网推出一个实战Devops开发课程：

同时，我的技术站点域名是（http://www.imoocc.com）,在慕课网域名加了一个C,所以，对于这套开放出来的Devops工程就名字就叫做“IMOOCC”工程吧。

开放出来到现在有三个多月的时间了，在此期间我收到很多同学和朋友给我的反馈，下面我来总结如下：

（一）版本问题

IMOOCC工程，开发之初用的是Python2.7.13、Django建议在1.8.2版本。上线没几天，有几个同学希望能用python3来开发，并且觉得Django版本使用比较老。

为什么要选择python2.7呢？想来主要还是思想上比较保守，python2.7对于原来的开发方式上就认为可以了。另外一个原因，就是曾经我看了一篇贴，在有些场景下需要的模块，python3的支持不是很好，如：进行自动化扫描利用到paramiko模块，有人在安装其中的一个依赖crypto，官方当时是不支持的。当然现在我的感觉来看应该python3出来都这么久了，不应该还有此问题。

（二）管理后台UI需要重新布局、美化

工程界面风格如下图，我对比看了几款其它成熟企业的后台，这块上有待完善

（三）工程中代码架构设计存在一些问题

在启动自动化扫描程序任务，执行main.py报错：

RuntimeError: Conflicting 'connectioninfo' models in application 'detail': <class 'apps.detail.models.ConnectionInfo'> and <class 'detail.models.ConnectionInfo'>.

这个就是由于设计组织代码结构的时候，不太科学，导致django工程导出，在某种情况下会产生问题，影响工程中models导入。

（四）代码优化完善

（1）一个体现在代码执行流程中的优化，如：自动化扫描发现，对于资产的发现、有的时候需要用到两次的ssh反复登陆探测，流程上完全可以考虑优化。

（2）另外一个体现在代码模块化、共有类的抽象不够，导致代码的重复性有一些高。

（3）模型设计上不够科学，字段名类型、长度。多表关联查询的业务场景如何有效解决。

（五）功能设计上问题

对于第一版开放的功能中，存在如下的一些问题：

（1）自动化任务执行场景上，队列实现，支持异步任务下发执行。

（2）自动化任务执行中，对于人员组关系和机器组关系，主机组关系和机器关系，权限如何定义。

（3）自动化任务执行中，实现普通用户模式、sudo权限普通用户模式、选择性的root用户模式，这部分功能存在缺失。

（4）CMDB的资产管理部分,缺乏人工管理和编辑功能太少