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

阿里云大数据计算平台的自动化、精细化运维之路本文章来自于阿里云云栖社区摘要：?作者简介： ? 　　范伦挺　　阿里巴巴基础架构事业群-技术专家　　花名萧一，2010年加入阿里巴巴，现任阿里巴巴集团大数据计算平台运维负责人。团队主要负责阿里巴巴各类离在线大数据计算平台（如MaxCompute、AnalyticDB、StreamComput免费开通大数据服务：/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 第二步：高效稳定的解决问题?　　第二个例子是关于问题排查的，上图画的是我们当前用的实时日志分析系统的架构，阿里因为这块的产品自研的都有，所以用的都是自研的产品。　　为了便于理解，我在边上备注了对应的开源产品，基本上的