AIOps探索 | 应急处置中排障的降本增效方法探索

大嘴吧Lucy

于 2024-01-17 10:54:38 发布

阅读量1.0k

点赞数 24

文章标签：智能运维大模型应急处置

本文链接：https://blog.csdn.net/dazuibar/article/details/135643220

版权

原作者：擎创科技资深产品专家布博士

前言

在事件管理及应急场景的场景下，一般会造成业务服务和技术服务故障（如应用系统、微服务架构等不同的技术组件）。为了实现对业务的影响分析、查看技术组件的相互依赖关系以及进行根因排查分析，通常需要构建调用链路系统和cmdb等来可视化业务层的交易链路和应用系统各技术组件之间的拓扑关系。然而，根据我近5年接触的项目经验，这两套系统的构建存在以下缺陷：

调用链路系统：需要对不同厂商和不同技术栈（如cs架构、bs架构等）的系统进行不同程度的改动，成本较高且项目周期较长。在出现告警后，相应的运维工具系统之间需要进行大量的集成工作，短期内很难看到效果。
cmdb系统：尤其是最近几年，一些AIOPS厂商过度炒作了cmdb的重要性，似乎没有cmdb就无法进行基于拓扑的排障分析。然而，在现实案例中，我们发现为了维护一套高标准的cmdb系统，企业需要进行至少一年甚至几年的治理过程，包括解决数据质量问题、提高数据更新效率、降低维护成本以及解决数据缺失等问题。维护成本高昂且由于cmdb需要应对多种应用场景，不可能面面俱到，导致在实施过程中最终产出的结果更像是一个“四不像”。

在事件管理及应急场景下有没有一种低成本且高效的方法可以快速地构建排障拓扑、实现业务层和技术组件层的链动分析，加速排障过程？答案是有的，本文将详细介绍一下*服务所有权模型*，主要包括如下内容：

服务所有权模型是什么？
模型构建完成的样子及能力介绍
如何逐步落地模型？
推荐的模型存储及计算方案
总结

服务所有权模型是什么？

我服务过许多国内大型的金融机构，他们在出现事件或应急的场景下试图研发各种工具以搞清楚当前正在发生什么事件、事件的告警对象依赖什么、谁在对告警对象提供服务、哪些业务受到影响？

想象一下在故障的场景下，您可以清楚地看到您所要解决的事件对业务、对依赖的技术组件和客户的影响，这被称为服务所有权模型。这种模型使开发、测试、运维人员能够更贴近客户、业务和要交付的价值。

通常把服务所有权模型分为两类：

1 业务服务

是直接向用户提供价值的服务，如信用卡、网上商城等，这些是客户直接接触的，也是企业向自己的客户提供的服务目录，通常最终客户并不会关注你提供的信用卡服务是运行在x86的服务器上，还是oracle的数据库上，他们只关注该服务提供的业务价值是什么、服务标准及规范是什么？当客户不能刷卡时，直接电话callcenter即可。

2 技术服务

是完成对业务服务的技术支撑平台，如某东提供网上商城，用户只需要在浏览器或手机端浏览商品并下单即可，但是他后台需要很多的技术组件为其提供业务服务，如移动端ios版本、移动端安卓版、csn服务、均衡负载、tomcat中间件等。

通过构建相互之间的依赖关系，可以将企业内部众多的业务服务和技术服务串到一起，形成一张巨大的企业服务网络拓扑，而其中的每一个节点即为一种服务，每一种服务都由独立的团队对其进行开发、测试、运维，保障服务的连续性。

模型构建完成的样子及能力介绍

上图所示，是一个典型的电子商务平台的服务所有权模型图，事件或应急场景下，能够实现以下能力：

将业务链路层和技术组件层告警进行有效关联

通过该模型提供的管理能力，在不构建cmdb和调用链路分析及埋点的情况下，将业务服务相互之间的相互调用关系、业务服务同技术服务之间的依赖关系清晰地刻画出来，从而在事件和应急场景下对告警进行有效关联。

业务影响分析和技术组件影响分析

通过服务所有权模型，可以清晰地了解业务服务和技术服务之间的依赖关系，帮助分析事件对业务和技术组件的影响。如上图，可以清晰看到最底层的技术服务组件“mysql - 库存”出现问题后导致直接依赖他的技术组件”库存api”和“redis - 缓存“出现故障，并最终通过”订单api“服务，影响到了三个业务服务，分别是”结算“、”移动商城“、”网上商城“。

促进团队协作

服务所有权模型使开发、测试和运维人员能够更贴近客户、业务和交付的价值。它帮助团队更好地理解服务的所有权和责任，并加强团队之间的协作和沟通。

加速排障过程

服务所有权模型提供了一个全方位的视角，使团队能够总览整个故障拓扑，它消除了孤立环境和沟通差距，提高了组织快速响应客户需求的能力。

可视化根因分析

由于可以总览整个故障拓扑，使运维团队在分析根因时不再是一条条独立的告警，而是可以从总览拓扑的视角查看整个故障的完整上下文，协助运维人员进行可视化根因分析。

其他更多能力……

如何逐步落地模型？

构建原则

在构建服务所有权模型之前，首先要要明确以下原则：

建议在管理层要达成共识，从实际应用的视角来构建服务所有权模型，而不需要等待调用链和cmdb全部构建完善再应用。
鼓励运维工程师在变更完成之后自行更新服务所有权模型，边应用边治理。
每个服务所有者构建自己的服务模型。
每个服务所有者必须清楚的知道自己的服务所支持和依赖的服务是谁，而无需知道整个依赖关系的全貌，如库存API的服务所有者必须知道自己所依赖的“mysql - 库存”和“Redis - 缓存“服务，支持”订单API“服务，但不必知道谁支撑订单API和依赖谁。
每个服务所有者都构建完成自己的上下游依赖关系之后，则会构建完成整个服务所有权模型。
针对有错或缺失的部分，可以边应用边调整。
无须一次性完美构建，持续优化即可。

构建过程

第1步：明确业务服务和技术服务以及他们之间的依赖关系

首先要定义清晰的业务服务和技术服务边界，以及自己所运维的技术服务支持哪些业务服务。

业务服务：直接面向最终客户的服务，如，网上购物商城服务，这是直接面向最终消费者的。
技术服务：是为支持某项业务服务而搭建的应用系统或微服务（现代的微服务架构），如web服务向用户提供了商品目录浏览、下单等能力，基于tomcat的应用服务为web服务提供了业务处理的能力，而数据库服务为应用服务提供了数据持久会存储的能力。
依赖关系：是指服务（包括业务服务和技术技术）之间的相互依赖关系，通过依赖关系的构建可以形成完整的服务所有权模型。

通常建议服务所有者先在纸上构建一个草图，明确自己所管理的服务边界以及所依赖和支持的服务有哪些，然后再着手构建服务所有权模型。

第2步：确认服务所有权

如上图所示，确保每一个服务都有具体的管理团队为其提供开发、运维，这样当发生事件或应急时可以有将的将告警路由到不同的团队进行处理，并可以促进团队之间的相互协作。

传统的应用系统是以应用为视角来进行管理的，为了更好地了解应用的架构，以及出现故障时，可以有效地构建应用系统的可视化架构拓扑，建议对整个应用系统进行架构上的拆分，建议如下：

应用系统所支持的业务，拆分为业务服务，这样当系统或相应的组件发生问题时，可以清晰的感知对潜在业务的影响。
构成应用系统的各组件，拆分为技术服务，如一套应用系统包括web集群、应用集群、数据库集群、数据库依赖存储等，可以拆分为web服务、应用服务、数据库服务、存储服务，这样可以有效的构建系统的可视化架构拓扑，而无须依赖cmdb完善之后才能构建。

第3步：构建服务拓扑以及依赖关系

针对第 1、2 步中手绘的服务拓扑关系，可以着手构建服务，如上图所示：为一个业务服务的创建过各，需要输入业务服务的基本信息，然后再从已有的服务列表中选择支持该业务服务的技术服务或业务服务。

服务配置完成之后，后续也可以对服务进行依赖关系的修改，如下图所示，可以对库存API所依赖的服务和所支撑的服务进行修改：

第4步：告警绑定服务

要在服务拓扑上清晰的展示每个服务的状态以及是否发生故障，则需要将告警绑定到服务上，实践中建议有两种绑定方式：

方式 1 - 对告警进行服务规则路由：针对这种方式在告警进入系统时要么通过丰富策略丰富对应的服务信息，要么根据其它的辅助字段，如所属的业务系统、告警对象类型（db主机、应用服务器等）关键字段，建立基于规则的路由策略。
方式2 - 事前构建服务依赖资源表：当服务创建时，运维人员清晰地知道该服务所使用的资源列表，如上图所示的电子商务平台中”redis-缓存“集群，使用了192.168.1.1和192.168.1.2两个主机，这样当告警对象名称为192.168.1.1和192.168.1.2时，会自动路由到该服务上。

建议使用方式2，只是对系统进行扩缩容时，运维管理团队要主动维护这些变更内容，则后续的告警才会进行有效的服务绑定。

第5步：持续优化和改进

服务所有权模型及拓扑依赖关系的构建不是一次性的，是一个长期治理和更正的过程，在使用的过程中会越来越趋近完善。使用的人越多，从服务所有权模型中所得到的回馈也就越多。

更重要的是他仅仅通过简单管理的手段即可完美替代调用链、cmdb两套系统的价值。

推荐的模型存储及计算方案

建议用关系数据库和图数据库两种存储方案，关系数据库做服务节点、节点之间关系的存储，而进行可视化展示、根因分析推荐、相似故障识别算法、服务节点链接关系推荐、影响分析等建议采用图数据库来完成，因为其提供了比关系数据库更好的图查找、遍历、计算的方法，主要包括：

图搜索算法：包括广度优先搜索（BFS）和深度优先搜索（DFS），用于在图中查找特定的节点或路径。
最短路径算法：例如Dijkstra算法和Floyd-Warshall算法，用于找到两个节点之间的最短路径。
最小生成树算法：例如Prim算法和Kruskal算法，用于找到连接所有节点的最小生成树。
图聚类算法：如K-means算法和谱聚类算法，用于将图中的节点划分为不同的聚类。
PageRank算法：用于评估网页的重要性，并根据链接关系进行排名。
社区发现算法：例如Louvain算法和标签传播算法，用于识别图中的社区结构。
图神经网络：一种基于深度学习的方法，用于处理图数据的节点分类、链接预测等问题。

请注意，这只是一些常见的图计算方法，还有许多其他方法和算法可用于处理不同类型的图数据。

总结

本文介绍了如何在事件及应急场景下低成本且高效地构建排障拓扑，加速排障过程。

通过服务所有权模型，可以清晰地了解业务服务和技术服务之间的依赖关系，促进团队协作，加速排障过程，并实现可视化根因分析。文章提供了一步步简单的落地服务所有权模型的构建过程，包括明确业务服务和技术服务之间的依赖关系、确认服务所有权、构建服务拓扑以及依赖关系、告警绑定服务，并强调持续优化和改进的重要性。通过构建服务所有权模型，可以更好地管理和理解服务的架构，提高团队的协作效率和快速响应能力。

#智能运维# #应急处置#