《阿里云智能运维的自动化三剑客.docx》由会员分享，可在线阅读，更多相关《阿里云智能运维的自动化三剑客.docx（9页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、阿里云智能运维的自动化三剑客整理|王银出品|AI科技大本营ID:rgznai100近日2019AI开发者大会在北京举行。会上近百位中美顶尖AI专家、知名企业代表和千余名AI开发者进展技术解读以及产业论证。而在AIDevOps论坛上阿里巴巴高级技术专家滕圣波就阿里云与智能运维的开展之路对智能运维自动化三剑客弹性伸缩、资源编排以及运维编排进展了重点介绍。在介绍自动化三剑客之前滕圣波为我们讲述了阿里的上云路以及智能运维的开展策略。以双十一为例阿里集团的业务量往年度只有60%70%承载在阿里云上而今年度将百分之百跑在公有云上。这意味着阿里云就是整个阿里集团的运维将创立机器、计算力、存储、网络以及管理机
2、器及数据库这些本质上都是运维的要做的事进展代码化以及自动化。由此可见阿里云已经成为阿里集团的技术底座。滕圣波还表示将来阿里云集团的技术输出只通过阿里云并且技术全面开放进而到达集团以及生态分享促进互联网生态开展。既然阿里云担当了整个集团的运维一角色那传统运维人员又该何去何从这本质上也是DevOps的问题。滕圣波以这么一个场景为例给出答案半夜有一个严重告警目前的机制是系统一旦出现异常就会把相关开发或者负责人叫起来。这意味着截至目前人工职守无可防止。但是阿里云的目的是无人职守毕竟一周连续四次都被凌晨叫起来去处理告警身体是吃不消的。想象一下一个运维人员半夜起来看日志、采取动作动作是什么无非就是机器不够
3、用了、代码多了、负载多了假如加机器加资源解决不了就回滚代码。这些肯定都是可以自动化的顺势而为人工智能必成开展打破口。我们都知道阿里云有SLA而所有都是从架构出发的但是架构不仅仅是阿里云的事情也是客户的事情。一个架构是针对容量规划的针对万人的架构以及针对亿人的架构一定是不一样的。众所周知企业都不是一开场就走到亿人这个步骤而是从万人渐渐成长起来的。企业成长经过中需要不断调整自己的架构以及运维。所以无人职守并不只是阿里云的职责也是客户的职责。简言之“从运维到SRE无人值守是目的自动化是无人值守的手段而人工智能又是自动化的手段之一。其中无人值守的最后一公里由客户侧运维开发。而后滕圣波为我们重点介绍了自
4、动化三剑客。第一便是弹性伸缩即基于AI预测的弹性伸缩。原有监控指标形式监控指标变化敏感引起实例数量震荡扩、缩容操作以及业务变化存在延迟智能预测形式可以做到预测业务变化智能调整实例数量结合目的追踪形式完美贴合业务变化可以最大程度地节省本钱。我们知道大多数公司的业务都是有流量曲线的有顶峰、有低谷那对应的业务承载才能怎样得知好比双十一阿里云在双十一有庞大体量它所承载的业务量一定是在双十一之前按照顶峰就计算好的。但是这有什么问题比方双十一之前阿里云有预估通过全链路的压力测试知道需要准备多少资源但是问题也来了我们要提取多久准备这个资源这是个本钱的问题资源是很贵的假如我们提早个月准备资源可能就多几亿元的本
5、钱负担在上面假如我们可以提早小时准备这个资源那我就可能节省出来很多资源。越可以灵敏地准备自己的资源就越可以省钱省钱极致到什么程度最多能省多少钱如下图容量上限以及曲线之间的面积是我们最多能省的钱这是弹性伸缩最大的价值。可惜理想很饱满现实很骨感。弹性伸缩很难把所有的本钱都省出来。弹性伸缩详细是怎么应用的以下用两个例子来讲明。先看上面这张图从技术角度分析为什么会出这个问题。首先发生的事情是一大堆狂点赞这两个人的粉丝量加起来是宏大的。假如这些粉丝只狂点赞还好赞就是数据库里多一条消息多一条数据记录。赞并不难难的是转发。转发这个事情太恐惧了它不仅仅是克隆在数据库里多几条记录。转发造成了更多消息流推送消息量
6、瞬间几何倍增。比方一开场100万人看到这个消息里面有10万人转发迅速在整个网络里造成了大量消息挤占了大量网络造成了大量数据库写操作。读不可怕因为读的话可以做分级、可以做CDN但写这个东西太夸大了写是必须真实的往数据库里做操作的。而且数据库当时有大量的缓存而写不是缓存的特点所以一下子就被打穿接着就成为数据库的负担了。在疯狂写数据的时候数据库突然崩了那么效劳就会限流。但限流对于很多用户来讲是不可承受的他会认为是效劳宕掉了。这时候我们就可以用弹性伸缩去解决。有两个思路一个是一定要快快是什么概念大众看看基于监控逐步转化的预测有很多都是基于监控指标的算法。当你的曲线已经开场往上走时监控一定是第一时间能发
7、现的这时候我们能做的是赶紧扩大自己的计算资源、存储资源、数据库、缓存可是实际上我们资源扩大的真实情况是滞后的。为什么监控指标出现动作时意味着流量已经来了这时候弹指标已经迟了、跟不上了。阿里云上弹一个指标大概十几秒这个十几秒对一个突发的新闻事件来讲是不够快的有可能它涨了倍了资源才涨了30。所以弹性计算、弹性伸缩最核心的就是要做到快。再比方用户抢火车票或干什么生意火车票出售一定有个顶峰负载一下子涨了5倍是非常恐惧的相当于多了4000台机器。但是4000台机器对阿里云来讲是万分之一、千分之一是流量上出现一个很平滑的不太引人注意的小刺而已。我们的弹性伸缩有提早准备的库存这就是资源大的优势本身也是云的优
8、势。但是再快也不一定足够快即便预测流量来了可是假如用户连5秒都不愿意承当损失那怎么办只能预测在洪峰到来前就把资源准备好。对此阿里有智能预测形式。不过目前还有局限性只在有规律的场景下做得很好例如定点出售火车票。而头条、微博、等等弹性伸缩不完全依赖于阿里云阿里云有机器学习算法、动态预测、实时告警等等基于监控很快帮客户做弹性但是最解析客户业务的一定是客户自己所以很多时候还得结合客户的详细业务提早把资源准备好。讲到资源自然就要引出另外一个三剑客资源编排。阿里云资源编排-ROS可以实现提交代码资源自动修改版本化管理、随时回滚和Copy/paste完成资源成套复制。上面是一个经典的网上应用的架构图能看得出
9、它有四点困境。第一需要更多资源。一般情况下在一个阿里云上随着业务的增长需要的阿里云资源会越来越多可能需要10个、20个、30个。阿里云上如今有300多种多少资源都是客户经常会用到的资源随着资源越来越多怎么管理是关键问题。CMDB是很流行的管理方法但是它无法保证自己永远是最新的并且永远跟实际相吻合。第二点是历史记录的存储问题。阿里云对ECS的历史记录不做保存需要客户保存资源编排就是一个很好的方法。第三是准确操作问题因为人是一定会犯错的。有这么一个场景某一天一个阿里员工在操作VIP时引发一个故障这个故障直接导致大量北京区域的很多ECS不可效劳了。大众可能会责怪这个运维但是是运维的责任吗这是典型的让
10、运维做背锅侠最深层次的原因是自动化。没有什么人不会出错除非让机器去操作一个经过测试过的程序让它再跑一遍是最不容易出错的其他情况下都可能出错。所以要想不出错就像代码那样把资源编排写成个代码测试之后线上跑一遍这才是万全之策。最后一点就是重复操作问题。企业并不是只有一个区域、一个环境他们大多有开发环境、线上环境等等这些环境可能只有一点点区别我们不可能每个都重复来一遍所以用资源编排就可以很好的解决这点。那现实资源编排详细是怎么实现的呢阿里云提供一个资源编排的效劳。比方把代码文件提交到代码库里提交之后会发现阿里云上多了一效劳器。另外版本管理copy/paste完成资源成套复制。可能听起来有点模糊所以腾圣
11、波教师为我们讲述来一个真实的使用场景云产品是分级的最底层的是云存储等等容效劳器是架设在之上的。上层的产品对客户提供效劳时一定会用到底层的产品比方我们买了一个数据库实际上我们是买了一个云效劳器数据库软件但是这个云效劳器是我们看不到的是数据库这个产品帮我们运维了效劳器。容器也一样我们买了容器底下一定是有效劳器的我们看不到效劳器是因为容器产品帮我们运维了效劳器。而容器效劳我们可以一键部署。这是ROS控制台一键部署本质上是做什么这个文本文件描绘了环境VCP是网络接下来点击创立它就会自动帮你做这就是ROS的模板。假如需要修改VPC直接把VCP属性修改就可以来。但为什么用阿里云的ROS无非是资源编排有两个
12、难点第一点是事务。什么叫事务一个文档有十几个资源涉及到回滚、加速。另外一点是状态。今天一台ECS明天两台ECS把模板从1改到2要2-11然后要再创立1台并比照版本的差异如此自建编排就复杂了很多所以大众可以尝试使用阿里云的资源编排。运维编排是自动化最后一位剑客专门解决背锅侠、自建DevOps平台、事件消费的问题。运维是事件驱动的。以前大众可能没注意到因为在此之前运维是人工驱动的。比方你收到一个是个事件事件驱动人去做运维。而自动化运维不应该这样云监控产生一个告警事件这个告警应该自动驱开工作这是自动化运维。事件驱动为什么很难因为做监控一定要做到不重不漏。不漏可以理解通过ACK确认机制保证事件交付到位
13、。一个事件发给你你必须给我回ACK我才知道你收到了不然我就不停给你发这样保证不漏。可是我们无法保证不重。消费端去处理消费端无法不重。事件有ID例如ID为1表示消费过为0表示没消费过并行消费时把它指成1就会产生bug。假如用原子锁当ID是1时表示第一次消费当ID是2时表示第二次消费那这就相当繁琐沉重了。为此推出OOS阿里云的官方运维编排效劳平台是高效、高可靠的serverless执行引擎只需要写模板然后执行进而保证秒级的处理。技术不断在进步阿里云智能运维技术已经成为新运维演化的一个开端我们期待在更多的高效的优质平台理论之后智能运维能壮大整个IT领域原文链接s:/zhuanlan.zhihu/p/82363522 (*本文为AI科技大本营整理文章转载请微信联络1092722531)