在 2022 年 4 月至 2023 年 3 月期间，经过DevOPS、DBA以及研发团队的密切协作与不懈努力，云掣为某电商行业客户实施了一系列数据库架构升级和深度优化策略，显著将每月数据库的告警事件数量从 1402 个降低至每月 22 个，并且实现了持续的告警事件下降趋势。
然而，自 2023 年下旬以来数据库的告警事件数量出现反弹，并长期稳定在每月 50-70个，未能进一步降低。自2024年开始甚至呈现出恶化的迹象，高于100的报警数量开始陆续出现。为此云掣对根因进行深入剖析同时对 SOP 记录的数据进行了分析，发现主要是由于一些长期累积的人因问题所导致，且无法单纯通过人工或流程管控以及培训去解决，也超出了SOP应对的范围，导致严重的重复性应对和人力消耗。因此，云掣启动了DBpass平台的迭代优化项目，从Archery DBpass升级到NineData，依靠数据库管控平台的优势，提升生产数据库操作标准化、可维护性、可靠性、性能。从而实现生产46台数据库，每月告警数量小于5个的稳定性 SLA 目标，为客户的业务稳定和用户体验保驾护航。
现存痛点
数据库查询风险
经过数据库生产环境历史事件数据分析，我们发现查询类事务的影响占比非常大，过去Archery 帮助我们管控住了结构和数据变更，但部分查询类事务没有得到有效管控，并且这块的问题发酵得日益严重，甚至威胁到生产稳定和安全。举例说明如下图，24年 3 月份危及生产环境稳定服务得数据库事件（总数49个）的 SQL 操作类型占比分析，其中查询操作造成的数据库告警占比高达 42%。经过深入数据分析和 SOP 记录调查，造成这 42% 查询问题的主要原因如下：原因一：少数拥有数据库连接信息的人（leader 级｜分组长级| 核心backup人员）为了紧急 hotfix 修复或者紧急核查线上问题数据时，直接连接数据库执行SQL，从而造成数据库资源波动。这部分SQL研发人员没有途径给到DBA确认风险或者判断是否有更好的执行方式。Archery DBpass仅支持数据库结构和数据变更审核，查询事务没有做任何限制。原因二：新版本代码上线，或者修复数据的紧急事件，又或者临时执行的SQL任务，无法给到DBA确认风险。DBA和DevOPS 只有被动得在24小时监控体系反馈的突然发生的CPU耗尽的危险事件中，发现异常SQL 或缺少索引或 Slow SQL，然后进行紧急应对，生产风险巨大，同时相关人员长此以往损耗巨大。原因三：由于Archery查询功能不够完善，研发人员更乐于使用类似于DataGrip这类专业数据库连接工具，但是每位使用者的数据库能力以及对规范和生产环境的安全意识水平都有高低，这就造成研发直接连接数据库会有风险。
数据库结构变更风险
每个月的数据库告警里，有差不多38%都是因为数据库结构变更造成的，期间通常会出现只读延迟告警和IOPS使用率告警。虽然一般会被列入计划内的变更，但本质上是对生产稳定的威胁，同时会引发相当规模的应对人员启用应对流程，造成人员损耗和浪费，我们必须避免这种灾害可能，从而避免服务不可用的情况发生，同时把有限的应对人力集中到需要的地方去。如果遇到必须全程锁表变更的情况，就会非常麻烦。例如之前订单组，遇到核心下单表Copy DDL变更，如果直接执行的话，可能会影响到正常下单。经过多方技术评估，最终把变更放在凌晨05:00执行（低峰期，下单人数很少）由 DBA 和研发在线监控，SQL 执行了 3 分钟，刚好期间没有用户下单，未出现锁等待的情况。如果期间有用户下单，那么就会直接造成用户下单失败，造成巨大损失。结构变更造成的数据库告警事件占比约有 38%，其中 98% 的变更分别会造成以下影响：
- IOPS 使用率抖动：这意味着在此期间数据库的性能会变的不稳定，SQL 语句的执行效率时快时慢，反映到用户身上，用户的操作会时快时慢，甚至失败，影响线上服务稳定以及造成用户使用体验下降。
- 只读延迟：业务会读取到旧数据，业务上不能接受，当延迟过高系统甚至会将所有的请求转发到主节点，造成主节点的负载飙升，极端情况下可能会出现主节点崩坏，从而导致生产环境故障无法提供服务，这是绝对不能发生的。
但是，除了上述的大部分情况，还有少数的特殊情况。影响范围不仅会导致延迟和IOPS 抖动，还会有一个更严重的风险，那就是锁表。会堵塞业务的写入操作，如果是核心表，可能会直接影响到用户下单，必要时需要停掉相关业务才能执行变更，也就意味着我们的生产环境无法持续稳定提供线上服务。
建设内容
直连数据库的风险解决方案
如下图，一些研发人员通过紧急修复的机会掌握数据库连接信息，通过五花八门的连接工具，就可以访问数据库，且没有统一的规范限制。
NineData 平台中有数百条规范限制，通过规范可以强制把所有人都拉到同一水平线上，从而满足研发人员查询数据库需求的同时，保障生产数据库的安全。Archery 仅是一个审核变更平台，而 NineData 则是一个数据库管控平台，提供不亚于 DataGrip 等专业查询工具的操作体验，最重要的是可以通过设置统一的规范和粒度更为细致的权限，帮助我们主动拦截掉可能会对生产环境造成影响的 SQL 语句。如下图，NineData 内置数百条语句编写规范，可以由DBA及运维人员按照环境等级配置，只要 SQL 命中规范就会阻止。SQL 命中规范后，提出改进建议，帮助研发人员改进低效 SQL 语句，有效降低问题语句发生的可能性，从而避免危及生产环境稳定的情况。根据历史数据分析，如果使用 NineData 作为数据库统一访问入口，预计每月可以有效拦截违规操作，提高SQL语句效能标准下限，预计可减少 25-30% 的数据库告警事件。
代码中的SQL风险解决方案
前文提到，造成数据库告警事件，查询占比 42%，分别是由直连数据和代码中的某些 SQL 以及业务的临时发布或者一次批量任务造成的，如果 SQL 执行效率不高或者并发过大，就非常容易危及数据库的平稳运行，从而导致生产环境稳定性风险。NineData 提供了一个SQL 代码审核功能，通过该功能，研发人员可以通过 SQL 文件、代码包、XML 等多种方式，在代码上线前，把 SQL 提交给 NineData 平台，平台中的内置规则和优化策略会对 SQL 进行智能预审，将不符合规范的 SQL 会被拦截，当然，研发也可以选择直接提交，由 DBA 来把最后一道关。举例说明，如下图，NineData 平台会将一些简单的缺少索引的 SQL 拦截并提出建议。根据历史数据分析，如果使用 NineData 的 SQL 代码审核功能，预计每月可以有效减少 15-20% 的数据库告警事件。
数据库结构变更锁表风险解决方案
相比于老的 Archery DBpass 平台，NineData 提供了无锁 DDL 变更功能。可以把 DDL 降级为批量 DML ，从而实现无延迟不锁表的结构变更，这是一个业内少有的能力，明显提升了数据库的稳定性和可维护性。
根据历史数据分析，如果使用 NineData 的 gh-ost DDL 结构变更，预计每月可以有效减少 25% 的告警事件。而且上面提到的 锁表风险，都可以转化为无锁变更，无需停业务，不会影响用户体验，完全消灭了线上风险。 核心价值
优化建议开发效率提升——数据归档和清理
数据库表中的数据不能任其无限增长，到达某个临界值会降低表的查询性能，且大表会降低数据库的可维护性。所以各业务组都会遇到清理无效数据场景，每个业务组都有不同清理数据的方式。以商品组为例，虽然清理数据的频次不高，但每次清理数据的行数都是几亿行一次。根据规范，物理删除业务数据一般是不被允许的，往往是由于外部压力，例如，空间不够，扩容会产生额外费用。技术角度来说，表太大会降低可维护性和性能。删除数据的操作都是研发自己写脚本清理，所以过程中需要实时关注进度，避免删错数据或者并发过大对数据库造成额外的影响。下图是与商品组某位研发的采访记录，非常具有代表性。研发人员也希望数据清理操作，能够流程化、标准化、自动化，从而降低线上操作风险。NineData 提供了数据归档与清理的功能，研发人员只需要简单的配置删除的数据范围，提交审批流程，平台就可以自动分批清理，让数据清理和归档操作更加标准化和自动化。使用 NineData 数据归档与清理功能，可以减少研发工作量，清理数据的操作，只需要在平台上提交流程即可，统一标准，合规可追踪，不用担心怕删错数据或并发过大影响线上，提高了删数据操作工作的标准化、流程化以及操作安全。
流程效率提升——导入导出
在运维过程中，研发也有数据导入和导出的需求，之前的流程都会先给到 DBA 需求，SQL任务由 SRE 团队人员，通过腾讯云的 DMC服务平台 手动执行 后，导出 SQL 文件，然后再发送给研发人员。
NineData 支持数据导入导出，只需要提交工单，DBA 和 leader 审批后，就可以将数据以 SQL、CSV、Excel 的格式自动化 导出。相当于之前的工作是人工操作的，通过 NineData 这些操作都可以自动化完成。
数据安全——数据追踪和变更备份
我们使用的腾讯云数据库，提供了实例级别的数据恢复功能，因此想要恢复数据的话，需要花费的时间和数据量成正比，数据量越大恢复所花费的时间就越长。而且即便业务只想恢复某张表的某几条记录，仍然需要恢复整个数据库实例，往往需要 1～3 小时，而且腾讯云一般是把数据恢复到一个全新的数据库实例中，新购的实例也需要不菲的费用。NineData 有一项技术，叫数据追踪和回滚，变相为我们提供了行级别的表数据回滚能力，并且是将数据恢复到原实例，节省新购实例的费用。恢复耗时上，根据线上实际操作结果，都可以在 5～20 分钟内恢复数据，大大提升了我们数据库线上灾备恢复的时间。数据丢失的故障，往往是因为bug、人为误操作造成的。虽然说发生概率较小。如果万一发生此类故障，导致用户数据丢失，不能及时恢复数据的话，这不仅会影响我们的商誉，还可能导致用户流失和销售业绩损失。NineData 可以将数据恢复的时间变得很短，在紧急情况下帮助我们快速恢复数据回到业务正轨，从而避免或减少这些损失。通过 NineData 可以减少数据库在数据丢失故障中的 RTO（表示从数据丢失到数据完全恢复所需的时间）由原来的 1～3 小时，缩短至 5～20 分钟。在试用过程中，已有业务组通过 NineData 数据追踪和变更备份的功能，快速修复了错误的数据
