关于《数据库服务能力成熟度模型》的内容和要求

近些年，随着人工智能、大数据、区块链等技术的兴起繁荣，应用对底层数据的要求越来越多样化，伴随企业日益增长的数据处理分析和丰富的应用场景需求，数据库技术不断发展创新，产品种类呈现多样化特征，技术生态呈现上云、开源、分布式的趋势。截止目前，信通院大数据产品的评测，针对于数据库产品目前已经累计达到70次，涵盖35家企业，从屏幕左下方可以看到全家福，其中包括53次功能测试和17次性能测试。全球数据库开源版本和商业版本的数量呈现接近1:1的态势，Gartner预测未来3年会有越来越多数据库跑在云平台上。

相对于产品，我们也看到了数据库服务的重要性在日益突显，数据库服务是围绕数据库的规划设计、实施部署、运维运营、优化提升等过程为核心的持续性服务，其目标满足需求方对于数据库产品选型、规划设计、实施部署、升级迁移、安全防护等方面的要求。

主要从两点可以感受到数据库服务重要性的日益突显，

首先是数据库服务的需求非常旺盛，随着企业在信息化建设、数字化转型的过程中，面临数据库的建设、改造、升级、迁移、整合的需求非常迫切，另外在公有云、混合云环境中多变形式下，数据库安全服务相比私有部署更加复杂。
其次，数据库运维服务得到不断重视，近年来数据库软件市场不断扩大，根据固定比例推算数据库运维市场也将随之增长。

数据库服务得到重视的原因也是我们看到行业内由于项目的前期规划、中期实施测试、后期运维、安全防护等重要环节未受到重视、操作过程不规范、管理制度不严格等因素导致项目失败、数据丢失甚至业务系统混乱的事件不断涌现，如何确保数据一致性、安全性、可用性成为数据库服务的重要挑战。

这里我们列举了三个失败案例：首先是服务承销商Salesforce丢失近5个小时客户数据，由于操作故障和缺乏容灾方案，并且这些数据是无法恢复。这些年针对于数据库迁移有一大血案，英国TSB银行由于缺乏前期规划和足够的回归测试，导致投入大量的人力财力后，新的业务系统上线仅20分钟就出现运行混乱，客户甚至可以看到别的客户存款，13亿客户记录出现问题，这给TSB银行带来了巨大的经济和声誉损失。此外，还有沃达丰CRM系统，由于流程不规范和人员持续违规的行为，导致数据库迁移失败。这些失败案例可以看出，国内数据库服务标准制定的迫切性是非常高的。

1、三大能力域

数据库服务能力框架由三个能力域，分别是：规划设计能力、实施部署能力和运维运营能力，这三个能力域一共有27个能力项，规划设计能力域包含8个能力项，实施部署能力包含7个能力项，运维运营能力包含12个能力项。

1.1、规划设计能力

考察一个数据库服务公司的规划设计能力，一共包含八大方面。

1.1.1、架构规划咨询

架构规划咨询主要指数据库服务方根据需求方的业务特性、业务要求及未来发展需求，对数据库类型及其它基础设施如服务器配置、存储、操作系统、集群架构等部分进行短期、中期、长期规划和设计。

在使用服务器或云服务时，帮助需求方选择合适的数据库类型，规划设计数据库架构体系，包括但不限于满足高可用需求、容灾需求、读写分离需求、双活需求、分库、分表、分区需求。

1.1.2、容灾备份规划

容灾备份规划主要指数据库服务方为确保用户数据的安全性，根据需求方的RTO、RPO等要求，结合用户的实际情况，设计符合用户要求的容灾架构和备份策略，当数据库系统发生软、硬件故障或机房遇到自然灾害时，既保证数据安全，也不中断业务或快速恢复业务。灾备根据业务等级，分为单机房灾备、本地同城灾备、两地三中心灾备等方式。

1.1.3、数据安全规划

数据安全规划主要指数据库服务方为确保用户的数据库、数据安全性，制定标准且可落地的数据库用户、口令、权限的设计规范作为新系统上线的安全管理基准参照。基于用户数据安全性和敏感性的要求，从防侵入、防窃取、防篡改、防泄漏、可追溯等多维度提供基于数据库的安全策略、安全软件、安全规范建议。

1.1.4、产品选型规划

产品选型规划是指数据库服务方根据需求方业务特性和用户的信息技术策略偏好，提供适合用户系统特色的数据库与平台的类型、版本、补丁选择，也可以向用户提供产品选型策略标准。

1.1.5、开发规范设计

开发规范设计主要指数据库服务方根据数据库特性与开发的相关性，从SQL代码编写、表设计、索引设计、其他数据库对象设计等多方面提供全面细致的开发规范指导，规范数据库需求方在业务系统开发过程中数据库的设计与开发，防范低效的数据库设计、低质量的结构化查询语言代码的出现，提升业务系统质量和开发效率。

1.1.6、数据库运维规范设计

数据库运维规范设计主要指数据库服务方根据数据库及业务系统特点，提供数据库标准化运维体系，如组织架构、管理流程、管理规范、变更管理流程等，保证系统长期、稳定、安全运行，强化数据库标准化管理，减少故障停机时间，在出现各类异常时有标准处理流程与处理方法可依。

1.1.7、数据模型物理化设计

数据模型物理化设计是指在开发部门完成业务模型、逻辑模型设计后，数据库服务方根据所选数据库的特性，结合各个逻辑模型的业务特性，如并发、读写、数据特征等，进行数据模型的物理化设计，确定其对应的表类型、索引设计等，从而获得高效持久的运行效率。

1.1.8、数据生命周期设计

数据生命周期设计是指数据库服务方根据数据的特质将数据归类，对不同性质的数据和不同生命周期的数据制定不同的数据生命周期管理办法。对持续增长的业务数据，根据数据特征和业务特征，提前规划出实现数据生命周期需求的表和数据处理方案，如归档、清理等。

1.2、实施部署能力

1.3、运维运营能力

2、评估对象

这个标准的评估对象是数据库服务提供商，它可以是传统数据库企业，也可以是提供数据库服务的云厂商，也可以是IT服务商。每个能力项划分为五个等级，分别是初始级、可重复级、稳健级、量化管理级、优化级。

参与评估的企业可以对三个能力域进行独立评估，也可以进行组合评估。服务提供方根据提供材料，由评估机构按照企业申请的评估类别以及对应的成熟度指标进行符合度的判别。

3、五大等级

以下这页内容可以看到对于五个等级的要求：从初始级，完成目标具有一定的偶然性，被动应答需求和问题的初始级，到具备一定经验和技术积累的可重复级，到具备一定知识库、流程和规章制度，保障目标达成成功率的量化管理级，到能够量化并能够监控服务过程中每一个环节，并且具备较高服务的工具和相对完备流程制度和方法论的量化管理级，以及最高级别，能够不断能够引入新的技术和理念，超预期达成目标，分享最佳实践成为行业标杆的优化级。

3.1、五大等级等展开说明：

初始级
在最原始的阶段，企业的数据库运维往往依靠于个人。个人的能力、水平直接影响运维效果。当出现问题时，人肉搞定。此时问题的解决，是没有总结积累、没有传承的。稍微好些的是，建立一套相对简单的处理流程。出现问题，可遵循此流程；但具体的处理方法是无章可循的。
可重复级
问题出现的多了，自然而然的想法是把常见的问题和解决记录下来，也就慢慢有了经验的传承（构建原始的知识体系）。加之之前的规范流程，就有了一套标准。当问题出现时，依据处理流程及处理方法，按图索骥即可。再进一步的，可以将这些解法可以脚本化、工具化，提高处理效率。
稳健级
当可重复级积累到一定阶段，就达到稳健级。此时构建的知识体系、流程、规范、制度已日趋完善。此时，是一个比较“自在”的阶段，如果没有大的目标，是可以小富即安了。
量化管理级
如再上一个台阶，就涉及到对服务的度量问题。因为只有达到可度量的状态，才可以不断提升，追求更高的管理目标。此外，也才有机会做到预测式管理，而非被动响应式。要想做到量化这一目标，是需要对数据库使用有着更高层次的认识。举个例子，如何评估你单位的数据库开发质量。为了达到这一目标，是需要你定义具体的指标及指标的评定标准，进而还需要通过系统、工具辅助完成指标的收集、管理、优化等工作。具有代表性的指标，甚至可以形成行业标准，指导其他企业的管理工作。
优化级
到了优化级别，不仅仅局限于提升数据库管理、使用水平，甚至可直接提升企业业务能力。其不在限于单一指标，而是提出新的概念，帮助从更多角度看待这一问题。甚至可以反馈产品，持续改进。对外，可以将已有内容形成行业通用化标准，引领行业的整体发展。

3.2、评估等级维度要求

从这页可以看到评估方法中对于五个等级的总领定义，为了使整个评估工作可信、透明和可追溯，对评估方法每一个能力项的编写均从这些维度进行要求，包含流程、制度、经验、方法、人员、技术、工具、交付物等。

流程
根据发展等级，从初始的针对个别问题的简单流程，到通用化、标准化；进而逐步完善、趋于完整；再到建立流程评估体系；最终形成不断迭代完善的流程。
制度
从没有制度，到有了简单制度保障，再到形成完善制度，制度实施评估等。
方法
从无到有，从个人经验，到经验传承；从知识库形成，到构建自有的方法论。
人员
从初、中、高级的人才梯队建设，到人员的能力培养体系的建立；从全面的人才，到专有化分工的人才配置；从简单的个人教授，到形成企业自有甚至行业标准的学习考察认证体系。
交付物
从无任何传承媒介，到文档的积累；从简单脚本到复杂工具、平台、系统；从单一处理型的工具，到收集、评估、预测、处理、优化等系统集合。从内部使用，到可输出外部等。

3.3、架构规划咨询能力的五级评估要求

以下是架构规划咨询能力的五级评估要求

初始级：
- 能力水平：
  - 服务提供方能够通过沟通等方式获取用户需求基本信息，并提取需要评估的信息；
  - 服务提供方能够提供评估工作需要的基本技术能力；
  - 服务提供方能够根据经验以及个人分析能力，针对部分架构规划完成评估，产出结果通常需要不断修正以满足项目需求。
- 评价标准：
  - 服务提供方能够通过沟通等方式获取用户需求基本信息，并提取需要评估的信息，形成需求评审文档；
  - 服务提供方拥有具备1年以上开发经验的数据库技术人员；
  - 服务提供方能够提供评估工作需要的基本技术能力，提供给用户需求评估输入参数文档；
  - 服务提供方能够根据经验以及个人分析能力，提供至少1种数据库部署架构的规划方案。
可重复级：
- 能力水平：
  - 服务提供方通过已有项目经验，通过信息搜集、用户案例分析等需求挖掘和分析手段定制化获取业务方架构规划方面的需求；
  - 服务提供方能够针对业务方需求提供定制化的架构规划方案；
  - 服务提供方能够依据用户需求制定对用户实际场景的架构规划详情和针对该业务方项目的评估方法和模型；
  - 服务提供方能够依据架构规划方案，完成对架构规划整体工作，产出规划报告。
- 评价标准：
  - 服务提供方通过已有项目经验，形成需求评审文档；
  - 服务提供方拥有具备2年以上开发经验的数据库技术人员；
  - 服务提供方能够提供容灾架构规划并提供规划文档；
  - 服务提供方提供定制化的架构规划方案。
稳健级：
- 能力水平：
  - 服务提供方根据在既有需求挖掘分析方案中，选择合适项目的方案获取用户对架构规划的需求；
  - 服务提供方根据既有架构规划方案中选择适合项目的方案，评估现状并制定具体的实施方案；
  - 服务提供方将项目中积累的经验抽象为过程持续改进既有架构规划方案。
- 评价标准：
  - 服务提供方拥有具备3年以上开发经验的数据库技术人员，并具备至少一次大型项目的架构设计经验；
  - 服务提供方能够提供高可用架构规划并提供规划文档；
  - 服务方提供架构规划实施落地的指导建议；
  - 服务提供方具备在高可用架构至少1个行业的成功案例。
量化管理级：
- 能力水平：
  - 服务提供方能够通过使用使用需求挖掘、需求分析方法获取用户需求中架构规划相关需求；
  - 服务提供方能够使用既定工具或方法论对架构规划过程中相关需求参数进行预估和量化；
  - 服务提供方在规划过程中能够监控客户需求变化对整个流程的影响，在需求变更的背景下依然可以高效完成项目。
- 评价标准：
  - 服务提供方拥有具备5年以上开发经验的数据库技术人员，并具备至少五次大型项目的架构设计经验；
  - 服务方提供架构规划实施落地的指导手册；
  - 服务提供方能够提供读写分离、数据库级双活架构规划；
  - 服务提供方具备在高可用、读写分离和数据库级双活架构三个方面共计至少3个行业的成功案例。（只提供一个维度也可以）
优化级：
- 能力水平：
  - 服务提供方能通过不断量化、优化自己的架构规划方法论以及流程管理方法，在行业内分享架构规划方案的最佳实践，成为行业标杆。
- 评价标准：
  - 服务提供方拥有具备开发经验的数据库技术专家，并具备至少十次大型项目的架构设计经验；
  - 服务提供方能够提供至少200个高可用、读写分离、应用级双活架构规划并提供规划文档；
  - 服务提供方具备在高可用、读写分离和应用级双活架构至少200个行业成功案例。（每种架构至少50个案例）

4、评估要点参考

4.1、规划设计域

4.1.1、架构规划咨询

架构规划，是数据库服务的重中之重。好的架构设计，不仅可以满足企业现状发展，还可满足未来一定阶段的发展要求。于此同时，还需要兼顾企业基础设施、运维能力、应用开发、财务成本、业务特征、风险评估等因素。

基础设施
在做架构规划时，需考虑企业自身基础设施现状及发展规划。包括但不限于服务器、存储、网络、安全等相关配套设施。如考虑云方案（公有云、私有云、混合云、跨云）等，还需要考虑云厂商的选择，是自建还是直接选择云数据库产品等等问题。基础设施，作为数据库的“底座”，其好坏对数据库的整体投产效果，非常重要。
运维能力
这里谈到的运维能力，包括软和硬两个方面。软的方面，主要是指人的情况（即自有人员的能力、结构、技术特点等）。硬的方面，则是指企业运维体系、平台等方面。
应用开发
企业现有的应用开发技术栈、开发模式、开发体系等。
财务成本
企业的财务状况、整体周期情况、主要财务考核指标（如ROI）等。
业务特征
行业、企业、业务特点，是否具有高增长性、不确定性、波动性等特征。企业现有所处阶段，及周期内会经历阶段。
风险评估
是否面临政策、法务、合规、监管类要求；是否有对数据一致性、业务连续性等的硬性要求。

评估要点： 这一能力域的考核标准更多是软的方面，例如人员资质、项目经验、行业经验等考察要点。服务方如在上述满足情况下，能够总结出发展趋势，能够前瞻性地指导企业架构规划，而非简单地解决具体问题，将会为企业带来更大价值，甚至改变企业初衷。

4.1.2、容灾备份规划

保证数据安全，是数据库的核心职能之一。容灾备份，正是为了满足这一要求。服务方需根据客户对RTO、RPO的具体要求，结合其自身情况，制定出符合要求的容灾架构和备份策略。在做这两方面设计之前，一般都需要对客户的业务应用做梳理，为后续制定不同的分级策略做好准备。

容灾架构
根据客户的容灾需求，可考虑单机房容灾、同城容灾、异地容灾、多中心容灾策略等。在技术方案上，可综合考虑应用级、系统级、数据库级、存储级等不同的容灾技术。
备份策略
备份策略上，一方面需要考虑客户的业务诉求，也需要考虑来自合规、监管类的要求。根据不同需求，建立其多层次的备份体系。此外，针对“多余”的这份数据，除了数据保护单一功能外，是否可带来更多附加价值也值得探索。

评估要点： 这一能力项更多是看中方案的成熟、稳定，特别是相关案例实践。毕竟容灾类的需求典型特点是，可能永远也用不到，但一旦启用绝不能出现问题。备份这块则更多强调在满足保护与成本间的平衡，重点考察的是方案的灵活性和成本收益的量化评估。

4.1.3、数据安全规划

数据安全，是数据库承载的又一核心职能。这里包括的内容较广，包括但不限于数据的生产、传输、存储、访问安全。安全问题涉及面很广泛，从基础设施（服务器、存储、网络）、系统（操作系统、应用系统、数据库系统）到开发规范、终端安全等。这是一个典型的木桶原理，即数据的安全性，取决于整体安全体系的最短那块板。因此，在制定数据安全规划时，不能仅仅局限于数据库端，要从全局角度去考虑。对于数据库本身来讲，从基本的用户、角色、权限划分，到数据的安全访问；从数据的加密存储，到数据的行列级访问权限；从数据的脱敏处理，到数据全生命周期的安全管控（审计等）。

评估要点： 这一能力项，强调基本安全能力的同时，更为强调全面性。除了从数据使用的方面考虑外，也包括了必要的制度、规范及实施策略等。

4.1.4、产品选型规划

在明确了架构规划后，这一步将要完成具体产品（包括平台、版本、补丁等）的选择。在选择时，需要细化之前架构阶段收集到的那些信息之外，还需要进一步收集用户的业务特征，为做好必要的选型测试（即POC）做好准备。
这一步的难点在于，如何构建符合客户真实需求的评测标准。常见通用的测试标准（如TPC组织系列），仅仅能代表通用性场景，对客户真实业务来说，不太具备参考意义。因此需制定有针对性的测试标准，包括常见的功能测试、性能测试、可用性测试、扩展性测试、应用开发适配、数据迁移、兼容性等。如果是采用云数据库，则还需考虑更多问题。

评估要点： 评估要点在于“切合度”。如何根据前面得到的信息选择最为适合的产品，并构建符合客户真实业务场景的选型测试来帮助客户完成这一步骤。针对客户需求的准确把握及对行业、业务特点的深刻理解，有助于完成这一过程。

4.1.5、开发规范设计

不同数据库，有其不同特点。如何发挥出数据库的最大效能，取决于如何根据其优劣点来设计结构、访问逻辑等。
开发规范设计正是根据数据库特性与开发的相关性，从SQL代码编写、表设计、索引设计、其他数据库对象设计等多方面提供全面细致的开发规范指导，规范数据库需求方在业务系统开发过程中数据库的设计与开发，防范低效的数据库设计、低质量的结构化查询语言代码的出现，提升业务系统质量和开发效率。

评估要点： 这一过程的难点在于，如何量化质量和效率。必要的工具、平台对落实规范，评估效果非常有好处。可以从事前、事中、事后，多个角度来进行评估，尽量将可能的风险降到最低。

4.1.6、数据库运维规范设计

评估要点： 规范好制定，落地是难点。既要保证不出问题，又要兼顾必要的效率。比较好的方式是工具平台化，如能有可量化角度看待则更优，甚至通过AIOps等新兴手段，则可进一步提高运维效率，规避风险。

4.1.7、数据模型物理化设计

评估要点： 如何确保物理模型符合预期，测试是必要的环节之一。能通过对客户业务的抽取提炼，将其核心逻辑描绘为数据库语言，进而验证模式是否符合预期。此处难点在于对业务提取和抽取能力。

4.1.8、数据生命周期设计

这一能力项，也是我个人觉得服务方做的不太好的地方。数据生命周期，是指针对数据的产生、应用、消亡的整个过程进行顶层设计。根据业务特点、增长速度等，制定对应的扩展性设计（满足数据产生要求）、数据分层设计（满足对热、温、冷数据）不同访问特点的设计、数据消亡（包括数据归档、压缩、转储、清理等）。

评估要点： 从业务特点，抽象出数据特点，帮助用户建立起从端到端的概念。

4.2、实施部署域

4.2.1、单机部署

单机部署能力，包括具体部署方案、实施计划、测试验证方案等内容。包括但不限于基础环境（硬件、软件）检查与准备、数据库系统安装、初始化配置、安全加固、部署验证、组件集成、测试评估、交付上线等环节。这其中有几个容易忽视的点：

基础环境检查与准备
各个客户环境千差万别，如何适配差异化环境，前期的检查准备工作很重要。其中包括对硬件的检查、基准性能测试（为后期验收测试做准备）、软件系统版本（含补丁）等情况做好摸底。与数据库软件的预安装条件进行对比，判断是否满足基本条件。与客户充分沟通，了解第一手的环境情况。
安全加固
在部署完毕、初始化配置完成后，需要做好必要的安全加固工作。将安全基础工作做到上线之前，尽量减少可能的风险问题。
组件集成
数据库不是孤立系统，是需要与客户方的其他系统一起组成基础平台。这里面可能包括客户方的监控系统、日志系统、安全系统、审计系统、备份系统、大数据平台、资源管理平台、数据中台等等。在交付上线之前，要做好与这些系统的对接。这些工作非常琐碎，但非常有必要。这一工作是否顺利，取决于前期对客户系统的调研是否完备？客户方（或第三方）配合是否默契等
测试评估
在做好上述准备工作后，交付上线之前还需要做好测试评估工作。这一步骤包括功能测试、性能测试、异常测试等。通过这一过程，让客户对新上系统有个全面的认识。
交付上线
测试通过后，择期对客户交付上线，正式将系统由客户方接管。一般建议有个过渡期，帮助用户逐步熟悉掌握。
对于云端环境，上述过程又有所不同。相对而言，云端环境比较标准，工作也会少些。

评估要点： 这一能力项，强调过程的完备、详实程度。一方面这与具体参与人员的能力有关，另一方面与实施过的项目积累经验有关。特别是对于前期、后期的工作更是如此。

4.2.2、集群部署

集群部署，与单机部署大致步骤相同。特殊之处在于集群环境，是多机构成，因此对网络要求更高，必要的前期测试一定要进行。此外，集群是整体发挥作用，集群内各组件之间的配合很重要，因此对调试安装的要求更高。

评估要点： 同“单机配置”

4.2.3、容灾架构部署

容灾架构部署，要比前两者更为复杂。具体部署难度，取决于多种因素，包括技术方案、容灾环境等。不同的容灾方案，带来的实施难度不同，之前谈到的容灾架构可能包括在应用级、系统级、数据库级、存储级等多种情况，可能涉及多方的配合，不仅仅单指数据库单系统。最终的容灾效果，也是取决于多方的配合情况。至于容灾环境，因容灾涉及到多个环境，可能包括同城单机房、同城多机房、异地多机房等情况。特别是对网络质量，要求很高，需要做对应测试，这是前提。此外，部署后的测试工作对于容灾也很重要。如何真实验证出容灾效果？对数据一致性会带来什么影响？如何回切等问题都需要考虑。最终给客户提交的，不仅是容灾环境，还包括必要的切换文档、演练文档、测试报告等。

评估要点： 要点在于对容灾核心需求的满足程度，这是要与客户有充分的沟通，得到一手的需求，设计出适合的系统。此外，与多方协同配合、测试验证演练也是必不可少的部分。

4.2.4、同步架构设计与部署

同步架构，与容灾有些类似，也是对多个环境的部署，差异在于需求为数据同步。需要关注点也与前者类似，涉及同步方案的不同所带来的差异。这里需关注两点：一是同步效果的评估，二是对源端系统的影响。这两方面是需要单独评估设计的。

评估要点： 类似上面，关注点在同步需求的满足程度及多方配合。

4.2.5、数据库迁移

数据库迁移，情况比较复杂，差异在于迁移目的、迁移目标和技术方案等。这里面包含的两种情况：

同构迁移
迁移前后的数据库相同。此时只要完成数据迁移即可，一般结构、应用等不需要修改。这种情况相对简单。常见的比如更换硬件等需求。
异构迁移
迁移前后的数据库不同，这种情况要复杂很多。一般除了数据迁移外，还包括结构迁移、应用改造、迁移验证等问题。如果迁移前后的数据库架构有大的差异，例如从单机到分布式等，则需要改造的内容更多。
迁移还有几个重要问题：迁移是在线还是离线？对时间窗口如何定义？如何做数据一致性验证？如何对迁移前后的应用功能、性能进行验证等问题？上述问题，均需要在方案中体现。这部分内容会很多，不展开了，可参考我之前写的一篇文章《如何做一次完美的数据库迁移》

评估要点： 方案的全面性，特别是迁移中、迁移后的评估等工作，上述甚至可占到总工作一半以上的内容。

4.2.6、数据库升级

数据库升级，一般可分为原地升级、异地升级两种。前者相对简单，主要问题在于升级影响、时长、回退方案等问题。后者来说，更为复杂些，有点类似于迁移流程，这里不展开了。

评估要点： 方案的全面性

4.2.7、数据库整合

数据库整合，一般是从资源角度考虑，重点需要评估整合后资源是否满足需要？有无业务风险等问题。必要时，整合方案之前加入测试工作。

评估要点： 方案的全面性

4.3、运维运营域

人生基本上就是两件事，选题和解题。最好的人生是在每个关键点上，既选对题，又解好题。人生最大的痛苦在于解对了题，但选错了题，而且还不知道自己选错了题。正如人生最大的遗憾就是，不是你不行，而是你本可以。

4.3.1、基础运维

基础运维，包含的内容比较繁杂。重点在于标准化、规范化，即数据库的产品化能力是否成熟，是否通过文档、系统提供出来。而不是仅通过黑盒的方式提供，这对于用户使用来说意义重大。除了常规的操作外，是否提供了开放能力，方便用户通过自有平台运维也很重要，特别是对于中大规模的企业而言。

评估要点： 标准化、规范化、文档化、平台化

4.3.2、云化运维

云化运维，重点是在于对云端资源的管理、安全及开放能力。

评估要点：成熟度

4.3.3、数据库监控

数据库监控，对于数据库稳定运行非常重要。监控的主要问题是几个方面：

指标全面性
指标覆盖能否全面，能监控到数据库的方方面面，包括但不限于实例级、对象级、语句级等。
报警可收敛
过多的指标监控，只会造成报警风暴，如何做到报警收敛，突出核心重点，也是监控一个要点。
开放集成性
可很方便的将数据库监控与客户其他报警平台集成，形成统一整体，进而可实现报警的联动，从基础设施、到系统、数据库、应用直至业务。以此可实现报警问题溯源，方便定位追查问题。

评估要点： 成熟度、全面性、扩展性、集成能力

4.3.4、健康检查

也就是我们常说的巡检，通过这一能力可对数据库的当前运行状态有所了解，对可能出现的问题做到提前预警、提前处理。当然，现在巡检形式也在发生变化，很多健康检查的工作融合到数据库内部或平台自身能力中。可在日常运行中，随时发现问题。特别是近些年来，在AIOps上的探索，也对健康检查带来一些新的思路。

评估要点： 全面性、前瞻性

4.3.5、SQL审核

SQL审核，对保证数据库应用质量、保证安全运行很重要，之前在这方面的重视程度不足，近些年来得到了广泛的关注。很多公司自研自己的审核平台，也有一些开源的方案，商业产品中也纷纷增强了这一能力。在功能上，包括结构级、语句级、执行特征等。这项工作一般通过平台完成，可以采用半自动、自动的方式进行，可大幅解放DBA的日常工作。这部分常见的问题是SQL审核的智能化程度、对多数据源的支持、对事前、事中、事后的全流程支持等。

评估要点： 平台化、智能化、可量化

4.3.6、备份恢复

备份恢复，是保证数据安全的最后一道防线。功能上除了常规的备份配置、作业监控外，更重要的是恢复验证、备份集的管理。一方面在备份有效性上的增强，一方面是成本与代价间取得平衡，满足数据安全需求的同时，减少客户成本支出。此外，还可以进一步挖掘其潜在能力，例如对开发支持、准生产验证、审计要求等的满足。

评估要点： 平台化、成本收益

4.3.7、安全审计

安全审计，功能要点在于全面性、详实可信且兼顾成本。这方面主要是满足合规性的要求，防患可能的风险。

评估要点： 全面性

4.3.8、应急方案演练

应急演练，之前往往重视程度不够，很多公司从未进行过应急演练。很多应急方案都存在文档中，束之高阁。但出现紧急情况时，应急方案反而不适应现状无法使用，失去了最本质的意义。因此这块的要点，是保证应急方案与系统环境的适应匹配，保持最新的状态。次之，则是尽量通过平台化能力（而非文档化），将应急方案沉淀下来，这有助于应急响应的时效性和有效性。应急演练往往不是单一系统的，需要联合基础设施、数据库、应用系统、业务部分等多方，协同完成。现在也有专门针对应急需求的产品出现，可配置多种资源协同完成应急演练。

评估要点： 有效性、时效性、可协同

4.3.9、培训

培训，是提高数据库产品使用效果，最为有效的手段之一。通过提升客户方能力，可有效提升使用效果，相较而言服务方投入也不大。培训重点在于摸清客户需求，有针对性提出培训方案，可满足客户从基础运维、架构设计、应用开发、性能优化等多种角度的培训需求。此外，具有一定影响力的产品，还可通过建立认证体系等方式，将培训从单一客户、开放到普通用户甚至学生等群体，构建自己的用户生态。

评估要点： 标准化、定制化

4.3.10、性能优化

性能，几乎是所有客户的要求，很多问题最后都归结为性能问题。针对性能的优化工作，是个较为复杂的问题。可包括数据库自身、基础环境、生态工具、架构设计、开发优化等多方面。要想从全局的角度审视性能问题，是比较困难的，可以借助一些APM工具。针对数据库服务方而言，一般还是局限在数据库自身性能、SQL语句优化等方面。建议采取的措施是日常收集性能基线数据，当出现问题时可对比分析，快速诊断，并给出优化建议。此外，针对客户进行必要的优化培训，也是有帮助的。上述优化工作，可通过工具、平台来完成，提高整体优化效率。甚至有的有实力的厂商，提供自治优化的能力，通过人工智能+知识库的结合，帮助客户实现自动优化。

评估要点： 优化评估方法、工具、平台

4.3.11、模型优化

模型优化，往往是较容易忽视的一点。这里所说是模型，可能包括业务模型、逻辑模型、物理模型，对数据库服务商来说，一般会局限在物理模型阶段。当然，如果对业务模型、逻辑模型有认识，会对客户带来更大价值，但这两点需要对业务有较为深入的理解。针对模型的优化，是有固定的方法论的，可通过知识库、文档、平台沉淀下来。

评估要点： 模型方法论

4.3.12、数据生命周期管理

数据生命周期管理，是对客户数据实现全流程的管理。从数据产生、使用、归档到销毁多个阶段的管理。这一能力，一般是通过平台来完成这些管理动作。相对而言，这方面的成熟经验不多。

评估要点： 方法论、成熟平台

5、证书范例

云和恩墨作为首批参与《数据库服务能力成熟度模型》评估的企业，最终顺利通过三大能力域的等级评估。其中“规划设计”和“运维运营”专项获得最高的五级评估，“实施部署”专项获得四级评估，这代表着云和恩墨在数据库服务领域已达到国内领先水平。

以下是三大证书，作为示范：

6、未来工作方向

未来数据库服务主要有四个方向：

第一个方向，信通院针对数据库服务能力将举行系列线上沙龙。
7月14号举办了第一场迁移的沙龙，主题是“数据库及应用系统迁移”。我们也知道，现在数据库迁移是当前数据库行业的一大热点，迁移如何保持数据的一致性、可用性，包括如何高效评估迁移项目的成本、周期、改造量，都是非常大的挑战，信通院从年初联合了11家企业，共同编写了《数据库及应用系统迁移指南》研究报告，在本次沙龙上进行了报告内容的详细介绍。同时也邀请了三家企业，分别是中兴、阿里云、云和恩墨的专家，进行经验和实践的分享。
第二个方向，细分行业特征，开展评估工作。
第三个方向，我们会不断优化评估模型和评估方法，持续评估企业的数据库服务能力，并构建服务方的能力图谱。8月即将开展预评估工作，欢迎企业参与。
第四个方向，未来针对数据库服务能力建立知识库。

参考文献：

国内首家最高等级：云和恩墨通过信通院数据库服务能力评估 https://www.modb.pro/db/42687
数据库服务能力成熟度模型标准介绍 https://www.databench.cn
解读《数据库服务能力成熟度模型》https://www.modb.pro/db/38006
星环科技通过数据库服务能力成熟度模型评估 https://www.modb.pro/db/47964

服务数据库

最后修改时间：2021-05-07 10:42:19

「喜欢这篇文章，您的关注和赞赏是给作者最好的鼓励」

关注作者