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

嘉宾引见
宋 健(宋意)：阿里巴巴运维中台技术专家。工作10年不断专注在运维范畴，对于大规模运维体系、自动化运维有着深入的了解与实际。2010年加入阿里巴巴，目前担任基础运维平台。加入阿里后曾担任：从零建立支付宝基础监控体系、推进整个集团监控体系整合一致、运维工具&测试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，一切其它采集机器信息的场景都可以运用这个采集工具，当规范发生更新时我们会同步更新小工具，以此完成对下层业务的透明化。

文章来源：今日头条(发布内容请上昭通热线网www.ztrxw.cn)