数据库部署的全方位静态分析

数据库部署的全方位静态分析

我的大部分技术生涯都在初创公司中度过。我喜欢快节奏和学习新事物的机会，以及将一个新产品成功带进市场的成就感。我的职业生涯始于QA。在初创公司中，开发人员与测试人员的比例不可能像大企业那样低。作为一名初创公司的QA工程师，收件箱的邮件总是比发件箱多得多。你是新版本发布的***一道关卡，因此你总处于显微镜之下。在初创公司的早期阶段，你很可能也从属于“客户支持”团队，所以当产品出现问题时，你会成为最忙碌的一位。

和其他从事相同工作的人一样，我总是非常关注于寻找正确的工具来减轻我的负担，但是不能牺牲我个人对于工作质量的定位。因此我在10年前就遇到了FindBugs。我***次使用这个工具时，我将它的结果分享给团队的开发工程师，他们感觉这个工具产生了多于真实Bug的误报或者属于一种“吹毛求疵”方式。但是，随着我们不断地根据自己的需求调整和扩展所执行的检查，并且将FindBugs得到的数据与测试和生产中发现的实际Bug数量相关联，FindBugs***成为每夜构建版本和按需构建版本的组成部分。这些报告是在早期预示潜在问题的好线索，也允许开发者提前修正错误，避免占用测试时间或运营故障故障时间。此外，对于我团队中的开发者而言由于每天都能收到构建系统的提醒，而且这些提醒会帮他们改掉自己的坏习惯，编写出更安全、更高效、更稳定的代码，所以他们产生的缺陷也越来越少。发布周期缩短了，产品质量提高了，客户满意度也提高了，这都证明了预防确实比治疗更加重要。

随着企业IT不断地拥抱敏捷开发实践和采用DevOps模式，以此更快地向市场推出更优质的产品，DBA实际上也开始感觉到压力。前面关于初创软件公司QA工程师的介绍也一样适用于DBA。随着版本发布越来越频繁，DBA接收到需要编写、检查、修改或优化的SQL脚本数量要远远多于完成的数量。DBA是数据质量、数据安全和数据平台性能的***一道防线，因此DBA也是***批响应问题的人。

在与我们协作的财富500强公司DBA中， 他们日常工作中最耗费时间的任务是检查SQL。有一些DBA将自己70%的时间用在人工检查SQL脚本上。他们会像FindBugs等工具检查Java代码一样去检查SQL：预示逻辑问题的编码模式、安全漏洞、性能问题及违反内部规定***实践或外部法规的合规性问题。

显然，DBA需要一种和十年前FindBugs一样的工具。SQL静态分析并不是新技术，但是目前可用的产品也只能做到静态分析。通常，它们会在不考虑上下文的情况下评估SQL语句。这种局限性会影响最终的生产力和质量，因为数据库生命周期管理的大多数时候都知道谁在何时、何地执行何种操作。例如，一个组织可能允许给一个测试环境分配权限和执行INSERT语句，但是绝不允许在生产环境的自动化任务中执行这些操作。任何SQL静态分析工具都必须考虑环境参数。

另一个让问题变得复杂的是数据库“版本变化”。虽然各个版本的应用程序都会打包、设定版本和全部替代，但是支持应用程序的数据模式一直存在，并且不断地进化。而且，外部合规性标准与内部审计要求通常规定要严格控制数据库的增量修改，并且要用严格定义的流程来跟踪变化。这意味着，DBA还必须（通过手工流程和检查SQL注释）确认能够跟踪到修改的原因，而且要在每一个环境中跟踪修改的执行结果。

DaticalDB Rules Engine在设计与实现时专门考虑了SQL检查与静态分析所带来的特殊挑战。下面是Datical DB通过静态分析安全可靠地提高效率的一些原因：

用于执行强大评估的模型——Datical DB将应用程序的模式抽象到一个严格定义和验证的对象模型中。这些强大规则的授权过程非常快速、简单。一旦编写了，它们就会在生命周期中每一个数据库执行Forecast或Deploy时生效。感知环境的修改验证—— 这个模型包含了应用程序生命周期中关于客户端环境和各种数据库实例的信息。你可以编写规则使早期部署阶段环境具有***灵活性，而同时让敏感环境具有***安全性。尽早确认内部与外部审计需求—— 在Datical DB中，为了遵守外部和内部审计要求，你只需要紧密绑定数据模型的各个修改。每次（或自动化框架）Forecast或Deploy时执行的自动化检查替代了手工检查，由它们来确认修改的可审查性。自动验证对你最重要的方面—— 提供自定义分析的功能，覆盖自己的内部***实践，如命名规范、允许和不允许的SQL和对象依赖管理。自动化重复任务—— 和许多分析源代码的静态分析工具类似，一些简单的鼠标操作就可以将Datical DB集成到构建或部署系统中。现在，每次构建或部署一个应用程序时，它就会执行验证规则，然后生成一个供整个组织使用的报表。由于DBA紧盯屏幕的时间大大减少所以他们可以专注一些更重要的项目和问题。代码质量提高意味着Bug减少——DBA制定规则，然后将它们分享给开发人员。然后，开发人员就获得一个关于他们所在组织接受和不接受的编码知识库。开发减少Bug数量将大大节点时间与金钱。让运维人员更多参与数据库开发——这个规则引擎与Datical DB Forecast高度集成。这个特性支持模拟数据库修改，而不需要真正修改目标数据库。当DBA向运维人员分享他们的规则时，运维人员就可以每天晚上对STAGE或PROD环境执行Forecast，保证当前在DEV或TEST环境的修改也符合下游执行的严格验证，这同样可以在生命周期前期发现问题，因此修复问题的代码更低、难度更小。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。