腾讯云基于QQ、微信、腾讯游戏等海量业务的技术锤炼，从基础架构到精细化运营，从平台实力到生态能力建设，腾讯云将之整合并面向市场，使之能够为企业和创业者提供集云计算、云数据、云运营于一体的云端服务体验。
10月31日，在第十一届中国系统架构师大会（SACC2019）现场，腾讯云数据库负责人林晓斌进行了以《大规模云数据库系统挑战和演进-易用性篇》为主题的演讲，深入浅出地介绍了腾讯云数据库系统在如何实现更高易用性方面的设计思考与实践。
一、数据库系统的基本要求
说到数据库系统基本要求，我们认为前面三项——可靠性、可用性、安全性，是及格线。
一个数据库系统天然要有可靠性，数据一定要有跨城市的冷备，保证不会丢。可用性是，在系统运行时正确存取所需信息，当系统遭受意外攻击或破坏时，可以迅速恢复并能投入使用，例如每一次主机故障最多影响60秒。安全性是指所有的操作都要有审计，可以防止信息的泄露和被盗。腾讯云数据库的安全技术提供跟微信支付同一套相同级别的安全能力，所以用户都不担心会有第三方窃取数据，比较关注我们怎么做到云上的运维工程师、运维方提供的安全性。
说到这三点，大家知道哪一个优先级更高？那肯定是安全性，数据不能丢也不能被偷走。下一个是可靠性，要保证每次写下去的数据一定能读出来，写下去的数据一定不被丢掉。下一个是可用性。如果发生冲突，比如可靠性跟可用性出现冲突时，应该选哪一个？当然是可靠性。比如主备切换时，主库瘫痪，如果判断备库有丢数据的可能，那我就不切，我一定要保证没丢再切。怎么保证没丢？多等一会儿或者多做验证，比如多花一分钟做验证，这时候拿可用性换可靠性，这些是基本要求。
性能和成本属于性价比，算是80分线。
说实话这十年以来数据库性能的优化和成本的降低主要得益于硬件的发展，比如磁盘读写能力，机械硬盘的iops是几百，现在都是按几十万来的。当然软件技术也在革新，不过最主要的原因还是硬件在发展，适配这个发展，数据库系统的设计思路也发生了很多改变。
真正把一个系统做到成熟了指标是什么？是易用性。在我看来，易用性是服务成熟度的标志，大家过了60分线跟80分线以后，拼的是易用性。
在制定目标时，在易用性方面通常都是说超出预期。那么一般我们说超出预期的时候，应该超出谁的预期？当然是超过用户诉求的预期。
二、超出用户诉求的预期
谁是用户？做一个数据系统，DBA就是我们的用户吗？实际上不止，我们认为一个系统的用户有很多，DBA是主要使用的人，研发和到服务端的售后一线也是这个系统的用户，还有云自己的运维工程师也是用户。
我今天站在云数据库系统开发者和设计者的角度上进行分享，怎么让所有的用户都做到超出预期——跟超出预期相反的是不及预期。每一类客户有多少诉求，我会挑最重要的三点来讲；每一类诉求做的不好是怎么样的，做的满足预期或者超出预期又是怎么样的。
1、客户DBA要什么？
客户的DBA希望：第一，维护成本低一点；第二，弹性能力好一点；第三，解决问题速度快一点。
1.1）关于维护成本
当你在做一个系统的时候，要先想到维护成本。我用三个颜色来表示满足预期的程度，最上面的是不及格情况，中间是满足预期的情况，下面这个是超出预期的情况。还有一个隐藏的，我们还可以再往前一步，不过没有列出来。下面我们慢慢分析。
从运维的角度来看，最不喜欢的就是封闭生态。大概在六七年前我碰到一个做自研系统的专家领军者，他说我们这个系统做得这么厉害、这个数据库做得这么厉害，不需要兼容开源协议，我自己搞，客户一定会跑来用我的。结果后来过了两年，市场就教育他了，后来他开始做MySQL兼容，过一段时间做Oracle兼容。
封闭生态意味着高学习成本和维护成本。客户DBA会想着自己构建的技能树在市场上的价值，对自己成长有要求的DBA，可能会提出系统至少要兼容开源协议。现在大家都知道，不管国内国外自研的数据库，都会或多或少的兼容开源的协议，大概也是经过了这个市场的教育，做得更好一点。
是不是兼容协议就算融入生态？不是，兼容协议是可以用客户端连上查询，就没了。备份迁移工具能不能直接使用现有的开源体系？如果可以，我们觉得这个系统做到超出用户预期。听上去像是全新的东西，但是我用原来市场上找到的、几乎大多数人用的技能树进行简单学习就可以维护这套系统，这是维护成本。
维护成本还有一个很重要的点，你能不能做到更方便的维护？腾讯云数据库有个天然的好处——微信，我们会把一部分运维操作在移动端上进行支持，所以在DBA外面遇到突发状况时可能不用掏出电脑，只用手机就可以操作。这种事情经过一两次，大家会觉得体验还不错，但是做的时候要想到这件事儿。
1.2）关于弹性能力
弹性能力做得不好的情况是需要手动操作，或者说每一次有什么扩容的操作都需要业务来配合，这样的话DBA会接受很大的挑战。因为所有没有状态的应用层都可以快速水平扩展，当出现问题的时候数据库系统就很可能变成整个弹性系统的瓶颈。当然，完全没办法扩容应该也不至于，只是说做得差一点，得上去各种手操，体现非常强的专业性。这看上去好像体现了很强的专业性，实际上处理问题速度慢，而且风险很高。
能满足预期的情况是什么？可以做到产品化以及小时级别的扩容，稍后我们会说一下这种架构大概是怎么做到小时级别。你说小时级别够不够？小时级别还行。比如电商尤其是互联网的业务，很多都可以支持预先预估，比如双十一快到了、还有618，各种平台都有。运营的人知道什么时候高峰期会来，可以提前做扩容，所以小时级别也够。
超出预期的是分钟级扩容。比如两分钟内做一个无节点，真正做到这样是挺厉害的。能不能说秒级？一会儿我们会说一下，当然秒级不是纯粹靠数据库层能做的了。
我们看一下没有扩展能力系统是什么样。不是完全没有扩展能力，最开始是支持简单的业务，一主一从的数据库，中间Proxy是为了客户切换时方便一点。很多数据库创建连接时成本很高，有了Proxy做连接保持，连接成本会低一点。扩容怎么做，登陆服务器执行各种工具和脚本，速度很慢。
但是这个已经是很多年前的了，现在能够达到大家的要求大概是（上图）这样两种架构，左边是一写多读的情况，一般也可以做到快速的，提前业务扩容，可以支持读的水平扩展，如果再多就得做读能力的扩展。右边是做写能力的扩展，我们系统看上去好像右边明显比左边好很多，如果全面碾压是不是左边不存在了？其实不是，一旦做了分片，有些业务请求需要做跨库操作，中间Proxy这一层需要做数据的操作，比如做排序、分组等等数据库逻辑的操作。这种架构很难保证100%兼容后端数据库，比如假设下面的master和slave是PG，左边架构就可以告诉你，100%兼容PG协议。
右边这种写是可以扩展的，但是一定会有兼容性的问题。一般如果你从单写集群迁移到多写集群，我们一定会建议业务同学要去做业务的回归，赶紧把所有的业务全量回归一下。真正有不兼容，中间Proxy是可以改的，Proxy不难改，有特殊语句我们照这个语句把逻辑写进去就是了。
如果能做到这样的排序能力也还不错，这个架构应该是2012年开始慢慢有人做。这几年围绕这个架构创新，比如基于右边的这种多写节点两PC的事务，如果觉得不够想再快一点，在几个Master之间做连接做分布式协议，让底层来实现分布式的事务，这样的话Proxy工作量可以小一点，系统一致性也更强一点。
这些都算是或大或小的创新，但是这些创新都绕不开一个硬伤，刚才说扩展一定是小时级别的，我们说小时级别是数据量大一点的情况，库很小不用。举个例子，一个节点有一个TB，这时开一个只读节点，把数据拷下来解压追日志，别的不说，下载过程很可能就要一个小时了。右边也一样，如果做数据分片拆分也一样，先拷备份然后进行数据同步。现在业务越来越大，拷数据时间越来越长。这一套方案用得很好的原因是，有很多业务可以提前做预估。大家知道后天要做活动，今天开始扩容，所以小时级别是够的，因为有两天时间让你做。但是这是电商类的、社交类的很难说，事件很可能是临时发生的，不能提前准备。
这个架构只是说满足预期，像数据库、CDB、TDSQL、Mongo、PG都支持小时级别的扩容。差别是CDB没有Proxy这一层，但是没有关系，比如左边读写，没有Proxy我们就可以用域名或者VIP，当然了像左边这种架构如果没有Proxy的话，你会拿到两个IP，一个主实例IP还有一个所有读节点读群IP，这是满足预期的操作。
怎么做到分钟级别？能否在不拷数据的情况下加能力呢？刚才说了历史上大家都在原来的架构上做一些或大或小的创新。2014年亚马逊搞了一个大创新，真正能解决拷数据的问题。最明显的特征是读节点和写节点之间共用数据，这意味着你到现在是一主一从，如果我现在压力大了，想再扩四个从怎么做？不用拷数据了，加四个计算节点就可以了，一两分钟可以扩一个，而且可以并行，这个首创者就是亚马逊Aroura。
腾讯云CynosDB目标是做成这个效果，可以实现分钟级，但不是秒级。首先拉起需要时间，接过来以后里面什么都没有，需要读数据，很重要的工作是要预热内存，还有Master跟Slave之间要同步信息。
分钟级别再往前能不能做秒级，或者一发现就马上做呢？我刚才说了不是在数据库系统内部做的，而是在周边。其实也没有什么系统需要说平时跑100%，只要监控它的增长曲线就可以了。比如一小时前50%，正常线一般就这样了，半小时前70%，20分钟前80%、95%了，非得等跑到100%才扩吗？可以提前扩，需要一到两分钟时间，但是我们可以通过分析系统的压力、趋势去提前预知有可能需要额外的增加，通过这种方式来提前扩容。
客户DBA要什么？简单一点，别让我上火，这是客户DBA的诉求。我们刚才说了能够有这样的一套架构，再加上不管你用成本来做还是提前扩容，这样在扩容方面是做到满足100分的线了。当然这个模式是单master写入，如果真正能做到多点写入大概可以做一些颠覆。目前读写节点磁盘阵列对网络要求也非常高，目前大家都在单可用区里做架构。跨可用区架构怎么办？基本跟上面的方案配套，每个可用区分库。
1.3）关于解决问题的速度
做的最不好的系统就是靠猜，把所有的可能性都处理一遍，比如运维一上去看现象，可能的解决方法有三十几个，每个都试，试完之后高峰期都过了。所以做的不好的就是靠猜，什么都没有日志，很多自研系统容易进入这样的模式，基本上不怎么打日志，或者打的日志都看不出什么东西。
做得好一点就靠专家，靠专家什么意思？日志打得足够详细，专家一来通过丰富的经验、监控数据、日志数据大概能够推测出问题原因，研发照着这个去改一下发现就好了，专家的价值是得到了很好的体现。
这个状态是所有DBA都喜欢的状态，有需要我来就有，我没来你们搞不定，这种感觉特别好。从做系统角度来讲，单个DBA是这样，如果说DBA负责人，更高层级的负责人来说，大家希望靠专家系统，搞不好这个专家很厉害，但来一个新来的同学就花的时间比较久，所以解决问题的时间比较不稳定。我们说满足预期的状态，应该是要靠专家系统。这个专家系统能解决什么事儿？至少简单的问题、固定的套路能够快速给出来。
解决问题的速度需要哪些？
首先要有完备的日志，日志要全，专家上来才有用。接着是简单问题自动处理，这个范围就很宽了。复杂一点的问题，要能够自动给出诊断建议。比如说碰到大量的死锁，这种一般难处理，但是要能给出信息来。大家知道一旦知道出现死锁，这个会开始出现大量消耗CPU的语句，导致CPU全部被用满。CPU一满，原来不是慢查询语句也变得慢查询了。专家一来，尤其是数据库内核专家，一上去先看执行计划对不对，源码对不对，实际很多慢查询是因为系统雪崩影响到的。一个好的诊断系统要能定位得出始作俑者，我可能不知道如何根治它，但是能够找出谁是这场雪崩的触发者，专家上来才能把精力集中在解决重要事情上。
再往前做一步，能够做到发现潜在问题，尤其在公有云服务里面，这个能力特别重要。所有问题一旦出现以后再去处理，都会稍微晚一点，即使有很快的自动化处理速度也一样。实际上所有的问题并不是等到高峰期的时候才产生的，尤其互联网都有封网时间，做大活动之前一周之内都不变更了。这意味着，那个雷就是一周之前埋的，本来从一周之前上线完到高峰期时间有一周的时间可以看，但是没有人管，为什么？因为没事儿。这个语句很差，全表扫描，但是没关系，这个机器IO快，全表扫描执行时间也不到500毫秒，一看很好，过了几天压力一上来，500多个慢查询，全表扫描一起来，系统撑不住了。这个慢查询之前是存在的，所以要想办法发现潜在的问题，告诉你这个有问题，如果你确保这种语句只是很低频不会有并发就没关系，但是如果它有可能是高频语句，需要事先做出提示，把潜在问题告诉DBA专家。做到这样，就算是80分了。
腾讯云数据库智能管家DBbrain就是这样。但是真正做到100分是什么？大家知道DBA的问题是什么？系统做的这么好，老板都不关注我了怎么办？这是个问题。好在现在大家都有微信，所以后面我们结合微信还有小程序的能力，你做得好与不好，如果客户愿意，我们会告诉你的老板。比如上个月这套系统平均分为60分，这个月变成98分了，老板跑来问你，你做了什么事儿，为什么这么厉害？这时DBA就可以汇报展示啦。
客户DBA要什么？第一个是学习东西不要太多，第二个是解决弹性扩容好一点，不要天天救火。第三个是解决问题的速度要快。客户DBA是最累的一群人，他们夹在中间 —上面有业务压力，下面的服务支持如果不给力，就很难受。
2、客户研发要什么？
客户研发要什么？学习成本要低，比如说不要弄自制API，因为客户端什么都不兼容。第二，最好不要升级，用得好好的就不要天天让我升级。第三，不要让我复现。
2.1）关于学习成本
我们先说学习成本，最差的是只有API，外面什么都没有，所有SDK都是官方唯一出品，别的地方也找不到材料。社区里去问，也没有人用过，碰到BUG只好去问SDK开发者，这个成本非常高。这个已经是被改掉的意识了，所以至少兼容开源协议还是需要的，不管做什么系统，我拿一个社区做好的MySQL API的Client直接接上就能用。从研发角度，性能能力，一些简单的操作，我在别的系统可以用，到你的系统也能用，但是我在MySQL上应用经验，诊断快速发现问题的能力，能不能在你这边也直接使用呢？这个还挺重要的。
2.2）关于“最好别升级”
第二个，最好别升级。每次升级都鸡飞狗跳，这是做的最差的情况。要通知所有人，通知所有的研发——尤其是大客户里面研发人员30、40个；通知所有业务我们要升级，你们要注意陪我们升级。升级的顺利还好，升级的不顺利一升级就故障，这是最差的情况。
比较满足预期的情况是闪断几秒，主备做切换。业务端说你要能够做到闪断，这就是满足预期的情况。大多数主备架构里常见的效果，至少业界要求的就是闪断，最好能够让他没有感知。要么别升，要么升的话不知道，这是最好的。把原主库上的请求路由到新主库上去就好了。客户唯一的感知，这个查询比上一个查询慢个几毫秒。就是刚才说到连接保持能力，有Proxy切换的时候就不需要。
2.3）关于“别让我复现”
第三个，不要让我复现。一碰到问题，比如早晨起来发现昨天晚上凌晨两点钟，出现性能节点，一看就是数据库的问题。我们拿到测试环境复现一下，拿什么复现？我也不知道昨天晚上跑了什么。所以最糟糕的情况，实在没辙了，“下次线上出现的时候我们赶紧看一下”，是最差的情况。
好一点的是分析日志到测试环境复现，这是大家目前应该做到的情况。所有系统要有访问日志、审视日志。这个数据库所有时间查询、更新语句精确到微秒，这样真的出问题了不用你复现，我把语句拿过来在测试环境里跑，基本可以完全复现当时情况。跑完以后，把这个结果直接告诉研发。
如果再好一点是保留现场+自诊断。这个系统自己要知道自己的健康状态是什么，平时打100分没问题，有的打分系统发现这个数据库现在不是100分，剩下80分、60分，赶紧给当时打一个快照，保存现场状态。当客户有问题来的时候，直接把当时的现场和诊断结果给他。
3、售后一线要什么？
一线同学很累，他们的诉求是不骂人，客户别骂我，老板别骂我，后端别骂我。客户骂人是解决时间这么长，老板骂我这些问题解决不了非得找后端，后端骂我是为什么这么简单的问题都不会。如果翻译成技术语言就是闭环能力。
这个闭环能力不是售后团队自己要做的，而是这个系统要给售后团队提供闭环能力，售后一线不是只管理数据库。因为我自己负责研发和后端运维团队，我会跟运维团队说，要谅解一线同学，你觉得这个问题不是很简单吗？其实不是。我问你两个linux发型版本的功能差异点，你也回答不出来。术业有专攻，一线同学要是能管所有的产品，每个产品都能做到专家级别，我觉得他就不在那个位置了。
所以你要怎么提升一线的闭环能力？我们还是说是因为系统做的不好，后端黑盒，前线什么都不知道。你要依赖于售后一线同学比客户研发更厉害，这甚至可能是个伪命题。
第二个是最常见的FAQ&专业培训。真正解决问题的方法是让通用型的人才用一套专家系统能够变成专家，这个才能真的解决问题。我可能是普通的一线，每个产品都了解一下，一旦遇到数据库的问题，我用这套系统去解答的时候，我的客户认为我是DBA专家，要有这样的系统赋能这样的能力，这个闭环能力才能做起来。这样的话，前端客户也满意、老板也满意，后端也满意了。后端是专门做数据库的专家，我们作为构建这套系统的人，我们要了解他们的诉求是什么。
4、云运维要什么？
对于云运维人员来说，第一点，日志要准确，如果日志出错了就没得搞。本来数据库系统内部有很多错误，你写一个系统把人家做的很好的返回错误的信息屏蔽了，专家上来也懵。第二，监控要实时。
第三是Release note要准确。能做到让Issue跟Release note一样已经不错了，真正做得好的是什么？我们每一次发布都要告诉后端跟一线，说我这里加了这些功能，这些功能干什么用的，这些功能在什么场景会触发什么样的效果，在哪些场景效果好，哪些场景负作用，要把案例讲清楚。这样的话，这些专家才能够有用武之地，我知道你这个系统详细是什么样，客户来问题才能够解决。
三、小结
最后做一个小结。从下往上，首先是不管做什么，我们都要有服务意识。做云服务的，服务意识是基础能力，而且要知道服务的是谁。我们刚才说，这一套系统做出来服务好多层，客户DBA是我们的客户，一线、前端、开发是我们的客户。把信息透明出去逐层交付，DBA做专家系统让一线能力更强，一线让业务的DBA更强。再往上就是专家系统。
所以DBA团队说，用了云服务我是不是没价值？我会不会没饭吃？从逐层交付想法就知道，这个系统做得再好，还是有专家的发挥空间。我能帮你做智能诊断等很多功能，但是一定有很多新情况解决不了，这时我们退一步，把所有信息展示给你，你来解决系统不能自动解决的问题。客户的DBA再去做针对自己业务的专家系统，再去逐层交付，交付给客户研发。在下层系统做得更好的情况下，用好这个系统，才能提供更好的服务。