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

文章来源：公众号ID-布博士（擎创科技资深产品专家）

哈喽~友友们大家好，最近运维界也是蛮热闹的，前有语雀多次崩溃，后有阿里全系产品集体故障，不管是哪种，都足够逼疯一个运维工程师。所以，本次分享楼主想就运维过程中“应急处置”分享一些看法，希望对你们有所帮助。

全部内容分为上下两篇，本次分享主要说一下以下内容：

一、传统调用链系统与CMDB系统的缺陷

二、服务所有权模型是什么？

三、服务所有权模型分类

感兴趣的朋友可以一键先马后看~

一、调用链系统与CMDB系统的缺陷

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

1.调用链路系统

成本高+周期长：需要对不同厂商和不同技术栈（如cs架构、bs架构等）的系统进行不同程度的改动，成本较高且项目周期较长。
短期效果不明显：在出现告警后，相应的运维工具系统之间需要进行大量的集成工作，短期内很难看到效果。

2.cmdb系统

适配周期长：最近几年，一些AIOPS厂商过度炒作了cmdb的重要性，似乎没有cmdb就无法进行基于拓扑的排障分析。然而，在现实案例中，我们发现为了维护一套高标准的cmdb系统，企业需要进行至少一年甚至几年的治理过程，包括解决数据质量问题、提高数据更新效率、降低维护成本以及解决数据缺失等问题。
不适合多场景运用：维护成本高昂且由于cmdb需要应对多种应用场景，不可能面面俱到，导致在实施过程中最终产出的结果更像是一个“四不像”。

那么问题来了，在事件管理及应急场景下有没有一种低成本且高效的方法可以快速地构建排障拓扑、实现业务层和技术组件层的链动分析，加速排障过程的系统模型呢？

答案是有的，那就是“服务所有权模型”。

二、服务所有权模型是什么？

近年我接触到的许多国内大型的金融机构，经常会发生一些有趣的事情，其中之一就是他们在出现事件后或应急的场景下就会研发各种工具试图弄明白当前正在发生什么事件、事件的告警对象依赖什么、谁在对告警对象提供服务、哪些业务受到影响？

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

三、服务所有权模型分类

1.业务服务

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

2.技术服务

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

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

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

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

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

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

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

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