作为一名忙得要死的 DBA 人员，如何卸掉手上的一部分工作？

dba| 2019-08-06

我没有时间顾全一切

我是一名非常忙的 DBA。开发人员常常在不经过我 Review 代码的条件下，直接提交到生产环境。这导致我一次又一次地陷入被动的境地，在美好的周末里，开发人员可能都在海滩上喝着美酒抽着雪茄，而我还在不断解决性能问题。这种境地是否似曾相识？也许开发人员可能并没有在海滩上享受生活，但也不会差得太大。

你很忙，你需要保证备份是可恢复的，服务器是被锁定的，提供新的实例，不能停止打补丁。这一切的维护计划不会自动执行
开发人员的工作也是如此，他们需要不断地更新系统，但是相较于 DBA 的修改，比例有所不同。通常来讲，开发人员管理的代码远远多于 DBA 管理的。
DBA 没有足够的时间审查所有的内容，修改的内容直接发布到生产环境，造成问题时 DBA 就不得不需查看当时的修改内容。如果 DBA 有时间的话，就应该在评审期进行检查。

这是一场噩梦，又会发生什么？

想象一下，如果有一群人可以帮你审查代码，如果每一个开发人员都有一个你信任的“守卫”来做代码审查？如果随着时间的推移你可以帮助程序员能够自己有能力检查 SQL 代码——如果这样可以减少您花费 1%、10%、50%、100% 的额外时间，又会怎样呢？你是否可以想象得到，躺在沙滩上的人会不会变成你自己呢？

行，但是该怎么办呢？我们的开发人员并不精通 SQL

我们先看看 DBA 在代码评审时应该做哪些事情：

确保格式正确，符合全部的标准。
是否有潜在的 SQL 注入的风险。
考虑修改的风险，比如说在一个 10 亿数据的表上面，修改聚集索引所花费的时间，实时性要求比较高的系统是否能接受这种时间上的消耗。
考虑一下对于性能的影响 —— 是否会导致 tempdb 溢出？是否会产生死锁？执行计划是否变糟？
代码是否符合开发人员的预期，merge 语句中的 update 语句是否正确。

想要开发人员足够了解 SQL，并能够独立自查自己的代码，减少线上问题，有许多需要注意的东西。

以上列出的只是其中一部分问题。通常来讲，快速看一遍代码很容易做到，但是没什么太大的作用。花费时间去思考修改的内容往往能够找出问题，但是也比较耗时，而且 DBA 往往没有那么多时间。所以这种情况，我常常称是一种恶性循环。

下面我们还是来分析一下 DBA 做的每一件事，看看我们能做些什么。

确保格式正确，符合全部的标准

自动化的方式可以直接节省全部的时间。在提交代码的时候，自己写一些工具来验证代码的格式是否正确，这里可以使用 DacFx 提供的功能，或者购买 Redgate SQL Code Guard，或者采取一些其他的方式。较好的方式是在提交代码的时候，如果不符合你的标准，就自动将格式修改正确。在这种方式下，你基本可以确认，已经提交的代码一定是符合标准的。

注意：我假设执行时，你的代码在源代码管理中，并且它不会停止所有操作（可能不停止备份）

是否有潜在的 SQL 注入的风险

将这 100% 自动化，是否使用了 sp_executesql 或 exec 这种“有风险”的存储过程？如果有的话你可以发出警告，或者你可以检查代码来查看是否有传递连接字符串的情况。

考虑修改的风险以及对于性能的影响

我把这两个问题合并在一起说，这里有两件事需要你来做，第一件事是提供一个好的测试环境，开发人员可以在这里编写性能测试。保证每次提交代码的时侯，运行这些测试，如果需要检查的脚本（包括需要部署的脚本）未在指定时间内完成检查工作，则阻止项目打包。

你可以做的第二件事，是跟开发人员一起工作并对他们进行一些训练，比如说在一个小时的午餐时间分享一些信息给他们，就是一个比较好的方式。分享的主题可以包括：“如何查看执行计划”、“SQL Server 以及索引相关的内容”、“如何统计比较感兴趣的信息”等等。我觉得你脑海中浮现的内容肯定比我想到的更多。我发现，当开发人员和 DBA 都开始书写并分享自己的见解的时候，这种方式会更加奏效。尽管内容可能并不是很深入，但是这并不重要，因为开发人员和 DBA 在这个过程中都会学习到一些知识。

好的性能测试需要有人去编写，而且，开发人员通过这个可以学习到一些东西，比如说如何查看执行计划，一旦有了这些测试，你的生活就会瞬间变得很惬意。如果培养了一个学习环境，在需要时提供一些指导，那么你就可以逐步地将代码 Review 的工作留给开发人员自己，自己从每天繁杂的工作中解脱出来，DBA 团队焕然一新，把他们精力放在更精彩的数据库工作上。