GOPS 全球运维大会(2018 上海站)部分演讲总结

标签:无 1805人阅读 评论(0)

1.     智能运维保障京东618  京东  王超

主讲人的演讲主要分四个部分:当前背景,如何减少故障,如何快速恢复以及对未来新方向的展望。

首先背景部分,介绍了海量的节点和数据给运维带来的考验,当节点数达到十万级时,只有做好自动化和标准化,才能执行AIOps;而当数据量过大时,数据库的查询时间就会很长,而不同的公司,不同的应用场景,容忍度是不一样的,超时就会造成用户流失。京东采用Redis处理缓存,将数据库查询控制在10ms以内。而像京东这样的电商企业,在大促时,会面临订单多且集中的问题,也是一个严峻的考验。

另外,主讲人强调运维要了解业务,还要考虑成本,要做好全方面的压测,适时进行扩容。运维的关注点是:质量,效率,成本和安全。

主讲人还介绍了DevOps和AIOps的概念区别,DevOps(Development和Operations的组合词)是一组过程、方法与系统的统称,用于促进开发(应用程序/软件工程)、技术运营和质量保障(QA)部门之间的沟通、协作与整合。而AIOps处理的是运维算法工程师,运维工程师和运维开发之间的关系,其中运维开发负责收集数据,而算法工程师工程量较少,负责对数据训练验证,构建模型。

关键的运维指标有:可用率、MTTR和MTBF。京东目标是保障可用率达到99.99%,这意味着连续运行一年时间里业务中断时间不超过52.6分钟。

所以减少故障就是要提高MTBF,采用高可用架构,单元化部署,采用合理的容量规划,消除单点故障,合理利用消息削峰填谷等策略。采用多维度的压力测试,和方便诊断的应用发布方式。

快速恢复就是降低MTTR。现在大多数的监控都是指标监控,监控网络、主机、应用性能和业务监控。对日志的监控要实现对海量日志的准实时查询,海量日志的数据挖掘与分析,还提出一些对日志的优化建议。

在对未来的方向展望上,京东已经开始使用了智能机房巡检机器人,进行机房的设备和环境检测,需要完成故障识别,故障报警和报告生成。另外,主讲人还提出智能客服的想法,面向的是数量众多的研发人员和数量少的运维业务人员,智能客服用来回答研发人员的问题。

 

2.     阿里巴巴智能监控新场景的探索  阿里巴巴  王肇刚

智能监控是智能运维的子领域,从数据采集、日志收集、到计算等产生数据,再设定一些判断的规则和策略,发送报警,这些都属于监控。

主讲人的团队在阿里内部负责横向看阿里巴巴业务指标的监控。

分享分为以下五个环节,。

一、新业态给业务监控带来的挑战

横向的业务指标监控,在技术层面也是通过日志的采集流程计算看一个指标下跌还是上涨,和普遍的区别在于只要业务发生了不可用或者发生问题,就希望都能够发现,但这时不一定是阿里巴巴系统的问题。 举个例子,如果阿里巴巴一点异常都没有,但是电信可能有问题。

任务的第一环节就是需要能够精确、及时的发现业务是否有异常。为了达到这个目标,阿里引入了称之为智能基线的系统。能够在没有任何阈值或者规则输入的情况下,自动做预测。比如淘宝和天猫的某些交易量在分钟级别是万或十万或更高的数量级,而这个可能是百或几百,波动的量级和原始量级在一个量级上,这个比较难处理。包括周期性,对于一般的在线服务,是7X24小时提供服务,每天什么时间流量最低?国内业务凌晨四点钟最低,这个会受门店的开关门影响,因为零售是有时间的。

二、增强版的时间序列异常检测实战

在做时间序列异常检测时,第一步想知道的是正常的曲线是什么样子的,所以要做基线拟合,阿里使用STL,再用比较传统的 N-sigma 做调整。这种架构能解决 60% 左右的问题,但是有些极端的情况解决不了。

第一次改进后首先做数据预处理,然后进行滑动平均。之后利用机器学习,对曲线做特征工程,加入一些统计特征编码和时间特征编码。

但是很多曲线不具备周期性,或者周期性非常零乱。所以做了第二次优化,引入了一层算法路由,目的是让算法自动把数据分类,希望能够通过机器学习的方式,把不同的曲线归到不同的算法里面去,这样的话不同的曲线走不同的处理路径,那么效果会很好。

三、多指标关联分析的探索

在新业态下,很多时候只看一个指标是没有办法判定业务有没有异常,或者发现指标和指标之间是有关联的。

我们经常在一些业态里看到会监控某一个业务的成功量、成功率、失败的错误请求数几个指标相关变化。有时候会发现指标有异常传播,这个传播有几种方向,比如在不同的业务之间传播,两个程序之间有关联关系,A坏了B也受影响了。还有就是混合部署的情况,同一个集群布两个业务,A被打爆,B也被压死了。

解决这个问题就需要发现和维护相关的指标,就是哪些指标应该有关联的,发现之后要维护。发现关联可以使用三种方法,第一种利用 CMDB看哪些应用之间可能相关;第二个利用时间序列相关性。但从实际来看,一般是在第一个检测的基础上,再在局部做第二种,而不是全局的检测。第三种利用关联规则挖掘看哪些项经常关联报警。

四、故障影响面和根因分析的探索

监控是为了发现问题,但是发现完了问题,很多时候是需要想怎么能够解决问题的。在故障根因分析层面,首先看一下问题的范围和边界,大家都想有一个自动发现问题分析原因的系统, 但在实际过程中,这个事情是非常难解决的,但是可以做到缩小范围。

首先要从阿里巴巴几万个应用程序里,先要看这个业务故障到底跟哪几个应用相关。阿里的目标是当站点、产品线和业务功能指标出现问题的时候,能够定位到应用服务层,包括数据库层面。之后可以对故障做一个结构化的快照,这样后的故障可以从中学些东西,但是这些快照如果用汉字写就很难被机器利用,所以阿里建立了一个囊括主流的所有运维相关事件的数据仓库,这个数据仓库能够告诉我们在哪些运维的对象上发生了什么事情,最后我们对这个事情做一个排序和筛选,把可疑的挑出来。

五、智能运维在故障治理领域的未来规划

最后主讲人探讨了在智能运维领域现在与未来还可以做什么事情。

运维本质上是解决在线服务运行中的质量、成本和效率三方面。 最近阿里在探索的,是无人值守相关的东西,靠自然语言提出的问题,是不是可以通过机器人来回答。现在还不能做到全自动,还是需要人工确认。

 

3.     个人体会

阿里的主讲人介绍了在监控时,面对一些时间序列分析问题的处理措施,提出当有很多的时间序列,有的周期性明显,有的周期性不明显的时候,可以采用算法路由,用合适的算法处理合适的数据。虽然我们这边的项目可能还做不到自动路由,但是可以分析提取一些数据特点,然后使用适合的方法。

另外,在对未来的展望上,大家都提出智能客服、无人值守这些类似的想法,解决运维人员面对的现实问题,京东和阿里也都已经进行了初步的探索使用,可以预见相关技术未来会有一定发展。

 

观看大会录像地址http://www.gaowei.vip/cv-836602.html?uniqueid=637122642540740607


查看评论

暂无评论

发表评论
  • 评论内容:
      
首页
团队介绍
发展历史
组织结构
MESA大事记
新闻中心
通知
组内动态
科研成果
专利
论文
项目
获奖
软著
人才培养
MESA毕业生
MESA在读生
MESA员工
招贤纳士
走进MESA
学长分享
招聘通知
招生宣传
知识库
文章
地址:北京市朝阳区华严北里甲22号楼五层 | 邮编:100029
邮箱:nelist@iie.ac.cn
京ICP备15019404号-1