立体化监控中人工智能场景落地

白凡

分享：赵明
编辑：白凡

今天带来的主题是立体化监控中的人工智能场景落地。给大家介绍一些监控的场景怎么应用人工智能的算法。

1. 自我介绍

我14年是加入京东，一直是负责京东APP这一块的运维开发和质量相关的保障，之前的话是在腾讯，也是负责电商系统的监控以及监控系统的开发。

从前中台的划分，我是在前台，更偏向于应用这一块的范畴和开发。我们智能渐渐从运维开发的角色更多的做一些质量相关，和质量监控相关的东西，不是传统意义上的一些监控事情，我分享的案例特别是有一个关于业务反馈的案例，大家觉得是挺奇怪，为什么是这个场景要落地？我后面会详细的做一些介绍。

2. 痛点和现状

我今天是来和大家分享的是什么？就是吐槽，因为部门里面很多人都在说AIops，要做一些人工智能，像我这种相对来说在比较大的公司落地的时候也有很多的问题，特别是对场景的把握，什么场景可以做，什么场景不能做，怎么做，怎么去利用一些资源落地的时候，都有很多的一些问题，并不是大家想象当中那么的理所当然。我们现在已经在落地了一些项目，这些项目都是通过很长期的过程，每一个项目都是要持续一年以上，都有一个相对来说比较漫长的过程来真正的落地。所以我觉得这一块的投入产出比都是要考虑在内，不是说现在火就去干，不是这样，我们一定要真正的衡量这个东西值得不值得，对我们的价值是什么。

我们想清楚之前没有必要去做，一会我会介绍一个案例，就是我们采购的案例，是做的不好的案例，确实对我们来说也是有很大的影响。
我说一下痛点和现状，几个点像需求，资源、规划这几个点大家知道。需求方面，我们没有什么需求，我们做的挺好，我们搞AI干吗呢？这个成本也是很大。资源很贵，人和贵，机器很贵，显卡也是很贵，可能我们研发人员不会看中这个，我的习惯就是拿到一些机器会看到这个机器的配置，搜一下这个机器多少钱，这个是我自己的个人习惯。

还有就是规划，为什么说规划？我后面会说到在落地的过程中遇到了什么问题，基础设施。什么是基础设施？设备是一个基础设施，还有一个是平台的基础设施，我们京东也有。但是我觉得老实说，离真正可以很好应用有一些差距。这一块基础设施的东西必须要在落地的时候要考虑的，如果没有的话，我们要怎么解决？这些都必须要考虑，不是说我要做就做了，因为周边的因素有很多。

我先说一下需求，告警，准确率，覆盖率，及时性需要亟待提高，这些东西大家会想到，还有一些分析，就是怎么从线下找到一个故障的根源，说说很简单。我后面会介绍一个案例，大家可以想一下这种根因分析怎么做。
我们在后端，就是传统的PC端，中低层和后端可以做的事情在几年前做的差不多了，比如说一些曲线的闭塞，这个不是很新鲜的东西，怎么让这一块东西应用到真实的场景中？我们可能要花很多时间来积累。
另外一个就是要用户画像，我提前透露一下，用户画像是我们做的很多的项目，这个不好做，有可能和我们自己京东的业务形态有关系，可能和我们现在一些数据没有准备好有关系。我们和算法团队沟通的时候，他们说你们要一个数据科学家。数据科学家做什么事情？就是规整数据，把所有的数据序列化，这个事情没有做完的话做用户画像是可以先放放。

第二个说的是前面介绍的一些资源，机器资源，人力资源。机器资源方面，大家看到一个英伟达的显卡是5万一张，很贵，现在新出一个V100，8万1块。人工智能从去年到现在，热度是和这个曲线差不多，17、18年很火，大家都做，股价也是涨的很快，中间有一些拉炮的事情，也会用很多的显卡资源。到现在19年，这个事情不一定那么火了。

还有一个就是人工智能这一块明显感觉到有一点下来，大家被风吹过一遍要想这个东西是不是需要，这个东西怎么做。

另外就是大神的资源，大神很厉害，我是写程序的，我是工程团队。在京东里面，我说一下我们的组织架构。我们做一个开发团队，是做配置算法资源。算法人力非常非常贵，起点很高，人才的竞争很激烈，怎么说？你招不到人。我所了解，我们有一些同事在美国硅谷，他们就做一些算法的研究，他们不会帮你部署或者是贴合你的场景做一些事情，更多就是关注这个算法的精度，还有这个算法适合不适合，能不能发挥最大的功能。这一块东西我们和算法团队沟通的时候是花了很长时间，是花了一年多的时间和他们合作，建立一些信任关系，公司内部团队也是需要这种沟通。

另外就是打标，我是接近实操层面，是开发的层面。碰到的问题很多，打标这个事情是很难的事情，没有人愿意打标。我们现在用的算法是要打标，很多的数据要打标，谁来打标？老师们和我说这个打标资源要找好，说有多少的人工就有多少的结果，打标的质量是决定后面算法的准确度，我很头痛，我们开发人员打标，为什么打标？我们要有一个标准，模棱两可的数据形成一个文档，说一定要这么打，不要打成那样。

其实每个人打标的方式和大家的思维不一样，我们在做的过程，对基础设施这一块的需求也慢慢的有了，觉得打标这个东西不是那么简单，不是说鼠标点点归归类就可以了，是双向互补的过程，必须要用两份数据，如果是一个人打标，产出的算法和结果和告警准确率不一样，可能这个人打标的想法或者是准确率相对比较高。另外一个人相对来说更低一点，打标的资源是很重要的一个点。必须要通过我们的一些准确度反哺打标平台，找出最优的打标的人去打标，帮我们这个算法进行进一步的提升。

3. 实践之路

前面说了很多关于现状和痛点，大家感觉这个东西是不是不要做了？我也觉得是挺难的，但是尝试还是要尝试，找一些场景确实是可以再试一下，我们也会了解到不管是一些公司，具体公司不说了，我知道一些。有一些专门的打标平台，提供一些中间键的算法平台，他们都可以做这个事情。我们这个团队一些特性来说，其实有一些东西不能全部自己做或者是去买，公司里面没有的话，我们要自己想办法解决，更多是这样。
后面的话我介绍一下怎么实践的，一共有四个场景，一个是用户反馈，网络切换，应用画像，告警基线。

成功的几项就是基线，做一些告警基线，算一些预测的曲线。还有一个就是网络监控，我们做了很多事情，有一些事情不是我们做的我们也做了，我们14、15年做这个事情的时候发现了一个问题就是对这个东西做的不是很多，怎么做不详细展开，大家有兴趣可以单独来聊。
还有一个就是用户反馈，后面会详细的介绍一下，就是在一个京东APP上面，大家用了不少了，大家可以提交一些反馈信息。在京东会比较细，我们为什么选择这个作为切换点？因为我们这个团队是属于前台，我们确实可以发现很多问题，这个问题不一定是中间键层和主键层可以发现的问题。
为什么可以落地？这几个场景比较简单抽象。另外就是关联的数据不是很多，我们这些数据都可以自己生产，而且这几个场景里面都有一些人力操作。

失败组，我说一下，说太多我觉得比较丢脸，简单说一下画像，昨天晚上我们经历了一个双十一期间最大的洪峰，昨天流量和双十一是差很多，我们一般的扩容、压测的时间会很长。对压测和对扩容有兴趣的话，可以问我。
这个花费了我们很多时间和精力，因为每年两次大促，大家都看的很紧，确实有很多不可控的因素。我们会比较长一个时间提前准备很多次的扩容。
今天我在我们一些微信上看到很多业务做扩容，我们会根据双十一流量的情况再去进行一些扩容的准备。昨天晚上是非常重要一个时间点。
我们想做这个事情就是为了扩容的时候日子好过一点，结果方面，我觉得不是特别的理想。原因是什么？刘老师说过了，很多数据拿起来不是很方便，标准都没有做，字段扁平化没有做，要做的话数据很多，特别是有一个问题是对流量的预估有问题，因为运营给我们一些流量数据，对一些流量的预期，怎么对应到机器和对应到TPS和PPS，这个算法是太复杂了。每一个应用都是不一样的存在，很多是带宽密集性，这个是简单的分类，有一些特殊应用场景没有放进去，怎么做模型？这个投入产出很大， 如果我们投入一些人力做非标品，这个对我们能力提升不是很大，所以我们觉得这个算法不能达到一定程度的话就放弃。

还有一个就是压测工具，我们自己的这个工具可能有一点问题，比如说没有压到位，不能压到一个临界值，也不敢压到一个临界值，这个东西执行起来比想象难的多。

4. 场景落地

一个是基线预测。今天有很多老师会说，我不仔细介绍了。网上也有很多介绍，大家可以上网查，就是拿一些历史数据，算一下概率，拿一些数据做对比，做一些告警等等。这些算法我们会用在一些网络、规则性、周期性的数据里面。这个里面也有一些网络相关的问题，我们团队是做的比较多网络相关的事情。
效果的话还不错，对规则曲线一些预测是符合预期的。

网络监控方面，比上面监控稍微复杂一下，不能说是人工智能，只能说是全自动，和智能有一点搭边。我们京东对我们的要求是比较高，另外一个就是我们是做机房的部署，需要有这种工具和数据支撑我们的切换。

运营商交割很难受，可能是在半夜，或者是凌晨，会导致我们14、15年的时候有一些波动，这个是不能接受的，我们在这种情况下做很多的方案维护数据，也是跟着我们自己相关的技术站做切换。切换的时候比如说上海移动的网络坏了，我们再切换到上海联通。这个大家也问这个为什么是业务部门和前台部门做？我们客户端这一块提供了一些配置策略，我们当时切换的情况是这样，谁先能切谁切，谁有能力就先把这个切换做了，第一时间把这个事情做好，这个是我们前台部门对团队和监控、切换的要求。在5分钟之内要切换，如果没有的话，可能要问责，影响KPI。

这个是在做这个事情之前的准备，像主动拨测，我们做了一些网络诊断。还有一些被动拨测，这两个是一个正一个反，判断是进流量还是出流量的问题。
还有一个就是异常的日志，这一块的建设伴随我们有一个TK，专门的采集相关的数据，然后去报一些异常的信息，比如说像网络组件层的网络异常，或者是一些组件的异常，我们定位上面的一些问题，这些数据会采集和上报。
这一块我们确实也是做的比较久，前期做了比较多的工作。
另外一个就是核心指标关联，这个是很简单，像核心机房的电压数据等等，这个是我们切换的一个重点。

调度这一块，也是从刚刚开始的全手动到半自动，到全自动，全手动就是告警了以后我们去看看是出什么问题，然后去切，看看平台有没有起来，起来就OK了，没有起来就继续切。
半自动，就是告警发出来以后，我们去看是什么情况，根据一些切换的值告诉你切换的对象，不要去选了。后面是根据这个经验值做一些自动的切换，然后发一个告警，告诉运维的同学已经切了。前面两个是轻人工智能。

后面就是业务反馈，我们做了3期，现在是第三期。做什么事情？我们可以再简单的介绍一下，一些用户有一些问题，通过客户端的功能去上网找东西，这个东西是非常非常细，在过去17年以后，我们很少发现发生变更或者是交换机、内部机房操作导致的工单下降的情况，我们对故障或者是去定位问题的细化程度已经到达了一个高度，订单出问题一定就会完蛋。订单没有问题，那么是什么问题？影响用户体验，或者是反馈问题。我们前台一些反馈、定责会根据这一块的业务反馈数据来做。
我们这一块在整个前台这一块是有相对来说比较重的话语权。

我们再说一下怎么做，这个是我们第二期的架构图。先说第一期，我们做了什么？分类，分词，这个是做的比较好一点，提升分类的准确度。把关键词归类，做一些分词，分类做一些准确度，做一些告警，这个是比较简单。这个准确度可能有一些问题，还有沉重一些未归类的问题，因为关键字不很全，我们不能实时维护这些关键字。
第二期就是根据架构图做了调整，做什么调整？半人工智能，半聚类，算法不说了，我也说不太清楚。大家有兴趣了解可以去看一下。

我们是把关键字做分类，很多的东西要进行进一步的归类，这个时候要人工智能持续打标，把这个东西归到合理的分类，这个时候人工智能就介入了。
第三期我没有画，上个月刚刚结束，还没有总结。主要是把关键字这一块替掉，用机器学习的算法把这个事情搞定了，增加了一个相似反馈的告警，发现什么？发现一些时间跨度比较大，从语义分析这个问题的场景。
提升点，我们每做一步要量化产出，我们都需要去统计准确度，告警的准确度，我们要把以前的告警拿出来，和现在的告警做对比，看看这个告警是哪一个更准确。另外一个就是模型的准确度，表现的东西就是告警的准不准，还有分类分的准不准，这个也要人去看，验证这个东西对我们来说是提高还是没有提高。

做这个过程中，我们也是做语义的分析，也是做一些情绪分析，把这些客服相关的问题，因为有大量的数据是客服相关，我们给他们一些算法保证把这个范围的一些东西做优先的处理。

这个是数据的总结，前面说了我们有很多分类，我们做了几期，打标的数据量也有这么多，分类有74个。主要是解决了对情绪、热点问题，新类目故障的快速的感知能力。

这边列了几个告警事件，这个时间我标出来了，大家觉得这个告警说时效性是乱说，我觉得我们告警不发出来可能这个事情就过去了。因为有一些数据的跨度会相对来说比较长，所以像这种问题和后端的服务不一定有关系，更多是在测试一些漏测，但是会造成用户体验的问题，我们会做这种事情。

另外一个案例，用户在用的时候，可能某一款手机的特殊的屏幕，特殊的机型出现了莫名其妙的问题，我们会把这个作为一个告警，做相似的聚合，通过相似度把这个作为告警发出来。

后面我们也是在不断的继续迭代，我们把告警阈值进行调优，情绪反馈也是继续做打标，或者是做一些自动打标的尝试，把这一套系统逻辑方式去做推广，或者做更多的接入。大家看到我们前面一些机器资源，不管是人力资源还是机器资源是很贵，我们要摊薄这个成本，我们就要考虑前期的一些准备。

5. 思考和展望

另外就是这个场景的一些挖掘，怎么挖掘？我觉得主要是要发现AI落地场景，要看看是不是可以做一些尝试。另外要珍惜一些资源，不管是人力还是AI。