数据库，作为企业重要IT基础设施之一，在数字化中扮演着重要的角色。其是否运行平稳、是否处于最佳状态、是否可方便的扩展等，进而是否能满足业务现状及未来发展，这些对于企业至关重要。要达到上述目标，取决于两个方面：数据库产品自身能力、数据库服务能力。可以说“产品+服务”，决定了最终的结果如何。但在很长一段时间里，对于前者（产品）有很多手段去了解、评估；但对于后者（服务）却少有有效的衡量方法。在过去的三、四十年里，传统数据库市场主要是以国外大型商业数据库为主，其服务能力经过多年积累已相对成熟、完善，并构建起一整套标准及相应的配套服务团队。但随着近些年来数据库市场有了明显的变化，一是以开源为主导数据库方案在很多公司得以使用；二是国产数据库也层出不穷，并愈发呈现蓬勃发展之势；三是分布式、云化技术特点为代表的新数据库形态逐步被人认知并投入使用。针对这种新的变化，过去按单一产品作为衡量标准就不太合适，急需一种通用的行业标准来度量数据库服务能力。
近期，信通院发表的《数据库服务能力成熟度模型》，由此应运而生。它的推出，有助于企业决策者，找到数据库服务重点，获取当前数据库整体现状，识别其中的不足并找准关键问题及差异，进而提供数据库服务能力的改进方向和意见，规划企业未来的数据库发展蓝图。本文根据之前信通院发表的《数据库服务能力成熟度》为基础，加以个人的一些理解分析。当前这一标准，正处于规范发布阶段，其具体细节和评价方式、标准还有待落实，也希望更多数据库从业者参与其中。为提高国内数据库整体服务质量，贡献自己的一份力量。本文部分内容引用信通院发布《数据库服务能力成熟度》报告及网名“失速的脑细胞”的一篇文章。
此次发布的数据库服务成熟度模型，将能力框架划分为三个能力域，分别是：规划设计能力、实施部署能力和运维运营能力。其可对应到数据库从选型评估、规划设计、部署实施、运维保障、开发优化等多个方面。在三个能力域内，又进一步划分为27个能力项，其中规划设计能力域包含8个能力项，实施部署能力包含7个能力项，运维运营能力包含12个能力项。具体可参考下图：
2).评估对象：服务方和使用者
此模型的评估对象，既可以是数据库服务提供商、也可以是数据库云厂商；甚至是数据库产品的使用者。前者作为数据库服务的提供者，此模型是可以作为甲方选择服务者的一种参考依据。后者作为数据库用户自身，也可以作为评估自身的技术能力的有效抓手。
3).评估标准：能力等级划分
在评估标准上，模型提出了五个等级，分别是初始级、可重复级、稳健级、量化管理级、优化级，其能力等级依次递进。从初始级，完成目标具有一定的偶然性，被动应答需求和问题的初始级；到具备一定经验和技术积累的可重复级；到具备知识库、流程和规章制度，保障目标达成成功率的稳健级；到能够量化并能够监控服务过程中每一个环节，并且具备较高服务的工具和相对完备流程制度和方法论的量化管理级，以及最高级别，能够不断能够引入新的技术和理念，超预期达成目标，分享最佳实践成为行业标杆的优化级。
其实上面能力等级划分，很容易映射到企业数据库管理阶段的发展。
- 初始级在最原始的阶段，企业的数据库运维往往依靠于个人。个人的能力、水平直接影响运维效果。当出现问题时，人肉搞定。此时问题的解决，是没有总结积累、没有传承的。稍微好些的是，建立一套相对简单的处理流程。出现问题，可遵循此流程；但具体的处理方法是无章可循的。
- 可重复级问题出现的多了，自然而然的想法是把常见的问题和解决记录下来，也就慢慢有了经验的传承（构建原始的知识体系）。加之之前的规范流程，就有了一套标准。当问题出现时，依据处理流程及处理方法，按图索骥即可。再进一步的，可以将这些解法可以脚本化、工具化，提高处理效率。
- 稳健级当可重复级积累到一定阶段，就达到稳健级。此时构建的知识体系、流程、规范、制度已日趋完善。此时，是一个比较“自在”的阶段，如果没有大的目标，是可以小富即安了。
- 量化管理级如再上一个台阶，就涉及到对服务的度量问题。因为只有达到可度量的状态，才可以不断提升，追求更高的管理目标。此外，也才有机会做到预测式管理，而非被动响应式。要想做到量化这一目标，是需要对数据库使用有着更高层次的认识。举个例子，如何评估你单位的数据库开发质量。为了达到这一目标，是需要你定义具体的指标及指标的评定标准，进而还需要通过系统、工具辅助完成指标的收集、管理、优化等工作。具有代表性的指标，甚至可以形成行业标准，指导其他企业的管理工作。
- 优化级到了优化级别，不仅仅局限于提升数据库管理、使用水平，甚至可直接提升企业业务能力。其不在限于单一指标，而是提出新的概念，帮助从更多角度看待这一问题。甚至可以反馈产品，持续改进。对外，可以将已有内容形成行业通用化标准，引领行业的整体发展。
4).评估维度：流程+制度+方法+人员+交付物
- 流程根据发展等级，从初始的针对个别问题的简单流程，到通用化、标准化；进而逐步完善、趋于完整；再到建立流程评估体系；最终形成不断迭代完善的流程。
- 制度从没有制度，到有了简单制度保障，再到形成完善制度，制度实施评估等。
- 方法从无到有，从个人经验，到经验传承；从知识库形成，到构建自有的方法论。
- 人员从初、中、高级的人才梯队建设，到人员的能力培养体系的建立；从全面的人才，到专有化分工的人才配置；从简单的个人教授，到形成企业自有甚至行业标准的学习考察认证体系。
- 交付物从无任何传承媒介，到文档的积累；从简单脚本到复杂工具、平台、系统；从单一处理型的工具，到收集、评估、预测、处理、优化等系统集合。从内部使用，到可输出外部等。
架构规划，是数据库服务的重中之重。好的架构设计，不仅可以满足企业现状发展，还可满足未来一定阶段的发展要求。于此同时，还需要兼顾企业基础设施、运维能力、应用开发、财务成本、业务特征、风险评估等因素。
- 基础设施在做架构规划时，需考虑企业自身基础设施现状及发展规划。包括但不限于服务器、存储、网络、安全等相关配套设施。如考虑云方案（公有云、私有云、混合云、跨云）等，还需要考虑云厂商的选择，是自建还是直接选择云数据库产品等等问题。基础设施，作为数据库的“底座”，其好坏对数据库的整体投产效果，非常重要。
- 运维能力这里谈到的运维能力，包括软和硬两个方面。软的方面，主要是指人的情况（即自有人员的能力、结构、技术特点等）。硬的方面，则是指企业运维体系、平台等方面。
- 应用开发企业现有的应用开发技术栈、开发模式、开发体系等。
- 财务成本企业的财务状况、整体周期情况、主要财务考核指标（如ROI）等。
- 业务特征行业、企业、业务特点，是否具有高增长性、不确定性、波动性等特征。企业现有所处阶段，及周期内会经历阶段。
- 风险评估是否面临政策、法务、合规、监管类要求；是否有对数据一致性、业务连续性等的硬性要求。
评估要点：这一能力域的考核标准更多是软的方面，例如人员资质、项目经验、行业经验等考察要点。服务方如在上述满足情况下，能够总结出发展趋势，能够前瞻性地指导企业架构规划，而非简单地解决具体问题，将会为企业带来更大价值，甚至改变企业初衷。
保证数据安全，是数据库的核心职能之一。容灾备份，正是为了满足这一要求。服务方需根据客户对RTO、RPO的具体要求，结合其自身情况，制定出符合要求的容灾架构和备份策略。在做这两方面设计之前，一般都需要对客户的业务应用做梳理，为后续制定不同的分级策略做好准备。
- 容灾架构根据客户的容灾需求，可考虑单机房容灾、同城容灾、异地容灾、多中心容灾策略等。在技术方案上，可综合考虑应用级、系统级、数据库级、存储级等不同的容灾技术。
- 备份策略备份策略上，一方面需要考虑客户的业务诉求，也需要考虑来自合规、监管类的要求。根据不同需求，建立其多层次的备份体系。此外，针对“多余”的这份数据，除了数据保护单一功能外，是否可带来更多附加价值也值得探索。
评估要点：这一能力项更多是看中方案的成熟、稳定，特别是相关案例实践。毕竟容灾类的需求典型特点是，可能永远也用不到，但一旦启用绝不
能出现问题。备份这块则更多强调在满足保护与成本间的平衡，重点考察的是方案的灵活性和成本收益的量化评估。
3).数据安全规划
数据安全，是数据库承载的又一核心职能。这里包括的内容较广，包括但不限于数据的生产、传输、存储、访问安全。安全问题涉及面很广泛，从基础设施（服务器、存储、网络）、系统（操作系统、应用系统、数据库系统）到开发规范、终端安全等。这是一个典型的木桶原理，即数据的安全性，取决于整体安全体系的最短那块板。因此，在制定数据安全规划时，不能仅仅局限于数据库端，要从全局角度去考虑。对于数据库本身来讲，从基本的用户、角色、权限划分，到数据的安全访问；从数据的加密存储，到数据的行列级访问权限；从数据的脱敏处理，到数据全生命周期的安全管控（审计等）。
评估要点：这一能力项，强调基本安全能力的同时，更为强调全面性。除了从数据使用的方面考虑外，也包括了必要的制度、规范及实施策略等。
在明确了架构规划后，这一步将要完成具体产品（包括平台、版本、补丁等）的选择。在选择时，需要细化之前架构阶段收集到的那些信息之外，还需要进一步收集用户的业务特征，为做好必要的选型测试（即POC）做好准备。这一步的难点在于，如何构建符合客户真实需求的评测标准。常见通用的测试标准（如TPC组织系列），仅仅能代表通用性场景，对客户真实业务来说，不太具备参考意义。因此需制定有针对性的测试标准，包括常见的功能测试、性能测试、可用性测试、扩展性测试、应用开发适配、数据迁移、兼容性等。如果是采用云数据库，则还需考虑更多问题。评估要点：评估要点在于“切合度”。如何根据前面得到的信息选择最为适合的产品，并构建符合客户真实业务场景的选型测试来帮助客户完成这一步骤。针对客户需求的准确把握及对行业、业务特点的深刻理解，有助于完成这一过程。
5).开发规范设计
不同数据库，有其不同特点。如何发挥出数据库的最大效能，取决于如何根据其优劣点来设计结构、访问逻辑等。开发规范设计正是根据数据库特性与开发的相关性，从SQL代码编写、表设计、索引设计、其他数据库对象设计等多方面提供全面细致的开发规范指导，规范数据库需求方在业务系统开发过程中数据库的设计与开发，防范低效的数据库设计、低质量的结构化查询语言代码的出现，提升业务系统质量和开发效率。
评估要点：这一过程的难点在于，如何量化质量和效率。必要的工具、平台对落实规范，评估效果非常有好处。可以从事前、事中、事后，多个角度来进行评估，尽量将可能的风险降到最低。
6).数据库运维规范设计
数据库运维规范设计主要指数据库服务方根据数据库及业务系统特点，提供数据库标准化运维体系，如组织架构、管理流程、管理规范、变更管理流程等，保证系统长期、稳定、安全运行，强化数据库标准化管理，减少故障停机时间，在出现各类异常时有标准处理流程与处理方法可依。
评估要点：规范好制定，落地是难点。既要保证不出问题，又要兼顾必要的效率。比较好的方式是工具平台化，如能有可量化角度看待则更优，甚至通过AIOps等新兴手段，则可进一步提高运维效率，规避风险。
评估要点：如何确保物理模型符合预期，测试是必要的环节之一。能通过对客户业务的抽取提炼，将其核心逻辑描绘为数据库语言，进而验证模式是否符合预期。此处难点在于对业务提取和抽取能力。
这一能力项，也是我个人觉得服务方做的不太好的地方。数据生命周期，是指针对数据的产生、应用、消亡的整个过程进行顶层设计。根据业务特点、增长速度等，制定对应的扩展性设计（满足数据产生要求）、数据分层设计（满足对热、温、冷数据）不同访问特点的设计、数据消亡（包括数据归档、压缩、转储、清理等）。
评估要点：从业务特点，抽象出数据特点，帮助用户建立起从端到端的概念。
单机部署能力，包括具体部署方案、实施计划、测试验证方案等内容。包括但不限于基础环境（硬件、软件）检查与准备、数据库系统安装、初始化配置、安全加固、部署验证、组件集成、测试评估、交付上线等环节。这其中有几个容易忽视的点：
- 基础环境检查与准备各个客户环境千差万别，如何适配差异化环境，前期的检查准备工作很重要。其中包括对硬件的检查、基准性能测试（为后期验收测试做准备）、软件系统版本（含补丁）等情况做好摸底。与数据库软件的预安装条件进行对比，判断是否满足基本条件。与客户充分沟通，了解第一手的环境情况。
- 安全加固在部署完毕、初始化配置完成后，需要做好必要的安全加固工作。将安全基础工作做到上线之前，尽量减少可能的风险问题。
- 组件集成数据库不是孤立系统，是需要与客户方的其他系统一起组成基础平台。这里面可能包括客户方的监控系统、日志系统、安全系统、审计系统、备份系统、大数据平台、资源管理平台、数据中台等等。在交付上线之前，要做好与这些系统的对接。这些工作非常琐碎，但非常有必要。这一工作是否顺利，取决于前期对客户系统的调研是否完备？客户方（或第三方）配合是否默契等
- 测试评估在做好上述准备工作后，交付上线之前还需要做好测试评估工作。这一步骤包括功能测试、性能测试、异常测试等。通过这一过程，让客户对新上系统有个全面的认识。
- 交付上线测试通过后，择期对客户交付上线，正式将系统由客户方接管。一般建议有个过渡期，帮助用户逐步熟悉掌握。
对于云端环境，上述过程又有所不同。相对而言，云端环境比较标准，工作也会少些。
评估要点：这一能力项，强调过程的完备、详实程度。一方面这与具体参与人员的能力有关，另一方面与实施过的项目积累经验有关。特别是对于前期、后期的工作更是如此。
集群部署，与单机部署大致步骤相同。特殊之处在于集群环境，是多机构成，因此对网络要求更高，必要的前期测试一定要进行。此外，集群是整体发挥作用，集群内各组件之间的配合很重要，因此对调试安装的要求更高。
评估要点：同“单机配置”
容灾架构部署，要比前两者更为复杂。具体部署难度，取决于多种因素，包括技术方案、容灾环境等。不同的容灾方案，带来的实施难度不同，之前谈到的容灾架构可能包括在应用级、系统级、数据库级、存储级等多种情况，可能涉及多方的配合，不仅仅单指数据库单系统。最终的容灾效果，也是取决于多方的配合情况。至于容灾环境，因容灾涉及到多个环境，可能包括同城单机房、同城多机房、异地多机房等情况。特别是对网络质量，要求很高，需要做对应测试，这是前提。此外，部署后的测试工作对于容灾也很重要。如何真实验证出容灾效果？对数据一致性会带来什么影响？如何回切等问题都需要考虑。最终给客户提交的，不仅是容灾环境，还包括必要的切换文档、演练文档、测试报告等。
评估要点：要点在于对容灾核心需求的满足程度，这是要与客户有充分的沟通，得到一手的需求，设计出适合的系统。此外，与多方协同配合、测试验证演练也是必不可少的部分。
同步架构，与容灾有些类似，也是对多个环境的部署，差异在于需求为数据同步。需要关注点也与前者类似，涉及同步方案的不同所带来的差异。这里需关注两点：一是同步效果的评估，二是对源端系统的影响。这两方面是需要单独评估设计的。
评估要点：类似上面，关注点在同步需求的满足程度及多方配合。
数据库迁移，情况比较复杂，差异在于迁移目的、迁移目标和技术方案等。这里面包含的两种情况：
- 同构迁移迁移前后的数据库相同。此时只要完成数据迁移即可，一般结构、应用等不需要修改。这种情况相对简单。常见的比如更换硬件等需求。
- 异构迁移迁移前后的数据库不同，这种情况要复杂很多。一般除了数据迁移外，还包括结构迁移、应用改造、迁移验证等问题。如果迁移前后的数据库架构有大的差异，例如从单机到分布式等，则需要改造的内容更多。
迁移还有几个重要问题：迁移是在线还是离线？对时间窗口如何定义？如何做数据一致性验证？如何对迁移前后的应用功能、性能进行验证等问题？上述问题，均需要在方案中体现。这部分内容会很多，不展开了，可参考我之前写的一篇文章《如何做一次完美的数据库迁移》
评估要点：方案的全面性，特别是迁移中、迁移后的评估等工作，上述甚至可占到总工作一半以上的内容。
数据库升级，一般可分为原地升级、异地升级两种。前者相对简单，主要问题在于升级影响、时长、回退方案等问题。后者来说，更为复杂些，有点类似于迁移流程，这里不展开了。
评估要点：方案的全面性
数据库整合，一般是从资源角度考虑，重点需要评估整合后资源是否满足需要？有无业务风险等问题。必要时，整合方案之前加入测试工作。
评估要点：方案的全面性
基础运维，包含的内容比较繁杂。重点在于标准化、规范化，即数据库的产品化能力是否成熟，是否通过文档、系统提供出来。而不是仅通过黑盒的方式提供，这对于用户使用来说意义重大。除了常规的操作外，是否提供了开放能力，方便用户通过自有平台运维也很重要，特别是对于中大规模的企业而言。
评估要点：标准化、规范化、文档化、平台化
云化运维，重点是在于对云端资源的管理、安全及开放能力。
评估要点：成熟度
数据库监控，对于数据库稳定运行非常重要。监控的主要问题是几个方面：
- 指标全面性指标覆盖能否全面，能监控到数据库的方方面面，包括但不限于实例级、对象级、语句级等。
- 报警可收敛过多的指标监控，只会造成报警风暴，如何做到报警收敛，突出核心重点，也是监控一个要点。
- 开放集成性可很方便的将数据库监控与客户其他报警平台集成，形成统一整体，进而可实现报警的联动，从基础设施、到系统、数据库、应用直至业务。以此可实现报警问题溯源，方便定位追查问题。
评估要点：成熟度、全面性、扩展性、集成能力
也就是我们常说的巡检，通过这一能力可对数据库的当前运行状态有所了解，对可能出现的问题做到提前预警、提前处理。当然，现在巡检形式也在发生变化，很多健康检查的工作融合到数据库内部或平台自身能力中。可在日常运行中，随时发现问题。特别是近些年来，在AIOps上的探索，也对健康检查带来一些新的思路。
评估要点：全面性、前瞻性
SQL审核，对保证数据库应用质量、保证安全运行很重要，之前在这方面的重视程度不足，近些年来得到了广泛的关注。很多公司自研自己的审核平台，也有一些开源的方案，商业产品中也纷纷增强了这一能力。在功能上，包括结构级、语句级、执行特征等。这项工作一般通过平台完成，可以采用半自动、自动的方式进行，可大幅解放DBA的日常工作。这部分常见的问题是SQL审核的智能化程度、对多数据源的支持、对事前、事中、事后的全流程支持等。
评估要点：平台化、智能化、可量化
备份恢复，是保证数据安全的最后一道防线。功能上除了常规的备份配置、作业监控外，更重要的是恢复验证、备份集的管理。一方面在备份有效性上的增强，一方面是成本与代价间取得平衡，满足数据安全需求的同时，减少客户成本支出。此外，还可以进一步挖掘其潜在能力，例如对开发支持、准生产验证、审计要求等的满足。
评估要点：平台化、成本收益
7).安全审计
安全审计，功能要点在于全面性、详实可信且兼顾成本。这方面主要是满足合规性的要求，防患可能的风险。
评估要点：全面性
应急演练，之前往往重视程度不够，很多公司从未进行过应急演练。很多应急方案都存在文档中，束之高阁。但出现紧急情况时，应急方案反而不适应现状无法使用，失去了最本质的意义。因此这块的要点，是保证应急方案与系统环境的适应匹配，保持最新的状态。次之，则是尽量通过平台化能力（而非文档化），将应急方案沉淀下来，这有助于应急响应的时效性和有效性。应急演练往往不是单一系统的，需要联合基础设施、数据库、应用系统、业务部分等多方，协同完成。现在也有专门针对应急需求的产品出现，可配置多种资源协同完成应急演练。
评估要点：有效性、时效性、可协同
培训，是提高数据库产品使用效果，最为有效的手段之一。通过提升客户方能力，可有效提升使用效果，相较而言服务方投入也不大。培训重点在于摸清客户需求，有针对性提出培训方案，可满足客户从基础运维、架构设计、应用开发、性能优化等多种角度的培训需求。此外，具有一定影响力的产品，还可通过建立认证体系等方式，将培训从单一客户、开放到普通用户甚至学生等群体，构建自己的用户生态。
评估要点：标准化、定制化
性能，几乎是所有客户的要求，很多问题最后都归结为性能问题。针对性能的优化工作，是个较为复杂的问题。可包括数据库自身、基础环境、生态工具、架构设计、开发优化等多方面。要想从全局的角度审视性能问题，是比较困难的，可以借助一些APM工具。针对数据库服务方而言，一般还是局限在数据库自身性能、SQL语句优化等方面。建议采取的措施是日常收集性能基线数据，当出现问题时可对比分析，快速诊断，并给出优化建议。此外，针对客户进行必要的优化培训，也是有帮助的。上述优化工作，可通过工具、平台来完成，提高整体优化效率。甚至有的有实力的厂商，提供自治优化的能力，通过人工智能+知识库的结合，帮助客户实现自动优化。
评估要点：优化评估方法、工具、平台
模型优化，往往是较容易忽视的一点。这里所说是模型，可能包括业务模型、逻辑模型、物理模型，对数据库服务商来说，一般会局限在物理模型阶段。当然，如果对业务模型、逻辑模型有认识，会对客户带来更大价值，但这两点需要对业务有较为深入的理解。针对模型的优化，是有固定的方法论的，可通过知识库、文档、平台沉淀下来。
评估要点：模型方法论
版权声明及安全提醒：本文转自网络平台，文章仅代表作者观点，不代表「金融文库」立场。相关版权归原作者所有，「金融文库」仅提供免费交流与学习，相关内容与材料请勿用于商业。我们感谢每一位原创作者的辛苦付出与创作，如本转载内容涉及版权及侵权问题，请及时联系我们客服处理（微信号：JRwenku8），谢谢！
