这是学习笔记的第 1824篇文章

对于开发同学来说，能够最快的响应业务需求是最能体现服务质量的事情了。

对于运维开发同学来说，能够最快的完成业务需求是最能体现运维价值的事情了。

所以两者结合起来，应该是大家都希望看到的情况。但是从我的理解来说，我是不希望在初期的时候就推行自动化上线的。因为隐患太多，需要填补各种潜在的坑和复杂的业务场景。这些细节会让你焦头烂额，所以我们开始的时候可以做一些功能裁剪的。

自动化设计该怎么推行，基石就是SQL审核，如果一条SQL语句的打分在90分(满分100分），基本能够判断这条SQL质量是不错的。如果这是一条create table语句，那么这条语句的影响范围是最小的。如果业务同学提交的服务器信息无误，配置无误，那么我们处理的时候无非就是点开页面，然后不断的点击处理。如此一来，整个事情的就没有什么技术含量了。我们可以做得更深入一些，直接坐到自动化执行，那么这个复杂度和技术含量就高了一个等级。

一个初版的SQL自动化上线的设计如下：

整体来说一个对象变更（DDL变更）的生命周期涉及三个层面。

第一层是提交工单，能够填写好单据是自动化上线的基础，如果单据信息比较清晰，填写的时候严格按照规范，我们需要做的就只有条件筛选了，我们可以对指定的SQL类型(create)试点，如果SQL打分超过90分，是符合自动化上线的要求的，可以通过这种方式督促SQL质量的落实。

在工单审批阶段，需要改进的就是审批的环节，我们可以通过配置的方式来灵活控制权限，这样一来既有的流程也不会受到影响。总体来说，这类需求的审批环节要尽可能简化，甚至达成一种默契，通过随机采样，或者尽可能少的审批环节来改进。

第三层是工单执行阶段，这里有几个点需要注意，一个是工单执行过程中如果执行失败，则需要重试执行工单，对于工单自动执行后出现错误，可以通过日志的方式记录下来。 另外就是工单的自动化处理，则是通过任务调度的方式来触发。

这样一来，整个过程都可以做到一个相对轻量级的调用方式，效率也自然就提上来了。 

最后对于SQL自动化上线的探索，可以先从后端开始加固，等条件足够成熟就可以通过切换和升级的场景来改进了。