再出发，如何将Devops真正落地

IMOOCC工程总结篇

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

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

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

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

（一）版本问题

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': and .

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

（四）代码优化完善

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

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

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

（五）功能设计上问题

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

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

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

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

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

完整开放出来IMOOCC工程功能还会有：代码发布、负载场景的自动化任务执行、项目安装初始化、配置管理、监控平台接口调用互通、定时任务调度等等，这里我就先不作一一举例了，放到计划篇吧！

大家晚安～