数据库运维场景中的连接

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

在数据库运维中对运维场景建立连接是一种很不错的方式，通过建立连接使得我们可以把原本单一的问题通过流程化的方式衔接起来。

以下是近期的一些实践和思路。

业务和运维团队之间工作的一个纽带就是工单，当然目前还没有明确的工单结算方式，但是可以很明确的说，工单是我们输出给业务方的业务价值体现。

在业务价值体现的过程中，我们可以把技术价值也打包进去。业务关注他应该关注的，我们在这个基础上把技术层面的附加属性也加进去，通过流程化的方式衔接起来。

首先第一个例子就是SQL审核，原本我们开发的自助SQL审核对于业务同学来说有很多的疑问，其实归根结底就是这种方式对于业务来说有些新鲜，但是适应需要成本，所以要推动他们主动去用，这个就很难衡量了。

但是我们通过连接的方式把SQL审核和工单结合起来，比如业务方要申请创建一个表，我们之前的方式是人工建议他做下SQL审核，如果他没做，我们其实也很难去逐一规范，而且更让人纠结的是哪怕发现了问题，要改进这个问题的代价相对较高。所以在初期的时候，SQL审核是完全面向业务，但是叫好不叫座。这种情况下，我们通过连接解决了这个问题，我们首先对SQL审核引入了打分机制，一条SQL质量好不好，是有一个分数的，如果分数低于60分，则不能正常提交申请，如果违法了必须遵守的建议，则必须整改后才能提交。所以通过这一道坎把不规范的业务需求阻拦在了工单申请的门槛之外，我们通过后台日志分析发现，有不少业务方开始重视这个问题了，而且在创建表的时候也会主动做下审核了，如果在提交的时候审核通不过，可以看到他们反复尝试，最终一条SQL从50分能够优化到满分（99分）。

能够看到这样的一种情况是很让人欣喜的，也通过这种方式使得我们不用就纠结到底怎么去推广这个工具，而是能够更加关注于做好这个工具本身。

有了这一层的效果，后期我们要推出SQL自动化上线其实就是一件水到渠成的事情了，我们目前暂规定SQL打分超过80分的可申请自动化上线，自动化上线可以使用最少的审批环节，最快的数据处理速度，对于业务来说更加具有吸引力，而这个80分的门槛也会变相激励他们更加关注于SQL质量。

当然还有其他的几个维度，比如安装部署，这个部分可以无缝的把灾备，高可用的属性打包起来，让业务在申请的时候就根据需求来决定这些信息，这个里面的一个核心就是成本，比如对于很多人来说，如果有一个下拉框选择内存，内存可选项是8g,32g,64g,128G,那么我相信很多业务同学都愿意选择较高或者最高的选项，因为对于他们来说，这种选择就是点点鼠标的事情，如果把这个部分和成本管理打包起来，我们的处境就会更加主动积极，至少通过成本的方式对于大家选择的时候会更加慎重。

当然业务巡检的情况和SQL审核类似，页面开发出来了，但是还没有完全推广用起来，我觉得这个地方的一大改进就是把监控和报警结合起来，监控数据能够推送出报警，报警信息可以间接调用巡检接口，这样对于运维同学来说，就会收到相关的巡检报告了，这种类似快照的报告形式对于处理问题的时候就会省去很多的精力。

而在这个基础上，我们完善了之后，可以把报警信息和巡检建议也一并发给业务方，这样业务方对于系统的负载和问题都会有一个清新的认识，而通过可视化的方式也让他们能够关注于自助巡检的信息。