解读《数据库服务能力成熟度模型》

数据库，作为企业重要IT基础设施之一，在数字化中扮演着重要的角色。

其是否运行平稳、是否处于最佳状态、是否可方便的扩展等，进而是否能满足业务现状及未来发展，这些对于企业至关重要。

要达到上述目标，取决于两个方面：数据库产品自身能力、数据库服务能力。

可以说“产品+服务”，决定了最终的结果如何。

但在很长一段时间里，对于前者（产品）有很多手段去了解、评估；但对于后者（服务）却少有有效的衡量方法。

在过去的三、四十年里，传统数据库市场主要是以国外大型商业数据库为主，其服务能力经过多年积累已相对成熟、完善，并构建起一整套标准及相应的配套服务团队。

但随着近些年来数据库市场有了明显的变化，一是以开源为主导数据库方案在很多公司得以使用；二是国产数据库也层出不穷，并愈发呈现蓬勃发展之势；三是分布式、云化技术特点为代表的新数据库形态逐步被人认知并投入使用。

针对这种新的变化，过去按单一产品作为衡量标准就不太合适，急需一种通用的行业标准来度量数据库服务能力。

近期，信通院发表的《数据库服务能力成熟度模型》，由此应运而生。

它的推出，有助于企业决策者，找到数据库服务重点，获取当前数据库整体现状，识别其中的不足并找准关键问题及差异，进而提供数据库服务能力的改进方向和意见，规划企业未来的数据库发展蓝图。

本文根据之前信通院发表的《数据库服务能力成熟度》为基础，加以个人的一些理解分析。

当前这一标准，正处于规范发布阶段，其具体细节和评价方式、标准还有待落实，也希望更多数据库从业者参与其中。

为提高国内数据库整体服务质量，贡献自己的一份力量。

本文部分内容引用信通院发布《数据库服务能力成熟度》报告及网名“失速的脑细胞”的一篇文章。

原文参考：/p/d672951c5c1a1. 成熟度模型概述人生基本上就是两件事，选题和解题。

最好的人生是在每个关键点上，既选对题，又解好题。

人生最大的痛苦在于解对了题，但选错了题，而且还不知道自己选错了题。

正如人生最大的遗憾就是，不是你不行，而是你本可以。

1).评估标准：能力框架与能力域此次发布的数据库服务成熟度模型，将能力框架划分为三个能力域，分别是：规划设计能力、实施部署能力和运维运营能力。

其可对应到数据库从选型评估、规划设计、部署实施、运维保障、开发优化等多个方面。

在三个能力域内，又进一步划分为27个能力项，其中规划设计能力域包含8个能力项，实施部署能力包含7个能力项，运维运营能力包含12个能力项。

具体可参考下图：2).评估对象：服务方和使用者此模型的评估对象，既可以是数据库服务提供商、也可以是数据库云厂商；甚至是数据库产品的使用者。

前者作为数据库服务的提供者，此模型是可以作为甲方选择服务者的一种参考依据。

后者作为数据库用户自身，也可以作为评估自身的技术能力的有效抓手。

3).评估标准：能力等级划分在评估标准上，模型提出了五个等级，分别是初始级、可重复级、稳健级、量化管理级、优化级，其能力等级依次递进。

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

其实上面能力等级划分，很容易映射到企业数据库管理阶段的发展。

•初始级在最原始的阶段，企业的数据库运维往往依靠于个人。

个人的能力、水平直接影响运维效果。

当出现问题时，人肉搞定。

此时问题的解决，是没有总结积累、没有传承的。

稍微好些的是，建立一套相对简单的处理流程。

出现问题，可遵循此流程；但具体的处理方法是无章可循的。

•可重复级问题出现的多了，自然而然的想法是把常见的问题和解决记录下来，也就慢慢有了经验的传承（构建原始的知识体系）。

加之之前的规范流程，就有了一套标准。

当问题出现时，依据处理流程及处理方法，按图索骥即可。

再进一步的，可以将这些解法可以脚本化、工具化，提高处理效率。

•稳健级当可重复级积累到一定阶段，就达到稳健级。

此时构建的知识体系、流程、规范、制度已日趋完善。

此时，是一个比较“自在”的阶段，如果没有大的目标，是可以小富即安了。

•量化管理级如再上一个台阶，就涉及到对服务的度量问题。

因为只有达到可度量的状态，才可以不断提升，追求更高的管理目标。

此外，也才有机会做到预测式管理，而非被动响应式。

要想做到量化这一目标，是需要对数据库使用有着更高层次的认识。

举个例子，如何评估你单位的数据库开发质量。

为了达到这一目标，是需要你定义具体的指标及指标的评定标准，进而还需要通过系统、工具辅助完成指标的收集、管理、优化等工作。

具有代表性的指标，甚至可以形成行业标准，指导其他企业的管理工作。

•优化级到了优化级别，不仅仅局限于提升数据库管理、使用水平，甚至可直接提升企业业务能力。

其不在限于单一指标，而是提出新的概念，帮助从更多角度看待这一问题。

甚至可以反馈产品，持续改进。

对外，可以将已有内容形成行业通用化标准，引领行业的整体发展。

4).评估维度：流程+制度+方法+人员+交付物•流程根据发展等级，从初始的针对个别问题的简单流程，到通用化、标准化；进而逐步完善、趋于完整；再到建立流程评估体系；最终形成不断迭代完善的流程。

•制度从没有制度，到有了简单制度保障，再到形成完善制度，制度实施评估等。

•方法从无到有，从个人经验，到经验传承；从知识库形成，到构建自有的方法论。

•人员从初、中、高级的人才梯队建设，到人员的能力培养体系的建立；从全面的人才，到专有化分工的人才配置；从简单的个人教授，到形成企业自有甚至行业标准的学习考察认证体系。

•交付物从无任何传承媒介，到文档的积累；从简单脚本到复杂工具、平台、系统；从单一处理型的工具，到收集、评估、预测、处理、优化等系统集合。

从内部使用，到可输出外部等。

2. 规划设计域人生基本上就是两件事，选题和解题。

最好的人生是在每个关键点上，既选对题，又解好题。

人生最大的痛苦在于解对了题，但选错了题，而且还不知道自己选错了题。

正如人生最大的遗憾就是，不是你不行，而是你本可以。

1).架构规划咨询架构规划，是数据库服务的重中之重。

好的架构设计，不仅可以满足企业现状发展，还可满足未来一定阶段的发展要求。

于此同时，还需要兼顾企业基础设施、运维能力、应用开发、财务成本、业务特征、风险评估等因素。

•基础设施在做架构规划时，需考虑企业自身基础设施现状及发展规划。

包括但不限于服务器、存储、网络、安全等相关配套设施。

如考虑云方案（公有云、私有云、混合云、跨云）等，还需要考虑云厂商的选择，是自建还是直接选择云数据库产品等等问题。

基础设施，作为数据库的“底座”，其好坏对数据库的整体投产效果，非常重要。

•运维能力这里谈到的运维能力，包括软和硬两个方面。

软的方面，主要是指人的情况（即自有人员的能力、结构、技术特点等）。

硬的方面，则是指企业运维体系、平台等方面。

•应用开发企业现有的应用开发技术栈、开发模式、开发体系等。

•财务成本企业的财务状况、整体周期情况、主要财务考核指标（如ROI）等。

•业务特征行业、企业、业务特点，是否具有高增长性、不确定性、波动性等特征。

企业现有所处阶段，及周期内会经历阶段。

•风险评估是否面临政策、法务、合规、监管类要求；是否有对数据一致性、业务连续性等的硬性要求。

评估要点：这一能力域的考核标准更多是软的方面，例如人员资质、项目经验、行业经验等考察要点。

服务方如在上述满足情况下，能够总结出发展趋势，能够前瞻性地指导企业架构规划，而非简单地解决具体问题，将会为企业带来更大价值，甚至改变企业初衷。

2).容灾备份规划保证数据安全，是数据库的核心职能之一。

容灾备份，正是为了满足这一要求。

服务方需根据客户对RTO、RPO的具体要求，结合其自身情况，制定出符合要求的容灾架构和备份策略。

在做这两方面设计之前，一般都需要对客户的业务应用做梳理，为后续制定不同的分级策略做好准备。

•容灾架构根据客户的容灾需求，可考虑单机房容灾、同城容灾、异地容灾、多中心容灾策略等。

在技术方案上，可综合考虑应用级、系统级、数据库级、存储级等不同的容灾技术。

•备份策略备份策略上，一方面需要考虑客户的业务诉求，也需要考虑来自合规、监管类的要求。

根据不同需求，建立其多层次的备份体系。

此外，针对“多余”的这份数据，除了数据保护单一功能外，是否可带来更多附加价值也值得探索。

评估要点：这一能力项更多是看中方案的成熟、稳定，特别是相关案例实践。

毕竟容灾类的需求典型特点是，可能永远也用不到，但一旦启用绝不能出现问题。

备份这块则更多强调在满足保护与成本间的平衡，重点考察的是方案的灵活性和成本收益的量化评估。

3).数据安全规划数据安全，是数据库承载的又一核心职能。

这里包括的内容较广，包括但不限于数据的生产、传输、存储、访问安全。

安全问题涉及面很广泛，从基础设施（服务器、存储、网络）、系统（操作系统、应用系统、数据库系统）到开发规范、终端安全等。

这是一个典型的木桶原理，即数据的安全性，取决于整体安全体系的最短那块板。

因此，在制定数据安全规划时，不能仅仅局限于数据库端，要从全局角度去考虑。

对于数据库本身来讲，从基本的用户、角色、权限划分，到数据的安全访问；从数据的加密存储，到数据的行列级访问权限；从数据的脱敏处理，到数据全生命周期的安全管控（审计等）。

评估要点：这一能力项，强调基本安全能力的同时，更为强调全面性。

除了从数据使用的方面考虑外，也包括了必要的制度、规范及实施策略等。

4).产品选型规划在明确了架构规划后，这一步将要完成具体产品（包括平台、版本、补丁等）的选择。

在选择时，需要细化之前架构阶段收集到的那些信息之外，还需要进一步收集用户的业务特征，为做好必要的选型测试（即POC）做好准备。

这一步的难点在于，如何构建符合客户真实需求的评测标准。

常见通用的测试标准（如TPC组织系列），仅仅能代表通用性场景，对客户真实业务来说，不太具备参考意义。

因此需制定有针对性的测试标准，包括常见的功能测试、性能测试、可用性测试、扩展性测试、应用开发适配、数据迁移、兼容性等。

如果是采用云数据库，则还需考虑更多问题。

评估要点：评估要点在于“切合度”。

如何根据前面得到的信息选择最为适合的产品，并构建符合客户真实业务场景的选型测试来帮助客户完成这一步骤。

针对客户需求的准确把握及对行业、业务特点的深刻理解，有助于完成这一过程。

5).开发规范设计不同数据库，有其不同特点。

如何发挥出数据库的最大效能，取决于如何根据其优劣点来设计结构、访问逻辑等。

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