导读：企业数字化，智能运维转型成为必然。宜信积极推动AIOps在科技和金融企业的落地。本文探索AIOps的一种实现形式：通过行为采集、模拟、主动感知等，从用户侧真实的系统体验出发，结合全维度的监控数据，更有效地实现智能异常检测和根因检测分析。1.运维的发展1.1运维的价值早期的运维工作比较简单。一般是系统集成工程师和研发工程师先开发项目并交付，然后负责运维工作的人员会在后台做一些操作。保证系统的正常运行。随着软件研发行业和技术的发展，运维的工作也越来越丰富。这一阶段运维的工作和价值主要集中在三个方面：1）效率大量业务上线，运维人员需要保证快速高效地为系统提供资源，应对业务变化，响应操作请求。2）质量运维的目标是保证质量和系统的稳定性。即要保证业务和系统7*24小时在线稳定运行，为用户提供流畅舒适的体验。为实现这一目标，运维的相关工作包括：故障预测：在问题出现之前预测故障发生的可能性。异常检测：当出现问题时，快速检测并定位异常点。根本原因分析：分析问题的原因，找出问题的真正根源。动态扩展：问题处理过程中可能会受到复杂因素的影响，需要对系统进行动态扩展。服务降级：不影响核心服务的边缘服务可能需要服务降级。3）成本随着公司规模的不断扩大，投入产出比也越来越受到重视。运维的另一个价值是降低成本。主要体现在：容量规划：规划每年在IT运维方面投入多少人员和资源。灵活调度：如何调度和分配资源，以达到资源的充分利用。利用率分析：利用率分析包括动态和静态两个方面。趋势分析：比如今年在IT运维上花多少钱，明年在这方面花多少钱。这是一个趋势分析。成本分析：成本分析包括今年有多少家企业，每家企业花了多少钱，IT技术设施有多少，有多少人。1.2运维困境如图，横坐标代表服务规模。公司业务不断增长，服务规模也相应增加。这里我们简单的理解为这是一个线性的变化，不管业务的突然增加。但是，业务规模的增加至少从三个层面反映了运维复杂度的增加：服务规模的增加直接导致服务器和网络数量的增加，其次是网络拓扑结构的增加。随着业务的增长，服务的技术堆栈也在增长。以前可以在前面跑一个服务，在后面跑一个数据库。现在随着服务规模的不断增长，不同服务形态的引入，可能会有队列、缓存等，技术栈也在相应增加。服务拓扑不断增长。以前可能一个烟囱服务就够了，但是现在随着微服务的应用，服务之间的调度很多，需要增加服务拓扑来满足需求。随着服务规模的增长，运维的复杂度呈指数级增长。运维人员的数量是否也增加了？纵观各个部门，答案是否定的。为了节约成本，每个部门和岗位的人员数量不会随着业务复杂度的增加而扩大，而是会越来越稳定。按照这个比例，相当于运维复杂度越来越高的时候，运维人员越来越少。中间的空隙怎么弥补？这就需要使用运维的方法。即如上图所示：运维质量=运维人员X运维手段。运维人员必须通过各种运维方式来解决运维困境，进而推动运维事业的发展。1.3运维的发展如图所示，运维的发展大致分为四个阶段：1）人工阶段人工阶段比较容易理解。研发人员交付系统，运维人员人工操作，保证系统正常运行。现阶段没有运维标准。2）在标准化阶段，随着越来越多的企业IT系统引入运维，所有业务都以系统的形式在线运行，运维的重要性越来越重要，但同时时间带来了研发和业务人员工作中的沟通障碍。这时候衍生出了一些标准，其中最重要的就是ITSM（ITServiceManagement，信息技术服务管理）。ITSM的目标是通过系统建设和标准化，固定所有日常运维工作，包括流程、信息管理、风险控制等。就像流水线一样，人员只需要按照标准参与即可。3）在自动化阶段，随着互联网的爆发，服务交付模式越来越多，用户对互联网和IT的要求越来越高。ITSM的缺点也越来越明显，主要表现在时??间长、成本高。无法适应快速变化的需求。于是从工程或者运维的角度，一种文化油然而生：DevOps，DevOps强调运维、研发和QA工程师的高度融合，需要从工程交付的角度不断迭代运维。同时，从企业IT管理或运营的需求出发，也需要解决快速演进的问题，因此ITOM标准也随之演进。ITOM与ITSM非常相似，不同的是将“S”改成了“O”，即Operation本身和它带来的各种自动化工具都被纳入到模型中，包括host、operation、releasesystem等。DevOps继续演变为当前的ChatOps。ChatOps的目标是整合研发、运维、QA，以聊天的形式进行交流。ChatOps的整体解决方案并不能很好地解决DevOps的困境。ITOM将所有操作在线化和自动化后，发现IT运维产生的大量数据非常有意义，特别是对于企业数字化。这些数据经过处理和分析后，可以为日常业务产生价值。于是Gartner提出了新标准“ITOA”。ITOA强调IT数据的价值，对IT运维分析提出诉求，但没有说明这些数据能做什么。不久，Gartner将ITOA演变成“AIOps”。此时AIOps中的“AI”指的是“Algorithm（算法）”，强调的是数据分析本身所产生的价值，包括用算法来解决在线故障发现、日常交互等运维问题。4）在智能化阶段，随着行业对IT运维的要求不断提高，AIOps和ChatOps都面临着一个严峻的问题：人类无法应对。从工程的角度来看，运维的现状是异构性很强，需要引入第三方应用和各种设备。交付方式也越来越多，运维复杂度成倍增长。为了解决上述问题，Gartner适时提出了“AIOps”的概念，其中“AI”代表人工智能。通过机器人的参与，将人工智能技术体系引入到运维的各个环节，帮助解决运维问题。运维的发展由此进入智能化阶段。2.什么是智能运维2.1什么是智能运维（AIOps）？BMC给出的AIOps定义是：AIOps是指通过1)使用分析和机器学习来分析从各种IT运营工具和设备收集的大数据，从而2)自动地自动化和增强IT运营的多层技术平台实时发现问题并做出反应。简单来说，就是引入多层平台，利用大数据分析、机器学习等手段，加强IT运维自动化能力。上图下方的三张小图分别代表了AIOps架构在2016年、2017年和2018年的演进，都是围绕机器学习和大数据构建的。2.2技术、场景和算法AIOps涉及的技术、场景和算法如图所示。1）技术层面大数据分析：主要关注分析部分，包括基于海量数据的分析。机器学习：数据量太大，简单的人工分析远远不够。它需要自己产生智能，这就是机器学习的价值所在。知识图谱：日常运维会产生各种经验数据，这些数据如何反过来为运维工作产生真正的价值，这就涉及到知识图谱。自然语言处理：自然语言处理是ChatOps可以引入AIOps领域的原因。我们希望找到一个相对简单易接受的界面，比如聊天平台Chat，它需要使用自然语言处理来理解人类的语言并向人们反馈，并理解相关的动作。2）涉及场景单指标异常检测：比如我们想知道实时数据的某个指标是否异常，我们可以检测出来，有异常就反馈。多维指标异常检测：之前指标与指标之间存在关联，通过聚类等一些操作可以检测到更多的异常。趋势预测：主要体现在成本部分，可以通过人工智能预测未来的增长和变化，更好地指导决策。日志异常检测：检测日志是否异常。根源分析：当故障发生时，可以从时间维度和空间维度找到故障原因。智能问答：以前每一次变更操作都需要向运维提出请求，现在这些功能都接管成了一个智能平台，日常的运维工作可以通过智能直接完成平台或机器人。智能执行：这是我们期望的方式。通过聊天窗口，我们可以实时感知线上业务的变化，需求提交到平台后，平台会自动执行。3）算法级规则统计机器学习变分自动编码器、GBRT、EMA、极限理论皮尔逊相关系数、DBScan算法FP-TreePathRanking2.3AIOps平台架构上图展示了一个典型的AIOps平台架构。底层是所有数据的来源。我们收集大量数据，通过实时分析，交付给算法平台。算法平台由三部分组成。首先是基于规则和模式的简单分类，然后通过领域算法，最后通过机器学习和人工智能来影响操作并使自动化运行。如果你了解AI，你会发现这其实就是一个AI代理，包括从Sensing到Thinking再到Acting，也就是从感知到思考再到执行的过程。3.易信智能运维实践3.1易信IT运维架构易信正在实施“中台战略”，将可复用的技术集中到技术中台、数据/智能中台、运维中台，提供统一的服务，节省人力物力，提高需求响应速度。宜信的IT运营架构分为四个部分：中心是技术中台，真正承载业务的是技术中台。技术中台沿用云平台的概念，从底层物理环境出发，包括IaaS、PaaS、SaaS。这里的SaaS其实是一个中台的概念，将通用的系统软件沉淀在中台上，统一为业务系统提供服务。数据/智能中台为其他业务和平台提供统一、可复用的数据和智能服务。运维中心积极响应研发和业务发起请求，维护在线业务系统。在运维方面，将传统的运维方式与互联网的快速迭代进行交互，在监控、信息化、自动化等垂直领域建立套间。运维如何使用数据/智能中台数据和应用？我们构建了一个通用的管道，将运维产生的有价值的数据传输到数据/智能中台。数据/智能中台根据运维需要的场景，对这些数据进行分析，反馈智能应用。3.2运维管理上图为运维管理架构。从左到右是从运维到运维，或者从运维到DevOps。左边更倾向于ITSM的概念，右边更倾向于DevOps的概念。从上到下就是从入门到执行。你可能更熟悉DevOps。以这部分为例介绍上图所示的架构。我们的构建方式是从自助入口，连接到持续集成和持续发布平台。持续集成和持续发布平台将全部采用自动化构建，包括主机、域名、数据库、负载均衡等组件，实现自动化。最后我们会收集线上的系统数据，包括指标、轨迹、日志等，这是监控部分。上述DevOps部分的运维管理架构非常适合交付2C产品，但是像易信这样大量面向内部人员的系统，要求能够快速响应用户问题和快速积累更多有价值的操作。维护请求和数据，单一的运维管理架构不足以满足上述需求。所以，我们也会搭建ITSM部分，即偏运营、偏管理、偏审计的部分。ITSM部分以服务台为入口，涉及的内部管理包括请求管理、事件管理、问题管理、变更管理、需求管理、编排管理等，涉及的信息管理包括资产管理、CMDB。让我们通过一个例子来看看ITSM的价值。系统出现故障：业务人员在提交用户手机号时报错，提示系统出现故障，请联系开发者。如果是在DevOps领域，处理这个问题就很简单了。将故障报告给研发，研发会解决。但是这样一来，下次可能还会出现同样的问题。如果将故障放到ITSM部分进行分析，则可以从根本上解决问题。发现故障后，通过请求管理告知后台人员。后台人员看到请求后，将故障升级为“事件”提交给研发人员。研发人员分析，故障原因是手机号触发了风控平台，而风控平台刚刚上线，状态码的解释不够充分。研发人员关闭平台，完成排查，将“事件”升级为“问题”。研发和产品人员分析问题后，认为需要更改相关服务，提供更详细的状态码和更清晰的错误提示，将“问题”作为“需求”提交。终于完成了“需求”，解决了“问题”，类似的情况就不会再发生了。3.3收集和处理如上所述，运维中心和数据/智能中心之间有一个共同的管道。运维中心负责收集所有的数据，进行简单的处理，传输到数据/智能中心，由智能中心分析处理数据，并将数据和智能应用反馈给运维中心。上图展示了数据采集和处理的架构。采集的数据形式包括动态和静态：动态数据包括服务、应用、链接、技术设施、全网、日志数据等；静态数据包括配置、拓扑、工单数据等，我们通过自己的系统收集所有的数据，通过统一的管道传输到实时分析平台（统一管道包括kafka、易信开源DBus、DBus将配置或预处理结构化数据），并对数据进行后处理。处理，包括相关操作，最终数据会分类存储在数据中心的数据库中，比如关系、索引、文档/日志数据会存储在ElasticSearch中，结构化数据会存储在Hive中，以及其他历史数据将存储在HDFS中。3.4智能场景运维中的智能??场景如上图所示。智能中台基于运维中心提供的工单、布局规则、CMDB、画像、Tracing、KPI、Logs等数据，通过算法为运维中心构建一系列模型和应用。注重排列规律。我们使用的编排工具是StackStrom。我们把每一个自动化动作抽象成一个原子，比如重启服务、重启机器、修改配置。这些原子通过StackStrom构建到单独的工作流中。这些工作流是由我们经验丰富的运维专家构建的更高层次的抽象和更语义化的模型。比如我要发布一个系统，包括机器扩容，无缝切换，涉及前端负载均衡的调整，后端应用的调整。这些都是编排规则。智能平台通过NLP分析、根因分析、趋势预测、异常检测等算法生成知识图谱和搜索引擎两种模型。这两个模型应用于运维中心的问答后台、编排管理和监控系统。1）智能问答/执行如图所示，是智能问答/执行的案例。用户通过服务台的对话窗口提出问题，这些问题以请求的形式发送到问答后台，后台利用搜索引擎和知识图谱的数据进行自动反馈。信息，包括问答、动作执行等。2）故障检测目前AIOps中研究最多的是KPI。利用日志等各种数据，通过根因分析、趋势预测、异常检测等算法生成相应的算法/模型，并将这些算法/模型应用到监控系统中，是监控报警部分。监控和报警结果将显示在显示板上，通知用户。4、如何实现主动感知4.1痛点我们的业务运行在IT环境中，IT环境就是承载业务的IT，包括数据中心、服务器、各种系统、第三方应用、网络用户设备等。随着云平台的建设和微服务的发展，很多运维人员无法观察。另外，出于投入产出比的考虑，有些部分我们就不去观察了。因此，实际上运维人员能够观察到的IT远小于实际承载业务的IT。在可观测运维的IT环境中，实际观测到的IT数据往往只包含交换机流量包、进程运行状态、网卡流量、CPU占用率、请求数等数据。如果要构建AIOps，数据的完整性非常重要。观察的IT环境越多，得到的数据就越完整，越有利于AIOps的构建。这时候就需要用到主动感知。4.2主动感知定义维基百科对主动感知的定义如下：主动感知是指选择代理的行为以增加从相关环境中的这些行为获得的传感器数据流中派生的信息内容。——维基百科通俗地说，主动感知其实就是给每个参与者一个身份。这个参与者会主动获取环境中的数据，同时会根据从环境中获取的数据，主动进行进一步的发现和获取新的数据。数据的信息量和信息价值。上图展示了一个典型的主动感知过程，重点关注感知部分。感知机通过态势感知、态势理解和预见，从环境中感知环境，产生决策，决策产生行动，行动再反馈给感知。4.3主动感知领域主动感知在人工智能领域并不是一个陌生的名词。它已经在大量的应用中得到应用，包括：机器人，机器人如何观察环境，如何查看边缘信息，如何识别物体。对于自动驾驶来说，如果把现实中获取的图像数据全部交给一个中心处理，信息量和计算量都会非常大，目前的芯片无法满足这样的处理量。我们的做法是在检测环境数据的时候感知变化，获取变化数据。智能手机主要体现在手机的GPS和摄像头，可以感知环境变化。直接影响人。路网监测和路网识别，包括主动感知车辆速度变化，判断车辆是否超速。4.4分布式主动感知AIOps引入分布式主动感知：通过为真实IT环境中的参与者建立模型，有目的地获取相关IT数据，并根据获取的数据不断优化获取的数据和方法，从而实现真正的ITReal-时间完成监控。传统的监控方式是被动的。被动采集不可能采集到所有数据，数据的真实性和完整性无法保证。如果能够对所有的IT参与者进行建模，并通过模型感知真实参与者的身份和他们拥有的数据，就可以采集到更实时、更完整的数据。1）主动感知建模主动感知建模包括局部建模和全局建模。本地建模只需要关注IT参与者是什么，例如工作场所和主机；全球建模需要考虑国内有多少工作场所，分布在哪里，如何联系起来。2）主动感知的动作主动感知的动作包括主动筛选的被动感知和主动行为的主动感知两个方面。被动感知配合主动筛选，比如网卡流量数据是实时监控的，但我不会收集所有的数据，只有当数据急剧增加或者出现异常时，这才是主动筛选。积极的感知和积极的行为。实际获取环境数据时，只是粗略的获取了内网部分机器的端口。如果发现哪个端口有危险，它就会对这些端口进行详细的检测，包括发送一些协议请求来模拟这些行为，这就是主动感知主动行为。3）主动感知的方法主动感知的方法有两种：基于规则的和基于智能算法的（如贝叶斯决策树）。目前使用最多的是基于规则的方法。4)主动感知数据类型主动感知数据类型包括画像数据、参与者之间的关联、主动行为的主动筛选和详细捕捉、位置跟踪等。5)主动感知系统主动感知系统包括全网Agent、业务Agent、网络代理和应用程序代理，它们都是我们的传感器。4.5全网感知模型用一个例子细化什么是分布式主动感知。全网感知背景：宜信在全国有多个职场，这些职场都是重要的参与者。使用业务系统的每个工作场所都有很多业务人员，需要对这些工作场所进行监控。利用分布式主动感知的方法，我们首先建立一个模型，即工作场所网络。在工作场所放一个Agent，因为工作场所分布在全国各地，而且是全网的，所以叫全网Agent。感知内容包括什么是出口；网络、身份识别；网络有多大；检查内网是否存在安全隐患。4.6全网感知应用全网agent获取本地工作场所信息，包括出口、网段、地理位置、运营商信息，反馈给拓扑图和地图。同时，ITSM将管理所有组织和工作场所信息。这些工作场所身份信息和主动感知Agent反馈的信息结合起来，绘制出准确详细的拓扑/地图。全网Agent从网络中获取并反馈所有工作场所设备及其分布。全网Agent会嗅探风险端口，扫描攻击，反馈特定风险的扫描数据。全网代理将网络统计数据反馈给系统，帮助完善拓扑和监控。我们可以通过网格数据加工作场所身份给不同的Agent添加不同的监控模拟配置，由Agent发起模拟监控数据。当发现异常时，可以从全网获取更详细的拓扑网络监控和密集的系统检测数据。上图是我们全网感知的一些例子，包括职场信息、组织信息、模拟监控数据、动态监控配置，这里不再赘述。4.7网络感知模型上图为网络感知模型。我们首先对模型进行建模。建模的点是网络的参与者，即每个交换机，实时监控和扫描网络中的所有服务器。通过该模型可以直观、实时的看到异常的详细数据，保障网络质量。上图显示了网络感知的示例。4.8主机/应用/服务感知除了上述应用之外，还有主机/应用/服务感知等。主机意识。当异常发生时，它会感知异常发生时的反馈过程、IO和网络转储细节。应用感知，根据运行状态动态调整采集密度和方式。应用程序感知，包括主动业务异常捕获和报告。4.9好处分布式主动感知的好处包括：更丰富的画像和拓扑更有价值的监控数据知识图谱根源分析异常检测4.10问题与展望1）问题主动感知在人工智能领域的应用已经有很多成功案例，但它在AIOps领域仍然是一个新生事物，还存在很多问题：缺乏理论支持缺乏智能感知算法主动感知数据挑战学习算法实施成本高2）展望运维数据带来的爆炸式增长AIOT越来越商业化，算法的应用降低了落地门槛。SD(X)系列物联网的普及，为未来带来边缘智能。5.社区易信是一家比较早实施AIOps实践的公司。我们正在为AIOps赋能，同时也专注于对社区的反馈。本文介绍的主动感知技术也计划开源，与大家共同探讨，共同进步。【本文为栏目机构易新科技原创文章，微信公众号“易新科技（id：CE_TECH）”点击此处查看作者更多好文
