双11黑科技，阿里百万级服务器自动化运维系统StarAgent揭秘

摘要：

还记得那些年咱们半夜爬起来重启服务器的黑暗历史吗？双11期间，阿里巴巴百万量级主机管理能安全、稳定、高效，如丝般顺滑是如何作到的？阿里巴巴运维中台技术专家宋意，首次直播揭秘阿里IT运维的基础设施StarAgent，详细分析StarAgent是如何支持百万级规模服务器管控？如何像生活中的水电煤同样，作...

导读：还记得那些年咱们半夜爬起来重启服务器的黑暗历史吗？双11期间，阿里巴巴百万量级主机管理能安全、稳定、高效，如丝般顺滑是如何作到的？阿里巴巴运维中台技术专家宋意，首次直播揭秘阿里IT运维的基础设施StarAgent，详细分析StarAgent是如何支持百万级规模服务器管控？如何像生活中的水电煤同样，作好阿里运维的基础设施平台？

嘉宾介绍

宋健(宋意)：阿里巴巴运维中台技术专家。工做10年一直专一在运维领域，对于大规模运维体系、自动化运维有着深入的理解与实践。2010年加入阿里巴巴，目前负责基础运维平台。加入阿里后曾负责：从零创建支付宝基础监控体系、推进整个集团监控体系整合统1、运维工具&测试PE团队。

StarAgent

从云效2.0智能化运维平台(简称：StarOps)产品的角度来看， 能够将运维划分为两个平台，基础运维平台和应用运维平台。基础运维平台是统一的，叫StarAgent，它能够当之无愧的说是阿里巴巴IT运维的基础设施。

从1万台服务器发展到10万台，又逐步达到百万级服务器，基础设施重要性并非一开始就被意识到的，是逐渐被发现的过程。不管是运维系统稳定性、性能、容量显然已经没法知足服务器数量和业务的快速增加。在2015年咱们作了架构升级，StarAgent系统成功率从90%提高到了99.995%，单日调用量也从1000万提高到了1亿多。

服务器规模达到百万级的企业，在全球应该也是屈指可数的，并且不少企业内部又按业务作了拆分，各业务管理本身的服务器，一套系统管理百万台机器的场景应该更少，所以咱们没有太多能够借鉴的东西，大部分状况都是本身在摸索中前进，咱们的系统也是在这个过程当中一步步演变成今天这个样子。

产品介绍

如上图所示，StarAgent分了三层：主机层、运维层、业务层，各团队按分层的方式进行协做，经过这个图能够大体了解StarAgent产品在集团所处的位置，是集团惟一官方默认的Agent。

• 主机层：指全部服务器，每台机器上默认安装了咱们的Agent。
  
• 运管层：指运维管控系统，包括应用运维体系、数据库运维体系、中间件运维体系、安全体系，各专业领域产品有独立Portal，经过StarAgent来实现对服务器的操做。
  
• 业务层：指各个BU的业务，大部分BU会直接使用运维层的管控系统，但有的BU可能会有些个性的需求，因此也会有基于下层能力封装出面向本身业务的一个专用运维portal。
  

应用场景

StarAgent贯穿整个服务器的生命周期：

• 资产核对：服务器上架后会设置为网络启动，而后会加载一个mini的OS在内存中运行，这个OS中就已经包含了咱们的Agent，OS启动后就能够下发指令来采集服务器的硬件信息作资产核对，如CPU、内存、磁盘的厂商及大小信息等。
  
• OS安装：交付业务前会先安装OS，安装什么样的OS也是向这个内存中的Agent下发命令实现的。
  
• 环境配置：OS安装完成后像机器上的帐号、通用运维脚本、定时任务等基础环境的初始化。
  
• 应用发布：应用配置与软件包的上线发布。
  
• 运行监控：上线后应用与业务的监控脚本、监控Agent的安装。
  
• 平常运维：登陆服务器、单机、批量等平常运维操做，包括业务下线前的清理工做等。
  

产品数据

这也是咱们产品在阿里内部的一些数据，天天有上亿次的服务器操做，1分钟能够操做50万台服务器，插件有150多个，管理服务器规模在百万级，Agent资源占有率也特别低，支持Linux/Windows主流发行版。

产品功能

StarAgent核心功能能够总结为两大块：管控通道和系统配置。

这与开源的saltstack/puppet/ansible等配置管理产品相似，咱们作的更精细一些。

• 管控通道：全部运维操做最终都会转化为命令到服务器上去执行，这个命令通道是全网惟一的，这里会有相应的用户权限控制、操做审计、高危命令拦截等能力。
  
• 系统配置：公共运维脚本、定时任务、系统帐号、监控Agent等等，这些配置会在Agent启动后自动初始化，OS中默认打包有Agent，因此能够作到开机后全自动完成服务器运维基础环境的初始化。

按照Portal、API、Agent细分后的功能列表，Portal主要给一线开发与运维同窗使用， API更可能是给到上层运维系统来调用，Agent表明每台机器上直接可使用的能力。

Portal

• 运维市场：也叫插件平台，相似于手机中的应用市场。各个业务的负责人在市场中若是发现了一些不错的小工具，点下安装就能够自动安装到业务对应的机器上，业务若是新扩容了服务器也会自动地安装这些小工具。小工具的开发也是来自于一线的同窗，你们均可以把本身开发的工具上传到运维市场，分享给其余人使用。
  
• WEB终端：在Portal上点下一台机器后会自动弹出一个终端，和SSH登陆到服务器的效果彻底同样，基于当前登陆人信息全自动鉴权，这个终端还能够经过JS的方式嵌入到任何其它网页中。
  
• 文件分发：比较好理解就不展开介绍了。
  
• 定时任务：与crontab相似，不过咱们支持秒级而且能够打散执行，好比对一批机器增长每分钟执行一次的定时任务，用crontab全部机器会固定的在每分钟第1秒执行，咱们在保证每分钟执行一次的同时每台机器上的执行时间不同。
  
• 主机帐号：包括三块功能：我的登陆服务器的帐号、机器上admin等公共帐号、一台机器与其它机器之间打通SSH通道。
  
• API帐号：与右边的API功能是紧密相关的，若是要使用右边这些能力，必须先申请一个API帐号。
  

API

• CMD：调用时传入目标机器与命令信息，就能够实现让指定台机器执行命令，登陆机器上执行的命令均可以经过CMD接口来调用。
  
• Plugin：对应前面的运维市场，若是经过运维市场把一些脚本安装到机器上，能够经过plugin的方式来直接执行这些脚本。
  
• File/Store：二者都是作文件分发，区别是file依赖下载源，store能够在调用HTTP API时直接把脚本内容POST过来。File基于P2P实现，在阿里内部有一个叫蜻蜓的产品专门作文件下载，好处是几百台、几千台机器同时下载时只会回源一次，对源的压力很是小，机器之间可以互相共享下载，目前蜻蜓已经开源。
  
• Action：对以上功能组装使用，例：先用file去下载脚本，下载完成后再用cmd来执行，而且中间支持and or的条件判断，下载成功才会用cmd执行。
  

Agent

• Hostinfo：提供采集服务器的主机名、IP、SN等信息。
  
• 数据通道：在每台机器上执行的命令或脚本的输出直接丢到这里，会自动把数据上传到中心，而后在中心消费这些数据。
  
• 增量日志和P2P文件：都是第三方来开发的，在运维市场经过插件的方式安装到每台机器上。
  

图：左边是Web终端，自动鉴权并且能够经过JS的方式嵌到任何web页面里面。

右边是批量执行命令的功能，先选中一批机器，在这个页面输入的命令都会发到这一批机器上。

系统架构

逻辑架构

咱们的系统是三层架构，Agent安装在每台机器上，与channel创建长链接，而后channel按期把链接本身的agent信息上报到中心，中心会维护完整的agent与channel关系数据。分享两个流程：

1.Agent注册

Agent有一个默认配置文件，启动后首先链接ConfigService，链接时会上报本机的IP、SN等必要信息，ConfigService计算出应该连哪一个channel集群，返回给channel列表，收到结果后断开与ConfigService的链接，而后与channel创建起长链接。

2.下发命令

外部系统都是调用proxy来下发命令，proxy收到请求后会根据目标机器查出对应channel，而后把任务下发给channel，channel再把命令转发到agent去执行。

部署架构

最下面是每一个IDC，channel会在每一个IDC中部署一套集群，Agent会随机在其中的一台创建长链接。上面就是中心，中心作了双机房容灾部署，同时在线提供服务，其中一个机房挂掉对业务是没有影响的。

问题&挑战

如上图：是咱们前年在作系统重构时遇到的问题：

前三个问题有点相似，主要是任务由状态致使，1.0的manager能够理解为2.0中的proxy，server等同于channel，每时每刻线上都有大量系统在下发命令，在1.0中若是把manager/server/agent任何一个角色重启，那么在这条链路上的任务都会失败，好比server重启后与它相连的agent都会断开，由于链路断了，当时通过这台server下发的命令就拿不到结果了。重启server又会引起第六个负载不均的问题，假设一个IDC中有一万台机器，两台server各连了5000台，重启后这一万台就全连到了一台server上。

用户若是调用API下发命令失败就会找过来让咱们查缘由，有的时候确实是系统的问题，但也有不少是自己的环境问题，好比机器宕机、SSH不通、负载高、磁盘满等等，百万级规模的服务器，天天百分之一的机器也有一万台，由此带来的答疑量可想而知。当时咱们很是痛苦，团队天天一半的人员在作答疑，半夜有断网演练还须要爬起来去重启服务来恢复。

面对这些问题如何解决呢？咱们将问题分为系统问题和环境问题两大类。

系统问题

咱们把系统作了一次完全的重构，采用分布式消息架构，仍是如下发命令为例，每次下发是一次任务，在2.0中对每一个任务增长了状态，proxy在收到下发命令请求后，会先记录并把状态置为收到任务，而后再向agent下发，agent收到任务后会当即响应，proxy收到agent的响应后会把状态置为执行中，agent执行完成后主动上报结果，proxy收到结果后再把状态置为执行完成。

整个过程当中proxy与agent之间的消息都有确认机制，没有获得确认就会进行重试，这样任务执行过程当中涉及角色若是重启，对任务自己就没有太大影响了。

2.0中channel集群内的机器之间会互相通讯，按期报告本身连的agent数量等信息，结合收到的信息与本身的信息，若是本身连的agent过多，会自动断开近期无任务执行的机器，经过这样的方式解决负载均衡的问题。中心节点与全部channel都有长链接，同时保存有每台channel链接的agent数量，当发现某个机房有channel异常或者容量太高时，会自动触发扩容或者从其它机房临时借调channel，在容量恢复后又会自动剔除扩容的channel。

环境问题

在2.0中proxy/channel/agent每一层都有详细的错误码，经过错误码能够直观判断是什么缘由致使的任务出错。

针对机器自己的问题，与监控系统中的数据打通，任务失败后会触发环境检查，包括宕机、磁盘空间、负载等，若是有相应问题API会直接返回机器有问题，而且把机器的负责人也一并返回，这样用户一看结果就知道什么缘由该找谁处理。同时还会把这些诊断能力用钉钉机器人的方式开放出来，这样你们平时能够直接在群里@机器人来作检查确认。

稳定

经过前面的介绍能够看到咱们实际上是运维的基础设施，就像生活中的水电煤同样，你们全部对服务器的操做强依赖咱们。当咱们出现故障的时候，若是线上业务也出现了严重故障，这时候业务故障只能干等着，由于操做不了服务器，作不了发布和变动，因此对系统稳定性的要求很是高，作到了同城双机房、异地多中心容灾部署，依赖的存储有mysql/redis/hbase，这些存储自己就有高可用保障，在这个之上咱们又作了存储间的冗余，确保任何一个单一存储故障不会影响到业务，相信整个业内不多有系统会作到这个程度。

安全

1分钟能够操做50万台服务器，输入命令敲回车就这么一瞬间，就能够操做数万台机器，若是是个恶意的破坏性操做，影响可想而知。因此作了高危命令阻断的功能，对于一些高危操做自动识别与拦截。整个调用链路也是通过加密与签名，确保第三方没法破解或篡改。针对API帐号可能存在的泄露问题，还开发了命令映射的功能，把操做系统中的命令用映射的方式改掉，好比执行reboot命令，可能要传入a1b2才行，每一个API帐号的映射关系都是不同的。

环境

机器宕机这类环境问题，经过与监控数据打通解决，前面已经讲过，网络隔离的问题也再也不过多陈述。这里重点说明下CMDB中录入的数据与Agent采集的数据不一致的问题，主要是SN、IP这些基础信息，由于你们在使用的时候都是先从CMDB取出机器信息，再来调用咱们的系统，若是不一致就会致使调用直接失败，为何会出现SN/IP不一致的问题？

CMDB中的数据通常由人工或者其它系统触发录入，而Agent是从机器上真实采集的，有的机器主板没烧录SN、有的机器有不少块网卡等，环境比较复杂各类状况都有。

这种状况就是经过创建规范来解决，分别制定SN、IP采集规范，容许机器上自定义机器的SN/IP，配合规范还提供有采集工具，不只是咱们的Agent，全部其它采集机器信息的场景均可以使用这个采集工具，当规范发生更新时咱们会同步更新小工具，以此实现对上层业务的透明化。