差不多在两年前，阿里内部出现了很多运维中台、研发中台等等，那有没有后台呢？不好意思，我们只有中台，没有后台，会在中台上构建与业务相关的各个前台。目前阿里的业务几乎覆盖了所有行业，有着很多业务线，如果业务线的前台到中台全部都是我们自己去建设，会造成一个巨大的浪费。我们需要去构建整个集团、或是阿里巴巴经济体所需要的统一的平台，避免重复性的建设。
最近我们在思考运维的本质到底是什么，就突然联想到一部名叫《太空旅客》的电影。电影里的飞船装了5000个乘客和大约50多个机组人员，从地球飞往其他星球要飞120年。这意味着整艘飞船必须是无人驾驶的，因为没有人可以活120年，靠人去操控这样一艘飞船根本不可能。所以飞船里有一套运维系统，也就是靠这套系统的运作，整艘飞船才可以飞120年不出故障。
这和我们现在做的运维系统是一样的。我认为运维的本质就是在线，即如何让这种在线的业务能持续不断地运行，满足客户的需求。如果把业务比作一艘飞船，你能否让飞船持续运行？遇到了任何故障或问题时能否自动解决？我觉得这就是运维的作用——稳定性。
而随着业务复杂度越来越高，已经没有办法靠人来运维整个平台和业务了。可以试想，如果要靠人，那需要投入多少人力？当发生问题时，我们人为地去感知问题后排查问题、定位问题，这时业务可能已经挂了很长时间。所以这也是我今天想跟大家分享的，我们基于对运维的理解构建起的智能化运维平台。
阿里运维历程
**
阿里的运维和很多公司有相似之处，也经历了四个阶段：
- 使用命令行工具运维；
- 系统化工具运维；
- 自动化平台；
- 智能化平台与无人值守实践。
按照上图这个层次，我们把运维的工作进行划分。对于双十一这样大型的活动，承载这么大的流量就必须要有很多资源。我们每年在准备资源的过程中会花大量的人力和资源，并且持续时间长，大概需要提前半年准备。而在近几年，阿里云发展起来了，等到更加成熟了就会把这个业务往云上搬。我们会先把机器买进来，把阿里云的整个基础设施装起来后，就把阿里的所有电商业务部署到它上面。等双十一结束后，有很多业务其实不需要用那么多机器，我们就把这些资源重新做一个格式化，再还给阿里云，由阿里云做另外的售卖。这也是为什么阿里会做阿里云的原因。因为这种大促的时间比较短，但特别耗资源，且需要大量的运维人员和工程师，所以我们会在资源这个层面做大量工作。
现在我们的平台实际上会更加自动化，用公有云的资源去做一些弹性，包括资源的利用率。而最近我们有一个系统，是属于做资源调度的系统，它能够更好地利用云资源，提升资源的利用率。事实上阿里的整个电商的资源利用率是比较低的，平均下来只有10%左右，所以我们会在这块大力投入，包括做一些智能化的东西。而有了资源后就需要部署，所以我们就提前铺设了一层，包括数据库的一些东西，这属于一个变更，即把代码部署上去，或做网络的更新等。
等代码铺设上去后，还要清楚线上运行后的状况，因此监控是必不可少的。我们有很多监控系统，比如说监控IDC层面的湿度、温度等，如果这个地方出现问题，那整个机房就会过载。网络则是另一个专业领域的东西，我们需要去监控整个网络、交换机，让网络处于一个健康的状况。再次，还需要有服务器层面的监控，应用、业务层面的监控等，所有的这些都是不一样的，属于不同领域，因此我们的监控系统也比较多。
再往上就是运维最核心的本质——稳定性了，我认为这是怎么强调都不为过的。我们的很多业务部们都有一个专门做稳定性的团队，覆盖从业务到技术的环境。而像阿里这种体量的公司，规模化是必不可少的，我们现在正在收购很多公司，那怎么让这些公司的运维体系能一次性快速便捷地搬迁进来，利用到我们中台的能力？比如我们做双十一大促销活动时，如何能快速把业务部署到云上？这些都需要做规模化的工作。
在以上这张图里，我负责的是蓝色部分的工作，主要是应用运维平台和基础运维平台，包括蚂蚁金服、菜鸟等个性化的东西，可以基于我们的应用运维平台做一些定制化的工作。
基础运维平台
基础运维平台是中台最核心的部分，是全部都打通的，我们的基础运维平台和基础设施是一样的。这就是刚才提到的中台概念，没有必要让所有人都去建设这个基础设施。就像国家的基础设施不会让每个人都去建设，而是由国家统一去做，能节约大量的人力和资本，并把基础设施做精、做深，这是非常有必要的，可以避免大量重复性工作。
运维通道 - StarAgent
StarAgent就是阿里运维的基础设施，它是一个运维通道，是基础设施中最核心的功能，主要是做命令的下发与执行。所有阿里的运维进程都在这上面，包括监控系统、调度所需的所有东西、数据采集等。信息的采集都在这个平台上，以插件的形式运行。
这个系统一天差不多有一个多亿的访问量且还在不断增长，因为我们的服务器数量在不断增长，业务的数量也在不断增长，但它的稳定性还是达到了99.995%
场景
在阿里运维的整个生命周期，包括装机、应用发布、配置变更、信息采集、监控和日常运维等，我们都会用到这个场景。
核心功能
核心功能如上图所示，就是命令的通道执行这样的一些方式，功能比较简单，主要核心能力是在稳定性和性能上面。
系统架构
**
这个系统是由三层架构搭建而成的，第一层就是我们中央的一层东西，用户如何访问这个？我们会通过用户的API做调用，如果权限足够大，可以给全网所有的机器下发指令。
每一个机房都有一个管控的服务器，即管控这个机房所有的机器，服务器都通过长链接的方式连到这个地方。还有末端的，就是一个插件的结构，大概如上图所示，会把信息全部都上报上来等等，这个也是能够支持网络结构的。
稳定性
安全
**
上图是安全方面的策略，我们有比较多重的保护，包括保护下发指令的安全不被篡改，以及整个账号体系有非常健壮的设计，来保证命令执行的安全性。
我们所有的命令都会做一个映射。另外，权限还是非常大的，这里必不可少的就是要保护整个系统，如果有特别高风险的命令在执行，我们必须能够快速准确地识别出来，从而保护整个服务器的安全。
自动化运维
自动化运维非常重要，我们不可能投入过多的人力去运维这么庞大的系统来管理所有的服务器。如果有哪怕1%的服务器出现了连接问题，我们都得投入大量人力去做，这也是为什么自动化运维非常重要的原因。以前可能需要十几人，每个人要频繁地去处理各种连接性的问题，所以我认为自动化运维是根本的东西。
插件平台
最后简单介绍一下插件平台。这是一个描述文件，即你要跑什么进程、利用多少CPU内存等都可以设定。当这个系统发生各种问题时，会自动帮你把这个进程解决掉，再通知你上线去做一些排查。因为阿里的服务器和网络都非常复杂，我们在一个业务线里测试的结果没问题，并不代表能保证所有的业务线都没有问题。命令一直在下发，如果不退出，累计起来就会有很大问题。这个系统本质上是保障服务器的稳定性，所以不管发生什么情况，我们要把服务器上的所有命令都管控起来，只要有问题就采取一定措施。
智能文件分发系统 – 蜻蜓
**要做容器化，文件的分发尤其是镜像的分发已经变成了一个非常大的问题，我们很经常在此过程中碰到这样的问题：原本只需要传一个包，现在要传一个镜像，但如果研发不太好，一出来就是一个多G的镜像在分发，会导致网络的堵塞。在这样的挑战下，我们当时就做了一个P2P的文件分发系统，非常好地解决了这样的问题。
在上图中，红色部分就是传统的文件分发方式，蓝色部分是我们用蜻蜓做的一个文件分发系统。其中，X轴是客户端的数量，最大程度是7000个客户端同时下一个文件。不管有多少个客户端，蜻蜓都可以非常平稳，大概几秒钟就可以完成分发。而传统的分发，等到1000个客户端时就已经没有数据了，因为它已经被客户端打爆了。
上图列举了一些场景，它在哪些地方能被用到，以及它的一些特性包括断点续传、智能网络的IO和磁盘的IO等。如何保证在下载过程中不影响到业务？不能把磁盘和网络全部打掉，那么传统的模式就是设定一个阈值，我就占用20m或50m，但很多业务可能在晚上并没有那么大的流量，你可以用更多带宽但用不起来；如果是业务特别忙的话，还是20m就影响到业务了。我们做了一个智能化的点，如何在不影响业务的情况下，充分地利用带宽和磁盘的IO，跟镜像相关的我们也做了很多的工作。这是去年10月份的一些数据，每个月有超过20亿次的访问。
它最初是在我们的发布系统里被用到，是一个基础设施，后来我们推广到了整个集团，现在访问量非常之大。这个系统目前已经开源了，上图有我们的协议地址，也有企业版的，商业化的版本里会有更多智能化功能。这个社区现在还比较小，希望大家能够支持一下。
应用运维平台
前面讲的基础设施并不是所有公司都会用到，当你的体量特别大时反而会成为一种累赘，相比之下，应用运维平台与大家的相关度可能会更密切一些。
我们的应用运维平台叫Normandy，上面有很多业务线，我们至少50%以上的平台都用这个来做运维。它的一个主要功能是资源编排，应用要用到的所有资源都可以用描述文件的形式做编排，并一次性生产出来，你的任何变化都会被系统感知到并去做一些变更。
有了资源以后，要做代码的发布，这也是这个平台非常大的一个功能。之前有人提到的蓝绿部署，发布的模式我们都是支持的，并且有非常多的发布模式。
当业务的代码发布上去时，这个业务就在线了，后面的工作就是日常性的运维，比如说磁盘的清理等日常工作，也是在这个平台上去做。
关于发布，我们也在做一些思考，因为运维的本质就是为了线上的稳定性。
我们对所有故障做了分析，发现60%的故障都是由变更引起的。而且行业内也有一种说法是，80%的故障可能都是由变更引起的。这也说明其实你不做变更，基本上是不太会发生故障的。毕竟像之前发生的支付宝电缆被挖断，以及腾讯的天津机房发生爆炸这类事情是比较少的，大多数情况下是因为变更造成的故障。
然而变更又是发布的一个重要环节，所以我们会发现，要让系统稳定、持续不断地运行，只要能卡住变更这个口子，基本上就能降低非常多的故障。
关于这个发布，我们也做了很多工作，其中就有对监控指标进行分类，包括系统、日志、业务等，对各种指标做检查。我们会检查发布和没发布的机器，以及发布的机器与前一天在各方面的一些对比，最后做出一个诊断。当有问题时，就能及时通过手机、钉钉把消息推送出来。可能现在你的系统发现了一些问题，要做一些人工判断，因为这也是一种输入，相当于数据的标注，判断我这次的系统判断到底准不准。如上图所示，各种指标会告诉你可能会有异常的，需要人工进行判断。
其实这个策略还是比较简单的，比如说一些针对JAVA的应用，在你的日志里会发现很多问题，譬如说有没有新的异常，我们的异常库会把新的异常记录下来，如果发现了就会提醒用户，因为这个新的异常基本就是代码引入的。
还可能有一些是非常致命的新异常，不太需要算法的介入（需要算法介入的是旧的异常），譬如你的指标频率突然飙升，那我们要发现这个飙升的指标，并把它提示出来，这就可以用很多方法了，包括趋势、同比、环比等。
提到会用到的算法，红色标注的部分在整个序列上的算法会比较多，主要是对这个应用进行一些历史数据的采集，再描绘出它的曲线。通过这样的数据学习，我们就能知道它未来的发展趋势和变化，如果超出了变化，就可以认为是异常。
**
上图的红色线就是我们真实输入的数据，蓝色线是我们预测的数据，如果是好的想法，这个红色线应该正好穿过蓝色线。而我们的监控报警或是异常检测，即根据红色线是不是超过了蓝色线的正负阈值来判断。
我们也做了测试，把线上发生的各种异常（包括用户认为是有问题或是认为报错了）的数据都引入线下，帮助我们去做进一步的评判，形成一个反馈机制。这整个过程都是自动化的，最后告诉我们调整的参数是否正常。这是我们自动化系统模块的展示，此处就不详细展开了。
另外，监控系统的数据采集是不是有断图，数据采集得对不对、准不准等等，也是非常大的挑战。还有我们的参数目前更多地还是人为去做固定的阈值，如果能使其更加动态，或是根据不同的应用状态去做一些动态的适配，也是有着非常大的挑战。
AIOps
**今年我们主要的工作就是发布，让所有变更都能接入智能化体系，从而保证变更不受影响。它的AI是基于算法的这样一套东西，我们更多是希望它走向无人化的状态，所以我们对它的理解可能不是一个算法，而是另外一个英文单词AIOps，即无人化的运维。
这需要一个过程，首先我们需要累计足够多的数据，其次是找到场景。开头提到的无人驾驶飞船是非常美好的，但要真的做到不需要任何人介入，需要走非常长的一段路。所以我们现在认为，一定要找到非常好的场景作为落脚点，再准备好所有数据，因为数据的质量真正决定了整套系统的天花板，而算法是可以不断尝试的。我们尝试用比较普通的算法来做运营，真正难的是特征的提醒和算法参数的优化，甚至是一些革命性的算法现在还比较少，关于这方面我们也和清华大学有一些合作，希望通过与高校的合作来看到一些更好的算法。
上图是对整个运维领域和智能化阶段做了一些分类。我们会有一些服务咨询/答疑，这也是可以做智能化运维的方向，我们现在更多的采用跟阿里的一些合作，在自然语言处理方面能帮助我们减少人工答疑的过程，尤其是重复性出现的问题。比如我想看一下我的应用在某一个机房到底运行得怎么样，可以通过自然语言的方式去做，大大降低人的介入。
第二是通过智能化算法降低故障，包括效率和优化。我们也有很多场景，包括刚才讲的资源的利用率，如何能更好地做服务调度，这上面其实我们也有很多应用。另外一个就是在可用性上面，自愈或者是预测。我们在做磁盘损坏的预测，在损坏前能够把业务都调走，让整个过程变得更加可预期一些。另外一个方面，我们也在做整个机房在能耗方面的工作，能够通过智能化的算法来降低能耗。谷歌在2016年就已经做到了，通过深度学习的方法让整个能耗降低了差不多30%。不过真正要达到第五级的自动驾驶的话，还是有挺长的路要走。
上图是我们在智能化运维上主要做的两个方面。第一个就是我们对运维的理解，稳定性是最核心要做的事情。在此基础上，我们希望整个系统达到非常优化的状态，包括前面讲的我们的自动化的调整，让性能更加高效。
上图是我们整个智能化运维平台的产品图，包括了前面说的应用运维上的能力，以及整个端上的一些东西，还有我们的一些规范、运维的一些红线等等。这个平台我们叫StarOps，有一个私有云版本，也会在今年六七月份推出公有云版本。
最后是我们的一些思考。首先度量是非常关键的，不仅仅是运维，所有的系统都应该有度量，没有度量就不会有提高。从中台的概念来讲，希望不要重复去造低水平的轮子，一定要有突破。而对于智能化运维这一块，还是可以从点入手，找到一个真实的场景，然后去做一些突破。
若有收获，就点个赞吧
0 人点赞
