操作方法:快速批量建站

　　操作方法:快速批量建站

　　批量快速构建网站

　　365网站建设者是快速智能，人性化的批量站建设，颠覆了传统的网站建设模式，专业丰富的模板制作网站。

　　

　　数据智能采集

　　不了解网站建设技术，还可以轻松采集数据，实现网站内容快速发布，从海量数据中挖掘有价值的信息

　　搜索引擎优化

　　

　　根据产品和用户搜索习惯定位关键词，进行科学有效的SEO优化，通过SEO技术获取目标流量，提升客户转化率

　　自定义网站/软件/应用程序

　　经验丰富的研发技术团队，完善的售后服务，根据您的网站施工要求，定制个性化的网站风格或功能。

　　优化的解决方案:网易游戏AIOps实践：异常检测的优化策略与平台化建设

　　AIOps即智能运维，是Gartner在2016年提出的概念。最初的定义是Algorithm IT Operations，是指通过机器学习、数据仓库、大数据等技术手段将人工智能应用到运维领域。数据，并根据运维产生的数据（日志、监控、应用等）进行分析和决策，得出最佳的运维策略，最终走向无人运维为技术成熟。

　　1. AIOps 路线规划

　　1. AIOps能力阶段

　　罗马不是一天建成的。根据此前发布的企业级AIOps实施白皮书，AIOps的发展主要有以下五个阶段，在我们目前的实践过程中确实得到了验证。

　　网易游戏智能运维团队于2018年开始算法研究和具体落地场景选择，随后在在线人口、异常检测、日志异常检测等方面尝试单点应用突破，取得了显著成效。目前，通过将各个维度的运维信息和告警信息串接起来，达到故障检测和进村后故障自愈的目的，从而实现多单机的流程化AI运维能力。场景AI运维模块串联。

　　这里的学习件指的是AI运维组件，由南京大学周志华老师原创创建，指模型+规范，具有可重用性、进化性、可理解性的特点.

　　AIOps 阶段

　　2、人员结构

　　与 Devops 相比，AIOps 的人员结构肯定发生了一些变化。最显着的变化是增加了算法工程师的角色。有些团队往往被称为算法开发研发工程师，即同时具备算法和平台开发能力的工程师。当然，如果一个算法工程师能够具备良好的工程能力，这肯定会对整个团队的发展产生积极的影响。但是很抱歉，要求团队中的每个算法工程师都具备良好的工程能力其实是相当困难的，尤其是在招人的时候，你会发现算法和工程之间存在一定的分离。

　　所以我们团队的配置更多的是以下三个角色：运维工程师，或者说我们的用户，他们负责给算法工程师提供具体的业务场景和需求，挖掘潜在的智能场景，提供平台，研发项目提供平台开发的场景需求。另一个是平台研发工程师和算法工程师。一个主要负责工程和平台建设，懂一点算法，但主要职责更倾向于工程开发。算法工程师专注于业务对应的算法的研究、开发和调优。这种结构也是为了专攻技术行业。

　　经过实际合作，这种合作方式大大提高了业务开发的效率，但也存在一定的技术盲点。

　　三、业务领域

　　1）时间序列异常检测

　　时间序列数据是按时间顺序排列的、时变的和相互关联的数据序列。由于运维场景的特殊性，运维数据本质上与时间序列密切相关。AIOps提供的时间序列智能分析能力是通过研究历史数据的变化趋势和内在本质，实现无需人工参与的时间序列预测、异常数据监控等智能分析功能。

　　2）故障定位及根本原因分析

　　随着微服务的发展，业务网络变得越来越复杂，问题的划分和定位变得特别困难。故障识别与诊断是运维场景中智能分析的核心部分。AIOps提供的故障识别和根因定位能力是通过数据挖掘的方式综合故障数据和人工经验，自动提取故障特征，自动定位故障。

　　3）文本处理分析

　　文本的处理范围很广。AIOps提供广泛的文本处理和分析能力，涵盖信息抽取、语义分析、智能搜索、对话系统等领域，并提供可直接应用于产品策略的NLP技术能力。

　　4）聚类和相似性分析

　　将一组物理或抽象对象划分为相似对象类的过程称为聚类。聚类是基于某种相似性进行抽象的过程。AIOps提供的聚类和相似性分析服务可以使用有监督或无监督算法，结合统计特征，对给定格式的数据进行相似性聚类，从而大大降低数据识别和处理的成本。

　　2.异常检测

　　1.问题

　　传统的静态阈值目前难以适应不断变化的业务场景。阈值过高会漏警，过低则会引发告警风暴。时序指标的异常检测不同于传统的静态阈值，用户无需手动配置。AIOps 使用机器学习算法结合人工标注结果，自动学习阈值，自动调整参数，提高告警的准确率和召回率。异常检测能够更好地满足多样化服务的需求，覆盖更多类型的异常。

　　二、适用场景

　　1）异常阈值难以定义

　　2）人工成本高

　　对于异常检测，其实网上很多文档或者书籍都给出了一些常用的算法或者工具。我们也在这方面应用这些算法或工具。当然，我们也做了很多相应的算法优化和调整。我给他们在这里。我们团队在这方面的一些思考和策略。

　　模型上线时，我们选择统计+规则的无监督解。主要优点是：

　　3) 毛刺异常

　　毛刺异常是在某一时刻突然出现在KPI曲线上的非周期性局部最大毛刺。如果只用KPI的大小进行阈值判断，很多情况下无法准确发现异常值，因为KPI值本身也可能有一定的趋势。使用一阶差分可以有效去除趋势项，从而暴露异常。此外，SR算法对此类异常也有很好的检测效果。

　　4) 异常的突然上升和突然下降

　　

　　异常急升急降是指KPI曲线上出现异常急升急降，但并未立即恢复，KPI值持续保持在异常值附近的异常。这是一个持续性的异常，很多业务，比如在线人数和CPU使用率，都非常关心这种异常。识别此类异常可以通过异常值任一端的窗口内的均值偏移来识别。

　　但是因为KPI本身有趋势和周期，所以正常点两端的窗口也有均值偏移。这时可以使用STL对时间序列进行分解，然后计算残差部分的均值偏移，可以减少趋势项和季节性项引起的误报。此外，较大的毛刺也会产生均值偏移，容易出现误报。因此，在计算两端窗口的均值之前，先使用esd检验去除异常值，这样可以去除大毛刺对均值的影响，减少模型的误报。

　　5) 频率变化异常

　　频率异常表现为持续的毛刺异常。此时曲线的振荡增加，也是一种持续性异常。这种曲线虽然比较少见，但也是商家比较关心的一种例外类型。

　　可以使用窗口内的一阶差分异常计数值来做出决定。

　　3.异常判断方法

　　设计好各种检测模型后，需要根据模型的输出进行异常判断，从而判断当前点是否异常。对于暂时性异常和持续性异常，需要使用不同的方法进行异常判断。

　　1) 分配方式

　　根据数据分布的假设，设定阈值，适用于瞬时异常的判断。我们使用 3sigma 和箱线图来确定瞬态异常，并在大多数曲线上测试了稳健的结果。

　　2) 业务计数阈值法

　　根据业务需求，设置计数阈值，适用于持续异常的判断。我们为持续异常设置了计数阈值，如果异常计数超过阈值，则会发出警报。例如，在稳健回归中计算实际曲线与预测曲线之间异常差异的计数；例如，窗口中一阶差分的异常计数可以直接通过计数阈值来判断。

　　另外，为了融合不同模型的输出，得到更鲁棒的判断结果，可以通过线性变换将分布法和业务计数阈值法转化为0到1之间的分数。这时候可以通过分数加权得到模型融合。，如果融合得分超过0.5，则为异常，在不同曲线中可以保持较好的异常判断效果，同时也具有较强的鲁棒性。

　　三、平台建设

　　AIOps本身也是一种迭*敏*感*词*发模式，我们在平台化的过程中也遇到了一些问题。首先是算法和工程之间的界限比较模糊。算法工程师希望专注于算法开发和调优，不想在工程上花费太多时间。另外，算法包与项目强耦合，算法的每次优化和参数变化都需要项目配合发布。

　　我们希望算法和工程能够更好的解耦，既能满足算法快速迭代的需要，又能满足工程平台开发稳定性的要求。

　　此外，我们还发现 AIOps 使用的数据可能是多种多样的。就异常检测而言，基础指标数据、日志数据、模板数据是不同的。

　　故障定位的扩展可能还需要使用与配置相关的数据，例如业务拓扑和网络拓扑的CMDB数据，甚至结合异常事件和变更事件等事件信息数据。

　　一、系统架构设计

　　基于以上问题和目标，我们设计了如图所示的五层系统架构。其核心目标是按需加载不同的算法，安排不同的检测流程，在保证高可用的同时提供多种服务类型。但是可以统一管理，隔离各个业务甚至流程之间，通过统一的平台进行调度。为了节省资源，动态调整算力，保证整个服务的运行效率。

　　1) 数据访问层

　　底层数据访问层负责实时采集各种监控指标、系统日志、业务日志和业务指标。对于系统和业务指标，可以通过我们监控团队自主研发的代理进行数据采集。一般在每台服务器初始化时都会自动安装配置。

　　2) 数据层

　　上述数据访问层采集接收到的数据会写入HDFS进行持久化，该层还将负责采集接收到的数据的预处理、ETL、聚合等。为了提高性能和可用性，指标数据会根据冷热数据的不同分别存储在 TSDB 和 Redis 中，我们检测使用的历史数据就是从这里获取的。

　　3) 服务层

　　这里主要是离线训练模型，训练好的模型上传到S3存储。当模型迭代或算法策略发生变化时，算法工程师可以独立完成整个环节的开发和测试，无需平台工程师。使用权。由于模型是从平台框架中提取出来的，可以独立配置和管理，进一步降低了算法与工程的耦合度。另外，当接入新的业务场景时，算法和工程师可以通过约定接口独立开发代码，分别上线。

　　4) 应用层

　　不同于网络服务的应用层，这里更多的是指不同SaaS平台的功能应用。基础运维负责反映指标的真实波动，通过数据层汇总数据。目前，我们的监控团队已经做到了秒级。液位监测数据显示。AIOps 平台也嵌入在这一层中。它的主要功能是通过实时流式传输、任务调度等调用相应的模型，对数据进行各种算法检测。

　　5) 显示层

　　用于检测结果的显示，已以单个事件或数据图的形式显示。

　　2.检测流程设计

　　这里主要介绍检测平台在应用层的内部实现思路。整体数据流如图所示。用户会在我们的运维门户网站上创建相应的检测任务，并将配置同步到flink规则库保存。这时候agent会采集将对应的指标数据发送给flink进行处理。预处理，flink 根据规则库中的配置对数据进行预过滤和预处理。

　　处理后的数据也会经过算法整理模块。该模块主要是根据之前的用户配置和我们预设的匹配规则，给检测到的数据添加一些排列、任务、策略相关的信息。这些信息决定了算法使用的模型、历史数据、特征和其他信息。然后，根据这些信息，动态加载模型调用并输出结果。

　　作为算法的抽象，算法模型可以通过注册上传的方式上传到S3中存储。注册完成后，算法模型会相应生成、排列和训练组件。平台和组件通过定义算法的唯一标识符、接口以及输入和输出类进行交互。平台调度引擎会根据上述配置动态加载相应的算法模型进行检测调度。

　　具体检测架构实现思路如图所示。首先，算法模型作为可插拔算法包存在于服务中。每个算法包都有独立的线程资源。使用python类加载方式，可按需下载更新。算法模型的热部署。

　　框架本身就相当于一个调度管理工具，负责加载不同版本的算法，进行算法路由和策略计算。同时，我们设计了一套相关的编排和调度协议，并将具体的参数配置和编排方式开放给工程师自己定义，进一步解耦了算法与工程、业务与平台的关系。

　　

　　例如，一些业务场景往往需要使用历史数据。事实上，算法工程师并不关心历史数据的获取和预处理。此类操作一般交给平台工程师。

　　我们抽象了平台内历史数据获取的逻辑。具体业务数据的获取和存储由平台工程师根据业务需要编写。对应的输入输出，算法调用模块通过协议获取一些关键参数和配置，内部自动调用这些具体的类和方法，将数据传递给模型进行检测。

　　事实上，在历史数据的获取和处理过程中，历史数据的提取往往成为瓶颈。例如，该算法可能需要 7 到 8 天的历史数据作为输入。随着检测次数的增加，这会给 TSDB 带来巨大的压力。另外，计算历史特征所需的输入量可能不同，冷热数据，读写分离都可以解决。我们还在平台内部维护了一组历史数据的内存存储，并通过管道添加数据压缩。缓存历史数据的方法。同时，将一些计算特征存储在内存中，以减轻实时计算模块的压力。

　　这是我们抽象类图的实现。基础类提供存储、排列、更新等基本操作。由于平台开发工程师根据业务场景定义数据，将这些独立的功能组合起来，满足各种业务需求。需要。

　　在用户体验方面，我也做了一定的改变。首先是标记异常的方式。我看到很多平台都是以事件的形式和同链比例来展示的，因为我们已经有一个报警平台兄弟系统，而在实际使用中发现这种单一事件的形式很容易给用户造成误解，所以我们使用像grafna这样的大图来异常显示和标注。

　　另外，用户反馈和标注非常重要，很大程度上决定了模型的调优，提高了算法的准确性。有时用户实际上很懒惰并且经常忽略标签。我们通过内部消息工具popo直接将检测结果和标注链接发送给用户，培养用户标注的好习惯。

　　4.智能故障管理

　　随着游戏和系统架构的日益复杂，运维人员收到的告警信息也变得多样化。面对故障时，复杂的告警信息让运维人员一时难以理清逻辑，甚至视而不见，无法第一时间解决最重要的问题。在与我们的程序和 SRE 沟通的过程中，我们发现它们在面临故障时主要有以下几个痛点：

　　众所周知，业务指标是应对故障最直观的手段，而日志则是记录应用运行状态的重要工具。我们希望在保留细节的同时，通过聚类的方式总结以上泛化的告警信息，这样告警发出后，可以通过故障传播链关联指标、日志、跟踪、变更事件等信息，找到最多的有故障的可能原因。

　　业务指标是整个故障定位的触发源。我们选取了游戏 SLO 中的重要指标，并按照分组的维度进行分类。由于SLO业务指标的毛刺较多，直接使用普通毛刺无监督模型会产生较多的误报。只有当异常在一段时间内持续上升或下降时，才能认为是异常。因此，SLO 异常检测模型使用隆起异常检测。

　　提升异常检测主要由两种模型组成，一种是mean-shift模型，另一种是predictive-average-shift模型。最终结果将融合两个模型的输入和输出。

　　1) 均值漂移模型

　　2) 均值预测偏移模型

　　服务指标异常后，启动故障定位，启动机器指标异常检测和排序。异常最可能的根本原因是通过对异常分数进行排序来获得的。

　　在对机器指标异常根因进行排序的同时，我们还对相关saas的机器指标和告警信息进行扫描，最后结合日志异常检测和分类，将根因结果展示给用户。

　　问答

　　Q1：智能运维前期规划有哪些好的方向和规划建议？

　　A1：首先，智能运维不是一朝一夕的过程。它作为一个长期演进的系统而存在，其基础是运维自动化、数据采集、分析、监控等基础运维工具。前期规划需要解决的问题包括海量数据的存储、分析和处理，数据仓库的建设，基础监控的实践经验。好的数据往往比模型更有价值。完成以上基础设施建设后，可以与具体业务人员了解最关心的SLO，并通过这方面进行异常检测建设。在模型选择方面，虽然有监督标注的成本会很高，

　　Q2：AIOps的基础一定是大量的历史监控数据。您如何设计数据采集规则和建模规则？

　　A2：目前我们已经基本完全采用prometheus的接入方式，并在此基础上搭建了数据采集中心。它的主要采集规则是基于采集器和适配器模式。用户通过采集器上传数据，适配器将数据重组后直接发送到相应的消息队列中进行存储。数据模型统一采用json标识，数据格式采用prometheus的数据格式。

　　Q3：能否介绍一下采集的日志规则？目前日志检测的思路是什么？

　　A3：用户通过我们的自定义客户端定义相关的日志指标，采集自己的数据。sdk 启动一个单独的进程，定期读取内存中的数据，将其组装成日志格式，并由我们的日志团队采集数据。具体数据格式如上一题。对于容器日志采集方式，一般采用以下几种方式：

　　我们目前的日常异常检测算法主要依赖于日志智能分类算法。获取日志实时分类模板后，我们需要根据每个模板的日志量历史数据，使用3sigma和boxplot判断异常，从而找到异常模式，分析异常。相应的异常通过警报发送给用户。

　　Q4：告警融合有哪些思路，哪些比较好？

　　A4：告警收敛主要有以下几种方法：

　　以上两种是策略类型，可以收敛一些告警，但无法获取告警之间的相关性。

　　Q5：如何选择基于互联网电子商务应用监控的动态阈值算法？

　　A5：主要可以分为有监督选择和无监督选择：

　　关注【dbaplus社区】微信公众号，搜索同名文章，即可观看直播~

　　云原生运维主题干货

　　关注【dbaplus社区】微信公众号，后台回复【220426】，即可免费获得精选“云原生运维主题”的三场免费直播及配套PPT~

　　收录网易游戏、去哪儿、