背景
随着搜索业务的快速发展，搜索系统都在走向平台化，运维方式在经历人肉运维，脚本自动化运维后最终演变成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。
克隆的优势明显：
- 服务隔离，通过压测克隆环境可以间接摸底线上的真实容量。
- 资源优化建议可以直接在克隆环境上进行压测验证。
- 克隆环境使用完，直接自动释放，不会对线上资源造成浪费。
压测服务
考虑到日常的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，还是业务建站等都将遇到世界级的难题等着我们去挑战。
原文发布时间为：2018-08-09
本文作者：云镭
本文来自云栖社区合作伙伴“阿里技术”，了解相关信息可以关注“阿里技术”