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

        数据库,做为企业重要IT基础设施之一,在数字化中扮演着重要的角色。其是否运行平稳、是否处于最佳状态、是否可方便的扩展等,进而是否能知足业务现状及将来发展,这些对于企业相当重要。要达到上述目标,取决于两个方面:数据库产品自身能力、数据库服务能力。能够说“产品+服务”,决定了最终的结果如何。但在很长一段时间里,对于前者(产品)有不少手段去了解、评估;但对于后者(服务)却少有有效的衡量方法。在过去的3、四十年里,传统数据库市场主要是以国外大型商业数据库为主,其服务能力通过多年积累已相对成熟、完善,并构建起一整套标准及相应的配套服务团队。但随着近些年来数据库市场有了明显的变化,一是以开源为主导数据库方案在不少公司得以使用;二是国产数据库也层出不穷,并愈发呈现蓬勃发展之势;三是分布式、云化技术特色为表明的新数据库形态逐步被人认知并投入使用。针对这种新的变化,过去按单一产品做为衡量标准就不太合适,急需一种通用的行业标准来度量数据库服务能力。数据库

        近期,信通院发表的《数据库服务能力成熟度模型》,由此应运而生。它的推出,有助于企业决策者,找到数据库服务重点,获取当前数据库总体现状,识别其中的不足并找准关键问题及差别,进而提供数据库服务能力的改进方向和意见,规划企业将来的数据库发展蓝图。本文根据以前信通院发表的《数据库服务能力成熟度》为基础,加以我的的一些理解分析。当前这一标准,正处于规范发布阶段,其具体细节和评价方式、标准还有待落实,也但愿更多数据库从业者参与其中。为提升国内数据库总体服务质量,贡献本身的一份力量。本文部份内容引用信通院发布《数据库服务能力成熟度》报告及网名“失速的脑细胞”的一篇文章。安全

原文参考:www.jianshu.com/p/d672951c5c1a性能优化


1. 成熟度模型概述服务器

     人生基本上就是两件事,选题和解题。最好的人生是在每一个关键点上,既选对题,又解好题。人生最大的痛苦在于解对了题,但选错了题,并且还不知道本身选错了题。正如人生最大的遗憾就是,不是你不行,而是你本能够。微信

1).评估标准:能力框架与能力域网络

这次发布的数据库服务成熟度模型,将能力框架划分为三个能力域,分别是:规划设计能力、实施部署能力和运维运营能力。其可对应到数据库从选型评估、规划设计、部署实施、运维保障、开发优化等多个方面。在三个能力域内,又进一步划分为27个能力项,其中规划设计能力域包含8个能力项,实施部署能力包含7个能力项,运维运营能力包含12个能力项。具体可参考下图:架构

2).评估对象:服务方和使用者
并发

此模型的评估对象,既能够是数据库服务提供商、也能够是数据库云厂商;甚至是数据库产品的使用者。前者做为数据库服务的提供者,此模型是能够做为甲方选择服务者的一种参考依据。后者做为数据库用户自身,也能够做为评估自身的技术能力的有效抓手。app

3).评估标准:能力等级划分框架

在评估标准上,模型提出了五个等级,分别是初始级、可重复级、稳健级、量化管理级、优化级,其能力等级依次递进。从初始级,完成目标具备必定的偶然性,被动应答需求和问题的初始级;到具有必定经验和技术积累的可重复级;到具有知识库、流程和规章制度,保障目标达成成功率的稳健级;到可以量化并可以监控服务过程当中每个环节,而且具有较高服务的工具和相对完备流程制度和方法论的量化管理级,以及最高级别,可以不断可以引入新的技术和理念,超预期达成目标,分享最佳实践成为行业标杆的优化级。

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

  • 初始级

    在最原始的阶段,企业的数据库运维每每依靠于我的。我的的能力、水平直接影响运维效果。当出现问题时,人肉搞定。此时问题的解决,是没有总结积累、没有传承的。稍微好些的是,创建一套相对简单的处理流程。出现问题,可遵循此流程;但具体的处理方法是无章可循的。

  • 可重复级

    问题出现的多了,天然而然的想法是把常见的问题和解决记录下来,也就慢慢有了经验的传承(构建原始的知识体系)。加之以前的规范流程,就有了一套标准。当问题出现时,依据处理流程及处理方法,按图索骥便可。再进一步的,能够将这些解法能够脚本化、工具化,提升处理效率。

  • 稳健级

    当可重复级积累到必定阶段,就达到稳健级。此时构建的知识体系、流程、规范、制度已日趋完善。此时,是一个比较“自在”的阶段,若是没有大的目标,是能够小富即安了。

  • 量化管理级

    如再上一个台阶,就涉及到对服务的度量问题。由于只有达到可度量的状态,才能够不断提高,追求更高的管理目标。此外,也才有机会作到预测式管理,而非被动响应式。要想作到量化这一目标,是须要对数据库使用有着更高层次的认识。举个例子,如何评估你单位的数据库开发质量。为了达到这一目标,是须要你定义具体的指标及指标的评定标准,进而还须要经过系统、工具辅助完成指标的收集、管理、优化等工做。具备表明性的指标,甚至能够造成行业标准,指导其余企业的管理工做。

  • 优化级

    到了优化级别,不只仅局限于提高数据库管理、使用水平,甚至可直接提高企业业务能力。其不在限于单一指标,而是提出新的概念,帮助从更多角度看待这一问题。甚至能够反馈产品,持续改进。对外,能够将已有内容造成行业通用化标准,引领行业的总体发展。

4).评估维度:流程+制度+方法+人员+交付物

  • 流程

    根据发展等级,从初始的针对个别问题的简单流程,到通用化、标准化;进而逐步完善、趋于完整;再到创建流程评估体系;最终造成不断迭代完善的流程。

  • 制度

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

  • 方法

    从无到有,从我的经验,到经验传承;从知识库造成,到构建自有的方法论。

  • 人员

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

  • 交付物

    从无任何传承媒介,到文档的积累;从简单脚本到复杂工具、平台、系统;从单一处理型的工具,到收集、评估、预测、处理、优化等系统集合。从内部使用,到可输出外部等。


2. 规划设计域

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

1).架构规划咨询

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

  • 基础设施

    在作架构规划时,需考虑企业自身基础设施现状及发展规划。包括但不限于服务器、存储、网络、安全等相关配套设施。如考虑云方案(公有云、私有云、混合云、跨云)等,还须要考虑云厂商的选择,是自建仍是直接选择云数据库产品等等问题。基础设施,做为数据库的“底座”,其好坏对数据库的总体投产效果,很是重要。

  • 运维能力

    这里谈到的运维能力,包括软和硬两个方面。软的方面,主要是指人的状况(即自有人员的能力、结构、技术特色等)。硬的方面,则是指企业运维体系、平台等方面。

  • 应用开发

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

  • 财务成本

    企业的财务情况、总体周期状况、主要财务考核指标(如ROI)等。

  • 业务特征

    行业、企业、业务特色,是否具备高增加性、不肯定性、波动性等特征。企业现有所处阶段,及周期内会经历阶段。

  • 风险评估

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

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

2).容灾备份规划

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

  • 容灾架构

    根据客户的容灾需求,可考虑单机房容灾、同城容灾、异地容灾、多中心容灾策略等。在技术方案上,可综合考虑应用级、系统级、数据库级、存储级等不一样的容灾技术。

  • 备份策略

    备份策略上,一方面须要考虑客户的业务诉求,也须要考虑来自合规、监管类的要求。根据不一样需求,创建其多层次的备份体系。此外,针对“多余”的这份数据,除了数据保护单一功能外,是否可带来更多附加价值也值得探索。

评估要点:这一能力项更可能是看中方案的成熟、稳定,特别是相关案例实践。毕竟容灾类的需求典型特色是,可能永远也用不到,但一旦启用毫不

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

3).数据安全规划

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

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

4).产品选型规划

在明确了架构规划后,这一步将要完成具体产品(包括平台、版本、补丁等)的选择。在选择时,须要细化以前架构阶段收集到的那些信息以外,还须要进一步收集用户的业务特征,为作好必要的选型测试(即POC)作好准备。这一步的难点在于,如何构建符合客户真实需求的评测标准。常见通用的测试标准(如TPC组织系列),仅仅能表明通用性场景,对客户真实业务来讲,不太具有参考意义。所以需制定有针对性的测试标准,包括常见的功能测试、性能测试、可用性测试、扩展性测试、应用开发适配、数据迁移、兼容性等。若是是采用云数据库,则还需考虑更多问题。评估要点:评估要点在于“切合度”。如何根据前面获得的信息选择最为适合的产品,并构建符合客户真实业务场景的选型测试来帮助客户完成这一步骤。针对客户需求的准确把握及对行业、业务特色的深入理解,有助于完成这一过程。

5).开发规范设计

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

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

6).数据库运维规范设计

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

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

7).数据模型物理化设计

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

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

8).数据生命周期设计

这一能力项,也是我我的以为服务方作的不太好的地方。数据生命周期,是指针对数据的产生、应用、消亡的整个过程进行顶层设计。根据业务特色、增加速度等,制定对应的扩展性设计(知足数据产生要求)、数据分层设计(知足对热、温、冷数据)不一样访问特色的设计、数据消亡(包括数据归档、压缩、转储、清理等)。

评估要点:从业务特色,抽象出数据特色,帮助用户创建起从端到端的概念。


3. 实施部署域

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

1).单机部署

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

  • 基础环境检查与准备

    各个客户环境千差万别,如何适配差别化环境,前期的检查准备工做很重要。其中包括对硬件的检查、基准性能测试(为后期验收测试作准备)、软件系统版本(含补丁)等状况作好摸底。与数据库软件的预安装条件进行对比,判断是否知足基本条件。与客户充分沟通,了解第一手的环境状况。

  • 安全加固

    在部署完毕、初始化配置完成后,须要作好必要的安全加固工做。将安全基础工做作到上线以前,尽可能减小可能的风险问题。

  • 组件集成

    数据库不是孤立系统,是须要与客户方的其余系统一块儿组成基础平台。这里面可能包括客户方的监控系统、日志系统、安全系统、审计系统、备份系统、大数据平台、资源管理平台、数据中台等等。在交付上线以前,要作好与这些系统的对接。这些工做很是琐碎,但很是有必要。这一工做是否顺利,取决于前期对客户系统的调研是否完备?客户方(或第三方)配合是否默契等

  • 测试评估

    在作好上述准备工做后,交付上线以前还须要作好测试评估工做。这一步骤包括功能测试、性能测试、异常测试等。经过这一过程,让客户对新上系统有个全面的认识。

  • 交付上线

    测试经过后,择期对客户交付上线,正式将系统由客户方接管。通常建议有个过渡期,帮助用户逐步熟悉掌握。

对于云端环境,上述过程又有所不一样。相对而言,云端环境比较标准,工做也会少些。

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

2).集群部署

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

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

3).容灾架构部署

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

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

4).同步架构设计与部署

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

评估要点:相似上面,关注点在同步需求的知足程度及多方配合。

5).数据库迁移

数据库迁移,状况比较复杂,差别在于迁移目的、迁移目标和技术方案等。这里面包含的两种状况:

  • 同构迁移

    迁移先后的数据库相同。此时只要完成数据迁移便可,通常结构、应用等不须要修改。这种状况相对简单。常见的好比更换硬件等需求。

  • 异构迁移

    迁移先后的数据库不一样,这种状况要复杂不少。通常除了数据迁移外,还包括结构迁移、应用改造、迁移验证等问题。若是迁移先后的数据库架构有大的差别,例如从单机到分布式等,则须要改造的内容更多。

迁移还有几个重要问题:迁移是在线仍是离线?对时间窗口如何定义?如何作数据一致性验证?如何对迁移先后的应用功能、性能进行验证等问题?上述问题,均须要在方案中体现。这部份内容会不少,不展开了,可参考我以前写的一篇文章《如何作一次完美的数据库迁移》

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

6).数据库升级

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

评估要点:方案的全面性

7).数据库整合

数据库整合,通常是从资源角度考虑,重点须要评估整合后资源是否知足须要?有无业务风险等问题。必要时,整合方案以前加入测试工做。

评估要点:方案的全面性


4. 运维运营域

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

1).基础运维

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

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

2).云化运维

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

评估要点:成熟度

3).数据库监控

数据库监控,对于数据库稳定运行很是重要。监控的主要问题是几个方面:

  • 指标全面性

    指标覆盖可否全面,能监控到数据库的方方面面,包括但不限于实例级、对象级、语句级等。

  • 报警可收敛

    过多的指标监控,只会形成报警风暴,如何作到报警收敛,突出核心重点,也是监控一个要点。

  • 开放集成性

    可很方便的将数据库监控与客户其余报警平台集成,造成统一总体,进而可实现报警的联动,从基础设施、到系统、数据库、应用直至业务。以此可实现报警问题溯源,方便定位追查问题。

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

4).健康检查

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

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

5).SQL审核

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

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

6).备份恢复

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

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

7).安全审计

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

评估要点:全面性

8).应急方案演练

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

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

9).培训

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

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

10).性能优化

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

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

11).模型优化

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

评估要点:模型方法论

12).数据生命周期管理

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

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





韩锋频道:

关注技术、管理、随想。


长按扫码可关注




QQ群号:763628645

QQ群二维码以下, 添加请注明:姓名+地区+职位,不然不予经过



本文分享自微信公众号 - 杨建荣的学习笔记(jianrong-notes)。
若有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一块儿分享。

相关文章
相关标签/搜索