共计 7305 个字符，预计需要花费 19 分钟才能阅读完成。
导语
阿里巴巴集团拥有超大的数据库实例规模，在快速发展的过程中我们在运维管理方面也在不断的面临变化，从物理器到容器、从独占到混布、从本地盘到存储计算分离、从集团内到大促云资源，从开源的 MySQL 到自研分布式数据库，运维管控进行了自我革新与进化。
作者 — 谭宇（花名：茂七），阿里巴巴高级技术专家。2009 年加入阿里，对分布式系统和数据库领域有很大的兴趣。目前负责阿里巴巴集团数据库中台建设，支撑了集团数据库在容器化、存储计算分离、在离线混部、大规模迁移建站以及智能运维等技术探索与落地。
本文梳理了阿里巴巴数据库运维发展历程以及对未来数据库自治时代的看法，期待与诸位一起讨论。
正文
我在阿里快十年了，前五年做一些分布式系统开发相关的工作，参与的系统包括 TFS/Tair/OceanBase，后五年聚焦在数据库运维平台及服务的建设，从搭建数据库集群、数据采集等底层运维到外部客户服务、POC 支持等都有所经历，好的想法历来稀少，外加个人天资愚钝，不敢说有什么独创的想法，都是实践过程中的一些感悟，且与大家分享，也是对过去一段时间的总结。
关于阿里的数据库，大家可能已经听说过很多，阿里巴巴数据库技术的发展与整个集团的技术发展类似，从商业到开源再到自主研发。早在 09 年以前，阿里巴巴数据库或 DBA 团队已经在业界非常知名，拥有多名 Oracle ACE / ACE Director，外加自发性的与业界的交流、分享以及著作，构建了非常强的影响力，很多人因此吸引而加入，这是一段荣耀时光，当时很多知名人物现在有的在创业、有的仍在集团不同的领域奋斗，江湖中仍然可以搜索到他们的传说。
后来就是轰轰烈烈的去 IOE 运动了，刚入职时经常在内部 BBS 上看到各种成功去除 Oracle 的帖子，基本套路就是 DBA 和业务开发一起配合，通过各种脚本把数据迁移到 MySQL 上。在这个过程中，遇到过很多问题，也在积极寻求各种新的技术，比如为了突破磁盘性能问题，在当时主流的还是机械硬盘的时候，使用了 Fusion-IO 等，也在 MySQL 内核上开始各种改进，形成了 AliSQL。
关于去 IOE、各自数据库内核技术、支撑的业务这些方面，讲的很多，大家可以搜到各自技术相关的文章，但很少有人讲过这背后有一个什么样的平台来支持这些业务变化以及技术迭代。过去的 5 年里，我和我的团队一直在做数据库运维或者是服务方面的事情，很难，我相信各位如果有做过这方面经验会感同身受。
一方面，这是运维类或服务类系统的“原罪”，这类系统形成初期，它只是一个工具或一个平台，使命是支撑好业务，自己并不实际产生价值。所有的技术要在这里落地，等落完地好像和你又没什么关系，价值感比较弱。今天 K8S 等系统的出现说明这个也可以做得很好，但相对来说这是一个更难做好的领域。
另一方面，业务的复杂性、技术栈的多样性以及所依赖的组件决定了这个系统在实现层面很难，你需要把各个组件一层一层的串联起来。从业务访问到数据库内核再到底层的网络、存储、OS、硬件等，任何一个层面出了问题都会集中反应到你的系统中，实现人员面临着从上到下各个层面问题的理解、异常的处理，对团队及个人能力要求极高。
一个很具体的例子，我们的运维系统涉及了前端、大数据处理、算法、数据库、底层软硬件等各个技术领域。在最初期团队不可能有各个领域的专家，需要每个同学了解并解决不同的领域的问题。
我想就这些方面，系统性地跟大家介绍一下我们所做的一些工作。主要包括三个方面：第一，我们整个系统的发展历程，所谓从历史看未来，不知道过去，无法推断出未来我们的样子。第二，现阶段的技术和产品，比如我们如何支撑我们现有的工作，双 11 大促等。第三，从过去和现在出发，我们未来一段时间要到达的样子。
1. 从历史看未来
阿里巴巴数据库运维发展的历程，主要有这几个阶段。09 年以前，以商业数据库为主，去 IOE 也才开始。之前没有整体运维规划、运维平台。使用了各类脚本、工具。
在 09 年以后，由于规模迅速膨胀，这个时候自然产生了一些工具团队，把各类脚本拼在一起，弄个界面，形成了最初的产品。
接着，随着复杂度进一步增加，以及云计算的推动。交付方面有了更高的要求，形成了服务化，比如 DBaaS 等。
近年来，随着大数据、机器学习等技术的发展，AIOPS 催生智能化。在智能化的基础之上，对各类服务平台的服务质量的进一步要求，也就是自治。
总体来讲，有两次比较大的革新。
第一次是从产品化到服务化。最初，我们的产品形成非常简单。没有什么平台，没有什么系统，大家一边干活一边沉淀一些脚本，到处分发。随着规模的增长，原来的那套脚本需要管理起来了，我相信很多团队最开始都会设立一个工具组，专门来干这个事情。这就会演变成一个团队做工具，另一个团队来使用，慢慢的两者之间的 GAP 就出现了。工具团队有工具团队的 KPI，业务团队有业务团队的 KPI，分歧会逐渐增大。
另外一个问题则是大家都在攒工具，攒平台。结果这些平台之间是相互不能通信的。比如一个应用开发，需要数据库、搜索、分布式存储等各个系统，开发人员需要去逐个申请，效率不高。
服务化的变革就是在这种情况下发生的。我们不提供工具、平台，而提供服务。这些服务之间相互打通，并且我们对提供的服务有相关 SLA 保证。这次革新可以说是云计算的基础，云计算的本质是 IT 资源交付技术的进步，这是云计算带给我们的最大价值。
第二次革新是自治，我们目前正处于这次革新中。
对 SLA 或者服务质量的追求是没有止境的。现在很火的 Cloud Native、Serverless 本质上都是对更高服务质量的一种追求。要提升服务水平，关键点有两个，一是规模，规模大了才能做更多事情，比如混合部署、智能调度、机器学习，都要求一定的规模和大量的数据。这也符合当前提供基础服务的云计算趋于集中的趋势。
规模也是问题的根源，管理一千个实例和十万个实例所需的技术完全不一样，所以另一个关键点是技术水平，有了规模还必须有相应的技术，比如容器化、机器学习、存储计算分离、RDMA 网络等技术的提升。
2. 理想照进现实
当然技术的积累是一个长期的过程，积累到一定程度就会引起质变。我们这些年在系统建设、技术积累方面所做了许多工作。先来看一组数据，这是刚刚过去的双十一数据库相关的一些情况。
大家可能看过一些数据，比如成交额，交易峰值。对于背后的数据库而言，每秒有超过 5000 万次的访问。特别是在高峰期，读写比是和平时不一样的。通常一般系统读写比大约是 9：1 或者 7：1。但在双 11 高峰时，数据库的读写比可能是 2：1。在写入比例极高的情况下，要求数据库不能出现任何抖动或者延迟，我们对任何一种新技术的引入都非常严格。
另外，阿里巴巴大促场景非常复杂，包括线上线下以及海内外多种场景。基础设施分布在全球多地，数十个机房同时支撑，系统复杂性非常高。
总结来看，我们的业务场景大致有以下几个特点：
业务多样性。作为数据库中台，数据库团队要支撑集团所有业务。包括核心电商、线下新零售场景以及各个独立子公司。各种场景对数据库的要求也不一样，比如线上场景就要求高并发低延时，故障快速恢复。线下场景则要求绝对可用，而且接入及使用数据库的方式都不受控制。而新加入阿里体系的收购公司，有原来的运维体系，要求他们做改变也不太现实。总之需求的多样性对数据库的要求非常高。
基础设施多样化，数据中心分布在全球，有的用公有云、有的有自建机房，有的用物理机，有的用 Docker、用弹性计算等，整个集团就是一个超级大的混合云。
双 11 超级大热点，除了成本和性能方面，双 11 在弹性方面有很高的要求。我们也不可能为双 11 买这么多机器，那太浪费了。早期，会在不同的业务线之间进行拆借，比如借云的机器或者借离线的机器，大促后归还，全靠人肉搬机器。整个大促周期非常长，人力成本和机器成本都很高。
针对以上情况，我们形成了如下架构。主要思路是向下层屏蔽差异，向上层提供多样化服务能力，中间围绕着弹性、稳定性、智能化进行建设。
早期的运维系统因为各种原因，没有设计好的架构导致难以扩展，最后越来越臃肿，推翻重构的事情并不少见。现今，我们设计了服务化的运维系统整体架构：
一来可以清晰地理顺系统各个模块之间的交互方式并标准化，彻底解决原来工具时代遗留下来的各自为政，各个功能散落在不同地方的问题，整个系统的发展不再背负历史包袱；
二来可以解决技术栈太多的问题，从前端到底层采集、算法分析，我们不可能统一成一个框架、一种语言。让这些模块能互不影响、互相交互，是整个系统能做强的基础；
三来可以将整个系统的数据集中起来，为后续智能化所需要的统一数据、统一算法提供基本要素；四来可以向外提供统一形式、功能多样化的服务。要想做好做强一个服务类的系统，服务化是第一步。
在底层，我们做了统一的资源调度层，用来屏蔽底层计算、存储、网络资源的差异，向上交付标准的容器。
中间是数据库层。因为业务的多样性，数据库类型多种多样，运行在不同的环境，我们通过统一的命令通道和采集通道的抽象来屏蔽这些差异。
再往上是传统的数据库运维层，包括常见的数据库的生命周期管理，我们称之为 Lego，希望 OPS 这样的基础功能能像乐高一样百变组合，迅速搭建我们想要的功能。还包括数据采集、处理存储的模块 Kepler，我们希望把所有的运行数据实时采集到，然后通过大数据处理、机器学习等手段发掘出深层价值，采集的数据包括 OS、网络、存储，数据库的 SQL 流水、性能指标等等，整个处理的数据量非常大，并且所有指标都要求是秒级的。每秒都要处理超过 100G 的原始报文。
再往上是智能决策层，这一层完成自动修复与优化的工作，比如预期内的故障，异常处理。也通过采集到的数据，做一些分析和决策。
我们把整个系统的功能以服务的形式提供出来，大家可以在这个基础之上定制想要的功能。过去几年，我们在架构实现方面一直坚持“一个平台、一套架构，集团孵化、云上输出”的策略，集团内部数据库管控平台提供服务，所有模块在一套架构下实现，产品在集团检验后开始在云上输出。不同的时期有不同的坚持，在智能化时代，我们对这个架构及策略也有所调整，这个在后面会提及。
解决架构问题后，我们过去两年主要围绕几个能力进行建设，一是容器化与存储计算分离，二是快速弹性与混部的能力，三是规模化交付与智能运维，这几项工作都是今天能够发展成为集团数据库中台以及支撑双十一的关键能力。
第一，容器化是技术的量变到质变，容器并没有很多开创性的技术，各种技术合在一起开辟了新的思路。所以在把数据库放到容器里首先要突破我们的运维思路，坚定可以把数据库放到容器里的这个想法。当然这个过程中也遇到过稳定性和性能问题，比如网络在使用 bridge 模式的时候，会有些 CPU 的增加。
最终在网络团队不断优化后，基本可以做到与物理机持平。容器化一方面解决了很多环境问题，另一方面也为数据库的调度提供了可能，我们从 16 年开始做数据库容器化，到今年，绝大部份的数据库都跑在了容器里。
第二，存储计算分离。其实数据库最开始就是存储计算分离架构的。在互联网时代，这个架构在最初遇到了瓶颈，因为互联网时代的容量扩张非常快。然后出现了分布式系统，把计算搬到数据所在的地方。但是随着技术的发展，特别是云的交付方式，存储计算分离的交付则更为便捷。交付多少计算能力，交付多少存储，一目了然。
另外，存储和计算的发展也不太均衡，比如双 11 的时候，我要求的是计算能力，其实存储并没有增加多少。所以随着技术的发展，我们这一圈基本上又转了回来。当然存储计算分离要不要上，我们也是经过了很长时间的讨论，今天来看，上存储计算分离这个决定是对的。在这个过程中也遇到很多问题，主要是延迟的问题，毕竟经过一层网络，IO 时间是有增加的。
我们最开始上了左边这个架构，将远程存储挂载到本地，这个延迟要较本地盘大很多，核心业务难以接受，在这个基础之上，我们大规模引入 RDMA 网络，通过 DBFS bypass 掉 kernel，延时基本能和本地盘相当，所以今年所有的核心业务就跑在了这个架构上。
有了容器化和存储计算分离的基础，就可以比较好的解决弹性问题了。之前我们的弹性主要靠搬数据加搬机器，现在数据可以不用搬了。我们大促所用的机器主要来自两个地方，一个是离线资源，另外一个是云资源，我们用完之后云可以继续对外售卖。
大家知道，双 11 的高峰期主要在零点时段。所以我们在高峰期来的时候弹性扩容，高峰期结束立即缩容，还机器给别人用。我们结合集团的调度，做了一套混部调度系统，可以做到数据库快上快下，今年我们的核心集群 10 分钟就可以完成弹性扩缩，而我们最终的目标是在 1 分钟内完成。
第三，交付和诊断。我们说云计算是 IT 资源交付能力的进步。我们基本完成了向用户交付数据库资源，开发人员可以通过系统自助完成数据库资源的申请与使用。如果只是把交付理解为用户自助获取数据库资源的话，我们已经完成得很好了。
但集团有更严苛和复杂的交付任务。比如下面两个例子：大促时需要在上十万个数据库实例里扩容数千甚至上万个实例，大促完成后还需要缩容回来。每年有固定的或临时的建站、迁站等操作，例如今年的一路向北和上海、张北多次建站，可能会涉及到数万数据库实例及数十 PB 数据，这些都非常考验我们交付的能力。
之前的常规做法是让人来评估，确定好操作的数据库范围，算好需要多少机器资源，如何摆放等，再通过我们提供的迁移操作来完成。人需要来控制其中的每一个步骤，这是一个相当繁琐的工作。每年都要做那么几次，在我们今天要求快上快下的时候就显得特别力不从心。
所以我们提出软件定义部署的概念，类似常说的编排。主要做两个事情，一是把我们的这些操作都精确定义和记载下来，线上的运行环境也能用代码精确定义出来。二是把中间的腾挪步骤交给系统，人只需要描述最终的状态，在我们预测准确到一定程度后，这个最终描述状态也可以由系统来完成，真正的完成大促自动化交付。
可以看到，我们的链路其实很长，中间的各个组件出了问题诊断是一件很难的事情。Gartner 有一个名词叫 AIOPS，相信大家都听说过，其实 Gartner 提出 AIOPS 很早，最开始指的是基于算法的 OPS，随着 AI 技术的发展呢，他顺势把这个词的写法给改了，但本质上没有变，仍然是依托大数据、算法来改变 OPS。
应该说这也是个朴素的概念，我们在差不多时刻也提出了这个想法，最开始叫做数据驱动，后来改名为运行数据与数据运营，也是通过各种算法，比如基线、异常检测、关联分析、趋势预测等等来自动决策或辅助我们决策。
这便是 CloudDBA 的初衷，先把各种采集到的数据汇聚统一、预处理再加上领域知识和算法，打通从用户到 DB，从 DB 到底层硬件这两个链路。在双 11 的时候也能实时的诊断访问链路。当然这里待挖掘的还非常多，现在我们可以说只应用了非常小的一部份。
最后，我把之前讲的这些都融进了一个产品 HDM，全称是混合云数据库管理平台。Gartner 有一份报告指出，到 2020 年的时候，有 85%的企业会使用混合云的架构。这和我们的判断是一致的。之前提到过，阿里巴巴集团就是一个超大的混合云，所以我们推出了 HDM，帮助企业把混合云数据库架构打通。
HDM 主要提供两大功能，一是统一管理，不管是云上的还是云下还是其他云的数据库，都可以进行统一管理与诊断。二是弹性扩展，一键把数据库上云也不再是梦想。在数据库层消除本地 IDC 和云的区别。
在提出 HDM 后一段时间里，我一度认为这基本上就是数据库服务的未来了。但这些年，不管是数据库领域，还是运维领域，都在飞速的向前发展，我们似乎又到了一个技术集中爆发的时间点。一方面是新的软硬件技术，比如容器、高速网络，机器学习，另外一个是云计算的发展，都在不断的推动我们向前，提供更好的交付及服务。
3. 通往智能之路: 自治数据库平台
在数据库领域，有自治数据库、智能数据库，在运维领域，有 AIOPS 等等。这对数据库运维来说到底意味着什么，我们结合过去和现在的情况，提出了自治数据库平台。这个定义是很多人一起讨论了很久才定出来的。
首先是平台的能力和目标，我们希望能做到自动驾驶，简单的说就是不需要人的参与。要做到这个，就要具备自感知、自决策、自恢复、自优化四大能力。其次是平台能为数据库赋能，今天的现状是我们用了很多种数据库，不能对每个数据库有很高的要求才能自治，我们可以进行能力分级。
我们也有非常明确的业务目标，这是阿里数据库事业部掌门人公开的目标：在 2020 财年结束的时候，阿里集团 85%的数据库实例要能做到自动驾驶。我为此定了两个评估指标，一是没有人接收这些数据库的报警，另一个是稳定性要达到 99.995%。
目标有了，具体怎么实现？首先，自治是一个技术的量变到质变的过程。在过去的一段时间里，我们应用了大量的新技术，包括存储计算分离，大数据处理与机器学习等等，掌握好这些技术是自治的基础。
有了这些技术，还需要革新我们的思路，就像今天的电动汽车或自动驾驶，由传统厂商来制造，都显得差强人意，这一方面是思维定势，另一方面则是有它的历史包袱。
我们需要破除这些，比如我们之前的数据、运维、资源都是分割开来的，所谓自动处理都是先接收一个报警，然后根据报警的内容做自动化，这明显没办法形成一个统一的整体。今天我们需要先去构建整个骨架，然后让数据、算法去丰富、去润滑整个系统。
另外还需要专业知识。数据库是高度专业的系统，之前可能由 DBA、内核开发人员去调校，靠数据，靠试错，靠经验。这些知识如何精确化、数字化下来，让系统也具备这些能力，是我们要去努力的事情。
最后，重要的一点是要持续提升原有的基础能力，不是说我们今天智能化、自治化就是数据和算法，其他基础能力同等重要，比如 OPS，我们提出了一个 ad-hoc 执行：假如决策模块作出了一个决策是全网内存水位高于 95%的数据库实例做一个 action，你要能够很快执行下去。
我们目前正在向这个方向前进，预计很快我们就会对一部份数据库实例实施自治，欢迎有兴趣的同学加入一起建设，共同迎接自治时代的到来。
本文作者：七幕阅读原文
本文为云栖社区原创内容，未经允许不得转载。
