江苏龙网

  1. 主页 > 生活百科 > >

DBA致命的低级工作？超大型系统数据库版本质量控制( 三 )

DBA


工具会根据不同的变更类型，使用标准化的流程 。比如工具检测到，投产内容是表的末尾增加字段，工具即产生对应的ALTER TABLE语句和运行脚本 。再大再复杂的数据库版本，它的生效流程种类总归是有限的（当然也可以在一定的时间里，工具系统逐步完善和迭代） 。程序总是能冷静和准确的根据我们编码出来的规则，选择恰当生效方式和流程 。系统架构师甚至都不用每一次上线都亲自来复核版本是否靠谱，他只需要在这一套工具程序稳定运行之前，复核规则和代码是否可靠即可 。几乎是一劳永逸 。
异常处理往往是需要人工介入的，比如你加了磁盘、赋予了权限 。但是异常处理完的后续工作，最好还是交回工具程序来处理 。这里就需要程序具有断点续跑和重跑的能力 。工具程序需要清楚的识别哪些步骤执行了，哪些没有执行，这比起DBA在万千作业里面去判断要重跑哪些脚本，先跑哪个再跑哪个要靠谱得多 。
投产检核其实通常并没有什么特别复杂内容，版本末端的检核程序可以比人类检核更加准确、更加高效 。
除此之外，最最重要的部分是这件事情 。任何工具、流程可能确实无法达到完美的程度，但是它却可以被固化下来，它是可持续积累的，这是它最大优势 。有一种情况是非常常见，就是同一个错误会反复发生 。某一个错误在发生之初，可能会被程序员重视，并在接下来的几次投产过程中被反复检查 。
但是，往往过了几年之后，同样的错误非常有可能再次发生 。因为可能这中间的人力发生了变化 。即使是同一个人，他也可能因为忘了，导致错误的重复发生 。而针对某一个问题的代码，一旦被写到了工具程序中，这个问题再发生的概率近似为0 。
五、我们的思路和原则
以上我们基本上只说了，我们需要做什么，并没有说具体是怎么实现的 。我们实现过程中的几个原则是比较重要的 。
1、零手工原则
这个原则即上线使用的所有DDL文件，执行脚本，均100%由版本准备工具程序产生，不允许手工编写 。整个版本的范围，输入信息应该仅仅是DBA选择某次版本日上线的哪些项目 。这些项目最终应该关联多少DDL，并产生什么样的生效脚本，均应该由程序生成 。
2、一眼看清原则
大型的系统，在投产前，因为各种各样的因素，调整上线范围是经常发生的 。所以，有时候还会需要DBA会去，检核程序生成的代码文件 。需要人眼看的部分，一定要非常的清晰 。切莫把生效用的脚本代码和投产范围相关表名、库名之类的内容，在文件内混在一起 。要进行清晰地封装 。
在上线版本包里，应该比较清晰的分为运行代码部分和上线范围部分 。
运行代码文件中，通常写的是标准化的流程和程序运行的代码，这部分一旦稳定之后，每次版本上线时，应该是固定不变的 。另一部分，是每次上线都不一样的部分，比如表清单等跟上线范围相关的内容，简明易读 。此外在版本生效过程中，输出的错误日志，也需要非常清晰，以方便DBA去查看 。这里也需要将流程的颗粒设计得非常细，在错误产生得时候，就可以快速精确的定位错误发生点 。
3、傻瓜原则
在正常情况下，上线的操作步骤一定要足够简化 。如果系统没有异常状况，应该是一个傻子都可以完成版本的正确生效 。这个原则主要用于排除人为主观因素，对投产带来的风险 。把复杂的事情，留在投产之前 。上线的时候，不依赖于当时DBA的状态和反应速度 。我们会把整个版本生效简化到运行一个入口脚本 。异常处置时，我们也还是重新运行这同一个脚本 。极致简化，不给操作者犯错的空间 。
不得不说，数据库版本质量控制，是DBA工作中我最不喜欢的部分 。但是确实我最花心思的部分 。上面的这些内容，无论思路或者程序的实现，其实并没有很难 。但是一个大型系统的DBA，对于每一次上线的数据库版本，心理有把握很难 。有100%正确把握，就非常非常难 。
我们可能需要几年，甚至于整个系统运行的周期，都在不断迭代，修补我们的工具程序，来堵住各种意想不到的漏洞，直到我们的版本质量，越来越接近完美 。
直播预告丨三位大数据专家齐聚，探讨实时计算、数据湖、数据治理、平台化建设与实践
随着企业业务规模的不断扩大，数据分析处理的准确性和实时性要求也逐步提高 。因此，建设兼顾效率和质量的大数据体系成为了业界的共同课题 。为此，dbaplus社群携手爱奇艺三位大数据专家，围绕“爱奇艺复杂场景下的大数据体系建设与实践”这一主题开展线上直播分享，针对实时计算、数据湖、数据治理、平台化建设等议题进行深入探讨，给大家提供企业级大数据体系建设管理经验参考 。


推荐阅读


上一篇：Kafka到底会不会丢数据？

下一篇：Springboot2 什么才是真正的架构设计?