当下泛 DBA 化的趋势是非常明显的，一方面业务对多类型数据库的实际需求，DBA不能只立足玩转一款数据库产品，关系型+非关系型/OLAP+OLTP/图数据库/消息存储，但凡跟数据有关的都可能是 DBA 需要去了解的。另一方面上云后 DBA 不用再为过去繁重的基础设施稳定性保障所拖累，同时云上提供了运维管理相关的 PaaS 化产品，这很大程度降低了 DBA 管理的复杂性，因此很多人会认为上云了对 DBA 的依赖就降低了或者干脆就不需要 DBA 了。

从近3年对云实际使用经验看，在人员与业务体量小一点的公司对开发&运维&安全标准规范都没有严格要求跟约束的情况下是适用的，但是体量稍微大一点就玩不转了，尤其混合云的环境下依靠云商能力是很难解决自身个性化的需求的。尤其体系化建设是无法依靠堆“云产品积木”的方式去构建。

提到体系化建设总给人一种很虚的感觉，到底体系化包含哪些内容？主要围绕着3个方面的能力建设上：

接下来简单介绍一下货拉拉围绕上述三点进行的相关能力建设。

货拉拉 DBA 团队管理了MySQL（阿里云RDS、华为云RDS、AWS-Aurora RDS）、ES、Kafka、RabbitMQ、Redis-Cluster 以及各种组件 Canal/ZK 等)，同时在全球有若干个 IDC，每个 IDC 又包含了多环境（测试、预发、生产），上千人的研发团队，这么复杂的场景跟体量还真的需要一个专业的团队来管理。

数据库上云稳定性并不能做到5个9，云只是解决了基础设施的管理问题，过去DBA在基础设施上投入大量的精力主要就是保障基础设施的稳定性，这么看上云确实能提高基础设施的稳定性保障水平。但是如何在应用层面保障数据库稳定性是不在云商保障范畴内的。

虽然有的云商提供了数据库自治服务但是整体看下来还是比较弱的，且不是每家云都具备该能力，而且自治服务是收费的也并不便宜。

通过对预发环境的 SQL 旁路然后将旁路结果对历史记录进行对比就可以很容易发现每天DB新增了那些慢、危险SQL，然后及时地预警给测试跟研发同学进行优化改造。同时与发布系统打通进行卡口、未优化完成的 APPID 禁止发布，起到拦截作用。

SQL 旁路的前提条件：接入货拉拉自研的数据库中间件、该中间件覆盖了所有云 RDS，基于中间件将各个环境的全量 SQL 旁路且分发到 Kafka 供数据库管理系统 DMS 进行消费处理，每天处理消息量达100亿，单纯消息分析处理能力对 DBA 就有一定的考验。

如何无差别防范任何 SQL 在任何场景下击穿数据库？一方面数据库中间件会实时感知数据库RT情况，一但RT整体响应异常则启动限流功能，或者 DBA 可以主动介入熔断、限流特定 SQL，甚至可以干扰执行计划做到走特定索引的功能。

同时 DMS 自愈系统会实时感知数据库 processlist 列表是否有堆积或者长查询，自愈系统会根据规则进行查杀动作，比如 CPU/IO 异常、SQL 执行时间超过规定时间、processlist 列表堆积、锁等待、连接数超警戒水位等。自愈系统要跟监控系统进行配合才能做到实时的感知能力，这也是需要进行个性化建设的。

可以看到该保障能力建设落地后，我们数据库 thread_running/processlist 列表堆积超过30（云上普遍都是4-8C这样的小规格活跃SQL数定在30相对合适的）的实例比例都不到1%（监控只要发现一次就视为异常），日常基于该指标就可以比较直观的评估最近一段时间数据库稳定情况了。

研发可以基于 DMS 系统获取到对应的慢查询趋势跟详情信息，方便研发进行日常优化治理。当然也需要一些系统外的机制保障研发是在不断治理的，整个 SQL 防控、兜底、治理就算闭环了。

可以看到高危慢查询万分率常态化下都在万分之一附近波动。

围绕 SQL 治理我们甚至做了一个类似阿里云的 SQL 洞察的功能，一方面兼容当前所有云产品其次其他云也不具备该功能而且即使有也不便宜！！

其次威胁稳定性的来源就是日常数据库的发布变更了。发布主要解决3个方面的问题。

就是大家通常说的SQL审核，尤其是在具备一定规模跟体量的业务下SQL规范是很重要的，一些微小的缺陷都可能被大流量、高负载放大影响。由于开源系统跟我们自研的DMS 系统整合比较困难，索性就重新开发了一个，通过数据运营指标发现其实研发是很难遵守规范的，几乎每周都有10%做的变更不合规。所以试图将云上 DB 直接交给开发自己维护这一个角度看就很不可行。

保证 DML 安全执行避免更新行数太大，以及能快速回滚数据吴跟新，对 DDL 尤其超大表能安全顺利变更完成，尤其我们运行在多家云上每家云的架构及内核特点都不一样对DDL的友好性也不同。我们最终还是选择通用 GH-OST 方式，为了降低锁/高并发等对DDL的影响我们也是对 ost 做了很多二次开发确保 DDL 成功。

货拉拉是家快速成长的公司，每天数据库变更量日均在600+，因此发布的效率跟成功率是很重要的，效率上我们发布系统会自动识别部署架构比如阿里云我们由于大量使用分库分表很多集群是没有 slave 节点的或者有 slave 节点单不参与 online 业务，对 gh-ost修改后会自动优化相关 hook 函数保证 DDL 效率优先。

为应对大规模发布我们发布系统被设计成分布式可以轻松扩容的，当发布能力不足时加几个 agent 节点就可以了，理论上我们能应对任何突发大量规模发布。

可以看到我们发布成功率还是非常高的，同时发布时长整体也都在10分钟左右就可以结束。

对 Redis 稳定性威胁最大的无非就大key、热key了。

货拉拉在发展初期PHP是主流，后续不同团队又引入了其他开发语言，由于我们目前采用的是统一Cluster架构，很多语言再对Cluster协议上支持的不够完善，最常见的问题就是集群节点发生调整会导致业务端长时间感知不到底层变化业务持续性故障，还有就是PHP短连接等问题，因此我们设计了一套代理来解决多语言的问题。

对PHP短连接服务实现短链变长链，由于是 sidecar 部署模式引用到 mesh 层的网络开销就比较小，应用RT与Redis节点CPU分别下了40%、60%。

对大key、热key也有了更好的应对方案，比如对大key限流/block访问，大key导致的危害一下就解决了，比如下图因大key导致的网络流量异常限流效果立竿见影。

对热key进行本地化缓存+低粒度更新，rt增高问题迅速得到缓解。

Kafka 本身其实是比较稳定的，但是对业务而言稳定性风险主要来自自身消费延迟感知问题，过去研发普遍会在消费系统里面埋点以此来感知消费延迟情况，但是实际效果上效果不是太理想，主要原因在于现在的延迟度量方式都是以 lags 这维度的，是比较抽象的。

基于时间维度的延迟度量是更直观的，对研发更加友好。我们设计了两个独立方式：

该方式比较简单由于要消费消息取时间戳因此效率非常低，但是比较准确。

该方式不需要消费消息效率非常高，准确度略差。

新的延迟度量有效解决研发对延迟度量上的焦虑，研发可以通过系统比较简单的配置就可以订阅消费延迟告警，也不需要再系统内进行埋点。

实际运维过程中来自 Kafka 本身的故障非常少，日常稳定性问题主要集中在诸如网络、磁盘异常导致的整体业务抖动，以及在防范一些 topic 生产或者消费导致的资源严重占用造成的相互响应问题。针对这个问题 DMS 系统设计了一个租户的概念，DMS 对集群broker 节点进行编组构成一个 Zone，创建 topic 时将 topic 指定到特定 Zone，实际创建时通过 go-sarama 接口将 topic 指定到特定机器（Zone），如下图：

这样设计的好处是实现资源隔离的目的、故障隔离的目的。比如某个Zone的机器异常不会影响其整体，同时对于单个Topic读写过大导致的资源占用也能很好的应对，同时还解决了Topic自由调度的问题，比如可以将一个小规格Topic迁移到大的Zone内，过程是对业务无感的也不用换链接地址。最后对提高资源利用率有很好的作用，因为不同Zone用的机器规格可能是不同的，日常扩缩容可以精确到Zone，避免集群整体扩容造成的浪费及业务影响。

篇幅原因不一一介绍了。

前面介绍过了货拉拉的基础环境其实是非常复杂的，DB选型多种类多，分布在几朵云上，每朵云都有独立运行的环境，DBA其实是很难通过云产品进行有效管理，如果只用单一云服务且体量有比较小依靠云 PaaS 产品也能解决一些日常问题，这显然不适合我们。

站在DBA跟研发的角度看都有共同的诉求：通过一个入口一个平台搞定所有日常运维需求+研发所有需求，因为站点、环境、选型太多了，先不论云上是否提供了类似能力，即使有对于一个上千人的研发团队也是极其低效的。因此一套大一统的系统架构是必要的。

对DBA而言无非就是通过系统将日常工作自动化掉，且在一套系统上完成。

整体对DBA而言日常90%以上的工作可以借助平台完成。

对研发而言无外乎就是资源申请、发布、告警订阅、变更、安全等自助化服务，这些由于内嵌了公司的很多流程、SOP 这一点云商 PaaS 是很难解决的。

DBA日常维护了MySQL、Redis、Kafka、ES、MQ等中间件，支持上千人的研发团队，日常咨询量减去知识库拦截率实际需要DBA人工支持的Case每天不足20个，研发日常大部分需求都可以通过DMS自主解决。

成本治理大致两个手段：运维手段进行资源治理、技术手段进行资源合理利用。

以我们成本占用比较高的MySQL、Kafka为例。运维上通过缩容、将配我们很快榨干了明显使用不合理的资源。在需要有所突破就很难了，因此需要在技术上找到新的增长点。

由于云是规格整体是偏小的应对突发异常的情况是比较弱的，我们将数据库拆分的比较细因此我们下掉了大部分slave节点。

经典存算一体架构下存储与计算是存在绑定关系的，不管是云上还是自建都会存在这样的关系，比如在云上你要买3T的存储你的CPU都不能低于8C，或者你要买一个16C算力你的存储不能少于3TB，这就会出现算力与存储不匹配的问题，造成算力跟存储的浪费。自建IDC下尤其如此 因为方便统一运维与硬件采购可能所有数据库服务器的规格配置是一致的这个浪费更加明，搞过自建的同学应该深有体会。今天我们可以充分利用云的能力来最大程度的提升我们的资源利用率加上我们自建能力及云的能力实现既便宜又好用。后续ServerLess架构成熟后相信成本控制上会有更丰富的手段。

自建环境下是很难将平均存储使用率做到这么高的，在2023H1结束前我们预计存储平均使用率能做到75%以上。CPU平均使用率15%左右，做到这一点是非常困难的，要兼顾成本跟容量安全，这块我们前面在稳定性介绍里提到了我们是具备比较强的应急处理能力的，确保我们具备探索更多的可能。

基于前面介绍的多租户的方式、不同场景使用不同配置的租户，不同租户内实现定向扩缩容，能有效的避免Topic间资源分布不均导致的资源浪费。

Kafka历史上为应对突发消息暴涨我们规定了存储使用超过50%可能就要扩容了，当前的磁盘、CPU平均使用率还是比较高的。

个人觉得上云后 DBA 的分布也应该是橄榄型的，大量的开发型 DBA 承担基建工作，很少量的运维型 DBA 仍旧承担传统 DBA 的部分工作，DBA 架构师来掌控全局。

作者简介：

蔡朋@货拉拉

10年+DBA工作经历曾就职饿了么、蚂蚁，现任货拉拉数据库部门负责人，负责数据库、缓存，消息队列的管理与平台研发工作。