人生苦短，我用python。
开发语言的选择，对我来说是一个比较困难的事情，java，go,python各有优点，对我从未做过开发的我来说，上面那句话直接让我毫不犹豫的选择python，对于我的选择来说，我感觉无比正确。
2017年中旬入职某公司，负责某企业高端存储的业务架构及性能分析，备份的管理，涉及高端存储20多台，高端光交20多台，以存储有关的服务器多达到2000多台。
涉及存储：日立，富士通，华为
涉及光交：博科，思科
刚入职的我比较兴奋，但因之前实施文档数据落后，导致工作开展十分困难，对此也对工作难度的整理存在以下事件：
存储及光交数量太多，管理及业务架构费事费力。
每次都需要登入存储查看存储是否能进行再次分配，分配后是否存在性能问题，对业务的性能要求是否达到要求，光交的端口分配是否合理等等一系列的分析，并整合。
业务故障不清不楚，通过文档整理的方式费时费力
每次一个业务服务器存在性能问题，需要排查许多文档，排查后在登入存储光交收集数据，查看可能存在的性能问题。
客户需求多变，例如客户要求各种各样的文档，文档要求数据类型多变，例如把所有存储内性能负载高的业务进行排列，目前所有光交启用啦多少个端口，存储前端口是否存在不够用的情况，某个部门一共使用啦多少容量，使用啦哪些存储，一共部署啦多少业务，一共规划啦多少物理机等等
业务运维质量参差不齐，无法及时感知链路的断开，只能通过光交进行排查，但光交所有online端口存在3000多个端口，几乎无法通过光交日志的手段进行排查（服务器还存在人为重启关机等正常现象），人工的排查也几乎不可能实现，只能被动等待业务报错。
从8月中旬开始利用业余时间进行python的学习。由于时间太少，一直是半吊子的水平，9月中旬开始正式编写脚本进行辅助工作。
首先写的第一个脚本是自动收集光交及存储的日志。
其次写个命令行的脚本对收集的日志进行自动分析，处理，每次需要查询时候启动脚本，选择最新的日志，通过选择查看类型，比如选择一个端口，自动显示端口的详细信息等等。
通过脚本的方式，工作效率也大大提升，效率大致提升50%，能有更多的时间进行python的学习。
通过python的进一步学习，以及对客户设备理解的加深。再次发现啦很多缺点，工作量一多还是忙不过来，而且容易出现信息错误或者遗忘某些事件的情况。
脚本功能已经完全满足不了我的工作需求。进而开始django的开发，通过数据库的关联性，将服务器，存储，光交进行连接起来。
该系统能达到的优点：
工作效率大大提高，原本一天完成的工作基本能压缩到一个小时
数据准确，基本是系统自动分析处理，不会出现意外录入错误，
风格多变的需求文档可以直接通过系统设置后自动导出
自动对光交及服务器的多链路进行巡检
自动对光交进行硬件巡检
自动对存储的lun，map，port，san，server的信息进行分类并关联
该系统关键性非常强，一处改动全部自动更新
图形化界面展示，对每个月的工作情况进行汇报，性能CMDB，业务关联一体的系统。
在我1月份转正的时候，整个业务系统基本全部完成，但是，凭我这种不是计算机专业，也不是做开发的菜鸟来说，系统的bug肯定是一大堆的，所以，之后剩下时间基本在进行系统bug处理，新功能的添加，性能优化等等，每个新功能的添加基本耗费一天的时间，但后期确可以给我省下无数的时间。
整整持续半年的辛苦，突然觉得挺值得的，python也从入门勉强达到初级的水平。
来几张贴图,前端基本靠bootstrap盗用，所以前端比较难看
目录
django存储光交业务管理系统第二节-pyhon脚本的编写
django存储光交业务管理系统-菜鸟开发日记第八节-目录的结构说明
django存储光交业务管理系统-菜鸟开发日记第九节-系统开发遇到的坑
django存储光交业务管理系统-菜鸟开发日记第10节-业务图表需求
django存储光交业务管理系统-菜鸟开发日记第11节-结束及总结
………………………………………………………………
如果各位python大神能看到错误，望各位给予指导改正，万分感谢。
该文档不讲技术细节，毕竟我觉得我的技术还是太烂，就不坑广大人民啦，项目上遇到的技术坑我会详细讲解下。
睡觉去啦，有空继续
