| 编辑推荐: |
| 来源作者徐小飞
，主要给大家讲解阿里大数据体系的趋势，Tesla运维解决方案，DataOps数据化运维，数据价值转化等。 |
|
本文摘要：
介绍Tesla如何支撑阿里离线计算和实时计算两大海量大数据平台的标准化日常运维运营，以及探索如何构筑运维领域的知识图谱，打造针对大数据平台和大数据业务的数据化全息投影，实现多维的立体化监控、智能决策分析、自动化执行的运维闭环。Tesla是面向企业级复杂业务系统的数据化驱动运维解决方案，解决方案包含一个统一运维门户(运维工单、运维垂直搜索)和四个运维基础平台(流程平台、配置平台、作业平台、数据平台)，集日常运维工单管理、自动化发布变更、统一配置管理、统一任务调度、智能监控告警管理、异常检测预测、故障自愈等。
分享大纲：
·运维新趋势
·Tesla运维解决方案
·DataOps数据化运维
·数据价值转化
·AIOps征程
开篇介绍：
我所在的团队叫大数据基础工程技术，通俗点说就是大数据SRE(为什么起基础工程技术这个名字? SRE文化里有个最核心的点就是使用软件工程的思想来解决运维问题)，我们团队支撑的是整个阿里大数据生态的运维运营，并沉淀出一套自己的运维解决方案体系——Tesla，这套体系是一个分层体系，包含了面向运维领域功能的运维中台和面向具体大数据平台业务的运维应用。目前Tesla承载了阿里大数据平台及业务共10w+规模节点的日常运维工作。相信了解阿里的人都听过这样一个词——“大中台和小前台”战略，同样在运维领域，我们也是利用这个战略来构筑我们的业务：大中台提供通用的运维领域功能，而小前台可以基于业务场景快速试错、创新。首先我们先看下运维的新趋势。
一.运维新趋势
刚好这几天Google IO大会也正在召开，相信在座的很多同学都会关注，今年的大会中有一个很吸引眼球的话题，就是在开场第一天放出来的两段Demo视频，是个电话录音视频，内容是Google助手帮助客户打电话到发廊或餐厅去做预约。那么亮点在哪里呢?在整个电话预约的过程中，发廊和餐厅的人完全没有感知到和他们交流的是AI机器人。换句话说，AI机器人已经达到了以假乱真的效果，不仅在交流过程中有语气词和思考，而且当话题出现中断时，还会提出反问句，能让话题回到机器人所要的情景进行下去。
Google对外宣称在某些特定领域，例如预约领域，他们已经通过了图灵测试。图灵测试大家可以去了解一下，图灵有一篇针对未来机器智能的论文，一句话解释论文里的图灵测试：当人机交互时，人类完全感觉不到对方是个机器人，那么就标志着进入了机器智能的时代。
大概在三年前，Google提出了AI战略。时至今日，我们看到Google在很多领域都渗透了AI，Google的AI并不是做一个全新的AI产品，而是将AI赋能到它的顶尖产品中。所以，我们表面看到的是预约服务，但其实为了达到这个效果是需要很强大的数据+算法的支撑。我们经常提到的ABC(AI，BigData，Cloud)，想要实现AI，前提一定是大数据和云计算，而在运维领域也同样是如此。这两年AIOps特别火，同样地我们认为要实现AIOps，一定是先有运维的数据和计算，就是说从DevOps到AIOps之间，有一段DataOps必经之路。
如何理解DataOps呢?首先，我们要拿数据来感知我们所运维的系统，继而利用数据分析做一些决策，再往下就是去触发自动化的智能闭环。我们认为DataOps中最核心的过程就是运维感知、决策和执行。
我们把无人驾驶和无人运维做了一个类比。无人驾驶也是Google第一个提出来的，现在有很多厂商投身其中，如果细看无人驾驶，其实我们发现与无人运维类似——无人驾驶是在传统汽车上附加智能感知、决策、智能控制系统。但是真正的无人驾驶还没有达到，即使是Tesla(马斯克的特斯拉)也不例外。而终极AIOps想要达到的是也是无人运维的效果，即在DataOps
的感知、决策和执行三个阶段都附加上AI智能。接下来先看下整体的Tesla运维解决方案。
二.Tesla运维解决方案
上面这张图是阿里大数据的体系，左边最底层是基础设施，包含了底层依赖，机房、天基、Staragent;其上有两大基础平台，一个是飞天平台，这是完全自研的，另一个是Hadoop平台。这两套平台之上分别对应的是MaxCompute和StreamCompute两大存储计算平台;再往上是数据应用层。而右边是Tesla大数据运维解决方案，我们可以看到Tesla贯穿了整个阿里的大数据体系，负责从基础设施到基础平台到存储计算平台的所有产品的运维支撑。
简而言之，Tesla就是在为阿里的大数据保驾护航。
MaxCompute是大数据的核心业务，而DataWorks可以理解为是一个面向开发者的前端，是MaxCompute的门户。
MaxCompute基本上承载了集团90%以上的计算和存储。在阿里，凡是和数据打交道同学都会用到DataWorks。StreamCompute承载了集团几十个BU的实时作业。大家可能感触最多的是每年的双11大屏，这背后都是由StreamCompute实时作业传上去的，可以达到秒级、毫秒级。最后是我们内部的机器学习PAI和AnalyticDB。
这张图是Tesla运维解决方案架构图。整个Tesla运维解决方案是一个分层的体系，从SRE中台到SRE应用。整体是一个垂直体系，也可以拿SPI来分，中台最底层是IaaS，IaaS层是最基础的公共集团的设施，之上是核心运维PaaS层，其中包含四大平台+两大类服务。
四大平台与运维人日常的工作相关，分别是配置平台、作业平台、流程事件平台和数据分析平台。再往上就是SaaS层，提供了所有的平台和服务。Tesla平台支撑了阿里大数据的十几个平台，因为每个大数据平台业务产品的运维特性都是不一样的，肯定无法做到一套运维系统支撑所有的产品运维运营，所以我们就采用了分层战略：
运维开发团队提供平台，而针对具体产品的运维应用由SRE同学利用平台去构筑。典型的SRE应用包括常见的集群管理、资源管理、监控告警、故障管理等。在这张图里我们可以看到DataOps体现在数据分析平台这一层。
这张图是应用维度。SRE应用这一层的功能也是分层的，最下面是其所依赖的基础平台，往上是面向业务的功能(包含业务中心、服务管控、平台运营、工具服务、运维中心和运筹优化)，利用这些功能向上支撑具体的运维场景(围绕稳定性、成本、质量、效率、安全以及体验的维度)，最终服务好业务的各类用户。
在运维/运营平台中抽象出了几块内容，开发框架、资源整合、运维数据化和智能分析。因为最终系统都是相似的，所以我们会给提供前后端框架、服务网关、二方依赖包以及工具插件，业务SRE只需在环境上去获取数据，做数据处理、元数据管理以及提供数据查询的服务。运维数据化(DataOps)就是我们前面提到的，智能分析支撑常见的运维场景，比如最典型的故障处理、监控分析、大促保障以及值班客服等，他们面临的客户是一堆客户，这也是DataOps在SRE应用上的体现。接下来我们重点解释到底什么是DataOps。
三.DataOps数据化运维
什么是DataOps?如何做DataOps?阿里五新战略中有一个新能源，我们认为数据就是新能源，现在已经进入到信息爆炸的时代，大家刷淘宝天猫时的每一次行为都会触发日志，这些日志最终都流到我们的平台里。如此海量的数据，如果能有效的组织管理好，那么就可以从中挖掘出价值，但如果管理不好，就可能会是个大灾难。
算法+技术，再结合数据就会产生新能源，而现在比较通用的数据挑战是我们怎么有效的去收集、清洗数据?如何保证数据的实时性、准确性?如何将无序的、没有结构的数据有序、有结构的分类、组织、存储管理起来?如何通过算法去打通数据，连接、分析数据，并从中提炼出价值?这一系列的问题就是DataOps需要解决的。
什么是数据化运维? 我们这样定义：就是把所有系统的运维数据全部采集起来、真正打通，深度挖掘这些数据的价值，为运维提供数据决策基础和依赖。
从系统“稳定性、成本、效率、安全”多个维度去驱动自动化、智能化的运维运营，从而助力实现真正的AIOps。
相比于传统运维，DataOps的改变可能就是把传统的使用命令、人工决策的运维过程转变成数据+算法的模式。
DataOps是实现AIOps的一个必经之路，是一个运维闭环。如何做数据化运维呢?右边这张图来自《大数据之路》这本书，当然这张图说的是阿里整个的数据中台，阿里数据中台把全公司所有和数据相关的东西都整合了起来，提供了一套统一的数据中台。其中，最下面是数据采集层，往上是数据库同步工具，中间是MaxCompute和StreamCompute，也就是数据存储计算层，最上面是数据服务层和数据应用层。
数据中台中的方案体系是OneData，它是用来规范数据中台，如何维护、组织、管理和使用数据的。OneData之上是OneService，有了这套组织管理和两大计算平台之后，就可以提供各式各样的数据服务，并再向上提供数据应用。在阿里，基本上所有的业务部门都是按照这个套路来做的。
如何做数据化运维?其实就是利用这套大数据体系来构筑大数据的数据化运营体系。这句话可能有点难以理解，更直白一点说，这套体系是由我们来运维保障的，但是过程中我们也利用其来构筑了运维运营体系。因为我们的使命是为阿里大数据保驾护航，而我们的做法也是用阿里大数据来做运维分析，数据化运维分解下来就是运维的数据采集、运维的数据计算、运维的数据服务以及运维的数据应用。
前面讲的是方法论，现在讲讲具体的实操。利用数据中台，我们首先做的是按照OneData规范建立运维的数据仓库，然后把所有运维相关的数据做分类抽象，包含公共数据、业务数据、元数据，runtime实时数据。基于这些数据抽象，我们提供了大量的运维服务和数据服务，比如异常检测分析、故障自愈、可视化流程、运维搜索、运筹优化、全链路诊断以及业务驱动。下面结合几个例子来具体解释下如何做数据化运维。
以全链路分析诊断为例，MaxCompute是一套离线计算平台框架，每天有百万级的任务在跑，这些任务都是由开发同学提交，当作业因为各种原因出现不可预知的错误，大家就会@运维值班人员看看是哪里的问题。后来我们发现，大部分问题是相似的，所以就总结经验，从用户都在这个平台上提交作业到最后执行的每个阶段都去打点、采集分析，做了一套全链路作业诊断工具。
这是一个自助式的全链路诊断产品，提供一个入口，用户只要输入作业ID，我们就能延伸到整个上下游去查询所有的有可能的问题，包括它的资源申请情况、配置是否正确、数据依赖是否都已满足、历史情况如何、是否有长尾倾斜等等。
上图中有我们工具的页面截图，可以看到左边是有分类的，其实在做这个全链路分析工具的时候，我们就把这个场景和去医院体检做了个类比，体检时医生要针对病人的各个环节做判断，然后输出病人的状态，OK还是不OK?如果有问题，立即提出来让病人去某诊室随诊。同样的，我们也是针对作业做了多个维度的检测，而且还会将诊断详情、时间分析、图表分析以及历史对比等，全部都透视给用户。最后的结果报告是用图表分析的，例如稀疏图形资源争抢，毛刺图形部分长尾、任意机器进程CPU消耗分析。
第二个案例场景是硬件自愈，目前我们已经有10万+台物理机了，每天有大量的硬件故障在发生，比如硬盘坏了，主板坏了等等。如果机器比较少，那么我们可能人肉或者直接提单就可以了，但是当量级到了一定程度，每天几十单或者是上百单的硬件故障，这种方式就不适用了。
所以我们就利用这套数据化的思路做了一个硬件自愈的流程。我们也是从服务器上采集到数据，然后流进流计算平台Blink再到数据仓库，做检测分析并得出决策。决策触发流程平台做一些自动化执行的action，调用集群操作系统去做机器维修等。
硬件自愈的本质也是一个三阶段的闭环，在这其中我们的角色有很多。例如有些故障重启一下服务或者双向配置即可解决，而有些故障需要使用万能大法，重启机器才能解决。如果碰到解决不了的问题就要进入无盘状态，去做业务隔离、重新克隆、整机维修，维修完之后自动上线。整套流程全部是自动流转，我们是无人值守的状态。
四.数据价值转化
通过前文的方法论和两个案例，我们大概解释了一下如何做数据化运维，接下来，我们再透视一下数据化运维的本质——从运维数据到知识的价值提取。
这里会涉及到几个概念，数据化运维的前提是先将一切对象数据化，也就是运维的全域数据，构筑完之后，使用知识图谱将这些数据连接起来，之后将数据当做服务提供给人，利用运维搜索去提供一些快速直达的服务。然后让数据说话，数据即视图，最后数据如果能清洗到一个决策时——有价值的知识，那么我们就认为数据可以驱动决策。
全域数据，基本上是运维相关的日志、事件、指标、报警等，特征也比较多，多维度、多层次、时效性、关联性等。这些东西的本质其实就是运维对象和运维事件。
有了全域数据之后，如何把数据连接起来?我们就利用实体与关系这两个概念来构筑运维知识图谱。下面图片是一个全息投影，可以比较形象地描述我们利用图谱来做的事情。我们就是尽可能的利用实体及实体之间的关系，再结合一些外部runtime的数据去还原当时系统的运行情况，然后把它映射到现实场景上去做精细粒度的感知。
当前我们整套知识图谱的数据量，实体数据大概在百万级，关联数据在千万级，同时我们还关联了很多外部runtime数据。
有了知识图谱之后，要给SRE同学使用。我们提供了一套运维垂直搜索功能，这是一个工作模式的改变，之前运维同学都是将很多功能分门别类的排布好，但是当功能堆得越来越多时，用户可能不知道要去哪里找他要的东西。而我们提供的搜索功能，它可以通过关键词来搜索相关的信息，例如搜索一个机器，那么我们就把这个机器相关的信息都推给他，包括这个机器当前安装的软件、进程状态、CPU内存、IO曲线等。
除此之外，我们还整合了阿里集团的所有运维资源，目的是为SRE提供一个垂直领域的搜索服务，改变运维习惯。同时，还提供了一个功能就是嵌入到某一个站点，提供站内的垂直搜索。
数据即视图，当有了大量的数据之后，我们会希望在很多地方将这些数据展示出来。但我们发现这其中有很多事情都是重复工作，所以我们就基于运维的可视化整合了这条链路，我们把所有的数据都按照要展示的格式规范起来。这样的话，只需要提供数据就可以在任意的地方展示，相当于数据本身是结构化的、可视化的。
可视化是基于Grafana，对接了很多的数据源。不过，由于Grafana是angularjs写的，而我们的很多前端站点都是React，所以我们做了一套基于React的前端组件来适配Grafana后端数据源，提供无缝的图表能力。根据SRE同学的反馈，几分钟之内就可以完成一张可靠的图表开发。
数据决策。以前都是人去提单，然后由工单来驱动运维操作来对所用的对象进行管理。但是现在整个思路发生了逆转，首先我们通过事件、监控等透视运维对象，并通过规则、算法等决策服务做出决策，最终完成action执行。简单来说，以前是人围着机器转，现在可能是机器围着人转。
以ChatOps智能运维助理为例，这个场景是某个同学想要知道某一台机器当前是什么情况，他在工作群里@一下助理，然后输入hostname，机器人就会返回这台机器的状态，机器所在的分组、隶属的集群、当前系统状态是不是OK、硬件状态是不是OK、安装的服务软件的状态是不是OK……这其中每个状态的结果都是一个链接，点击之后就会跳转到针对这个问题的详细情况。
现在，针对服务状态、机器状态，我们正在把更多的场景都往ChatOps这套理念来推。它所做的就是将一些简单重复的工作沉淀下来，让这些信息直达用户，缩短用户与功能之间的距离。同时，我们还有一个兜底的意图，因为ChatOps毕竟还是通过一些意图去规则、处理东西，当没有匹配到你的意图的时候，可能就找不到了。这时，怎么办呢?我们把前面做的运维搜索来兜底，如果根据关键词没有搜索到，那么我们就调用搜索接口来做反馈。
五.AIOps征程
说了这么多，到底什么是AIOps?AIOps中的AI经过修改后，目前最新的释义是Artificial
Intelligence。为什么说实现AIOps必须要经过DataOps阶段?因为我们认为AIOps其实就是在传统的DataOps之上附加智能，如果在感知、决策、执行每个阶段都附加上AI的附加值之后，我们认为这才真正实现了AIOps。常见的AI手段包括算法、深度学习、神经网络等等。
AIOps绝对不是从无到有，它一定是随着你在某个领域持续地构筑、持续地积累，然后在每个阶段附加上新的AI。
这张图是我们团队头脑风暴出来的，我们发现无人驾驶和无人运维很像。SAE将无人驾驶划分了六级L0到L5，他们认为当前市面上大部分的车都处于L2阶段，即实现了一些基础自动化，比如ABS防抱死系统、自动定速巡航等等。L1阶段可能就是乞丐版，不具备这些功能的车。L3是有条件的自动驾驶(马斯克的Tesla实际上只是L2.5)，
L4是高度的自动驾驶，如果说L3还需要驾驶员坐在旁边，出现问题时接管，而L4基本上在特定条件的路上完全无需驾驶员介入，车子能自动判断做出决策。L5是完全自动驾驶，是一种理想状态，可能很难达到。根据文档的描述，L5阶段，给定车辆一个起始地点和结束地点，其它就不用去管了(跨越国家、左道右道都能自动切换)，它自己会去判断、处理一切，淡化了司机的概念。
类比无人驾驶，无人运维也可以分为6个阶段，L0是人肉运维，L1是脚本、工具化运维，是当前各大公司都具备的一个状态，L2是开发运维一体化DevOps，它的最大特征是有一些简单的规则、阈值的判断，L3是数据化运维DataOps，最核心的东西就是数据化算法，L4是高度智能化运维，这时系统已经完全具备了自动运维的能力，并能够提供人机对话的交互。L5是
完全智能化运维，可能就像电影里的天网系统完全自主防御，你想破坏它都不可能。最后以一个案例来介绍下我们在AIOps上的尝试。
以Project智能迁移场景为例，在计算平台中，所有用户的资源管理都是申请一个Project，计算平台根据配额组来分配资源，当前配额组的资源是不是够用，有没有超过预算?同时，对于系统我们也会有个期望，系统应该运行在一个什么样的状态，核心指标应该是多少，水位是百分之多少，正常情况下不会触发哪些相关事件……一旦系统在后台触发了事件，系统会做自动判断，执行智能迁移的Plan计算。如果想要达到系统所期望的运行状态，需要将哪些Project做迁移，迁移到哪些集群，这时我们会通过ChatOps与人做一个确认的交互报备，通过自动智能的Project迁移之后，系统再次回到我们期望的状态。在整个过程中，我们可以做到无人值守。
最后再整体回顾一下，首先，我们讲了DevOps到AIOps的一个概念，重点讲述了什么是Tesla;然后定义了DataOps数据化运维，并以两个案例讲述了如何做DataOps;接下来，我们分析了数据化运维的本质，包括运维全域数据、知识图谱和搜素、数据即视图、数据驱动业务;最后，我们讲述了AIOps并不是无中生有，而是DataOps+AI，并与无人驾驶做了类比。最后再来个广告。
我们这里有很多优势也有很多挑战。来阿里最大的优势就是这套大数据体系实在太成熟了，以前我做数据化运维的相关工作都需要我去从无到有构筑数据化体系，但在阿里，这一套触手可用;同时我们所运维的对象本身就是阿里大数据，这又是一个可以跟阿里大数据亲密接触的地方;我们的舞台足够大，量级至少在国内可以称得上No.1，同时所运维的对象也很复杂，所以我们需要更高效更智能的手段。 |
