自动化平台开发小结（六）

最近几天还在不断的改进平台里的事情，而翻了下之前写过的文章，发现从起步到现在也有一个多月了。如果不是看看自己总结的文章，好像啥也没干。

在此期间，我设立了两个里程碑，第一个月跌跌撞撞，算是技术积累，从初期的规划，熟悉Python和Django,到捡起多年尘封的web技术，一个月很快就过去了。第二个月是规划设计，主要实现基础的架构和功能设计，花大力气重新定义了统一的模板风格，对ORM的一些基础实践，保证基础可控。而到了最近开始接入一些业务的时候，发现需要做的事情要比想的还要多，或者可以这么理解，需要解决的问题比预想的多。

问题比想的多，也比想的严重，越是发现问题，反而有一种喜悦的感觉，因为通过一些数据的重构和连接，发现了原来不曾发现的问题，原来一问三不知的问题现在有了答案，而且还有了图表展现。与此同时菜单比以往多了不少，远比初期规划的多了一倍，这意味着工作量增加了不止一倍。我来说说自己的一些理解。

确切的说，是从这周开始，我开始接入业务的信息。本来主要是给MySQL方向支持，但是发现其他的方向上的需求其实更迫切。所以大家如果能达成共识，而不是抱着帮我，配合我的态度，事情其实可以做出另外一个境地。

我按照我完成的进度来说说。

1.基础功能的权限粒度

对于权限的粒度和控制是我在初期的建设中最关注的，我想了很多，也遇到了技术瓶颈，最后还是自己想明白了之后，发现原来是固步自封。

比如对ORM的拿捏，最开始是无法控制，一到定义表关系的时候就很纠结，一来需要熟悉，同时又要定制各类需求。突破这个瓶颈期确实花了一些时间，最后果断抛弃了外键，大量的关联表，而只是依赖于自带的ORM来实现一些基础的增删改查，而对于复杂的查询需求，是通过定制SQL下沉到DAO层来实现。后期对表信息的关联做一些管控，盘子大了之后，可以注意到很多看似不重要的地方。

2.元数据稽核

元数据的稽核比自己想象的要复杂，棘手。这个工作量无异于重新搭建和设计一套CMDB.

元数据的信息主要的问题在下面几个方面：

1）元数据缺少

如果整理这部分信息，就会发现因为各种原因，每个人几乎都有一套自己的元数据源。尽管已有一个元数据平台，多套平台集合起来，而且分成不同的类别，可以说是混沌状态，而且最让人纠结的是到底缺少了那些信息，还很难去定位。这个工作是个体力活，也是很不招人待见的事情。

2）元数据信息错误

元数据存在的意义就是有效，可以参考，这是对元数据的信任或者是依赖，也是对平台的信任。所以一旦这个纽带建立不起来，其他的都是白扯。结果在整理的过程中发现，有些服务器的硬件信息是错误的（你说我咋知道，因为显示是0），有些是数据库的主从状态，这个信息靠人工确认是很难的。我们可以有其他的解法。

3）元数据信息状态未知

元数据的信息状态未知，这个问题非常纠结，简单来说，就是我们也不知道这个信息到底对不对。这个需要通过多种方式来弥补，比如多系统的数据交互，来得到一个相对来说有参考价值的信息来源。或者就是通过流程来控制，元数据信息的维护不应该是人工通过修改按钮来触发。

3.Echarts的备份可视化

实现这个是想让平台看起来能用，让一些大家都不知道的数据能够更明确，比如备份的数据，一天备份了多少次，备份集大小是多少，备份多长时间，如果我们得到数据，没有分析层的支持，那么就是一个黑盒，蒙着头干活而已。

所以通过可视化的方式来展现，就可以清晰的看到，那些地方可以改进。

4.异步数据源同步

要想不闭门造车，就是能够更多参考其他的可借鉴之处，对于数据来说也是类似，如果数据库去维护机架位的信息，肯定是很困难的，但是让系统部的同学去维护，就是一个很自然的事情。所以我们可以直接参考这些信息，可以做异构系统的数据源信息同步。兄弟部门开好API，定义好规则和方式就很容易操作了。

5.paramiko接口接入

这个部分没有话太多的时间，就是简单的接入，支持ssh的方式去操作一些命令。目前的效果还不理想，后续继续改进。

6.接入celery，flower信息接入

这部分的信息比较有借鉴意义。同事调研了celery的内容，但是因为前后端的一些技术原因，没有很好的把信息利用起来，所以我有平台，他有基本的一些东西，我们就可以结合起来。

这个部分的工作做好了，后续就是一个很不错的功能，如果自己搞，从头再来，意义不大。

7.单点实例管理

这部分信息很有意思，如果是测试环境，可能就不需要从库了，但是需要周期性的备份。

如果是流转业务，可能就不需要从库或者备份了。

所以我设立了一个单点实例管理，可以管理这些信息。