在今天这个时代，企业中的数据已不仅仅是传统意义上的信息记录载体，它和土地、劳动力、资本和技术跃升为企业发展的五大生产要素之一，被时代赋予了新的内涵和价值。数据正以其独特的新质生产力属性，驱动着企业的创新转型与高质量发展。在这样的背景下，企业数据库承载和管理新质生产力中的生产要素的过程中，数据库的连续性管理(Business Continuity Management)的重要性尤为凸显。

本文将聊聊数据库连续性管理，是系列的第三篇，前两篇分别介绍了：数据库选型、数据库文档。由于企业数据库连续性建设是既复杂又重要，将分为【数据库连续性，我们该知道什么】、【数据库连续性，我们该做什么】上下两篇文章。本文为第一篇，大约3000字，预计读完需要12分钟。

01 什么是连续性

所谓数据库连续性，顾名思义：当业务系统上线后，数据库面对各种潜在威胁和挑战时，能够保持正常运行和数据完整性，从而确保业务系统稳定运行的能力。当然，不同的业务场景，决定了数据库系统重要程度不同，不同的企业对于数据库连续性的预期差异是很大的。

在业内，评估数据库连续性有两个重要指标：RTO、RPO。

• RTO：恢复时间目标(Recovery Time Objective)，指系统所能容忍停止服务的最长时间。

• RPO：恢复点目标(Recovery Point Objective)，指系统所能容忍的数据丢失量。

下图表示了RTO和RPO的关系：

从上图可以看出，RTO、RPO 都使用时间来度量，但他们存在一些区别。RTO 更关注数据库系统的可用性，侧重于强调系统停机时间。而RPO关注于数据的完整性，描述了数据库能够容忍的最大数据丢失限制。

对于绝大多数企业业务来说，业务连续性(Continuity)的优先级应该低于数据完整性(Integrity)。如果维持业务会导致数据错误或者数据丢失，那么应该毫不犹豫牺牲可用性。举个例子，对大多数用户来说，几个小时不能使用银行服务和银行数据错误，显然大部分用户会选择前者。因此，对于企业而言，RTO可以沟通，而RPO通常是为0。

人民银行发布的金融行业《云计算技术金融应用规范、容灾》(JR/T 0168-2020)标准中对 RTO、RPO 有更明确的说明：

对于企业而言，系统故障总是会发生的，我们不能幻想服务器的CPU、内存、磁盘、网络设备不会损坏，也不能永远期望地震、火灾、水灾等自然灾害不会发生，也不能不考虑人为操作因素。因此，企业通常根据业务要求定义可接受的 RTO、RPO，然后IT部门根据要求设计灾难恢复方案(Disaster Recovery)。

完美的方案当然是 RTO、RPO 都为 0，这样当发生故障后，系统立即恢复，而且完全没有数据丢失。但是，不能“只看见贼吃肉不见贼挨打”，要达到双0目标系统设计是极其复杂的，而且造价也是非常昂贵的， 企业是需要慎重评估其ROI。

02 复杂性和重要性

企业数据库工作可以分为五大块：数据库选型、架构设计、建设实施、生产运维(连续性保障)、团队培养，其中连续性保障是最复杂、最重要的一环。

• 复杂性

连续性保障之所以复杂，主要体现在以下几个方面：

技术挑战：数据库作为企业的核心数据资产，需要运用多种技术手段，如备份恢复、容灾设计、高可用集群等，以确保在硬件故障、自然灾害等不可预见事件发生时，数据库能够快速恢复并继续提供服务。

流程管理：连续性保障不仅仅是一个技术问题，更是一个流程管理问题。需要制定详细的灾难恢复计划、应急预案以及定期演练机制，确保在紧急情况下能够迅速响应并有效处置。

监控与预警：另外还需要建立完善可观察和预警系统，实时监测数据库的运行状态，及时发现并处理潜在的风险和隐患，并能面对各种突发情况有相应解决措施。

• 重要性

连续性之所以重要，则是因为它直接关系到企业的业务连续性、客户体验以及数据安全。一旦数据库出现故障或中断，可能导致业务停滞、客户流失甚至法律纠纷等严重后果，毕竟下面这些新闻离我们并不遥远。

2020年2月，微盟删库损失0.87亿，市值蒸发超 20 亿，程序员被判6年

2021年7月，河南暴雨致使机房停电，多家网站陷入瘫痪

2022年9月，长沙电信大楼起火，海量数据如何保全?

2023年6月，中国电信广东全省突然崩了：连10000号都打不通!

提高数据库连续性，企业需要投入大量的资源和技术力量，并不断提升团队的应急处理能力和技术水平。同时，还需要与业务部门、安全部门等紧密合作，共同构建完善的数据库安全保障体系，确保数据库的连续性。而灾难恢复(Disaster Recovery)是提高连续性的重要措施，早在上个世纪90年代国际相关机构关于灾难恢复有明确标准。

03 灾难恢复

灾难恢复(Disaster Recovery)是指企业系统灾难发生后，将系统恢复到正常运作的能力。一般要满足三个要素，首先系统中的组件、数据都具有冗余，即一个系统发生故障，另一个系统能够保持数据传送的顺畅;其次具有长距离性，因为灾害总是在一定范围内发生，因而充分长的距离才能够保证数据不会被一个灾害全部破坏;第三，容灾系统要追求全方位的数据复制。这就是灾难恢复的"3R"(Redundance-冗余、Remote-异地远程、Replication-全数据复制)特性。

图片来自网络，金融行业业务连续性国家标准发布时间图

目前，关于灾难恢复/备份在业内有个广为熟知的国际标准——SHARE78。SHARE是一个独立的信息技术协会组织，于1955年在美国成立，由IBM等公司发起，目前有上千志愿者，主要提供各种IT科技类的培训、咨询等服务。

SHARE78虽然共分为7个层级和8个模块，但78其实是指SHARE于1992年在加州安纳海姆(Anaheim)举行的一次盛会的编号。也正是在这次会议上，SHARE制定了一个有关远程自动恢复解决方案的标准，即SHARE78，后来业界一直沿用SHARE78作为灾难恢复/备份行业标准。

SHARE78首先制定了业务恢复的8个细分模块，包括：

• 备份/恢复的范围

• 灾难恢复计划的状态

• 应用地点与备份地点之间的距离

• 应用地点与备份地点如何相互连接

• 数据是怎样在两个地点之间传送的

• 允许有多少数据丢失

• 怎样保证备份地点数据的更新

• 备份地点可以开始备份工作的能力

根据这8个模块，SHARE78 对灾难恢复/备份定义了7个层次：从最简单的本地磁带备份，到将备份的磁带存储在异地，再到建立应用系统实时切换的异地灾备系统;恢复时间也从几天到小时级，再到分钟级、秒级或零数据丢失等。

图片摘自SHARE78

04 影响因素

数据库业务连续性的影响因素复杂多样，可以分为五大模块：性能瓶颈、硬件故障、软件故障、人为操作、安全问题，下面逐一介绍风险。

• 硬件故障

硬件故障是影响数据库连续性重要因素。对于数据库而言，硬件故障可能直接导致数据丢失、服务不可用，进而影响到整个业务运行的稳定性。

以存储设备为例，损坏可能导致数据无法读取或写入;性能下降也会影响到数据库的性能，比如读写速度变慢、响应时间延长等。网络对数据库可用性影响也非常大。在云计算和分布式系统日益普及的今天，分布式数据库服务部署在不同的 Region ，通过网络连接各个服务。如果网络连接不稳定，可能导致数据库服务延迟、中断，甚至数据传输错误。如TIDB架构图。

图片来自TIDB官方文档介绍

自然灾害和城市电源故障等不可抗力因素也是系统业务中断的常见原因。地震、洪水、泥石流等自然灾害可能导致数据中心受损，服务器、存储设备等设施遭到破坏。而城市电源故障则可能导致数据中心停电，服务器无法正常运行。

• 软件故障

数据库作为IT系统三大基础服务(操作系统、中间件、数据库)，本身是一种复杂的应用系统，不可避免地会存在Bug和漏洞。这些漏洞可能源于代码编写的缺陷、安全设计的不足或者对特定场景的疏忽。另外，由于数据库本身的复杂性和专业性，使得非专业人员难以察觉这些漏洞。可以看下面这几个链接。

MySQL：8.0.32 优化器的严重 Bug

Oracle：国家信息安全漏洞库(CNNVD)通报多个版本的安全漏洞

MongoDB：CNNVD 通报多个版本存在信任管理安全漏洞

达梦：多个版本数据库安全漏洞

• 性能瓶颈

性能瓶颈是数据库管理中经常遇到的问题，也是影响数据库连续性常见因素。常见的问题有：不合理的数据库查询、处理能力不足、内存泄漏等。这些问题不仅会影响系统的响应速度，还可能导致服务中断，对用户体验和业务连续性造成严重影响。

复杂缺乏索引的查询、全表扫描等都可能导致查询效率低下，从而增加系统的响应时间。当数据库面临高并发请求时，如果服务器的处理能力不足以应对这些请求，就会导致系统响应变慢。当数据库应用程序存在内存泄漏时，随着运行时间的增长，可用内存会逐渐减少，最终导致系统性能下降甚至崩溃。

• 人为因素

人为因素也是影响数据库连续性重要因素，它可能源于操作人员的疏忽、缺乏经验、培训不足或简单的失误，甚至是恶意的故意为之。在复杂的生产系统环境中，即使是微小的配置更改或操作失误，也可能引发连锁反应，最终导致整个系统的长时间不可用、大量数据丢失等严重故障

• 安全问题

安全问题具有不可预测性，可能来自内部或外部，且攻击手段日新月异，使得防范工作变得异常复杂。常见的外部安全问题，如DDos攻击，它通过大量无效或高流量的网络请求来耗尽目标系统的资源，从而使其无法正常提供服务。内部安全问题同样具有极高的风险，比如业务数据、客户隐私数据泄露。这种泄露不仅可能让企业面临重大的法律责任和经济损失，还可能严重损害组织的声誉和客户关系。

以上就是影响数据库连续性的因素，企业进行数据库运维管理时，需要对这些潜在的风险因素进行有效的管理和控制。面对这些潜在风险，通常是通过生产变更管理、数据和服务冗余、可观察性建设、权限管控、安全加固等方式方法，来提升数据库连续性，确保企业生产系统能够为用户提供高效、可靠的服务。

05 总结

本文主要介绍了数据库连续性定义、重要性以及灾难恢复的国际标准和营销连续性重要因素。下篇文章，我们将讨论：提高数据库连续性企业能做什么、该怎么做，重点介绍生产变更管理、数据和服务冗余、可观察性建设、权限管控、安全加固等方法在业内的一些最 佳实践。有兴趣的朋友，欢迎关注本公众号、标记加星。

作者介绍

司马辽太杰，目前就职于一家国有企业，主要负责数据库连续性保障、性能优化、架构选型和设计。10余年数据库架构和管理经验，专注于数据库运维、架构和行业发展，擅长常见关系型、NoSQL、MPP 等类型数据库。杭州乡下桐庐人，业余热爱历史、足球，偶尔读点闲书。欢迎关注个人公众号“程序猿读历史”