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

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

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

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

免费开通大数据服务：https:///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 第三步：更高效的硬件维护