这是学习笔记的第 1836篇文章
SQL自动化上线的工作做了初步的设计,目标是希望对于业务同学使用是一个相对平滑的过程,把目前工单需求中的一些瓶颈点做到显著改进。
首先对自动化上线,不是所有的场景都需要支持,也不是所有的变更都需要做到自动化上线,而是选取一个对环境来说相对稳定的场景,比如create table这类需求,目前的评价标准是SQL质量打分在80分及以上时,create语句我们就需要实现自动化上线。
这是一个两头改进的方式,首先是审批机制,这里的审批会采用极简的方式,审批不会再分发到各级主管审批,随着审批节点的增加,这个审批环节和审批周期会大大拉长,对于业务响应来说,其实是需要优化的。 这里的一种折中方式就是采用知晓,即指定的自动化上线工单在满足提交后,会抄送各级领导,一路绿灯走下来。
执行的部分,因为涉及多个系统的交互,这里会开始解析相应的SQL语句,比如业务方一次性提交了5条SQL,那么我们就需要在后端开启循环模式,逐个应用对象变更的操作。 这个过程的实现方式需要借助任务调度来处理,通过异步任务接入的方式快速响应前端需求,实现平滑的对接。
而SQL执行的情况到底怎么样,我们可以把结果持久化,通过日志的方式记录下来,是否成功,如果失败,失败的日志也需要记录下来,方便人工介入管理。
对于失败的处理是关键的一环,在执行失败的时候,需要及时介入,通过提供的现有日志做出分析和判断,在人工介入后,可以手工确认完成,而如果一次性成功,则直接通过即时通讯方式提示业务方。
总体下来如果一条SQL的质量较高,而且满足自动化上线的基本条件,则最快的情况下,上线SQL只需要1分钟搞定。
整个代码的实现,最开始想容错处理的步骤是比较复杂的,需要考虑一系列的处理策略,代码开发一定很耗时,结果在睡觉前码了不到40分钟就基本搞定了基本流程,在满足基本需求的前提下,能够快速迭代和响应,在满足基本需求的情况下,逐步打磨产品迭代是一种相对稳健而高效的实现方式。