聊聊数据库变更管控的白屏化

news2024/12/26 10:25:34

在前文中介绍了当涉及到数据库相关的变更如数据更新或者误删表等误操作时，通过延迟库或者闪回等功能来恢复业务，这些已经属于事后的故障处理了。当故障发生后，所要面临的是故障影响的不可控，所面临的损失也是不可预估的。就像最近洞庭湖发生溃坝，明明可以提前预防和发现，没有引起足够的重视，最终导致更为严重的灾难。信息系统的生产运维过程也是同样的道理，通过事前和事中的一些技术手段和流程上进行管控防范，提前发现问题、变更过程中的及时阻断，避免对系统的进一步影响，提升系统的可用性。本文结合同业在变更管控中的最佳实践，聊一聊数据库变更管控的白屏化流程。

1、主动式的变更风险防御机制

生产系统的变更包括应用变更和基础设施变更，其中应用版本部署涉及到应用程序投产、数据库版本部署和参数维护等操作。通过持续集成持续交付等应用自动化部署流程打通开发测试、验证和生产系统的部署环节，在应用投产的全流程自动化中，通过事前的规范检查和评审、事中的变更阻断和防御机制，降低应用投产带来的风险。

为实现应用系统投产全流程自动化管控，某国有大行采用Jenkins Pipeline流程编排引擎和ansible服务器管理技术，基于PaaS平台的云原生特性，建立了智能投产验证平台。在此基础之上，针对应用配置复杂、变更风险易忽略、风险分析难的痛点问题，建成主动式轻配置变更风险防御机制。投产验证平台验证种类达80+种，月均下发验证任务3w+次，累计发现和规避投产风险8000+次。

在这里插入图片描述

通过在生产部署不同阶段实现主动式针对性的验证，根据反馈结果决定是否阻断变更流程。

在阿里云及B站等互联网公司，基于SRE的生产系统管理体系，加强生产变更预防，拦截低级变更事故，降低变更引起的风险。通过配置不同的阻断策略，阻断变更过程、提示异常不做阻断和阻断变更过程并升级审批等防控策略，进行变更过程中的阻断或者干预。

在这里插入图片描述

2、数据库变更管控

据统计70%的故障是由于生产变更引起的，对于应用版本部署可以通过灰度版本验证、白名单等方式进行版本验证，变更异常时通过隔离、切流、回退等方式快速阻断变更异常的风险，快速恢复业务。但是对于基础设施变更涉及到基础域的逻辑层或数据层变更，一旦出现变更异常，则会造成全局性的影响。尤其是应用版本部署过程中涉及到的数据库变更操作，DDL变更过程中的业务影响、变更后的执行计划变化、DML变更对逻辑数据的更新等操作，都需要在整个变更流程中，基于技术手段或规范流程进行预防性检查或阻断，减少数据库变更带来的投产风险。

2.1 数据库规范性检查

应用在数据库开发及表结构和索引设计时必须遵循一定的规范，这些规范既是数据库功能和性能的最佳实践，也是应用系统运行时候的保护和约束。一个好的应用设计和开发的SQL尽量简洁，通过程序逻辑去实现业务功能而不是通过SQL一层层嵌套去实现业务上的逻辑，结果往往是SQL极其复杂。在测试环境虽然能跑通，但是在生产真实的业务系统却会带来潜在的性能风险。数据库版本部署前的检查包括SQL和DDL规范检查，基于既定的SQL规则和DDL规则，对应用的开发SQL扫描以及版本部署的DDL进行扫描，形成检查报告嵌入到应用投产评审流程中。

1）SQL扫描

在持续集成环境，定义SQL审核规范，基于规则引擎对开发代码中的SQL进行审核，对于不满足规范的会在流程中，提前发现潜在的风险。

在这里插入图片描述

2）DDL部署流程

在应用版本DDL部署流程中，需要进行DDL规范和SQL规范检查、DDL投产时长评估和验证以及DDL投产异常时候的应急处理，如下图所示：

在这里插入图片描述

SQL和DDL规范检查存在一个问题是，项目开发人员会将不满足规范检查的SQL或DDL增加到白名单中，这样又增加了DBA审核的难度。尤其是数据中心的DBA，通常是基于经验规则对DDL进行审核，但是不知道具体的业务访问SQL，在审核时候也很被动。比如一张新建表只有主键字段没有索引字段，在DBA看来会有全表扫描的风险，但是开发SQL访问根本没有查询的操作。这就跟一张表建了几个索引，但是SQL访问可能没有走这些索引是一个道理的，需要在持续集成阶段提前发现和审核。

2.2 投产前预检查和阻断

由于生产和开发测试数据量和统计信息的差异，在实际数据库版本部署时候可能存在评估不足的风险。通过DDL投产前的预检查动作，评估大表DDL耗时多久、影响多少记录数、增加多少存储空间等。如果超出预期，需要重新评估业务影响窗口或者调整变更时间点，做好应急措施。但是在实际执行层面，由于生产环境和开发环境网络上物理隔离，如何在投产前访问持续集成的SQL集合进行实际生产环境的SQL预检查。在DDL或者SQL不满足投产部署要求时，此次变更窗口是否中止，还涉及到整体窗口评估的问题。还有评估准确性的问题，曾评估热点表的在线DDL影响，只有在真实生产环境实际执行才会发现锁等待的影响时长多久。这些在像阿里云这样的互联网公司或许没有问题，开发测试和生产环境可以全流程打通。而且变更窗口更为宽松，曾经几次互联网公司的生产故障发生在白天时间段，所以白天业务时间段也是可以部署的？另外不同的数据库需要不同的规则，技术实现上通用规则的集成以及变更部署流程如何闭环，也是需要借助平台工具才能实现的。

2.3 运维查询的管控

数据库白屏化管理的另一个场景是运维查询类SQL访问，对于这一类非业务访问的SQL，由于管理员查询SQL的随机性以及并发不受控，对生产业务系统会造成潜在的次生灾难。因此需要统一的查询入口，其中制定不同数据库SQL访问的限制规则，对于不满足规则的拒绝访问，比如执行计划全表扫描或者访问记录超过记录限制。同时对数据库的访问进行并发限制，基于以上规则来最大程度的保护当前生产系统。

以上是数据库变更管控的一些想法和理解。