SQL文件管理方式影响研发团队效能和系统稳定性，这里有解决方案了...

高效的管理软件工程中的SQL文件，不仅影响软件研发团队的效能，还影响系统的稳定性。

在过往的经历中，SQL文件在团队中通常没有得到很好的管理。以下是我的经验。

SQL文件管理是如何影响软件研发团队的效能和系统稳定性的

想象一下一名后端开发，当涉及到数据库方面的业务开发时，他的工作流程如下：

1. 1. 在本地启动开发环境：打开IDE、启动本地的DB；

2. 2. 写业务代码，将业务代码转成SQL文件；

3. 3. 手工在本地DB中执行SQL文件；

4. 4. 本地启动程序，然后调用服务，验证SQL文件的逻辑和业务逻辑是否工作正常；

5. 5. 如果不正常，重复2，3，4。这个过程是开发人员最低效的地方；

6. 6. 如果不正常，则另执行一条修复的SQL。至此他已经执行2条SQL，接下来还可能增加，直到他完成业务开发。

最后，开发人员会回溯他到底执行了哪些SQL语句，并整理出一个最终的SQL文件给到运维（开发还经常整理错误）。并告诉运维，这个SQL需要在测试环境上执行。

当运维在测试环境执行该SQL时，发现报错了，然后他们反馈给开发。开发第一反应通常是：我在本地执行好好的啊。然后开发与运维共同“联调”。好在花了一天时间，他们调通了，原来是开发漏了一条SQL语句。同时他们也发现开发本地环境的DB版本不同，且SQL schema与测试环境不一致。这是另一个导致他们花这么多时间调bug的原因。

但是，接下来的事情也不是一帆风顺。他们在生产遇到了同样的问题。还因此产生P0事故。

不同的人看待以上工作流程会有不同的看法。有人觉得是开发人员的能力的问题，有人觉得是运维的能力的问题，也有人觉得是SRE的能力的问题，还有人觉得是项目管理流程的问题等等。

这时，通常会有人提出：我们需要一个SQL管理平台，以提高研发效率和降低对稳定的影响。

但是，我们真的需要另搭建一个SQL管理平台吗？SQL管理平台为什么能解决以上问题，又解决了什么问题？这是我们在“搭建SQL管理平台”前必须考虑清楚的。

开发人员解决问题的方式

在过往的经历中，经常有开发人员要求能在本地连接到测试环境DB的权限。即开发人员希望能在本地直接云端的测试环境DB，方便开发。

作为运维团队的Leader，面对开发团队大量的“投诉”的压力，你会如何处理？

我是拒绝的。理由是