优维全面可观测产品能力分解④:故障可观测

微服务系统异常检测和根因定位 方法综述 CSUR22 - Anomaly Detection and Failure Root Cause Analysis in (Micro) Service-Based Cloud Applications: A Survey 基于(微)服务的云应用中的异常检测与故障根源分析:综述 总结 到目前(2022),学术界故障检测和根因定位方法的综述 当前的异常检测技术,都需要一个baseline去构建预知识。当线上执行差距过大(并发压力、环境、基础测试集构建错误等),会造成检测不准确 根因定位技术:各有千.. 阅读详情

动图封面

《优维全面可观测产品能力分解》系列文章的第一篇,介绍了「架构可观测」是从系统架构的视角来呈现链路与服务的状态数据;第二篇介绍了「变更可观测」是从变更的角度看系统状态的变化,及与事件的关联关系;第三篇介绍了「应用服务可观测」是深入服务链路的调用情况,基于Trace来做请求级链路追踪,实现服务的横向可观测。下面内容为该系列文章的第四篇,主要分享「故障可观测」的能力。


2023年过去了,但是相信没多少技术人会特别怀念它。对于技术人来说,这是不平静的一年,尤其是各大公司萝卜蹲式的各种P0/P1故障,频繁占据了热搜榜单。例如:滴滴崩了、阿里云一个月两次服务中断、语雀服务器崩了、微信&QQ先后故障、唯品会故障超12小时......

互联网大厂“组团”故障,说明在如今这个充满不确定性和复杂性的数字化时代,哪怕是互联网大厂亦不能避免各种故障的发生。这无疑再次为广大企业与组织敲响警钟,即当数字化转型步入深水区,业务应用全面走向线上化和智能化之际,我们的业务系统连续性到底应该如何保障?

正如AWS CTO Wanner所言:“Everything fails, all the time。”我们需要接受任何时候故障都可能会发生,既然故障无法避免,那么需要做的就是预测什么时候出现故障、如何快速定位故障、发现故障原因,并确保业务连续性受到最小影响,将损失降到最低。

因此,企业数字化转型中缺少不了业务系统保障的“连续键”,实现故障可观测性的建设已成为企业数字化转型中的一道必答题。

1

系统保障不能没有“连续键”

业务连续性的保障是重中之重,企业与组织数字化转型的不断深入,业务全面走向数据驱动和智能化的同时,外部攻击、人为错误、运行故障、自然灾害等对业务连续性的影响日渐突出。业务一旦中断,损失往往是企业不能承受之重,业务系统保障已不能没有“连续键”。

不过,传统故障排查和处理过程正成为业务系统连续性的“拦路虎”。在多云架构、复杂业务和海量数据的趋势下,企业自身IT环境走向复杂化,传统故障排查和处理的过程普遍存在一些通病:

  • 经验主义缺陷:故障排查定位时,依赖运维经验,无法形成标准高效的故障定位方法;
  • 野路子方法论:故障处理过程没有标准化的处理方案,故障应急处理效率和质量不可控;
  • 故障跟进割裂:缺乏有效的故障跟进处理机制,无责任人,导致故障往往是临时解决,且没有得到最终解决;
  • 信息各自为政:缺乏统一的故障分析沟通的地方,沟通和分析的过程信息均散落各地,导致无法有效的分析统计,进而无法有效的治理。

基于对以上痛点的洞察,企业与组织需要升级全新的故障排查与处理的能力,实现业务系统的连续性管理。

2

优维「故障可观测」

为业务系统按下“连续键”

作为新一代运维核心系统提供商,得益于在可观测领域多年的实践,优维技术团队构建了更加精细与完善的可观测能力,尤其是在故障可观测能力的建设上全新升级,能第一时间呈现故障的根因,并能联动应急处置快速恢复。

优维「故障可观测」产品能力可做到故障的有效识别、跟进、快速定位、应急处理与分析总结,帮助企业减少故障带来的损失。

基于常见的故障场景提供智能分析,「故障可观测」帮助企业快速完成故障定位,减少服务故障带来的企业损失。基于特定的故障场景提供常见的故障处理预案,确保服务快速恢复。还提供标准化故障处理流程和统一的故障处理作战室,确保责任到位,提高沟通效率,最终形成故障处理规范。

产品功能

就观测能力而言,优维「故障可观测」具体表现在“故障工单”和“故障根因分析”两大功能层面,助力企业高效进行故障排查与处理,确保系统稳定性与连续性。

故障工单的能力特色在于:其一是与优维ITSM的工单处理进行联动,支持团队更好管理故障,提高故障响应速度;其二是关联告警轨迹追踪,即故障发生后,通过告警轨迹追踪,及时了解告警的变化,且可按阶段查看告警的状态;其三是同源故障关联,即已知故障解决后,会自动关掉相关的故障单,避免不同的运维小组重复报障,减少沟通成本,提高故障处理效率。其四是对接应急预案,在故障发生后,可快速响应,进行应急决策,根据应急预案进行故障的处置与恢复。

另外,我们知道,故障的症状是最先发现的,而导致故障的原因才是最终排除故障的关键。因此,「故障可观测」的另外一大功能-故障根因分析,首先让用户及时了解服务的传播轨迹,再通过横纵向综合分析,将服务上下游及支撑服务的基础设施纳入到整个故障分析的链路中,再结合告警、变更、高负载等事件进行全面分析,实现故障的深度诊断,快速定位故障根因,并清晰地给出关键性结论,更加方便企业去做分析和判断。

3

故障可观测的场景价值

  1. 故障定位:作为运维人员,皆希望通过故障定位工具或智能分析快速完成故障根因分析,以便于制定后续恢复方案。「故障可观测」可使运维人员不依赖个人运维经验,快速完成故障定位。
  2. 故障处理:「故障可观测」可帮助运维人员迅速恢复服务可用性,彻底解决故障源头。
  3. 建设故障处理的标准流程:提供标准化故障处理流程,协助故障处理时各个角色的工作可高效开展。特别是作为运维平台负责人,针对已解决完的同类型故障进行归纳总结后,可制定故障处理的标准流程规范,确保不同的运维人员对同一类故障的处理是标准可控

系统故障不应该成为企业的负担。优维希望通过全新升级的故障可观测能力来改变过去传统的故障排查与处理,并从容应对各种不确定性,为企业的业务和系统保驾护航。

根因多维分析 | 一文看懂5大代表性算法的原理和优势 本文为大家盘点一下与多维定位相关的5个具有代表性的算法(文献)原理、针对场景、优劣、落地性等。 阅读详情

相关推荐

复杂运维场景下,如何实现分钟级的故障根因定位

作者介绍 熊亚军 灵犀技术总监,原百度系统部高级项目经理,负责百度IT基础设施监控团队,其带领的团队经历了百度服务器规模迈入几十万量级,网络架构数次演进,对服务器尤其是网络层的监控和运维自动化智能化有丰富的经验。 开篇:在超级互联网公司,随着服务器规模都早早迈过 10 万台量级,加之业务模式的多样性和 IT 架构的云化迁移,其 IT 运维团队面临的挑战与日俱增,常规的系统和经验都需要不

jiayani的专栏 1万+

用根因定位法,让运维效率再高一点!

‍‍作者 |中国农业银行研发中心 王哲头图 | 下载于视觉中国出品 | 优快云云计算(ID:优快云cloud)随着业务不断发展,微服务架构越来越受到各大企业的青睐,随之也给传统运维带...

优快云云计算 3035

根因定位FluxRank论文背景说明

摘要 软件服务的故障直接影响用户体验和服务收入。因此,运维可以在服务所在的每台计算机上监视服务级别的KPI(例如响应时间)和计算机级别的KPI(例如CPU使用情况)。当服务失败时,运维必须尽快定位根本原因的机器并减轻故障。由于难以获得所需的额外测量数据,现有方法的应用受到限制。目前故障定位在很大程度上是手动的并且非常耗时。本文介绍了FluxRank,它是一种可广泛部署的框架,可以自动准确地定位根本原因机器,以便可以触发某些操作来减轻服务故障。我们使用来自搜索公司的五个真实服务(具有成千上万台计算机)的历史案

lovelife110的博客 4995

告警策略与根因定位

异常检测->告警策略->根因分析都是AIOps中非常关键的步骤。 告警策略模型通常和业务类型、用户偏好及应用场景等业务相关,解决不同场景下特定问题。 根因定位:定位发生异常时那些属性导致了异常;定位哪些指标的异常导致事件异常的发生; FOCUS:《Focus: Shedding Light on the High Search Response Time in the Wild》,目标是解决在运维过程中,发现高搜索响应时间之后,使用机器学习算法发现异常的原因和规则。 FOCUS 使用系统

Mark_Australia的博客 2666

智能运营分析平台的根因分析架构:架构师如何快速定位问题?(因果推断+可视化)

根因分析作为智能运营的核心能力,直接决定了系统故障排查和性能优化的效率。本文构建了一套融合因果推断与可视化技术的根因分析架构框架,为架构师提供从数据采集到决策支持的全流程方法论。通过解析传统相关性分析的局限性,深入探讨因果推断在复杂系统中的理论基础与实现路径,结合多层次可视化技术,使运营团队能够快速定位问题本质而非停留在表面现象。文章系统阐述了架构设计原则、核心算法实现、最佳实践指南以及未来发展方向,为构建下一代智能运营分析平台提供全面技术蓝图。发生了什么异常?为什么会发生?如何防止再次发生?

大数据洞察的博客 1457

STM32硬件SPI调试ADS1256的3个致命坑,CubeMX配置避坑指南

本文深入解析STM32硬件SPI调试ADS1256高精度ADC芯片时常见的3大配置陷阱,包括SPI时钟频率、时钟极性与相位、数据字节序等关键问题。通过CubeMX实战配置指南和实测数据对比,提供稳定可靠的解决方案,帮助开发者避免常见错误,提升采样精度和系统稳定性。

weixin_42550597的博客 346

根因分析告警(进行根因分析的要素)

本文目录一览:所谓的AIOps,简单理解就是基于自动化运维,将AI和运维很好的结合起来。AIOps的落地在多方面直击传统运维的痛点,AI算法承担起分析海量运维数据的重任,能够自动、准确地发现和定位问题,从决策层面提高运营效率,为企业运营和运维工作在成本、质量和效率方面的优化提供了重要支持。可见,AIOps 在企业中的作用正在进一步放大。但事实上,很多企业对于AIOps 能解决什么问题并不清晰,今天我们就以博睿数据的AIOps 的三大场景和算法说起。作为中国领先的智能可观测平台,在AIOps实践方面,多年来博

Dove_1234的博客 1925

SOI技术解析:绝缘体上硅的结构优势与应用场景

本文深入解析了SOI(绝缘体上硅)技术的核心结构、性能优势与应用场景。SOI通过在硅衬底与器件层之间引入绝缘的埋氧层,实现了优异的电隔离,从而显著降低芯片功耗、提升工作频率并增强抗干扰能力。该技术已广泛应用于5G射频前端、高性能计算、汽车电子及MEMS传感器等关键领域,是推动半导体性能持续提升的重要技术路径。

jj890的博客 403

面向故障处理的可观测性体系建设

可观测性体系不能仅仅只有散乱的数据,而应让数据呈现特征,让特征呈现观点,让特征和观点辅助洞察:洞悉故障直接原因,完成止损!这才是建设可观测性体系的核心目标。诸君共勉。,我们愿意成为您向上的台阶,让您的可观测性体系更加完善,让技术体系底气更足。快来聊聊吧:微信公众号SRETalk。

n9ecommunity的博客 267

深度探索:非线性随机森林(Nonlinear Random Forest,NL-RF)原理及应用

非线性随机森林(NL-RF)旨在通过结合集成方法与高级技术来捕捉和建模数据中的非线性关系,从而改善传统随机森林在处理复杂非线性数据结构时的表现。

qq_51320133的博客 2067

Python实现课程时间表

用Python实现课程表功能

life is like a play 2042

优维全面可观测产品能力分解①:架构可观测

2023年,基于客户需求的洞察,历经1年的潜心优化,优维在第四季度推出集大成产品——「全面可观测解决方案」,涵盖架构可观测、故障可观测、变更可观测、用户可观测、应用服可观测、资源可观测、运维状态可观测等不同场景的可观测能力。基于系统架构和业务的视角,在架构可观测能力的设计展现上,采用“墙”的形式可视化展示系统、应用的运行状态,分别设有系统墙、应用墙、业务墙;优维「架构可观测」致力于系统架构视角、业务视角的整体状态的可视化呈现,以及系统架构视角的立体化剖析,为系统架构的稳定性提供有力的监控数据支撑。

EasyOps_DevOps的博客 1223

Win11大版本更新失败:系统保留分区空间不足的终极解决方案

本文针对Windows 11大版本更新时遇到的“系统保留分区空间不足”错误,提供了详细的诊断与解决方案。核心问题在于EFI系统分区(ESP)空间过小,导致更新失败。文章重点介绍了使用傲梅分区助手等第三方工具安全扩展EFI分区的完整步骤,并提供了手动清理、使用安装介质修复等替代方案,帮助用户彻底解决更新障碍,顺利完成Win11升级。

weixin_29280219的博客 960

优维全面可观测产品能力分解②:变更可观测

尤其是对于金融行业及大型互联网公司来说,稳定性就显得更为重要,另外,从诱发稳定性问题的原因分析来说,变更问题所占据的比例,常年超过一半以上,而故障60%到80% 是由于变更引起的。同时,消除信息孤岛,拉通东西向变更、南北向变更及变更时间流构成三维立体的变更观测视角,为运维提供全方位的变更洞察。基于上述存在的问题,优维「变更可观测」旨在帮助用户观测生产环境的系统变更行为,让业务运维可以更加准确地评估系统健康状态,同时辅助其更高效地处理变更引起的故障,确保系统的稳定性与连续性。

EasyOps_DevOps的博客 1002

在 SAP BTP 中通过 MTA 自动创建 Service Broker 的原理与实战

本文探讨了如何在SAP BTP的Cloud Foundry环境中通过MTA部署自动创建和注册Service Broker。传统手动注册方式存在依赖管理员、环境一致性差等问题。通过MTA部署可实现自动化Broker注册,利用占位符生成安全凭证,并确保平台端与应用端认证一致。文章详细解析了关键配置参数,包括create-service-broker标志、Broker名称、认证凭据和访问URL的设置方法。这种基础设施即代码(IaC)方式能提升DevOps实践水平,使服务注册成为应用部署流水线的有机组成部分。

2007 年 ~ 2025 年,深耕 SAP 技术 18 年 201

EMC诊断技术及电磁兼容理论设计

本文深入探讨了EMC诊断技术,重点在于滤波篇,详细讲解了EMI滤波器的设计、选型、测试及应用注意事项。内容涵盖噪声限值法规、滤波器的法规依据、插入损耗测试以及滤波电容的高频特性。同时,还阐述了噪声源的近场与远场特性,如何快速定位和抑制噪声。通过实例分析,提供了滤波器件和辐射噪声抑制器件的选型策略。

让你爱上电路设计 2164

优维全面可观测产品能力分解③:应用服务可观测

基于用户痛点的洞察,针对微服务架构下,复杂的服务调用关系和缺乏服务部署的实时画像,及对服务资源使用情况不清晰的问题,优维「应用服务可观测」提供服务全景透视能力,基于自动发现,立体展示服务调用关系和服务部署架构。针对服务的黄金指标,支持服务故障多维立体分析的能力,包含可查看服务级、实例级、接口级指标,以及通过提供高级对比、时间机器等多维对比能力,定位性能瓶颈和故障原因,解决排查问题难、性能瓶颈难发现的问题。其中,「应用服务可观测」通过提供系统级的服务调用地图,可视化的展示服务的调用情况。

EasyOps_DevOps的博客 737

SAP Clean Core 对传统 ABAP 开发人员来说意味着什么:机遇和挑战

SAP Clean Core是一种战略方法,旨在优化和现代化 SAP S/4HANA 系统,通过尽量减少定制,确保核心系统的稳定性、高效性和对云环境的兼容性。Clean Core 作为一种设计思路,致力于让 ERP 系统的核心功能保持简洁、规范,避免不必要的复杂化,最终维持一个标准化的核心,使系统更容易升级、性能更优越,同时支持快速的创新能力。

2007 年 ~ 2025 年,深耕 SAP 技术 18 年 611

优维全面可观测产品能力分解⑦:资源可观测

资源可观测」是面向资源展开的基础监控能力,通过提供多维采集手段,可纳管一切IT资源,包含网路、硬件设备、中间件、业务应用等,并可对接zabbix、Prometheus。以上,基于OneModel去做资源纳管,通过内置监控套件,实现标准化采集,再内置立体化、场景化的监控视图的能力,减少监控启用的使用成本,让用户使用路径更加明确。基于OneModel去做资源的自动纳管,并且把资源自动发现作为启动监控的一环,用户只需选择合适的方法,即可快速纳管到对应的资源。目前,覆盖的资源范围广,保证核心资源的全覆盖。

EasyOps_DevOps的博客 961

汉书HE8,好用的汇编代码编写工具

汉书HE8,好用的汇编代码编写工具早期编写汇编代码所用功能强大

efm32 入门.pdf

本PDF共计22页,介绍的是操作驱动API,下载与否自己斟酌。

优维眼中的Manus:AI工程化思维重构Agent的运维端启示

当Manus演示视频中那个自动生成的PPT带着些许不完美的排版问世时,我们看到的不是技术缺陷,而是一个新时代的隐喻——真正的智能化不在于追求完美无瑕的单个操作,而在于构建可观测、可干预、可演进的技术体系。我们曾经在某头部券商的案例中提到,正是通过类似的「决策-执行-验证」三层架构,实现了数据中心百万级资源的智能调度。这种工程化思维很容易让我们联想到优维的「运维原子能力库」理念——优维Murphy平台将复杂的运维操作拆解为可编排的原子指令,Manus正在构建面向通用场景的AI原子能力矩阵——

EasyOps_DevOps的博客 825

LinePhone3.2.7(android端最新版本) sip客户端

SIP客户端For android:LinePhone3.2.7(最新版本),官网地址:http://www.linphone.org/

HotSpot-多维属性的kpi异常定位(根因分析)

最近公司有这方面的需求,所以,就找一些论文和资料来了解一下在异常检测基础之上,如何做到对异常或者故障的根因分析。 有两种根因分析的需要,一种就是单指标异常检测,就是指标就是一维的这种,如果这种指标发生异常,直接就能够锁定到相关时间,位置,如果这种做异常检测,自然就需要升维,就是比如说,同时针对几个指标来进行,用窗口划分,然后看看同一时间段,都有哪些指标发生异常,然后这些窗口内的数据就组成原始处理数...

坚持的力量 9978

Devexpress16.2.6破解工具

Devexpress16.2.6破解工具Devexpress16.2.6破解工具Devexpress16.2.6破解工具Devexpress16.2.6破解工具

阿里微服务质量保障系列:阿里变更三板斧

变更是指对线上系统的任何操作(如:发布、增加、修改或移除等),或其他对生产业务可能有影响的任何操作。基于阿里巴巴的历史经验,有一半以上的重大故障皆为变更触发,因此,变更过程的风险防御显得尤为重要,会直接关乎业务的稳定性。

伤心的辣条 2403

云效故障定位研究论文被ICSE 2021 SEIP track收录

近期,由阿里云云效团队联合复旦大学CodeWisdom研究团队、阿里技术风险部安全生产团队,合作完成的论文《MicroHECL: High-Efficient Root Cause Localization in Large-Scale Microservice Systems》被ICSE 2021 SEIP track录用。本文针对大规模微服务系统的三种可用性问题,提出了一种高效的根因定位方法MicroHECL。 MicroHECL基于动态构建的服务间的依赖图,分析了所有可能的异常传播链路,并基于相关性

云栖技术精选 671

标准化故障根因定位应该怎么做

在现代软件开发和运维中,故障的及时响应和有效解决是确保服务稳定性的关键。然而,由于技术环境的复杂性和多样性,故障的根因定位往往是一项耗时且充满挑战的任务。为了提高故障处理的效率和准确性,标准化故障根因定位的方法和流程显得尤为重要。本文将探讨为什么需要标准化故障根因定位,以及标准化故障根因定位应该怎么做。标准化是提高工作效率和质量的基础。在故障根因定位中,标准化意味着建立一套统一的流程和方法,使得不同的人员在面对相同或类似问题时,能够按照既定的路径进行调查和分析。

kindlingx的博客 1039

Agith:openEuler 运维变更观测工具

针对 openEuler 运维变更过程观测困难的问题,华为 2012服务实验室 OSMind 团队开发了基于 eBPF 的变更观测工具—— Agith。Agith 可以识别与变更相关的行为,并将变更过程表示为一种拓扑结构——变更影响面。通过变更影响面可以完成变更告警、审计、根因定位、依赖分析等功能。背景云计算成为信息时代的算力底座,服务千家万户。作为重要的基础实施,稳定压倒一切。但同时云计算也在追...

2301_76434200的博客 214

【根因定位】报警聚类算法在美团业务系统的落地实施

在业务服务中,日志记录了关键执行点、程序执行错误时的现场信息等重要信息。当系统出现故障时,运维人员通常会查看错误日志来定位故障原因。在业务流量较小、逻辑复杂度较低的情况下,错误日志较少,运维人员可以快速定位问题。然而,随着业务逻辑的不断迭代和系统接入的依赖服务增多,错误日志的数量可能急剧增加。在这种情况下,错误日志的内容可能相互掩埋、相互影响,运维人员面对大量报错可能难以理清逻辑,导致难以快速解决核心问题。报警信息是系统中的一种重要报告机制,用于通知运维人员发生故障或异常。

weixin_47082769的博客 1348
上一篇: 飞行员还是电话接线员?软件开发人员消亡的预测是荒谬的
下一篇: 优化云的 10 种方法...
优维科技EasyOps
博客等级 码龄5年 1483粉丝 395原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值