其实到了现在的阶段，我开始做了大量的尝试，也开始去弥补之前欠缺考虑的一些地方，比如对于业务方向的接入，对此我也做了反思。运维工作中几点深刻的经验和教训

我现在做的一个改变就是更多的承接业务，数据库部署安装我接过来，服务开通我接过来，然后把数据库的DDL变更接过来，虽然忙和累，但是我希望让我通过这种方式能够深入业务，找到业务的痛点和我的难处，这样去寻求解决方案的时候，不会有一种高屋建瓴的感觉。所以接入的业务越多，其实我是希望承接更多，能够解放自己，如果能够做到这一点，说明我的实践是值得的。

所以在很多实现方向上其实我是比较焦虑的，比如我们离自动化的还有距离，更不用提外面大火的智能运维了。虽然我们考虑了很多的实现路径，但是不可避免的一些基础路径是逃不掉的，那就是脚本化和工具化。尤其是工具化的工作，大家更是容易忽视。

如果要实现这个方向的事情，我马上做了如下的实践。

1.部署安装的过程，使用脚本模块化的调用，逐个测试，把涉及到手工操作的地方都要做到脚本化，脚本化做差不多的时候，其实接入到运维平台就是一个很自然的事情了。

比如数据库的安装部署，我需要检查这台服务器上是否已经有服务，是否已经安装有其他的实例等等，其实通过元数据层面我就很容易得到，做出判断，其实脚本只是做一些纯粹的事情，保证一些基础逻辑的正确，而如果接入到平台的过程，其实也是一种工具化的过程，我们可以在里面嵌入丰富的逻辑，使得整个过程更加高效可控，我想着也就是工具化所希望带来的一些收益吧。

所以对于一个看似简单的部署界面，我们糅合了更多的业务场景，比如内核参数优化，系统环境配置，监控配置，备份配置，元数据配置等等，如果这些都是安装部署流程中的一个环节，那么整个安装部署就算是一个完整的流程了。

另外在实践的粒度上，我觉得一个比较好的方式就是我们能够从小做起，比如我们做DDL变更的时候，使用PT工具是很不错的，对于5.5版本尤其是标配。那么我们接触一个业务需求，只是添加一个字段，做一些简单的配置，如果数据量不大的情况下，其实我还是建议你用工具来做的，倒不是工具多好，而是希望从这些细小的地方锻炼自己，500万的表变更我做好了，我相信翻几倍的情况下，你做起来也会从容许多，做这个事情不是炫技术，而是越简单的场景我们越是重视，通过标准化的操作，带给自己的收益也会更大。如果提前能够发现更多的小问题，其实是一件好事，如果这个表千万上亿的级别，变更失败就很尴尬了。

简单总结下，运维工作中的脚本化是我们着重入手的一个开始，然后我们可以把整个过程衔接起来，但是模块化，后期去做一些复杂的逻辑校验的时候，这算是运维平台的一个优势和亮点吧。