网站与微信结合,天猫网站建设可行性分析,西语网站域名,沧州网站营销推广文章来源#xff1a;公众号ID-布博士#xff08;擎创科技资深产品专家#xff09;
哈喽~友友们大家好#xff0c;最近运维界也是蛮热闹的#xff0c;前有语雀多次崩溃#xff0c;后有阿里全系产品集体故障#xff0c;不管是哪种#xff0c;都足够逼疯一个运维工程师。… 文章来源公众号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“服务影响到了三个业务服务分别是”结算“、”移动商城“、”网上商城“。 3.促进团队协作
服务所有权模型使开发、测试和运维人员能够更贴近客户、业务和交付的价值。它帮助团队更好地理解服务的所有权和责任并加强团队之间的协作和沟通。 4.加速排障过程
服务所有权模型提供了一个全方位的视角使团队能够总览整个故障拓扑它消除了孤立环境和沟通差距提高了组织快速响应客户需求的能力。 5.可视化根因分析
由于可以总览整个故障拓扑使运维团队在分析根因时不再是一条条独立的告警而是可以从总览拓扑的视角查看整个故障的完整上下文协助运维人员进行可视化根因分析。
其他更多能力…… 本次内容到这里就告一段落了下期会跟大家具体说说在实践场景中如何逐步落地服务所有权模型也会给大家推荐一些比较好用的模型存储以及计算方案感兴趣的朋友可以关注起来~ 供应商。公司专注于通过提升企业客户对运维数据的洞见能力为运维降本增效充分体现科技运维对业务运营的影响力。 行业龙头客户的共同选择 了解更多运维干货与行业前沿动态
可以右上角一键关注
我们是深耕智能运维领域近十年的
连续多年获Gartner推荐的AIOps标杆供应商
下期我们不见不散~
