dbaplus社群 18小时前
防宕机范本:服务器故障全流程自动化管理实践
index_new5.html
../../../zaker_core/zaker_tpl_static/wap/tpl_guoji1.html

 

随着B站业务快速发展,服务器规模爆发式增长,传统人工故障管理方式面临挑战。本文介绍了如何通过整合硬件监控、日志、故障检测及管理,实现服务器故障的全生命周期管理,包括故障分类、自动化检测方案(带内/带外信息采集、故障规则管理)、自动化维修方案(业务上下线自动化、维修过程自动化),并总结了管理架构及未来展望。

🔧 明确故障分类:软故障与硬故障(系统软件错误、硬件损坏等),按维修方式和业务类型分为在线/离线维修,高效分配资源,优化处理流程。

📊 传统故障管理不足:故障发现滞后、排查效率低、沟通成本高、自动化不足,难以满足现代互联网业务需求。

🔄 自动化故障检测:带内Agent/带外BMC采集硬件状态,日志平台存储系统日志,检测服务分析信息,规则库定义故障规则,故障管理平台可视化展示。

📈 信息采集方式:带内依赖操作系统和软件工具,监测粒度细但服务器崩溃时失效;带外依赖BMC,适用于服务器不可用场景,但监测范围有限。

🔍 带内信息采集:自研Agent采集磁盘、网卡、GPU等硬件状态,弥补内核日志不足,提供更全面监控。

🔗 带外信息采集:通过Redfish API和SNMP Trap获取信息,Redfish作为补充,SNMP Trap提供高准确性和灵活性,但OID厂商差异导致覆盖不足。

📚 故障规则管理:制定统一故障规则库,包含故障代码、描述、类型、等级、规则表达式,快速识别故障并指导处理。

🤖 业务上下线自动化:自动报修生成任务,通过callback接口与业务方交互确认,支持在线/离线维修模式,提升维修效率。

🚀 维修过程自动化:邮件/API通知相关人员,自动更新资产信息,服务器状态自动流转,健康检测验证修复效果,实现全流程自动化。

🌐 总结架构:硬件层、数据采集与日志层、故障诊断与报修管理层,带内带外协同,实现高覆盖率、准确率和召回率。

🔮 展望:未来将利用AI技术实现智能化监测,提高故障定位处理效率,强化安全性和可靠性。

通用工程 2025-07-25 07:15 广东

通过整合硬件监控、日志和故障检测及故障管理,实现了服务器故障的全生命周期管理。

一、背景

随着B站业务的快速发展,用户规模和内容生态不断扩展,平台的技术架构也在不断演进。伴随着这一增长,服务器数量呈现出爆发式增长,支撑起了海量用户请求和复杂的业务场景。然而,随着机器规模的持续扩大,服务器故障管理面临的挑战也愈发严峻。

    人工处理效率低:传统的人工故障排查和修复方式难以应对如此庞大的服务器规模。


    工具链分散:由于硬件故障的多样性,不同硬件需要不同的工具,导致运维团队需要频繁切换工具,增加了排查的复杂性和时间成本。

在这样的背景下,如何高效地进行服务器故障管理,成为保障平台稳定性和提升用户体验的关键课题。本文将详细介绍我们在服务器故障管理中的实践与探索。


二、服务器故障


1、故障分类

明确故障分类是提升处理效率的关键一步。通过科学的分类标准,可以更精准地识别问题并采取针对性的解决方案。

通常,服务器故障可以分为软故障和硬故障两大类:软故障主要系统软件错误(例如文件系统错误)、服务异常或其他软件层面的问题,而硬故障则包括磁盘硬件损坏、网卡硬件故障、GPU硬件故障等物理层面的问题。

此外,根据维修方式和业务类型的不同,还可以进一步划分为在线维修和离线维修。在线维修通常针对不影响业务运行的小范围问题,而离线维修则多用于需要停机处理的故障。


通过这样的分类方式,能够更高效地分配资源,优化故障处理流程,最大限度地降低故障对业务的影响。我们当前主要针对硬故障以及文件系统故障进行检测和处理。


2、传统故障管理的不足

随着服务器故障复杂性的增加,传统的人工故障管理方式已难以满足现代互联网业务的高效需求,主要存在以下问题:

因此,我们决定全面推进故障检测与维修的自动化建设。


3、目标

针对传统故障管理的不足,我们的目标是:


三、自动化故障检测方案

自动化故障检测整体架构和工作流程流程如下所示,主要包括服务器端的带内Agent/带外BMC、日志平台、检测服务、规则库和故障管理平台五个核心部分。

接下来,我们将深入探讨带内信息采集与带外信息采集的实现细节,以及故障规则的定义与管理方法。


1、信息采集方式

通过对业界主流服务器信息采集方式的深入调研,我们总结出两种主要的信息采集方式:带内信息采集和带外信息采集。

带内采集依赖服务器操作系统和软件工具,能够获取更丰富的系统数据,监测粒度更细,支持分析应用和系统日志。然而,其局限性在于,当服务器崩溃时,带内采集将无法工作。

带外采集依赖独立的管理硬件(BMC),即使服务器宕机也能远程管理,适用于服务器不可用或系统故障的场景。但其监测范围主要集中在硬件层面,无法深入操作系统层,数据的细粒度相对较低。

在大规模数据中心中,带内采集和带外采集各有侧重,二者相辅相成,缺一不可。通过结合这两种采集方式,可以实现对服务器运行状态的全方位监控,确保信息的全面性和准确性,为自动化、高效的服务器健康管理提供有力支持。接下来,我们将具体介绍如何结合这两种采集方式进行信息收集。

1)带内信息采集

传统的带内故障检测方式主要依赖操作系统内核日志,但内核日志在硬件状态监控方面存在一定的局限性,例如无法全面覆盖硬件健康状态或提供细粒度的硬件基础数据。

为了解决这些问题,我们自研了 Agent,用于采集磁盘、网卡、GPU 等硬件状态信息。Agent 的设计旨在弥补内核日志的不足,提供更细粒度、更全面的硬件状态监控。接下来,我们将具体介绍磁盘和 GPU 的信息采集方式。

①磁盘模块

磁盘模块主要负责监控存储设备(如 NVMe、SSD、HDD)及其存储控制卡的运行状态,我们通过自研的 Agent,结合多种系统工具,对磁盘的基本信息和健康状态进行采集,包括寿命剩余百分比、坏块数量等关键数据。Agent 将采集到的信息进行结构化处理后,上报至检测服务和资产服务,分别用于故障检测和资产管理。

整个架构如下图所示,Agent 通过调用操作系统工具(如 dmidecode、lspci 等)以及厂商提供的阵列卡管理工具,整合多源数据,确保信息的全面性和准确性。

②GPU模块

针对 GPU 的带内检测,主要监控计算核心与显存利用率、显存健康状态(如内存 ECC 错误)、功耗等关键指标,比如NVIDIA GPU 的 XID 错误表示 GPU 内部硬件或驱动等异常。

为了满足异构计算卡的采集需求, Agent封装了 DCGM 和 DCMI 接口,能够适配 NVIDIA、华为及其他厂商的 GPU 卡,统一采集 GPU 的健康状态信息。Agent 将采集到的原始数据进行结构化处理后,提供给检测服务和监控服务,确保 GPU 状态的全面监控和高效管理。其整体架构如上图所示。

2)带外信息采集

当服务器发生严重故障(如系统宕机或重启)时,系统可能无法记录相关故障信息,甚至完全丢失日志。针对这种情况,带外信息采集能够收集关键的故障信息,帮助快速定位问题。带外信息采集主要通过两种方式实现:一种是通过 Redfish API 接口获取信息,另一种是通过配置 BMC 使用 SNMP Trap 进行主动上报。

SNMP Trap 与 Redfish API的对比

SNMP Trap 属于服务器的主动上报机制,相较于 Redfish,具有以下优势:

但是由于各大厂商对 OID的定义和维护存在差异,不同厂商的设备可能使用不同的 OID 来表示相同的硬件状态或故障类型。这种不一致性可能导致 SNMP Trap 告警信息的覆盖范围不足,某些关键故障可能无法被及时捕获或识别。因此我们引入 Redfish 健康巡检机制作为补充和兜底方案。


2、故障规则管理

为了更高效地管理和处理不同硬件设备的故障,我们针对各类硬件设备制定了统一的故障规则库。故障规则库的核心目标是通过标准化的规则定义,快速识别故障类型、评估故障影响,并指导后续的处理流程。

故障规则库包含以下关键字段:

示例故障规则库结构如下所示。


四、自动化维修方案


1、业务上下线自动化

在引入维修沟通自动化之前,当业务发现机器宕机或异常时,通常通过企业微信通知运维人员进行排查。运维人员手动分析问题后,给出指导性建议(如维修、重装或重启),整个流程完全依赖人工推动,效率较低,且容易出现信息传递不及时或遗漏的情况。

为了解决这一问题,我们引入了维修沟通自动化机制(如下图所示)。该机制通过自动化的方式实现了故障检测、任务生成、callback 确认以及维修闭环的全流程管理,显著提升了维修效率。

该图展示了维修沟通自动化机制的整体流程,主要包括以下两个阶段:

1)故障检测与任务生成

自动维修系统接收到报修信息后,生成维修任务,并读取业务配置(如 callback 接口信息),为后续的交互做好准备。

2)callback 确认流程

业务方确认故障后,进行业务下线,返回可以维修的反馈。


自动维修系统完成维修后,通知业务方维修已完成。


业务方最终确认维修结果并上线服务,完成闭环。

自动维修系统支持两种维修模式:在线维修和离线维修,分别适用于不同的故障场景。

两种模式均需要业务方进行确认,确保维修操作不会对业务造成损害。通过这种机制,系统能够高效处理不同类型的故障,兼顾业务的安全性和维修效率。

此外,通过该自动化机制,取代了传统的人工通知方式,实现了故障报修和沟通的高效化与自动化,显著提升了维修流程的效率,减少了人工干预的复杂性。


2、维修过程自动化

在传统的维修过程中,许多操作依赖人工完成,例如邮件通知、资产信息更新以及服务器状态的流转。这种方式不仅效率低下,还容易出现遗漏或错误。为了解决这些问题,我们引入了维修过程自动化机制(如下所示),涵盖以下核心功能:

1)邮件或API通知

2)配件更换后的资产自动更新

3)服务器状态的自动流转

4)健康检测

通过维修过程自动化机制,我们实现了从任务生成到任务完成的全流程自动化管理,显著提升了维修效率,降低了人工操作的复杂性,同时保障了数据的准确性和可追溯性。


五、总结与展望


1、总结

上图展示了服务器故障管理的整体架构,分为三个主要层次:服务器硬件层、数据采集与日志层、故障诊断与报修管理层。

该架构通过整合硬件监控、日志和故障检测及故障管理,实现了服务器故障的全生命周期管理。带内和带外监控相结合,既能提供细粒度的运行状态信息,又能在系统不可用时获取关键的硬件故障数据。通过故障诊断和报修管理模块,可以快速定位问题并高效完成维修,保障业务的稳定运行。通过带内和带外的协同工作,我们故障管理的相关指标得到了显著提升:

带内监测覆盖了操作系统运行状态,带外检测覆盖了硬件健康状态,两者结合实现了几乎全方位的故障覆盖。

通过带内和带外数据的交叉验证,有效减少了误报和漏报,确保故障检测的高准确性。

结合实时监控、主动告警和定期巡检,确保大部分故障能够被及时发现和处理。


2、展望

服务器故障检测与维修是保障系统稳定性和数据完整性的关键环节。随着数据中心规模的不断扩大,对服务器健康状态的实时监测和及时响应变得更加重要。在未来,我们期待以下几方面的完善:

智能化监测系统: 利用机器学习和人工智能技术,能够更准确地检测潜在的故障迹象,提前预警并采取必要的维修措施。

更高效的故障定位与处理: 随着技术的发展,故障定位与处理将更加精准和高效。新技术的应用将简化诊断流程,加快故障解决速度,从而降低系统维护成本。

安全性和可靠性的强化:未来的服务器维护将更注重安全性和可靠性,加强对服务器硬件和软件的安全性管理,预防数据泄露和未授权访问。


作者丨通用工程

来源丨公众号:哔哩哔哩技术(ID:bilibili-TC)

dbaplus社群欢迎广大技术人员投稿,投稿邮箱:editor@dbaplus.cn

阅读原文

跳转微信打开

Fish AI Reader

Fish AI Reader

AI辅助创作,多种专业模板,深度分析,高质量内容生成。从观点提取到深度思考,FishAI为您提供全方位的创作支持。新版本引入自定义参数,让您的创作更加个性化和精准。

FishAI

FishAI

鱼阅,AI 时代的下一个智能信息助手,助你摆脱信息焦虑

联系邮箱 441953276@qq.com

相关标签

服务器故障管理 自动化检测 带内外监控 故障规则库 自动化维修
相关文章