从DevOps到AIOps，阿里如何实现智能化运维？

摘要： AIOps英文全称是Algorithmic IT Operations，是基于算法的IT运维。AIOps是运维领域上的热点，然而在知足业务SLA的前提下，如何提高平台效率和稳定性及下降资源成本成为AIOps面临的问题和挑战。

背景

随着搜索业务的快速发展，搜索系统都在走向平台化，运维方式在经历人肉运维，脚本自动化运维后最终演变成DevOps。但随着大数据及人工智能的快速发展，传统的运维方式及解决方案已不能知足需求。

基于如何提高平台效率和稳定性及下降资源，咱们实现了在线服务优化大师hawkeye及容量规划平台torch。通过几年的沉淀后，咱们在配置合理性、资源合理性设置、性能瓶颈、部署合理性等4个方面作了比较好的实践。下面具体介绍下hawkeye和torch系统架构及实现。

AIOps实践及实现

hawkeye——智能诊断及优化

系统简介

hawkeye是一个智能诊断及优化系统，平台大致分为三部分：

1.分析层，包括两部分：

1） 底层分析工程hawkeye-blink：基于Blink完成数据处理的工做，重点是访问日志分析、全量数据分析等，该工程侧重底层的数据分析，借助Blink强大的数据处理能力，天天对于搜索平台全部Ha3应用的访问日志以及全量数据进行分析。

2） 一键诊断工程hawkeye-experience：基于hawkeye-blink的分析结果进行更加贴近用户的分析，好比字段信息监测，包括字段类型合理性，字段值单调性监测等，除此以外还包括但不限于kmon无效报警、冒烟case录入状况、引擎降级配置、内存相关配置、推荐行列数配置以及切换时最小服务行比例等检测。

hawkeye-experience工程的定位是作一个引擎诊断规则中台，将平时运维人员优化维护引擎的宝贵经验沉淀到系统中来，让每个新接入的应用能够快速享受这样的宝贵经验，而不是经过一次次的踩坑以后得到，让每位用户拥有一个相似智能诊断专家的角色来优化本身的引擎是咱们的目标，也是咱们持续奋斗的动力，其中hawkeye-experience的数据处理流程图以下所示：

2.web层：提供hawkeye分析结果的各类api以及可视化的监控图表输出。

3.service层：提供hawkeye分析与优化api的输出。

基于上述架构咱们落地的诊断及优化功能有：

• 资源优化：引擎Lock内存优化（无效字段分析）、实时内存优化等；

• 性能优化：TopN慢query优化、buildservice资源设置优化等；

• 智能诊断：平常化巡检、智能问答等。

引擎Lock内存优化

对于Ha3引擎，引擎字段是分为倒排（index）索引、正排（attribute）索引和摘要（summary）索引的。引擎的Lock策略能够针对这三类索引进行Lock或者不Lock内存的设置，Lock内存好处不言而喻，加速访问，下降rt，可是试想100个字段中，若是两个月只有50个访问到了，其余字段在索引中压根没访问，这样会带来宝贵内存的较大浪费，为此hawkeye进行了以下分析与优化，针对头部应用进行了针对性的索引瘦身。下图为Lock内存优化的过程，累计节省约数百万元。

慢query分析

慢query数据来自应用的访问日志，query数量和应用的访问量有关，一般在千万甚至亿级别。从海量日志中获取TopN慢query属于大数据分析范畴。咱们借助Blink的大数据分析能力，采用分治+hash+小顶堆的方式进行获取，即先将query格式进行解析，获取其查询时间，将解析后的k-v数据取md5值，而后根据md5值作分片，在每个分片中计算TopN慢query，最后在全部的TopN中求出最终的TopN。对于分析出的TopN慢query提供个性化的优化建议给用户，从而帮助用户提高引擎查询性能，间接提升引擎容量。

一键诊断

咱们经过健康分衡量引擎健康状态，用户经过健康分能够明确知道本身的服务健康状况，诊断报告给出诊断时间，配置不合理的简要描述以及详情，优化的收益，诊断逻辑及一键诊断以后有问题的结果页面以下图所示，其中诊断详情页面因篇幅问题暂未列出。

智能问答

随着应用的增多，平台遇到的答疑问题也在不断攀升，但在答疑的过程当中不难发现不少重复性的问题，相似增量中止、常见资源报警的咨询，对于这些有固定处理方式的问题其实是能够提供chatOps的能力，借助答疑机器人处理。目前hawkeye结合kmon的指标和可定制的告警消息模板，经过在报警正文中添加诊断的方式进行这类问题的智能问答，用户在答疑群粘贴诊断正文，at机器人便可获取这次报警的缘由。

torch-容量治理优化

hawkeye主要从智能诊断和优化的视角来提高效率加强稳定性，torch专一从容量治理的视角来下降成本，随着搜索平台应用的增多面临诸如如下问题，极易形成资源使用率低下，机器资源的严重浪费。

1）业务方申请容器资源随意，形成资源成本浪费严重，须要基于容器成本耗费最小化明确指导业务方应该合理申请多少资源（包括cpu，内存及磁盘）或者资源管理对用户屏蔽。

2）业务变动不断，线上真实容量（到底能扛多少qps）你们都不得而知，当业务须要增大流量（譬如各类大促）时是否须要扩容？若是扩容是扩行仍是增大单个容器cpu规格？当业务须要增大数据量时是拆列合适仍是扩大单个容器的内存大小合适？ 如此多的问号随便一个都会让业务方蒙圈。

解决方案

以下图所示，作容量评估拥有的现有资源，是kmon数据，线上系统的状态汇报到kmon，那直接拿kmon数据来分析进行容量评估可不能够呢？

实际实验发现是不够的，由于线上有不少应用水位都比较低，拟合出来高水位状况下的容量也是不够客观的，因此须要个压测服务来真实摸底性能容量，有了压测接下来须要解决的问题是压哪？压线上风险比较大，压预发预发的资源有限机器配置差无法真实摸底线上，因此须要克隆仿真，真实克隆线上的一个单例而后进行压测，这样既能精准又安全。有了压测数据，接下来就是要经过算法分析找到最低成本下的资源配置，有了上面的几个核心支撑，经过任务管理模块将每一个任务管理起来进行自动化的容量评估。

以上是咱们的解决方案，接下来会优先介绍下总体架构，而后再介绍各核心模块的具体实现。

系统架构

如图，从下往上看，首先是接入层。平台要接入只须要提供平台下各应用的应用信息及机群信息（目前接入的有tisplus下的ha3和sp），应用管理模块会对应用信息进行整合，接下来任务管理模块会对每一个应用抽象成一个个的容量评估任务。

一次完整的容量评估任务的大概流程是：首先克隆一个单例，而后对克隆单例进行自动化压测压到极限容量，压测数据和平常数据通过数据工厂加工将格式化后的数据交由决策中心，决策中心会先用压测数据和平常数据经过算法服务进行容量评估，而后判断收益，若是收益高会结合算法容量优化建议进行克隆压测验证，验证经过将结果持久化保存，验证失败会进行简单的容量评估（结合压测出的极限性能简单评估容量），容量评估完成以及失败决策中心都会将克隆及压测申请的临时资源清理不至于形成资源浪费。

最上面是应用层，考虑到torch容量治理不只仅是为tisplus定制的，应用层提供容量大盘，容量评估，容量报表及收益大盘，以便其它平台接入嵌用，另外还提供容量API供其它系统调用。

容量评估也依赖了搜索不少其它系统，maat, kmon, hawkeye，drogo,成本系统等整个造成了一道闭环。

架构实现

克隆仿真

克隆仿真简单地理解就是克隆线上应用的一个单例，ha3应用就是克隆完整一行，sp就是克隆出一个独立服务。随着搜索hippo这大利器的诞生，资源都以容器的方式使用，再加上suez ops及sophon这些DevOps的发展，使得快速克隆一个应用成为可能，下面给出克隆管控模块的具体实现：

克隆目前分为浅克隆和深度克隆，浅克隆主要针对ha3应用经过影子表的方式直接拉取主应用的索引，省掉build环节加快克隆速度，深度克隆就是克隆出来的应用须要进行离线build。

克隆的优点明显：

1. 服务隔离，经过压测克隆环境能够间接摸底线上的真实容量。
2. 资源优化建议能够直接在克隆环境上进行压测验证。
3. 克隆环境使用完，直接自动释放，不会对线上资源形成浪费。

压测服务

考虑到平常的kmon数据大部分应用缺乏高水位的metrics指标，而且引擎的真实容量也只有经过实际压测才能得到，所以须要压测服务，前期调研了公司的亚马逊压测平台及阿里妈妈压测平台，发现不能知足自动压测的需求，因而基于hippo咱们开发了自适应增长施压woker的分布式压测服务。

算法服务

容量评估的目标就最小化资源成本提升资源利用率，因此有个先决条件，资源得可被成本量化，成本也是搜索走向平台化衡量平台价值的一个重要维度，因而咱们搜索这边跟财务制定了价格公式，也就拥有了这个先决条件，和算法同窗通过大量的实验分析发现这个问题能够转换成带约束条件的规划问题，优化的目标函数就是价格公式（里面有内存 cpu磁盘几个变量）约束条件就是提供的容器规格和容器数必定要知足最低的qps 内存和磁盘的须要。

AIOps展望

经过hawkeye诊断优化和torch容量治理在tisplus搜索平台上的落地大大下降了成本提升了效率和稳定性，为将AIOps应用到其它在线系统树立了信心，所以下一步目标就是将hawkeye和torch整合进行AIOps平台化建设，让其它在线服务也都能享受到AIOps带来的福利。所以，开放性，易用性是平台设计首要考虑的两个问题。

为此，接下来会重点进行四大基础库的建设：

运维指标库：将在线系统的日志，监控指标，event和应用信息进行规范整合，让策略实现过程当中方便获取各类运维指标。

运维知识库：经过ES沉淀平常答疑积累的问题集及经验，提供检索及计算功能，便于对线上相似问题进行自动诊断及自愈。

运维组件库：将克隆仿真 压测 及算法模型组件化，便于用户灵活选择算法进行策略实现，并轻松使用克隆仿真及压测对优化建议进行有效验证。

运维策略库：经过画布让用户拖拽及写UDP来快速实现本身系统的运维策略，运维指标库，运维知识库及运维组 件库提供了丰富多样的数据及组件，使得运维策略的实现变得足够简单。

基于上述基础设施的建设结合策略即可产出各类运维场景下的数据，全面进行故障处理，智能问答，容量管理及性能优化各类场景的应用。

本文是阿里搜索中台技术系列AIOps实践的分享，搜索中台从0到1建设已经走过了3年，但它离咱们心目中让天下没有难用的搜索的远大愿景还离的很是远。在这个前行的道路上必定会充满挑战，不管是业务视角的SaaS化能力、搜索算法产品化、云端DevOps&AIOps，仍是业务建站等都将遇到世界级的难题等着咱们去挑战。

本文做者：云镭

阅读原文

本文来自云栖社区合做伙伴“阿里技术”，如需转载请联系原做者。