运维开发里程碑的小结

昨天吹的牛，今天能完成吗？在开始今天的小结之前，简单提一下计划的任务。

明天，实现几个还不错的功能点

说实话，截止目前，五个功能实现了四个，所以算是基本达标了。后续的改进点依旧有很多，突然发现这样的设计和贯穿，有了一种豁然开朗的感觉。只要行得通，改进也有了方向。

我来说下艰难的第一步：

脚本化演进的必经之路：工具化

这个步骤大家很可能会轻视，因为看起来实在是太简单了。提供脚本，能够解决业务需求即可。但是落实的时候却发现很可能不是这么回事。

首先我有一大堆的路径可选，怎么走都没错，怎么找到一个最佳的平衡点。

比如运维服务器连接到目标服务器，有路径1+2或者6可达，但是折中从设计的角度来看，1+2的方式是推荐的。

比如运维服务器连接到目标数据库实例，有路径1+2+3或者1+4甚至5都可以满足需求，最后我还是选择了最难的一条路，就是1+2+3，这个过程中的调用关系和逻辑如何保证呢，我其实是在2+3的过程中写了一个简单的agent的角色。从这一步开始我就会明确自己接下来要脚本化的内容是需要做到一种工具化的提升。这样一来是统一的接入方式和数据处理方式。

所以原来纠结的脚本管理，在这个地方就会有一些完整的思路了。

第二个是元数据的边界，我举个例子来说明，截止目前，安装部署，服务开通的基本功能我都是尽量在平台里来做了。前期苦逼的事情比较多，脚本的不规范和不健壮让自己投入了不少的精力来完善。达到一定程度之后，这个事情就突然变得会轻巧起来。因为安装部署会自动录入元数据，原本手工操作的事情都自动化完成了。

而如果手工添加实例信息，其实如果有了前面的数据流程补充，其实实例添加所需要的信息是很少的。系统层面的信息我们完全可以参考系统API的，应用的描述信息完全可以参考应用信息中的。

这些也是自动化的一个环节之中，只是一种潜移默化的形式而已。

到了这个阶段之后，我发现要继续提升的空间相比之前，就好像水的状态从固态到了液态，感觉很多流程都流动起来了，只要能够动起来，需要做的事情多起来，那么意义就显现出来了。

接下来的一个里程碑里，需要解决的事情会越来越重要，后端业务中会完善备份恢复，同时自己也打算把一些前端的内容好好补充一下。同时在架构上对于微服务也会做一些调研。