超大型系统的数据库版本质量控制

这似乎是DBA工作中最为无聊、繁琐以及最没有技术含量的事情。这也许是DBA工作中，最可能一击致命，产生巨大损失的工作内容。这部分内容虽然LOW，但是对于DBA工作来说，却是基石般的存在。
​从最朴素的角度上来看，投产上线的数据库版本只有两部分，一部分是DDL文件，另一部分是在OS上运行生效DDL文件的脚本。当一个系统里的数据库表并不多的时候，数据库版本可以作为应用程序版本的一部分。数据库建表、变更，由开发者或者运维者执行生效到生产环境即可。往往有经验的开发者或者架构师，可以凭借丰富的经验，一眼看出版本生效是否存在风险并给出回避方案。
当系统越做越大，变得复杂起来，数据库表变得种类繁多，开发者的人数也越来越多。通常会有出现两种选择。一种是，谁的表谁管，即每次投产的数据库变更归对应的开发者，依然视为应用程序版本的一部分。另一种是，整个系统的所有数据库变更，由某一个DBA来统一实施。
前一种方式，往往会产生各式各样，五花八门的实施方案。因为每个程序员都有自己的开发习惯和喜欢用的脚本。如果这个系统，不仅复杂，而且还很重要。那么这个系统的架构师就不得不花加倍的时间，来复核这些五花八门的方案的正确性和风险程度，以确保投产上线的万无一失。
这时候，另一种模式会有个显著的好处，因为它有一个统一的实施工艺，这对于系统架构师或许会非常的重要。因为无论这个系统里面有多少数据库表，架构师只需要审核有限种类的实施方法就行了。毕竟只有一个实施的DBA，怎么着也不可能做出太多的实施方案。不过显而易见，这种模式对这个实施的DBA可不是什么友好的事情。我们来想象一下，若是一个DBA做一个超大规模的数据库版本，可能会遇到什么？
版本准备阶段，这指的是上线范围确认之后，到上线投产之前，做准备的阶段。

1. 手滑风险
   如果一次投产，仅仅是新建一张表或者加一个索引。选择手搓一个SQL语句并拍到环境里的情况，并不罕见。甚至不能说这有什么非常不合理。但是手写数据库DDL和生效脚本绝对是充满了风险和不确定性的一件事情。也许在测试环境或者专门的版本验证环境运行一次版本，能有效的挡住一些错误，但是绝对不会是万无一失的。举个例子：比如说数据库表的最后一个RANGE的范围（000-999）手滑写成了（000-998），凑巧测试环境，并没