阿里云大数据计算平台的自动化、精细化运维之路

阿里云大数据计算平台的自动化、精细化运维之路

本文章来自于阿里云云栖社区

摘要：作者简介：范伦挺阿里巴巴基础架构事业群-技术专家花名萧一，2010年加入阿里巴巴，现任阿里巴巴集团大数据计算平台运维负责人。团队主要负责阿里巴巴各类离在线大数据计算平台（如MaxCompute、Analytic DB、StreamComput

免费开通大数据服务：https://https://www.360docs.net/doc/c416378910.html,/product/odps

作者简介：

范伦挺

阿里巴巴基础架构事业群-技术专家

花名萧一，2010年加入阿里巴巴，现任阿里巴巴集团大数据计算平台运维负责人。团队主要负责阿里巴巴各类离在线大数据计算平台（如MaxCompute、AnalyticDB、StreamCompute等）的运维、架构优化及容量管理等

1、前言

本文主要会从以下四个方面来写，分别是：

阿里大规模计算平台运维面临的一些挑战；

阿里自动化平台建设；

数据精细化运维；

我对运维转型的思考和理解；

2、在阿里我们面对的挑战

在讲挑战之前，我们可以简单看一下阿里大数据平台演进历史，我们的MaxCompute（原ODPS）平台是2011年4月上线的，2013年8月份单集群超过5K，2015年6月单集群超10K，目前在进行异地多活和离在线混布方面的事情。

首先是规模大、小概率事件常态化

对于小概率事件大家不能赌运气，基本每次都会踩中狗屎的。譬如各类硬件故障，规模小的时候觉得硬件故障概率比较低，即使坏了也比较彻底，但是规模大了后会有很多情况是将坏不坏，类似这种奇葩事件会越来越多。

还有网络链路不稳定，网络链路会有很多原因导致它不稳定。一方面是网络设备多了，网络设备出现故障的概率也大了，另一方面运营商日常割接、挖掘机施工等都会对我们带来挑战。

还有一部分是工具，机器的环境变得复杂以后，我们对工具稳定性就有更高要求，比如你要考虑到有些机器的SSH 会hang 住，还有某些机器yumdb是坏的，不能想当然的以为一条命令下去一定会执行成功。

其次是多机房多地域

几千公里距离会有几十毫秒的延时增加，大家在布置异地多机房应用的时候，要考虑到应用之间的超时设置是不是合理，需要重新review 尤其针对多次往返的请求，累加效应是非常明显的。

还有一块是资源不均衡，可能那个集群早上忙一点，那边是下午忙一点，但是因为计算任务依赖下面大规模底层数据，所以你不可能利用长传带宽直接来进行直读直写的计算，因此要考虑应用的合理布局。

关于自动化平台建设，自动化的意义我想读者们应该是有共识的。

第一自动化能够提升稳定性，机器的操作比人要靠谱，固化的操作交给机器去做，可以减少人犯错机会，提高线上稳定性。

第二自动化能够提高效率，机器代替人做很多事情之后，把我们从日常繁琐运维操作中解放出来，解放出来以后我们可以做更有价值和意义的事情。

今天因为时间关系，我会从以下四个最常见自动化方向做简单举例介绍，变更、问题排查、硬件维修，交付检查。右边是我们内部用的运维平台架构简图，下面介绍的东西都是基于这个平台的功能模块。

3、四步走让平台自动跑起来

3.1 第一步：实现自动变更

说到变更，做运维的总是有很多共同语言要聊。变更在我们日常工作中占的时间还是比较多的，包括变更方案整理，变更跟进执行，都是比较耗时的，另外变更也是非常危险的。

原来有过统计，号称70%稳定性事件是跟变更相关的，有可能是运维工程师直接变更操作引起的，也有可能是上线代码有bug 引入的，这两类都归结在一起，反正是“线上不作不死，一作就死”。

但是不能因为这个不发布，还有很多功能开发也是跟我们一样，天天加班熬夜，搞出来的代码不给他推上去也说不过去，还要满足业务需求，那这个问题得解。怎么解呢？

我们内部思路是首先会把最底层的一些操作进行原子抽象，比如像把一台机器从VIP 里摘取出来，装一些包进行固化，固化之后抽象出来，称为工作流，然后把工作流进行组装把它称之为组合工作流。

一个组合工作流对应一种日常的固化变更类型，比如控制集群服务升级等等，这样固化的变更就可以由对应的组合工作流去做。

在组合工作流之上，还会有一层封装需求单。主要解决开发的自助申请，审批等环节。在工作流执行页面可以查看详情，包括对应的每个步骤具体命令，返回信息，执行超时时间，超时或者失败的通知方式和人等等。

通过这样一套平台，基本上能够解决日常固化的那一类变更请求，能够做到变更由开发自己申请发起，运维只需审核一些参数、测试报告等等。

3.2 第二步：高效稳定的解决问题

第二个例子是关于问题排查的，上图画的是我们当前用的实时日志分析系统的架构，阿里因为这块的产品自研的都有，所以用的都是自研的产品。

为了便于理解，我在边上备注了对应的开源产品，基本上的流程或者逻辑也是比较好理解的，首先在服务器上部署Agent，Agent 会依据日志服务里配置的规则进行过滤以后，将对应的信息推送到日志服务。日志服务里数据可以实时进入到流计算平台进行实时分析计算，并且把结果存到RDS 里面，然后tesla 通过RDS 进行调取和展现。

另外日志服务存的数据，也会通过实时建立索引，提供WEB 级别日志查询，帮助用户做日志查询。同时也会导入max compute 做永久存储和进一步分析。

基于这套系统，我们举一个例子：异常流量排查。流量打满是很常见的问题，通过这样的机制怎么帮忙我们排查和定位这些问题呢？

比如有N个机房，机房与机房之间有很多链路，每一条链路带宽都是有限的，有时一个突发流量尖峰过来会导致流量拥塞，假设平台上有一条链路，流量打满以后，呈现黄色预警状态，通过点击这条链路，就会进入流量分析实时界面。

这里可以看到从某个时间段到某个时间段，从某个机房到另外一个机房最近十分钟的情况，这里显示的是最近十分钟对应作业流量总的情况，点击流量最高的点可以在右侧看到每个作业对于流量贡献情况及其最近10分钟的变化趋势。

下面还可以列出来这些作业具体的项目归属，作业名称等等。通过这个机制就可以很快定位到问题的原因。这里收集的日志是阿里云飞天盘古master audit log，盘古master 有点类似Hadoop里的name node 节点，它会记录所有集群发起的数据访问请求，包括来源IP 是什么，获取数据大小是多少，发起的作业名称等。

把这些信息通过前面介绍的实时架构收集完之后，放到流计算平台算，然后再结合网络地域和IP 归属，就可以画出整个网络拓扑和实时流量图。

基于这套平台还可以做很多其他的事情，比如说网络静默丢包，这个理论上来讲在网络层很难做到监控。但可以通过收集作业执行日志，分析长尾和失败的作业相应的源IP及目的IP分布情况，可以发现某些交换机的异常情况。做到先进行隔离，再让网工去排查解决。

3.3 第三步：更高效的硬件维护

第三步是硬件维修，我们内部有个硬件全生命周期管理工具称之为是DAM，在日常工作中它能够涵盖整个硬件循环的生命周期，上线以后如果发现线上有硬件问题，它会调应用自定义的下线接口，把这台机器从具体应用里摘出来，从应用层面隔离完之后，再去调机房维修自动接口进行报修。

报修以后会监测这个维修单子状态，等维修结单后，自动做上线前硬件检查，检查通过以后会把这个工单关闭，同时调用应用自定义的上线接口，完成服务器上线。

所以这套东西基本上跟应用是属于松耦合的，只要应用提供满足条件的上下线API 接口，基本上都可以转起来。

这是它的一个架构简图，主要有三大模块：Dam Worker 、Dam Client、Dam Center.

这里面主要难点还是在于硬件信息收集和分析，怎么判断这块磁盘坏了，怎么判断CPU 是有问题的。这其中需要长期的数据和经验积累。

这里我可以简单介绍一下我们现在采集的信息源：

硬盘主要依赖于kernel log/smartctl/tsar

内存是ipmitool/mcelog/stream，

CPU/风扇是mcelog/cpu频率/ipmitool，

网络/网卡/交换机端口是tsar/kernel log。

主板方面如果我们分析以后都不是以上信息，那可能就是主板的原因。

上面这个图是一个最终的效果，这个系统在规模化场景下还是非常有用的，以前没有这个的时候，值班人员是比较痛苦的，因为我们知道现在互联网用的机器都不是高可靠的，去IOE 都差不多了，都是廉价的服务器，所以出现一些硬件问题还是比较常见的。

很可能一个电话过来，客户就开始抱怨作业又长尾了，你上去一看，这个机器硬盘有问题，加入黑名单，重跑一下，用户和我们自己都搞得很痛苦。

现在我们就不会因为单台机器的硬件问题而受到骚扰了。主要白天看看那些异常工单原因，不断优化逻辑即可。

对于这类自动处理我们肯定采取比较保守的策略，任何系统拿不准的或者不是完全精准匹配的就不动，先做隔离而不做进一步自动处理，放到异常工单池子里，由人工介入分析异常case 什么原因，不断完善我们硬件检测判断的模型。

3.4 第四步：完善的交付检查

交付检查分为软件交付检查和硬件交付检查，软件交付检查就是用前面介绍过的工作流，硬件交付检查主要针对CPU、内存和磁盘，对于CPU 做法是绑定每个CPU 算π，算算它的消耗时间分布，最终把曲线画出来，标准就是看曲线的偏离程度。

其实大家可以看出，大部分还是很规矩的，会集中在一起，类似上面有几条偏离曲线的就是我们认为有问题的。那么这里大家可能会问，为什么你这里集中在两个区段，是不是有一半的机器都是有问题的，其实是因为这个集群机器是异构的，本来就有两种类型的cpu。

内存压测采用通用的stream 方法，就是对内存做拷贝、读取相加，读取做乘法诸如此类的，对于性能指标明显偏离的机器也是有问题的。

磁盘主要用Linux FIO 命令按照不同的读写比例和块大小，来看它的表现。

其实这里并没有用到什么高深的技术，我之所以拿来说是告诉大家这个极其重要，尤其是对于离线场景。离线计算在公司里一般给的是都是更廉价，更低成本的硬件设备，甚至很多时候在线应用退役的机器也会拿来用，即所谓的利旧。这种时候再加上机器是经过搬迁的话，那硬件的压测就必须做，否则线上会很长时间不得消停。

4、数据驱动精细化运维

下面我们讲讲数据驱动精细化运维，今天主要是讲一些点，举一些例子，以此来表达我的一些想法。

大家都知道数据是有很大价值的，我们通过历史数据分析，能够知道平台过去是发生过的事情，对于现在的数据分析，可以知道平台现在正在发生的事情，还可以通过建模预测未来可能会发生的事情，所以数据可以说是能够通晓过去未来之事。

我们运维的大数据平台上每天都在产生海量的各种运维日志、信息，我们手里拥有在线、离线，各种大数据平台，我们也想把运维做得更精细化一些，可以说是有数据，有需求，有平台，正可谓天时、地利、人和，所以一直在这方面做些尝试。

4.1 实时大屏背后的精细化运维实践

第一个例子是关于双十一大促的，这个屏相信大家不会太陌生，这是双十一大促在深圳晚会现场直播的一个媒体屏，上面有双十一大促最终定格的成交额1207亿。

这是一个GMV 翻牌器，它的作用就是实时汇总当前每一笔成交，并且把成交额显示在上面，在光鲜亮丽的媒体屏背后，其实我们还有很多保障用的技术屏，今天就带大家一起来看看其中的一块技术屏。

这上面的数字都抹掉了，简单介绍一下我想说的事情，左边部分是用于承载翻牌器成交额实时计算作业主备集群负载情况，在它的右边显示的就是几个关键的核心作业当前实时的延时情况，单位是毫秒。

这里最右边的这几个白色的数字，代表了每个作业对应的延时，有了这个之后我们才能知道当前算的成交额比真实的用户下单时间，它的延时有多大，超过一定的量，我们就要进行链路切换。

所以有了这个数字以后，可以更好地帮助我们判断现在哪条链路是好的，哪条链路不好的，不好到什么程度，好的话什么程度，不能盲目的去拍脑袋判断，需要有实时化的量化指标做评判。

这里还要强调说明一点，这里用不同的颜色深浅分成三段，这三段分别代表这个作业它的日志采集延时、消息队列读取延时和读到之后计算的延时，把三段延时进行了分开展现，这个有什么用呢？

当链路有问题之后，我们可以知道哪段出的问题，因为实时计算整个链路是非常长的，对于秒级应用来讲，每个环节消耗的时间都是需要被清晰度量的，也就是说，有了这个时间你才能准确判断现在是因为哪里出现的瓶颈导致整体延时不达标。

也就是说，不但能够知道哪条链路有问题，还可以知道链路具体问题点在哪，加快问题定位。

所以对于这个核心指标我建议大家做到三化

量化，这些压力值都可以清晰看到。

细化，每个指标再分细一点，可以更精准判断和定位问题。

持久化，这些实时屏不能看完就算了，还要把数据存起来，非常有用。

所以做到三化，量化、细化、持久化，在核心指标量化分析里是很重要的。

4.2 存储分析在精细化运维中的实践

下面讲一个存储分析的例子，这个例子起源是因为集群规模太大了，每年都被老板盯着能不能省出一点钱来，我们分析了下存储的数据，看看每个byte 是被什么占用了，这是可以分析的。

我们通过分析之后得到右边的图，这个是真实的图。看了这个图之后，你会注意到，原来存储是这么被消耗的。其中我们可以找到一些应用层的优化。

譬如平台是分层的，每一层为了数据安全都会做自己的回收站（延迟删除）功能，站在每一层独立去看都是合理的，但各种回收站累加在一起就会发现回收

站占用比例有些高（尤其是对于频繁删除类型应用）。可以从整体运维的角度去看，对于各层回收站策略做评估。

另外我们还发现一个优化点，就是inode。我们可以计算下看看我们要不要

用到这么多inode，按照PPT公式计算可能只需要原来的1.75%就够了，万台集群可以因此省下6PB的存储。

当然这里面实际适用inode大小还是要根据自己应用场景去评估。大家经常做数据运营，数据分析，其实它在很多地方都在那儿等着大家，有很多点可以去做，包括我们日常忽略的，司空见惯的，觉得不值一提的地方，大家可以细究一下，会发现那里有另外一番天地。

4.3 精细化运维在资源优化上的成果

还有一个是资源优化例子，大家知道资源调度器里有一个用户资源申请的值，和申请之后真正跑起来的实际消耗值，我们建立了一个用户实际消耗和用户资源申请的比例，理想值我们希望接近100%，这个指标能够说明调度模型的资源使用状态，有了这样的衡量指标之后，我们做进一步细化分解，看看怎么优化这个指标。

这个是实时计算里面作业的情况，每个作业我们会去看它的资源使用趋势，这上面红色的两条直线是作业里设的申请值，下面蓝色波动比较大的是这一周来资源使用的尖峰值，大家可以看到即使按照这一周作业使用物理资源峰值来看，离申请值也是很远的。

所以这里面还是有不少优化的事情可以做，包括提醒用户自己做优化，也可以在平台层面自动做优化，来达到节省成本的目的。因为一旦调度器认为可以申请的资源都分配出去了，哪怕这时平台物理水位非常低，它也不会调度更多的作业了，所以这件事情也是我们可以深度去做的。

5、如何摆脱苦逼运维的魔咒

5.1 转向运营或许是破解之道

我个人对于运维转型的一些理解和思考。运维转型最近被谈的比较多，有一个论调就是运维向运营转。

这个问题我是这么看的，传统运维更多关注的是平台稳定、安全，也就是非常传统的两个领域，更多关心的是平台是不是活着，这个平台没有出问题，没有挂掉，这是传统运维关心的事情，重点关键词活着。

对于运营来说，除了活着，还要看平台质量怎么样，用户用得好不好，这个平台本身它的效益怎么样，它的成本是不是还能进一步优化，用户感受怎么样，用户满意度怎么样。

而对运维来讲，包括运营，我们大部分都是跟垂直的具体产品或者平台绑定的。不可能完全脱离他们，去谈运维的价值。

所以运营是以一种更积极开放的态度，去看待我们所运维的对象，多看一点，不光看它的活着，还想想怎么能够帮助它和自己一起去成长和发展。

5.2 自动化在转型过程中的四个阶段

然后讲到转型逃不开自动化，我个人认为自动化可以分为四个阶段：

第一个阶段人肉时代

这时候人就是一切，你说了算，你说什么命令就是什么命令，这时候没有任何校验标准机制，就像交警纯人肉指挥交通一样，什么时候让你走就走，什么时候让你停你就停。

第二阶段工具时代

好比交警手里的指挥棒和哨子，这些工具提升了他的个人能力，比如哨子可以让更远的车辆听到他的指令，棒子可以在天气不好的时候让汽车看到他的指令。

这个阶段还是以我们人为主体，工具在能力上做了一定延伸和拓展，但是始终还是人为主，器为辅。还是人在决定这个操作要不要做，什么时候做，参数应该是什么。只是人做完决定后，可以由工具搞定具体落地执行，提升了执行效率，节约下来了时间。

但是离开了人还是什么也不是。所以这个时代，单兵作战能力增强了，但是人逐渐成为整个运维的瓶颈点，因为工具的能力是远远大于人的能力的，更多需求就堆在你手里的，你怎么编排和控制。你成为瓶颈点了，工具越多，人的瓶颈点就会凸显。

第三个阶段平台时代

这个阶段过渡到器为主，人为辅的阶段，还是以交通举例，这里面大家可以看到由很多工具沉淀变成了完整的交通疏导指挥平台，包括红绿灯，包括限速和车道划分等等，这一系列规则和工具，最终不是零散的在那里放着，而是通过一个有序组织变成一个固化的平台，通过这个平台，能够完成交警日常工作中交通疏导的事情。

对于我们运维也一样，我们怎么把我们的经验、想法和技能放到平台里，最终变化自助或者自动化运维平台，这样的时代才能称之为平台时代，就像我刚才前面说的变更平台一样。

我不知道大家有没有经历过，其实很多公司经历过，变更平台可能有很多不同的人开发过很多拨，第一拨可能是开发写的，第二拨可能是工具团队写的，第三拨可能是运维团队自己写的。

这里做一个变更平台并不难，难的是怎么把运维的想法和思考沉淀到平台里面去，怎么让平台有和你相当的能力，这时候它才能代替你日常的职责，所以它这里面的灵魂和思想很重要。

同样是做开发变更平台，开发考虑的是怎么快速高效的执行变更，那运维做的时候会有些什么更多的思考呢？

你会考虑是否有灰度功能，是不是应该先灰度发布一部分，然后有自动冒烟机制，冒烟过了我再引流，然后有没有快速回滚机制，这就是区别，为什么我们要自己去做，自己转型，我觉得别人很难理解我们，也很难救我们，所以要自己转型做自己想要的运维平台。