摘要：本文主要分享如何构建反脆弱性的云数据库服务体系与实践，实现分布式云数据库服务的高可用方案，同时采取措施保护分布式云数据库整体服务，实现跨机房分布式自动切换方案，并在实践过程中，实施分享 SQL 自动发布，实现0误操作，有效保障云数据库服务的同时，提高了 DBA 及研发人员的效率，并完成有效数据库评价，实现完整的反脆弱数据库服务保障体系。

　　作者：成思敏

成思敏， 21CN 数据库架构师/技术专家/DBA 主管，长期从事数据库工作，任公司 DBA 主管，数据库架构师，技术专家等。擅长数据库整体架构的构建，数据库自动化运维设计，早期介入数据库服务研究，长期从事在云计算下的数据库运行情况难题解决，并长期公司内部 DBA 团队建设培养，对内数据库规范培训。

本文根据成思敏老师在DTCC数据库大会分享内容整理而成，主要分享构建反脆弱性的云数据库服务体系与实践，实现分布式云数据库服务的高可用方案，同时采取措施保护分布式云数据库整体服务，实现跨机房分布式自动切换方案，并在实践过程中，实施分享 SQL 自动发布，实现0误操作，有效保障云数据库服务的同时，提高了 DBA 及研发人员的效率，并完成有效数据库评价，实现完整的反脆弱数据库服务保障体系。

一、云数据库服务情况简介

各位朋友大家下午好，我是来自21CN 的成思敏，也是一名专业岗，这几年在云数据库上面我成长得比较快，我们公司的业务发展也是很快。我所带来的分享主题是云数据库反脆弱运维体系，跟大家分享一下六年来在云数据库方面遭遇的挫折和总结的经验。

那云数据库的脆弱性是什么？我们如何去反脆弱？如何建设强大的数据库服务体系？

这就是我们今天需要讨论的话题。脆弱性在《六西格玛》这本书上指的是质量问题，质量问题其实牵涉到有十几种，比如说故障、性能、数据的恢复、数据的备份以及同步、性能调优等。即使是数据库没有故障也很稳定的时候，但是cpu基本是在10%以下，那么也是长期低负载的情况下，它也属于质量问题，因为它浪费了公司资源；这些都属于脆弱性的范畴。

当大家解决一些问题的时候，一般是很有成就感的。不知道大家是如何去判断一个问题的，希望大家在解决问题的时候深挖最根本的原因，因为解决的问题往往是表面问题，比如说杀一个会话，调一调SQL，去优化。我们往往只是触摸到问题的冰山一角。

1、云计算与云数据库服务情况

现在已经是云时代了，在2009年的时候我是被亚马逊的云计算震惊了，从那个时候我就一直在想如何去建设。对于DB来说，他们说一个DBA可以去维护3000台数据库实例的时候，我们该怎么去做这个事情，怎么去实现？

云计算的基础是整个资源池，能够提供智能的决策，以前是帮决策者去做决策，但是云计算能够提供智能的决策，所以它现在越来越成为企业先进性的标志。因为云数据库是云计算的核心应用，所以每一个DBA、每一个数据库工作者包括研发不得不去重视云数据库。

到2018年为止，我国的企业上云率是30.8%，美国企业上云率是80%。但并不是所有的企业都能够上云，包括美国。比如说化工类的配方、财务的核心数据甚至一些国家的军事机密，这些是不应该上云的，即使是私有云。走向网络化的时代，企业一定有自己的命根子，他要保住这些东西。我国企业上云率为什么和美国相差这么多？我个人认为，一个是因为我们的云计算起步稍微有些晚，另外就是IT行业的人工成本还是稍微低了一点。美国的人工成本是非常高的，可能对专业岗来说没有上限，在这样的情况下，美国的上云成本要稍微低一点，所以美国的上云率比较高。

2、云数据库与传统数据库

那对于云数据库和传统数据库来说，主要是云数据库和传统数据库来说，因为它放在云计算上面，所以它的安全性得到了很大的保障。像MySQL的单实例性能是非常弱的，我们也是经历了六年才发现各种各样的问题，它比我们想的还要弱。SQL性能拿数据量来说，因为数据性能随着数据量增多而衰减，所以数据量不能过大。另外，在迁移方面，云数据库可以实现秒级的切换，对于传统的数据库比如Oracle来说，可能至少需要几分钟左右。云数据库可以解决IO的问题，通过分布式事务并可以实现高可用分布式的架构，能够解决存储的问题。 它还可以实现高可用连续性。在服务方面，它可以建立分布式架构，也可以实现高可用和读写分离等多种连续性解决方案。

对Oracle来说，我们就用各种手段去做数据库调优和保障数据库性能，但是对于云数据库来说，它一个弱不禁风的MySQL云数据库，如何去保障整个应用？拿实例来说，有可能1个Oracle实例能够顶200个MySQL的实例，那你如何去维护200个实例，我们就需要具备掌握综合使用工具的能力。在六年中,虽然有挫折的地方，但我们确实利用云计算的智能和全栈的技术能力，极大地提高了数据库的运维效率，并且我们根据业务需求，即使是一个小小的MySQL，也支撑了非常高的300亿行数据规模的数据库。

3、云数据库服务运维体系存在问题特征

那云数据库的问题在哪里？这是经过六年来我们的总结，问题SQL很多，有时候一个insert语句当时也没有发生高并发高性能的问题，但它就是一个慢查询，慢查询有可能是20分钟，也有可能是7秒，这个问题是非常的严重。还有一个就是SQL不稳定，因为MySQL一个列上面可以建好几个索引，和Oracle不同。在这种情况下，执行计划会走偏。

另外一个是监控不准，因为虚拟机等都OK的情况下产品发生了问题，然后客户就找我们的麻烦，这是很常见的，已经几乎每天都会发生。然后就是云数据库的服务剧增。因为我们要支撑高并发，所以我们就用中间件，不管是分表分库还是读写分离，都会存在不可知的问题。另外就是架构过高，那经过我性能压测，我们一个中间件代表一个MySQL的时候，它性能衰减有可能达到60%。

另外就是云计算的资源池过于集中，有时候我们把各种服务放在一起，数据库会莫名其妙地发生奇怪的问题。其实是因为业务增多，有可能一个资源池挤不下，所以把相同的应用在不同的机房去部署，也就是跨机房的部署。再就是排查问题比较难，这个问题遇到很多次了，那时候一升级我们就发现了问题，但捕捉不到相关的SQL。但是数据库看起来是很平静的，中间件是一会儿有问题一会没问题的情况，所有的工作人员都对这些无头案很困惑。

4、我司六年云数据库服务历史

我们公司上云大概是2013年初，一直以来云数据库服务运维的复杂度是不断增高的，因为数据库类型、数据库的架构类型、服务业务类型、云数据库的资源中心以及项目数以及更新的需求数目等，其中数据量增加最高，这对DBA增加了维护、管理、技术的要求。因为都是我们自建的云数据库服务，我们所面临的问题非常的大。

5、云数据库与云计算相遇，存在主要问题

云数据库属于PaaS的范畴，它下面是IaaS基础设施及服务，我们前几天也遇到一个问题，数据库无故中断了十分钟，以为宕机，我去找云公司，原云公司说没宕机，性能也没有问题。后来云公司向我反馈说是云计算的软件和宿主机的网卡驱动存在着冲突。

还有一个问题就是LINUX操作系统内核和云计算内核发生了冲突，这是群死群伤的问题，是几百台几百台的问题，那我们去如何去解决?我们也发生了整个机房宕机，就像阿里云一样的整个机房宕机的问题，还有类似于阿里云的整个资源池的共享存储发生了IO的争夺。另外我们也发生挖矿病毒，还有其他各种各样的问题。我们面临整个资源池要废掉的问题，成百上千的实例要搬到另外的资源池上面去，这是一个非常大的问题。在这种情况下，我们需要产生一个新的保障模式。

二、反脆弱运维体系构建过程

1、数据库异构上云迁移过程（2013年开始）

下面我们看一下整个的构建过程。大概在2013年10月份的一个业务中，我们做了一个迁移的操作。那个时候我们一穷二白，只有MySQL和Oracle两种市场所提供的中间件，市场上提供的大概有阿米巴 、ATLAS，cobar，MyCat是零点几版本，大家都不敢用。在这种情况下，为了支撑业务我们只能分表分库，即使完成了以后，我们所有的监控还是一穷二白。像MySQL这样一个完整的监控，在市场上也是不健全的，因为它的指标和之前有点不一样。在这种情况下，我们做了全部用脚本化去监控，做了最原始的脚本化。

我们业务要求只能够在凌晨3点到6点施工。在迁移过程中，市场上的工具是原厂自带、第三方或SQLserver还有普通的一些迁移方法我们都尝试过，后来发现这确实是很困难的事情。所以，我们DBA就用了原始的存储过程，再加上这个DTS 这样的迁移模式，把业务梯度化分类。最热的数据在停机三个小时之内完成，但是在迁移的过程中又发现了很多的挫折；我们迁移工具、存储过程等在测试的时候都是OK的，但迁移的过程出现了问题。在迁移的过程中数据是有问题的、不匹配的，所以对研发做了一个限制和标准。在这种情况下我们完成了这样一个艰巨的任务，花了三个月的时间完成了3亿多行核心数据的迁移，包括代码编写。现在最大的数据有30多亿行，一直运行得很完善，而且这个项目已经做了双节点的正常运行。

总结一下，在使用云数据库过程中，我们一定要考虑到云计算的环境，不要觉得整个资源池是无限的。要注意云资源池能够给你分配多少台主机，它到时候装不下你的业务怎么办？还有我们刚才所说的云计算那么多的问题，该如何去保障？另外，目标的数据库也不要做得太花哨，要做自己能够运维的数据库。 比如说MySQL就是非常好的例子，都是大家都会用，也会有保障的模式。

在迁移方案中， 我比较倾向于研发级的迁移，可以一个用户迁过去，然后发现不行再迁回来。现在已经成熟的一个模式，大概是迁了半年，反反复复。虽然说很慢，但它确实保障了高并发的业务连续性要求。在迁移技术当中，我还是建议自研，因为市场上的那些工具都不完整，比如说前段时间我们用了开源工具愚公，用中间件迁移的时候很不好用。我们的研发整整花了一个半月才改造好。另外，在迁移过程中，希望大家把数据的一致性和迁移的效率要做好，我们目前有五六种迁移的能力，基本上都是在去Oracle的路上。现在还有几十台核心的业务在做，这个事情是很艰巨的。

还有另外一个，大家不要觉得DBA就要失业了，只是工作模式发生了变化。像我们团队来说，曾经是三个人，现在有十几个，DBA是越来越多了。大家可能以前只是维护级，现在需要研发能力，我们需要不断创建工具，多做创造性的运维工作，转换工具模式。

2、云数据库服务技术原则

对于云数据库我们需要坚持一个原则，我一再强调要保持云主机的特性、弹性轻巧和资源的集中，大家以前都觉得好像一个Oracle里边可以放八个项目，很多个项目去复用，但是云主机它是很有很轻巧的，4C、2C这样的都可以，但是要适当的复用。

另外一个就是数据库建设的原则，不要觉得自己技术很高端，去创造性的直接拿来最成熟的工具去做。当你发生问题的时候也不要害怕，在社区上找你的盟友，然后去解决。

再一个就是可实施性的原则，然后当项目去立项的时候，你做一个不可维护的、大家都不知道的工具，必然会给这个项目带来很重大的问题。我们需要架构简单灵活，解决问题非常快速，大概需要这样的一个思路。尽量不要用分布式，因为我曾经做过MySQL的分布式测试，大概系统损失 2/3左右的运算，性能非常弱。那要是再放在云机上面，我做了一个测试，QPS到2000的时候，事实上我用到一千的时候它就死了。

这个性能我觉得是不可靠的，虽然整个云资源池给你去压测的时候是非常大的，但实际上用的时候打了折，只能把性能打折作为业务能力的评估标准。所以大家不要太信整个资源池，因为它有资源争夺的现象。

我们需要关注性能，DBA经常去调优，经常去背锅，不管是研发问题还是项目设计问题。那在这种情况下，我们需要从开始就约束研发、约束产品，当项目立项的时候我们要考虑到请求的比例、请求的时间间隔、请求的响应时间、请求的并发情况和系统吞吐量。经常会说性能边界的问题，如果当这个资源就硬件资源和MySQL的配置都很合理的情况下，那就需要知道软件的边界能力，需要去知道系统达到瓶颈的情况，从上端去压测，不然的话锅永远是DBA的。

对于应用性能，我们需要关注同步与异步、并发量、请求的响应时间、返回的数据量、能不能够要求研发，有请求速度可控的能力，我们杀会话是杀不完的，调优是调不完的，需要从项目设计就开始就去解决并发量等的问题。

关于云数据库，刚才说了需要关注资源池和网络环境、云主机的能力、数据库的类型和数据库的架构以及数据库节点的能力。一定要配合研发，产品需求要理解清楚。对于数据库来说，我们必须清楚业务和cpu是优先的，还是MEM优先的，还是存储优先的，然后再做适当的匹配和云主机的能力，这样才能够为公司提供可靠的数据库系统，替公司节约成本，提供最佳配置。

3、分布式数据库案例

这是我们的一个案例，一个分布式数据库的架构。上面是多VIP的模式，下面是一个负载均衡集群，然后下面是分表分布的中间件，再下面就是MySQL的一个集群，做了一个很普通的主从。因为我们有双节点，所以这个地方没有用高可用直接切换的本机的能力。我做了一个数据库的标准给我们公司，说对于一个MySQL来说，必须是一主一从一异地，在异地必须做这样的一式三份的能力，这救助了我们整个系统很多次。

大家一定要在MySQL的架构中做一个缓存的集群。我们用的是memcached这样的一个能力，然后我们还有一个能力用的是Redis。

4、分布式数据库问题防范

基于刚才的架构，我们需要建设一个故障树，我们知道问题，预先做一个问题的埋点，知道问题发生在哪里，先把问题列出来。不要觉得什么都是意外，没有意外的，因为你知道你用了什么，问题会发生在哪里，要很明白要做的事情。

在这个时候负责均衡层它一定是有问题的，另外一个中间件也是有问题的。因为我们曾经遇到过分表分库的中间件、我们的研发， 甚至谓词都不写，何谈分片，就是把这个直接上线。那如果说这个发生在1000个实例的情况下，是不是所有的实例都cpu90%以上，这个是有很大风险的。还有集体高并发，另外我们也遭遇过缓存崩塌，缓存崩塌就高并发到SQL，而且SQL集可能是个烂SQL集，只一条SQL可能数据库就死了。即使就是分表分库的，但是它很多个分片支撑在上面，遇到高并发你也会死掉。

5、分布式数据库双节问题

在刚才的案例中我们做了一个双节点，我们曾经做了三节点，但是三节点上线以后制约点很多，然后就撤销了。双节点一直在用，但是双节点发现很多的问题。我记得我们的团队成员在双节点体系没建设好的时候，每天半夜由于复制中断报警起来三次去处理。在每个节点当中，我们设了一个极星平台和北斗平台，北斗是中间件的自动管理化，极星平台是整个数据库的自动化管理层，整个的架构大概就是这样。

基于这个问题，我们重要的思维是来自otter，otter拿过来也是很不好用的。但是它提供了四个很有效的框架，他用了etl及TCP滑动窗口的思路，然后用了ZOOKEEPER协调工具。我们利用了这样的思维，在每个节点按实例去做高可用。当一个中断的时候，就是这个节点死了，然后做一个自愈的自动重启，基本上完成了95%以上的问题。现在我们DBA是比较幸福的，因为我们整个机制按照这种思路去完成，每个组件都不能有单点，每个机房它都有另外一个地方的组件复制节点。

这个时候我们也要建立一个故障树，我们最长的专线是近2000公里长。而且我们的机房（云资源池）非常多，同城的机房（云资源池）之间就是三毫秒到六毫秒的延迟。但是距离越远的时候，大概有的时候到80毫秒的延迟。我们要很清楚专线的能力，不但是中断，普通的延迟都要80毫秒，更别说怎样去做灾备的能力。中间件的问题里有个ZOOKEEPER，我们ZOOKEEPER里面的一个DATA数据很关键，虽然说ZOOKEEPER里的数据（本身在内存）， 过一阵子它会以日志的模式落到落到磁盘上，但事实上它内存里面总有那么1000到2000条数据放在里面（我们需要保证它的完整性）； 所以这个时候我们需要用数据库来解决，把数据全部写到数据库里面，每个节点异常的时候我们该如何去做？一定要规范研发SQL，既然有双节点，就要约定不能用的地方。然后这个SQL不能够分片，不能够有什么样的DDL语句，不能有什么样的存储过程，都要说得明明白白。我们的双节点经过大概 2014年开始建，到现在有五年的时间，基本上可靠性已经达到行业的标准，所以我们的业务支撑也比较好一点。

6、NOSQL数据库

MongoDB下面这个组件我就不说了，一般MongoDB有四个组件，我们采集多个VIP与DNS协调，还有另外一个是分片。上面我们用了一个负载均衡层，我们的思维也是每一层都不能有单点。那给大家讲了这么多的问题所在，我们需要从哪个点去保障我们的业务？

7、NOSQL数据库（MONGODB）

MongoDB也属于虽然叫集群，它也有分片，所以它也是分布式的。 那分布式的数据库，我们一般的定义是保障整个数据库正常运行，一个节点不能影响整个数据库的运行，对吧？但事实上我们所遭遇的是什么？一个分片有问题的时候，然后他上传到中间件也没问题，但是你的应用呢？应用怎么设计？所以，研发一定要明确一个分片影响的应该就是这个分片上的数据应用，而不能是全局的。因为他发现有问题的时候，他在应用层RESIN或TOMCAT等响应慢时，就发生了堆积显示数据库慢，其实不是数据库集群（是某个分片），但整个应用会存在问题，其实这数据库是分片数据库，但应用整个架构看是伪分布式的，这个问题经常发生。所以在这种情况下，我们一定要去站到更高的角度上看数据库的设计。我们一直说调优在这种复杂的环境下有很大作用，其实作用没那么大。

8、威胁分析

经常有人说数据库上的故障80%都是DBA误操作的。事实上不是的，我们经过六年的运维发现，与数据库相关的所有人员他都脱不了干系。另外就是发现了研发在应用层做一个清理数据库的定时任务，那这些任务死了，然后又是高并发，数据库就发生问题，还有运营人员那个SQL不知道怎么写的。然后可能是200行，可能是六个以上分页，又是MYSQL和云机，下面的事情就开始抛包袱了。

在这种情况下，对于业务层来说， 一个是事务的SQL比较差，一个是应用升级的时候没告诉DBA做审核，没有评估完整。然后是突然间数据量增长以后，性能突发的衰减，但是只有30%，其他的其实都是人为。但是七成中也就只有百分之十几是DBA做的。所以这个事情大家一定要想清楚，多方面的考虑问题并解决去保障好我们的数据库，为公司带来效益。

9、环境分析

平时在维护一个Oracle的时候，大家都死命的去保障一台，稳定的时候DBA可能会在嗑瓜子。事实上我们现在所遭遇的就是几十个资源池。 每个资源池有很多个数据库，现在又遭遇到物联网（现在及未来更多更多的数据库（嵌入））。但我们的产品要求不能有故障，故障运行到谁手上，那就是谁的问题。这就要有个思维，所有的数据库问题都不能影响产品，需要故障无害化处理。至于怎么去无害化处理，就是高可用、自愈等能力。

10、监控体系构建

监控已经是一个常态，那对于刚才那么多的资源中心如何去保障云数据库监控的有效性和收敛性，我们如何去做？当然肯定要考虑做一个分布式的监控系统，那大家开始的时候说用ZABBIX等什么东西，但是我们的监控基本是原创的，它是用OS机是用ZABBIX，因为最初很多的东西监控的数据比较模糊（这几年才比较具体），比如说磁盘小于10%，但不知道具体是多少。但是当分布式监控平台做好了以后就真的高枕无忧了吗？不是的，因为我们也是遭遇很多问题，刚才那么多的资源池、那么多的实例发生问题的时候，我们是没发现的。在这种情况下，我们就设计了这个是元监控平台，它来自于谷歌的思维。元监控他的思维是来自什么？源数据。源数据是数据的数据，刚才我们的嘉宾说他们的元信息系统，那是信息的信息；元监控也一样，也是监控的监控，是二级监控。

我们的监控会发生什么问题？第一个分布式的监控一定会死掉，第二个监控的覆盖不全，有的主机没部署上去监控不全。第三个就是要监控升级，监控的版本不一致。出现这三个重大问题的时候，我们需要用元监控平台去解决。我们现在做了一个初始的，只是发现了问题就报警。我们未来会做这样的一个平台，发现了问题，把这个元监控作为一个最高的标准，然后把最新的版本派过去，给它更新上去。另外，如果说如果监控的进程死掉以后可以自愈，然后重启监控。另外一个就是监控覆盖不全的时候，把最新的监控远程安装上去，这就是元监控的使命。

但即使有这些东西的时候，也有一个问题，数据库不断地去重启，等你发现重启以后，什么问题都找不到。针对这点，我们设计了这个DBA快照采集系统，三秒钟采一次，也是分布式的。 基于MySQL和Oracle全部做这个，这也是我成就感最高的一点，因为我们用它诊断了很多东西，快速地去发现它的趋势（并是全业务的，全局的），抓住它的上层信息以及SQL。还有一个点就是虽然快速地抓住了它，但是应用升级升得不干净。比如说我们有一个应用有200多台应用服务器，升级的时候升级了90%，剩下的10%是老系统。所以业务会有问题，数据库也抓不住。我们通过这个采集系统很快就能诊断出问题。

这个就是我们基于刚才的思维所做的一些系统。这个元监控系统比较初级，它只有告警的功能。对于基本的报警，我们设了五级监控，五个级别，有的三天发一回、一天发一回、一小时发一回、一分钟发一回等等。但是采集数据都是一分钟之内，采集系统所有的数据都是写到数据库。大家可以把数据库做各种各样的一个东西，然后随时都可以全局去看所有的项目的SQL、所有的项目的现状是什么，不需要登录到数据库就可以直接去查看分析及诊断，及时发现问题接解决问题。

11、自动化与自助化可视模型

对于DBA来说，安装操作系统，云机的话除了模板之外的所有技术都是我们自己做的。在这种情况下，我们从2014年有了思想及准备，2015年开发了一个更新和查询的自助化平台。这样的话，一个DBA可以维护3000台实例，可以把这些给研发、给运维，只要我们设好规范，就可以更新。另外，自助化的质量平台，发现问题就用告知的模式给你发邮件或者发短信。另外就是自助化的中间件，我们把整个拓扑放上去，然后做了一键切换配置。自动化部署平台目前也是DBA去干。当时我们公司的MySQL模板是我建的，建完以后十分钟可以解压，稍微配置就可以完成数据库的配置。但这些还不够，因为我们所有的监控和采集需要有关联、需要监控的、需要评估的、需要标准化的，我们去部署验收的列表经过15个版本。我们有31条规则配置，如果你没有完成这31个工作，那这个数据库就不能算是完成了部署。

在这样的情况下我们做了一个自动化的部署平台，它可以部署自动完成验收的报告单，包括扩容缩容也要产生报告，而且可以批量地部署。我们测试过一百台十分钟可以完成这样的部署，这也是快速部署的思维。

DBA是要巡检的，光监控是不够的。我们做了一个自动化平台，只看结果。把核心的一些传统用告警的模式，实现自助化。出现过MySQL有些业务在程序上死循环，然后发现自增列满了，表已经满了，但是磁盘不一定是满的。所以我们做了一个监控，还有一些权限方面的作为监控的补充。这是一个很完善的自助化模型，那大家可能要谨记，生产灰度都可以做生产的，测试和研发一定要网断隔离，如果不隔离可能会出现生产的应用挂在测试数据库上面，测试的应用又挂在生产库上面，出现了很多的误操作。

关于刚才所说的自动化更新，我们做了一个工单系统，市场上第一家做这个的是美团，后面比如YEARNING ，ARCHOR等系统，每个公司都是各展神通。在这个情况下，我们改造了开源，利用我们自己的思维，做了一个自动化的东西，给它嵌入了自动化的流程。因为我们DBA不可能每天晚上12点起来去update一条。我们把这个作为自动化的检测环境，如果那个时候存储要死了，插入2000万行、更新多少行数据、产生了多少日志需要评估的，所有的性能在90%。那个时候再备份，还能不能更新？能不能去执行业务的升级？这都是我们需要检测的，如果不行就延迟半小时，如果还实在不行，就在规定的时间内告诉研发告诉DB没更新成功（放弃更新）；

关于质量自动评价平台，我们做了十个维度的模型，然后把这个问题的过频，过慢的，Top N的SQL告诉相关的人，比如说研发和DBA，那这个时候我们都能够有所展示。

12、指令处理流程

除了这个GUI可视化平台之外，还有一些大量的一些大的东西，这个是比较常规的，那大家需要根据规范制度用一个堡垒机等安全机制，用一个存储数据的存储，使用审核工具 以及密码的存放机制，然后去安全地操作。

13、建设数据库专用知识库

大家一直都在优化，但是只优化没用，要从整个体系与维度去做。除了技术能力之外，我们要建设技术知识库，根据每个项目要建病历，这个是我一直的理想，我们也一直这么做。我们必须把这个规范和工程手册、项目文档集中起来，大家知道DBA是最不忠心的岗位，在这个时候我们必须一进来就去研究这个东西，那DBA必须在这个场景之下去做这样的一个东西。我们已经建了1500多件自创的文档，有4000多个工具，包括像脚本、自动化的一些工具。

14、建设能力与质量评级7分制

除了这个知识库之外，我们必须有一个客观的质量评价标准，根据这个评级我们要建一个能力的体系，要不断细化。我希望大家能根据这些客观评价你到底做的好不好，给公司一个交代，公司需要做一个客观的评价的依据，我们到底能不能做好甲方的东西，能不能做好市场需要的东西。

15、自动化与监控的关系

自动化的意思是，监控不是只告诉DBA干什么事情的，它是用来做自动化的，是用来自愈的。它最终的是要服务自愈、同步自愈、备份自愈。如果实在不行要数据库服务自杀才能够让应用保持健康，一定要有这样的一个思维。

16、构建效果

这个是我们的一些成果。我很自豪的说，因为我们的业务能力是这样，但是我们DBA的能力要大于这个很多，其实我们已经可以和市场接轨了。

三、预见-未来

云数据库的未来最终是要智能的，这是一个趋势。人工智能我们DBA应该要学一下。

数据库的容器化主要是用于数据库的实例，也把它作为一个接口来对待，要做一个无服务化。但是一个资源池跑到另外一个资源池的时候，迁移到不同共享资源池的数据迁移时，却是与其它的迁移方式相同，大家需要有这样的一个能力。

区块链区块链是一个很好的解决方案，DBA可能要多想一想这个思路。

因为我们的架构是非常高，从每一个节点需要做一个。我想告诉大家的是IBM的自主计算，那本书不厚，但是很有思想，希望大家能够去学一学IBM的伟大之处在哪里。思考我们做的到底好不好？应该怎样做好数据库？

最后讲一下数据库的发展趋势，因为5G到来，到互联网，网络技术有分布式和区块链，有TMT的融合与互联网的融合，人工智能提供智能的数据库是未来我们努力的方向。最终我们要提供一个智能数据库，实现智能运维，尽量人不要参与，因为我们的人是很贵的，让系统参与。最好系统要做到百分之百，虽然说不可能，但是我们要向那个方向去努力。