前言：在上一篇《无数据，不工作！运维“数据思维”有多重要？》中，我们站在运维的视角来对数据的作用做了一些解读，其中包括数据的重要性、运维的数据观和数据思维的理解。在本篇中，对运维数据的一些高阶使用场景进行介绍，运维数据使用的发展态势和落地价值，本章节重点从产品开发角度，探讨运维数据场景的高阶落地途径和方法。

一、 运维的数据覆盖面和难点

对于狭义的运维来说，数据的覆盖面相对较为单一，以系统稳定和资源管理为主，大致可以分为三类，资源元数据、系统状态数据、事件类数据。其中资源元数据主要覆盖基础架构、标准化支撑组件、虚拟资源数据，以及相关的属性、组成以及关联关系。系统状态数据以各类监控输出为主，如使用率、存活状态、支撑能力以及系统级、组件级、请求级的链路交互和拓扑关系。事件类数据一般是描述对系统和设备的变更、业务系统的异常、流程节点的阻断和策略数据。

对于广义的运维来说，数据的覆盖面取决于公司展业的业务复杂性和组织架构职能的交叉延伸，在狭义的运维数据覆盖面之上，还包括了较为广泛的业务数据、运营数据、工程效率数据、用户体验数据。相对应的也衍生出复杂的数据使用场景、数据处理规则、数据关联关系和更为复杂的运维数据输出能力。

对于运维数据场景输出来说，有几个前置阶段，分别为场景适配、运维数据中台、运维工程体系和运维数据策略，本章节主要以场景适配阐述。在这几个阶段中，都有一些共性的数据难点，如不确定的数据来源，多类型的数据结构，基于场景的数据关联变化。下面举一些典型的例子。

二、 运维数据的高阶场景

在运维数据输出场景中，大都遵循数据的时效和获取方式。在数据处理时效规则方面一般有三种，离线数据处理规则、近线数据处理规则和实时数据处理规则，相对于的数据获取也有不同的方式，一般有，周期性的拉取数据、周期性的主动推送数据、实时获取数据。在数据运用和场景适配阶段，离线适用于指标统计类，近线适用于智能监控的故障诊断和预测，实时适用于自愈场景、无人值守场景、自动调度场景。本章节中的高阶场景以告警自动阈值、知识图谱、故障自动评估、无人值守变更和数据血缘流向为例，分别阐述相应的场景落地和具体方法。

1、 知识图谱

知识图谱的大面积运用是从谷歌的搜索服务开始的，从此知识图谱的数据输出能力得到了更大范围的拓展，最常见的是各类知识库。在运维领域，很多高阶的运维数据运用，尤其是基于海量数据的颗粒度关联以及数据的聚合场景下的应用，通俗点说，基于运维的知识图谱是基于业务连续性框架下的运维知识工程。

很多人有疑问，运维的知识图谱和CMDB好像是一回事，其实这个说法并没有错，知识图谱是采用数据聚合和运维策略的CMDB进阶方式。通常我们会遇到一个场景，在云环境下，某台宿主机重启，知识图谱会告诉我们这台宿主机上运行哪些虚拟机，部署了什么系统，承接了什么业务，这些系统的服务状态又会影响哪些下游系统，下游系统又会影响什么业务场景，业务链路会造成什么影响，对正常展业带来了什么风险，这是知识图谱的的一种能力输出方式。

在知识图谱的落地过程中，我们需要打通基础架构、系统架构、业务架构的数据层次和数据颗粒度的关系，这种数据量是非常庞大的，如CMDB、配置中心和接口系统，甚至还需要对接业务需求系统，比较理想的情况下获取完整的结构化数据。同时通过运维策略和业务规则进行数据层次关系落地，对运维数据不断的筛选和知识验证，最终达到正确的运维知识结构，下面我们举一个某个业务的知识图谱例子。

在以上关系图中，我们可以发现一些不合理的地方，如系统C部署在同一台物理机上，redis集群的主节点1和从节点1部署在同一台物理机上，C系统的d接口是一个公共接口，集群规模不够大。通过知识图谱的一些图形化能力，可以查到丰富的结果，展现给各能力子域较为全面的知识，还可以进阶为更高级的语义匹配能力。知识图谱在运维领域主要构建了常见的容量场景、业务链路场景、故障场景，通过一定策略判断对数据输出实现辅助决策功能。

对于AiOps而言，知识图谱实现了一定的数据思考和数据推理，和监控系统的打通能够实现事前事中的风险判断和风险溯源。

2、 故障自动评估

故障自动评估有较多的应用场景，主要有应急演练时快速避免盲测带来的风险，故障发生时快速判断对业务的影响面，故障自动评估也是基于运维知识图谱的衍生能力之一。

同样以上述图标为例，再做一些延伸，当我们对以上宿主机1-6进行数量穷举，宕机一台的有6种方式，宕机二台的有15种方式，宕机三台的概率较小不做分析，此处还可以形成数据中心和机柜的信息进行数据聚合。针对宕机一台进行分析得到，宿主机3和宿主机4宕机对业务链路产生中断影响。

在故障自动评估中，有一点需要特别关注，那就是数据的模糊边界。数据的边界大致分为三类，面向基础架构的数据边界、面向应用系统的数据边界、面向业务保障的数据边界，在这个过程中需要将这些数据边界完全打破，形成多层次的颗粒展现。

在落地过程中还有一点值得关注的，统一偏业务侧的运维语言和业务连续性评估方法，这是偏向顶层的设计，将业务逻辑、数据流和基础架构集成数据进行分析评估，并实现多个数据模型的输出汇聚，在业务服务的影响下进行数据映射。

除此之外，还有最重要的场景识别，这也是CMDB是否成为运维知识图谱唯一的发展之路，如果不考虑交付的嵌入，基于流程的场景识别和基于业务服务化的场景识别是运维数据的高阶使用中必不可少的一个抓手。

3、 无人值守变更

变更在运维领域是核心的输出能力，项目上线和产品投产在交付环节，变更是最后一个步骤，因此变更的成功至关重要，在运维领域而言，无人值守变更并不是没有人的变更，是无需人员过度参与的变更。

上线变更过程中大致有几种类型，分别为变更前评估变更步骤和上线策略，其中包括代码变更、数据库变更、网络策略变更、流量切换、业务开关和策略。变更中执行变更策略和上线策略，确保变更有序正确，变更后执行系统和业务检查。

在很多企业，变更过程是这样的，运维人员关注监控、发布单、机器、业务故障预警，监控能够反映出来当前系统的一些状况，例如机器的负载是否上去了，接口的成功率是否下降了，发布单则能让我们了解当前的发布情况，有多少机器已经更新到新版本了，有多少还在跑旧版本，有多少机器启动又遇到异常了等等，盯着机器则可以看一些日志信息，是否有一些新的异常出现了，异常的量是否很大。这种变更方式被很多的企业所接受，但是人毕竟是局限的，如果运维人员责任心不强，或者流量过大数据刷新过快，又或者对业务指标相对不是很熟悉，很容易造成变更过程中的故障被疏忽，因此我们需要无人值守变更。

一般情况下，无人值守需要具备一些必备的条件，①具备业务线的发布的先后顺序，系统之间发布的阻断条件，如A系统发布成功后执行B系统发布，B系统成功发布后可以同时对C、D、E系统进行发布。②业务开关策略需要纳入到自动变更体系，如A系统发布后执行关闭某个挂起任务。③必须提供完善的验证条件，如最新包验证、异常启动日志验证、无日志验证、异常业务日志验证。④触发阻断后自动回退。⑤基于业务指标的监控回检，如用户流量、业务成功率、异常指标的同环比。

无人值守变更是运维数据高阶运用的典型，通过对接发布策略、基础架构、全链路监控和数据分析系统，对发布过程中的流量数据进行采集分析和比对，进行结果的判断，事后针对历史变更故障异常集的回放属于更高阶的功能。

检验无人值守变更的最佳方式还是事后验证，通过业务监控的召回率和准确率指标来回溯，优先保证准确率，其次是召回率。

4、动态阈值

动态阈值在AiOps中是个热门的话题，最佳实践案例也比较多，在此，笔者简单介绍下动态阈值的一些基本方法和场景。

需要动态阈值的一般在高流量且突增突降的电商生态场景，如数据源输出、支付、线上抢购，此类生态系统的运维方式和普通的运维方式相比存在不同。如监控指标繁多，动辄上万监控指标，且配置复杂，一旦用户流量呈几何级的爆发，准确率和召回率断崖式的下降，连带了剧烈的报警风暴，噪音也呈几何级的上升。因此调整监控阈值并不是一个好办法，只能通过数据挖掘或机器学习来达到阈值自动调整。

一般的数据偏差有三类场景会进行关注，①数据的环比同比出现明显问题；②周期内的数据出现持续偏离的问题；③数据指标在时间周期内发生较为明显的漂移。

在实际的业务场景中，结合数据偏差情况所对应的三种阈值类型，①周期性波动的数据，如非活动期间的接口平均耗时和活动期间的接口平均耗时，工作日流量和非工作日流量，此类数据一般是按天来计算；②某些时间的突变数据，如接口的峰值耗时和数量，此类数据更多体现在局部数据的影响放大，针对此类数据的处理要格外审慎，需要考虑场外因素，如发布、第三方外部系统导致的短暂异常。③毛刺数据，毛刺数据是寻常监控难以发现的，对于全局数据来说，毛刺对均值和阈值基线不会存在影响，但对于抢购场景的洪峰阈值存在较大的不确定性，因此在阈值方面要做一些滤波操作。

在报警风暴方面，除了对报警信息按照系统级进行收敛，还需要有依赖策略。根据知识图谱的数据关联，进行基础架构和业务系统的关键字数据匹配，对告警信息进行依赖匹配。举个简单的例子，如某台宿主机宕机，宿主机承载的虚拟机出现请求失败，在秒级和分钟级的数据呈现势必引起较高的峰值耗时和熔断数量，对于业务指标的影响不会放大，因此需要对服务器宕机短信和接口耗时短信进行策略依赖和异常依赖，避免报警风暴和额外的人力投入，这也是通过传统的数据挖掘来达到数据特征的关联分析。

故障处理包括四个阶段，故障发现、故障处理、故障恢复和故障总结，而动态阈值是故障发现的重要一环。

三、 后记

运维领域的数据使用从最开始的运维保障到现在数据能力输出，一方面来说提升运维能力的宽度和广度，实现了自动化到智能化来进行运维效能提升和运维成本降低。另一方面，对数据进行技术变现，来完善科技对业务的支撑能力，让运维从幕后走到前台。