上周部门总监，到现场来视察，顺便被项目经理很愉快的出卖啦。好吧，饭点的时候给总监演示啦一遍系统。
总监的想法果然与众不同，提出啦以下几项建议：
1.系统是否能用在其他省得项目组使用。
2.是否可以将主机，虚拟机，网络设备也一起加入进来，形成一个整体性的系统，且业务跟主机，网络设备及防火墙进行关联。
3.能否直接接入内网，直接采集所有设备的信息,及性能相关信息。
根据领导提出的想法，我这边进行逐步分析，情况如下：
1.由于系统对于设备是高度定制化的，除啦光交能通用以外，存储类型众多，个人的力量无法收集所有的存储信息。
2.主机，网络设备这边都有商业化的系统进行采集（比如华为的设备管理软件，emc的高端存储运维系统），但商业化的产品基本上是基于设备的，而不是基于业务的，通过他们的系统没法看到属于哪个业务系统。我这边的设想是通过api接口或者爬虫的方式对以上的系统进行信息采集，并且存入自己的数据库，并进行业务名称的添加。
3.虚拟机这块也是大头，经常有需求说需要统计某某部门的虚拟机的量等等，vmware这块比较好办，通过python的第三方模块，可以直接登入vmware，进行信息采集。citrix的我就没则啦。
4.性能采集这块，由它去吧,我这是基于业务的，而不是基于设备的, 我最多通过第三方的商业化产品进行抽取数据。
系统的重构开发：
先上个图：
1.所有的光交及存储采集的代码全部抽取独立出来，修改成agent，系统通过api封装，定义接口规范。其他运维人员只要懂python，可以自己写agent，通过定期的方式将自己所管理的不同类型存储，光交信息及服务器信息通过api的接口进行post。
2.系统层面的views.py代码写的太烂，重复性太多，针对权限这块比较麻烦，也需要重构，需要将业务逻辑跟数据库的访问进行分开来写，而不是像这个系统全部写在一起，导致权限设计这块相当麻烦，应该也是通过接口的方式进行调用。所有针对数据库的增删改查写在一个model_api.py文件里面，views.py里面专注业务逻辑。
model_api.py设计大致逻辑如下：
class 表名称:
@权限检查
def 增：
@权限检查
def 删：
@权限检查
def 改：
@权限检查
def 查：
技术水平在不断的提升，发现之前写的代码简直烂到渣啦,不过能用就行，整套系统历时半年，根据客户的需求不断的定制修改，现在基本上OK。
最后，好吧，想法是美好的，现实是骨感的。够用就行，重构一个人就算啦，太累，有这个精力还不如哦去啃啃django的源代码，加强对代码的理解能力。
目录
django存储光交业务管理系统第二节-pyhon脚本的编写
django存储光交业务管理系统-菜鸟开发日记第八节-目录的结构说明
django存储光交业务管理系统-菜鸟开发日记第九节-系统开发遇到的坑
django存储光交业务管理系统-菜鸟开发日记第10节-业务图表需求
django存储光交业务管理系统-菜鸟开发日记第11节-结束及总结
………………………………………………………………
