背??景随着搜索业务的快速发展，搜索系统正在走向平台化，运维方式经历了人工运维、脚本自动化运维，最终演变为DevOps。然而，随着大数据和人工智能的快速发展，传统的运维方式和解决方案已经不能满足需求。基于如何提高平台效率和稳定性，减少资源消耗，我们实现了在线服务优化大师hawkeye和容量规划平台torch。经过几年的沉淀，我们在配置合理性、资源合理性设置、性能瓶颈、部署合理性四个方面都做了比较好的实践。下面详细介绍鹰眼和火炬系统的架构和实现。AIOps实践与实现hawkeye—智能诊断优化系统介绍hawkeye是一个智能诊断优化系统。平台大致分为三部分：1.分析层，包括两部分：1）底层分析项目hawkeye-blink：基于Blink完成数据处理工作，重点是访问日志分析、全量数据分析等。该项目专注于底层数据分析。借助Blink强大的数据处理能力，每天分析搜索平台上所有Ha3应用的访问日志和全量数据。2）一键诊断项目hawkeye-experience：基于hawkeye-blink的分析结果，进行更贴近用户的分析，如字段信息监控，包括字段类型合理性，字段值单调性监控等。另外，还包括但不限于检测kmon无效告警、smokecase入口、引擎降级配置、内存相关配置、推荐行列配置、切换时最小服务行比。hawkeye-experience项目的定位是做引擎诊断规则的中台，将平时运维人员在优化维护引擎方面的宝贵经验沉淀到系统中，让每一个新接入的应用都能快速上手。享受这样宝贵的经验，而不是一次次踩坑后获得，让每一位用户都有一个类似于智能诊断专家的角色来优化自己的引擎是我们的目标，也是我们不断前进的动力斗争。hawkeye-experience的数据处理流程图如下：2.web层：提供鹰眼分析结果和可视化监控图表输出的各种API。3、服务层：提供鹰眼分析优化API的输出。基于上述架构，我们实现的诊断和优化功能包括：资源优化：EngineLock内存优化（无效字段分析）、实时内存优化等；性能优化：TopN慢查询优化、buildservice资源设置优化等；智能诊断：日常巡检、智能问答等。EngineLock内存优化对于Ha3引擎，引擎字段分为倒排（index）索引、正向（attribute）索引和summary（汇总）索引。可以通过引擎的Lockpolicy来为这三类索引设置内存的加锁或者不加锁。锁住内存的好处不言而喻，加快访问速度，降低rt，但是想象一下，100个字段中，如果两个月只访问其中的50个，其他字段根本不在索引中访问，这会导致大量浪费宝贵的记忆。为此，鹰眼进行了如下分析和优化，针对头部应用进行了针对性的指标瘦身。下图展示了Lock内存优化的过程，总共节省了大约数百万。慢查询分析慢查询数据来源于应用的访问日志。查询次数与应用的访问次数有关，通常在千万级甚至亿级。从海量日志中获取TopN慢查询属于大数据分析范畴。借助Blink的大数据分析能力，我们采用分治法+hash+小顶堆的方式获取，即先解析查询格式，获取其查询时间，取解析后的k-v的md5值数据，然后根据md5值做Sharding，计算每个shard中的TopN慢查询，最终在所有TopNs中找到最终的TopN。针对分析出的TopN慢查询提供个性化优化建议，帮助用户提升引擎查询性能，间接提升引擎容量。一键诊断我们使用健康评分来衡量引擎的健康状态。用户可以通过健康评分清楚地了解自己的服务健康状况。诊断报告给出了诊断时间、配置不合理的简要说明和详细信息、优化收益、诊断逻辑和一键式诊断后出现问题的结果页面如下图所示，诊断详情页面未列出，原因如下：空间限制。智能问答随着应用的增多，平台遇到的问答问题也越来越多，但在问答过程中不难发现很多重复的问题，比如增量停止的咨询、公共资源告警等。对于这些有固定解决方法的问题，其实就是提供chatOps的能力，可以借助问答机器人来处理。目前hawkeye结合kmon的指标和可定制的告警信息模板，通过在告警文本中加入诊断，对此类问题进行智能问答。用户在问答群中粘贴诊断文本，at机器人即可获取报警原因。torch-capacitygovernanceoptimizationhawkeye主要从智能诊断和优化的角度提升效率，增强稳定性。火炬专注于从容量治理的角度降低成本。随着搜索平台应用的增多，面临着以下问题，很容易导致资源利用率低，机器资源浪费严重。1）业务方随意申请容器资源，造成资源成本严重浪费。需要明确引导业务方合理申请多少资源（包括cpu、内存、磁盘）或者资源管理，以容器成本消耗最小为基础屏蔽用户。2）业务不断变化，真正的线上容量（能承载多少qps）不为人知。当业务需要增加流量时（比如各种促销），是否需要扩容？如果扩容是扩列还是增加单个容器的cpu规格？当业务需要增加数据量时，拆分列或扩展单个容器的内存大小是否合适？这么多问号中的任何一个都会让业务方感到困惑。解决方案如下图所示。现有的容量评估资源是kmon数据，在线系统的状态报告给kmon。是否可以直接分析kmon数据进行容量评估？实际实验发现还不够，因为线上应用很多，水位比较低，高水位下的拟合容量不够客观，所以需要压测服务才能真正了解性能和容量.压力测试好了，接下来要解决的问题是压哪里？上线压力风险较大，预发资源有限，机器配置较差。所以需要在线上克隆模拟单个实例，然后进行压测，既准确又安全。有了压测数据，下一步就是通过算法分析找到成本最低的资源配置。在以上核心支持下，通过任务管理模块对每个任务进行管理，自动进行能力评估。以上就是我们的解决方案。下面首先介绍一下整体架构，然后介绍各个核心模块的具体实现。系统架构如图所示，从下到上，首先是接入层。接入平台只需要提供平台下各个应用的应用信息和集群信息（目前接入tisplus下的ha3和sp），应用管理模块会整合应用信息，然后任务管理模块会应用被抽象为个人能力评估任务。一个完整的容量评估任务的大致流程是：先克隆一个单实例，然后对克隆的单实例进行自动压测，达到极限容量，压测数据和日??常数据由数据工厂处理，格式化后的数据交给决策中心，决策中心会先用压测数据和日??常数据，通过算法服务来评估容量，然后判断收益。如果收益高，会结合算法容量优化建议进行克隆压测验证。如果验证通过，结果将被持久化。进行简单的容量评估（根据压测得到的极限性能进行简单的容量评估），容量评估完成后故障决策中心会清理克隆和压测应用的临时资源，以免造成浪费的资源。最上面是应用层。考虑到火炬容量管理不仅仅是为tisplus定制的，应用层提供了容量仪表盘、容量评估、容量报表、收益仪表盘供其他平台访问和使用。此外，它还提供了其他系统传输的容量API。容量评估还依赖于搜索许多其他系统，例如maat、kmon、hawkeye、drogo和cost系统，形成一个闭环。架构实现cloneemulationcloneemulation简单来说就是克隆一个在线应用的单个实例，ha3应用就是克隆一个完整的行，sp就是克隆一个独立的服务。随着搜索河马工具的诞生，资源以容器的形式使用，再加上suezops、sophon等DevOps的发展，快速克隆一个应用成为可能。下面给出克隆控制模块的具体实现：克隆当前分为浅克隆和深克隆。浅克隆主要是针对ha3应用通过影子表直接拉取主应用的索引，省略构建环节，加快克隆速度。深度克隆意味着克隆的应用程序需要离线构建。克隆的好处很明显：服务隔离，通过对克隆环境的压力测试，可以间接的了解线上的真实容量。资源优化建议可直接通过克隆环境压测验证。克隆环境用完后会自动释放，不会浪费线上资源。压测服务考虑到日常kmon数据的大部分应用都缺乏高层指标，引擎的真实能力只能通过实际压测才能获得。因此需要压力测试服务。公司的亚马逊压测平台和阿里妈妈的压测平台发现无法满足自动压测的要求，于是我们基于hippo开发了分布式压测服务，自适应增加压力woker。算法服务能力评估的目标是最小化资源成本，提高资源利用率。因此，有一个前提是资源可以用成本来量化。成本也是搜索平台衡量平台价值的一个重要维度，所以我们这里用金融来搜索。制定价格公式后，我们就有了这个前提。经过和算法同学的大量实验分析，发现这个问题可以转化为带约束的规划问题。优化后的目标函数是价格公式（有内存、cpu、磁盘几个变量）约束条件是提供的容器规格和容器数量必须满足最佳qps内存和磁盘的要求。AIOps展望通过在tisplus搜索平台上实施鹰眼诊断优化和火炬容量管理，大大降低了成本，提高了效率和稳定性，为将AIOps应用于其他在线系统树立了信心。因此，下一步将结合鹰眼和火炬进行AIOps平台建设，让其他在线服务也能享受到AIOps带来的好处。因此，开放性和易用性是平台设计的两个首要考虑因素。为此，下面将重点建设四大基础库：运维指标库：将在线系统日志、监控指标、事件和应用信息进行标准化和整合，方便在运行过程中获取各种运维指标。战略实施过程。运维知识库：通过ES积累日常问答中积累的问题集和经验，并提供检索和计算功能，方便线上同类问题的自动诊断和自愈。运维组件库：克隆模拟、压测和算法模型组件化，方便用户灵活选择算法进行策略实施，轻松使用克隆模拟和压测有效验证优化建议。运维策略库：允许用户通过画布拖拽写入UDP，快速实现自己系统的运维策略。该策略的实施变得足够简单。基于上述基础设施的构建结合策略，可以产生各种运维场景下的数据，并在各种场景下应用综合故障处理、智能问答、容量管理和性能优化。
