责任共担模型

朋友和我吐槽，自从他负责的系统上云后，在云数据库上经历了好几次故障，而事后的故障复盘，居然都是他们自己的责任和问题，这让他很被动。更尴尬的是，原想着上云后，数据库的问题都是公有云厂商负责，所以他们运维团队中也没有招聘DBA，当下没有很好的优化思路，于是找我一起探讨这个问题。

朋友的这个Case很典型，认为上云就万事大吉，上云后一旦出现问题，又会觉得上云各种不靠谱。在公有云厂商中，被大家广为认可的观点是“责任共担模型“。在海外，亚马逊AWS、微软Azure均采用了与用户共担风险的安全策略。例如，AWS 作为IaaS+PaaS为主的服务提供商，负责管理云本身的安全，业务系统安全则由客户负责。客户可以在AWS安全市场里挑选合适的产品来保护自己的内容、平台、应用程序、系统和网络安全。而微软Azure也探讨了IaaS, PaaS和SaaS用户的“责任递减”模式。在这里，我们并不打算展开讨论该问题，只是希望引入该概念，让大家建立初步的认知：上云后，依然是需要客户和平台双方通力合作才能取得好的结果。

上云后他经历了什么？

下面是朋友讲述的故障，限于故障原因的重复，我删减了一些Case，听朋友讲完后，我非常吃惊，心里暗想，这和上云有啥关系，这些问题，你不上云照样都会发生的，只能说你运气好，发生在上云期间，大家对于新事物多少有一些宽容，不然，后果不敢想啊。

后端模块批量重启，重启时需要从数据库加载业务数据，因并发重启且该请求为慢SQL（几十秒），云数据库负载快速升高，部分请求开始超时，然后请求失败的模块无限重试，导致云数据库负载过大而崩溃，依赖该数据库的其他业务也全部故障；
在短时间大量并发请求数据库，高峰期并发达到2200左右，导致数据库出现大量慢SQL，进而数据库性能急剧下降，多个业务页面展现变慢，性能退化明显；
批量创建的任务，其执行时间完全一致，系统在瞬间对数据库请求大量数据，连接数上涨，导致该数据库上的所有业务均发生故障；
一次秒杀活动，系统请求量剧增，峰值流量达到平时流量的30倍，远超之前预估流量。部分功能大量请求数据库，占满数据库链接，导致数据库崩溃，进而引起系统无法正常运行；
其购买的安全扫描产品，对接口进行了空参数请求，而接口对于空参数请求进行了数据库的全表扫描，数据库压力飙升，陆续出现了慢SQL，数据库CPU使用率持续在100%，导致该数据库上的其他业务也全部故障；
某服务访问数据库错误导致响应下游请求合法用户列表的结果为空值，下游模块直接将所有用户的权限全部删除，导致系统完全不可用
没有专职DBA，云数据库的变更直接交由研发自己执行，研发多次数据库修改出现异常，导致服务故障和数据丢失；
研发怀疑数据库性能恶化，因此就重启了数据库，重启期间，有一个模块请求数据库失败，就直接崩溃了；
在华南部署的一套业务系统，连到华北的数据库，导致系统的响应时间长期居高不下，原因是一个页面包含了非常多的数据库请求，单个请求延时增加40ms，但几十个请求串行执行，延时足足增加了2s以上。

故障原因分析

和京东云平台质量部的同学们对上述的Case进行分析后，我们总结了以下原因：

慢SQL

常态下系统中存在很多慢SQL，其执行时间少则15s，多则60s以上，如果慢SQL的执行次数增加，必然导致云数据库压力上升，数据库连接被占用，处理其他请求的速率也慢了下来，直至连接数被耗光，导致服务异常，或者在连接数没耗光之前，就因为数据库CPU使用率100%而导致服务异常了。

高频SQL

高频SQL看似没有问题，但延时一旦增加或者网络抖动，高频SQL就可能变为较慢的SQL，基于其基础足够大，足以将系统拖垮。

复用

上面的多次故障都是因为某一个业务异常导致数据库故障后，影响到了数据库上的所有业务，这可能是源于期望降低运维复杂度，所以搞了一个最大规格数据库的原因，确实，所有业务共用一个数据库从管理角度肯定更简单。

读写未分离

上述的Case，大部分都是读请求导致的故障，突然间因为各种原因，导致请求上涨，而数据库实例只有一个，没有水平扩展，所以很容易被打挂。

数据库连接数设置不合理

从故障描述中可以看到，随便一个请求，都可以把数据库的并发连接数打到2000+以上，进而导致其他业务不可用，没有对不同业务进行合理的资源分配。

缺乏变更流程

研发直接到线上数据库中修改数据，修改错误的原因有表的名字错了，where条件错了，或者是对较大的表结构进行调整，操作前不在线下进行测试验证，操作前也不进行数据库备份，很容易导致重大事故。

权限管理混乱

多个CASE都是研发直接操作线上数据，这是权限管理混乱的表现，也是很危险的事情。试想，人人都能修改数据库，会有什么后果大家应该都很清楚。如果修改了和交易数据相关的数据，或者是删库跑路，那就麻烦了。

不限流

多个CASE也都看到这个问题，所有的接口都没有做限流，大家可以发起随意量级的访问，因此随便一个用户发起批量请求都足以将系统打垮。

云平台质量部的建议

结合该朋友的情况，云平台质量部的同学经过讨论后，对数据库的改进给出如下建议，而对于一些较为通用的问题，如系统异常后直接崩溃，空参数等等，则不在此进行讨论，我们后续会有专门的文章进行说明

TOP-N的SQL限流

TOP-N的SQL分为两种情形：

慢SQL，也就是执行耗时的TOP-N

SQL优化
合理设置数据库连接数
执行耗时超过1s的SQL直接kill（对于部分场景可以进行自定义，如同步任务，写SQL，重要性较高的SQL等）
SQL问题较多的账号进行紧急封禁

高频SQL，也就是执行频次的TOP-N

通过业务层的缓存功能减少高频SQL

在京东云上，提供了性能优化的功能，可以查询到所有的慢SQL，一定要加以使用。

最后提一句，一定要想办法在集群上实现自动化kill慢SQL的功能，而不要等遇到出问题后挨个找人来看能不能杀这些SQL，那就太晚了，经验值，一旦走到这个地步，故障时长起步40分钟。

隔离部署

核心业务必须使用独立的数据库实例，仅非核心业务可以考虑共用数据库实例。从而避免单个用户的问题影响到所有业务。但隔离不仅仅是基于业务角度进行隔离，还可以根据业务情况进行其他维度的隔离，例如将一些报表类业务从核心业务中剥离出来，类似的思路，业务运维的隔离方式有很多，可以参考《任务调度系统如何通过隔离提升可用性？》

从成本角度看，京东云很好的考虑到了这点，两个小实例的价格等于一个大实例的价格，因此拆分并不会增加费用，而管理成本的增加也非常低。

读写分离

京东云的云数据库提供只读实例，且只读实例应该尽量分布到多个AZ中，从而实现应用程序的就近访问。简单点就是新增几个只读实例将读请求进行迁移，复杂点，可以将不同业务类型的读请求分配到不同的只读实例上，利用隔离的特性将故障控制在较小的范围内，从而保障大部分功能的正常使用。

限流

限流不仅仅在数据库层面通过连接数的方式进行控制，更需要前置在业务侧进行，毕竟业务侧的限流机制会更为灵活和定制化，更能满足业务的需求。如何限流，可以参考《预案三板斧的限流大法》。

数据备份

对数据库的任何修改和调整，都需要进行备份，以免发生上述朋友的问题。京东云提供了灵活的数据库备份管理功能，需要好好的使用起来。这个地方的重要性，就不赘述了。

数据库的监控

没上云之前，可能会有专门的DBA团队来对数据库进行监控，上云后，如果没有专职的DBA，那么业务运维团队就需要承担起这个责任来。下面是从京东云的监控中截取的几个关键指标，当然，还需要有对数据库功能的监控。在这点上，云平台质量部有较为丰富的经验，大家也可以参考《一份运维监控的终极秘籍！监控不到位，宕机两行泪》。

流程建立

对于变更和权限管理等，都需要逐步建立起相关的流程，并尽量自动化起来。同时，针对各种高频操作，还可以提供如操作手册，checklist手册等，尽量减少手工操作。

三板斧

我个人的习惯，任何问题，提供了多个解决方案后，最后都要通过三板斧来进行优先级排序，便于大家抓住重点。

隔离部署&&读写分离，利用京东云的能力，可以快速搞定，所以放第一位；
TOP-N的SQL，找出来容易，优化则需要研发配合，因此放第二位，可以先从那些执行时间几十秒的SQL开始下手；
限流，或者在接入层进行，或者核心模块上进行开发，耗时略长，因此放第三位。

最后，感谢平台质量部的多个小伙伴一起群策群力完成的上述方案。

参考文献：

《责任共担模型》

创作场景

上云了，如何保障云数据库的高可用？