底层是所有数据的来源，我们把大量数据收集起来，通过实时分析交付到算法平台。算法平台包括三部分，首先是基于规则和模式进行简单的分类，然后通过域算法，最后通过机器学习和AI的方式影响Operation，让自动化运行起来。
如果大家了解AI，就会发现这其实就是一个AI智能体，包括从Sensing到Thinking到Acting，即感知到思考到执行的过程。
三、宜信智能运维实践 3.1 宜信IT运营架构宜信正在落地“中台化战略”，将可复用的技术集中到技术中台、数据/智能中台、运维中台，统一提供服务，节约了人力和资源，提高需求响应速度。
宜信的IT运营架构分为四部分：
居于中心的是技术中台，真正承载业务。技术中台沿用了云平台的概念，从底层的物理环境开始，包括IaaS、PaaS、SaaS，这里的SaaS实际上是一种中台的概念，将通用性的系统软件沉淀到中台上，统一为业务系统提供服务。
数据/智能中台，为其他业务和平台提供统一的可复用的数据和智能服务。
运维中台，积极响应研发、业务发起的请求，维护线上业务系统。运维方面采用传统运营的方式和互联网快速迭代共同交互的方式，在监控、信息、自动化等垂直领域建立所有套件。
运维如何使用数据/智能中台的数据和应用呢？我们建立一个通用的管道，把运维产生的有价值的数据传输到数据/智能中台，数据/智能中台通过对这些数据进行分析，并基于运维需要的场景反馈智能应用。
3.2 运维管理
上图所示是运维管理架构。
从左到右是从运营到运维，也可以说是从运营到DevOps，左边更偏向于ITSM的概念，右边更偏向于DevOps的概念。从上到下是从入口到执行。 大家可能更熟悉DevOps，以这部分为例介绍上图所示架构。
我们的建设方式是从自服务入口，它被对接到持续集成和持续发布平台，持续集成和持续发布平台会利用所有的自动化建设，包括主机、域名、数据库、负载均衡及其他组件，实现自动化，最终我们会把线上的系统数据收集起来，包括指标、跟踪、日志等，这就是监控的部分。
上述DevOps部分的运维管理架构对于交付2C产品是非常适合的，但对于像宜信这样，有大量系统是面向内部人员的，要求能够快速响应用户的问题，并且能快速沉淀更有价值的运维请求和数据，单一的运维管理架构不足以满足上述要求。
因此我们也会建设ITSM部分，即偏运营、偏管理、偏审核的部分。ITSM部分以服务台为入口，涉及的内部管理包括请求管理、事件管理、问题管理、变更管理、需求管理和编排管理等，涉及的信息管理包括资产管理和CMDB。 下面我们通过一个实例来看ITSM的价值点。
系统出现一个故障：业务人员在提交一个用户的手机号时报错，提示系统出现故障请联系开发人员。如果是在DevOps领域处理这个问题就很简单，把故障报给研发，研发就给解决了。但这样处理，下次可能还会出现同样的问题。
如果将故障放到ITSM部分进行分析，就能让问题得到更根本的解决。发现故障后，通过请求管理把这件事告诉后台人员，后台人员看到请求后将故障升级为“事件”并提交给研发人员，研发人员分析得知引发故障的原因是手机号触发了风险控制平台，而风险控制平台由于刚刚上线所以状态码的解释并不充分，研发人员将平台关闭，故障处理完成，同时将该“事件”升级成“问题”。研发和产品人员对该问题分析后认为需要变更相关服务，提供更细的状态码和更清晰的错误提示，于是将“问题”提交成“需求”。最终“需求”完成，“问题”解决，之后类似的情况也不会再发生。
3.3 采集和处理前文提到运维中台和数据/智能中台之间有一个通用管道，运维中台负责采集所有数据，进行简单加工，并传输给数据/智能中台，智能中台分析处理数据并反馈数据及智能应用给运维中台。
上图所示为数据采集和处理的架构。
采集的数据形式包括动态和静态两种：动态数据包括业务、应用、链路、技术设施、全网、日志数据等；静态数据包括配置、拓扑、工单数据等。