服务器故障管理实践

1. 背景

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

人工处理效率低
：传统的器故人工故障排查和修复方式难以应对如此庞大的服务器规模。模板下载工具链分散 ：由于硬件故障的障管多样性，不同硬件需要不同的理实工具 ，导致运维团队需要频繁切换工具，服务增加了排查的器故复杂性和时间成本。

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

2. 服务器故障

2.1  故障分类

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

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

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

图片

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

2.2 传统故障管理的不足

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

故障发现滞后：依赖人工巡检或用户反馈
 ，可能导致故障发现不及时 。排查效率较低：人工排查故障原因耗时较长，可能延误问题解决 
。业务迁移沟通成本较高：问题的发现和处理依赖于人工通知和响应 ，企业微信的沟通方式增加了响应时间，无法实现快速修复。维修过程自动化不足：人工推动的流程缺乏系统化的审计和记录，难以追踪问题处理的全过程。源码下载

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

2.3 目标

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

解决故障发现滞后和排查效率低下的问题
：将在第三章介绍自动化故障检测方案
，通过“信息采集--故障规则匹配检测--告警输出”流程实现快速发现和精准定位故障 。解决沟通成本高和流程自动化不足的问题 ：将在第四章介绍自动化维修方案，实现高效协同和全流程自动化管理 。

3. 自动化故障检测方案

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

Agent：部署在服务器上的轻量级组件，负责采集服务器的硬件状态信息（比如磁盘、网卡和GPU卡等）并上报到检测服务。日志平台：服务器通过 rsyslog将系统日志转存到日志平台，供检测服务进行解析和分析 。检测服务：检测服务包含多个检测模块，可以分为两大类，带内故障检测（负责处理 Agent 上报的信息和 Dmesg 日志）和带外故障检测（负责处理 SNMP Trap 报文和 Redfish API 数据）。DB ：存储故障检测规则，供检测服务调用 ，用于判断是否触发告警；同时存储检测服务生成的告警信息，供后续查询和展示。故障管理平台 ：故障平台读取告警信息 ，并以可视化的方式展示给用户。

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

3.1 信息采集方式

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

带内信息采集

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

带外信息采集

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

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

3.1.1 带内信息采集

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

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

（1） 磁盘模块

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

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

图片

（2） GPU模块

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

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

图片

3.1.2 带外信息采集

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

SNMP Trap 与 Redfish API的对比

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

高准确性：由于 OID（由服务器厂商定义）在机型层面具有唯一性，通过 OID 映射自定义的故障类型  ，可以对故障进行更细致的分类，避免出现未知错误，减少误报的概率，从而显著提升故障检测和上报的准确性。高灵活性：通过订阅机制 ，可以根据厂商和机型级别灵活关注不同的告警类型，满足多样化的监控需求。

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

3.2 故障规则管理

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

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

故障代码：每种故障对应唯一的标识，用于快速定位问题。故障描述：对故障现象的简要说明，帮助运维人员理解问题 。故障类型：分类故障的部件，例如网卡故障 、NVMe故障、GPU卡故障等
。故障等级：根据故障的严重程度划分等级（P0、P1、P2） ，以便优先处理高等级故障 。故障规则表达式：通过规则表达式定义故障的触发条件，例如日志关键字匹配 、硬件指标阈值超限等。

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

图片

4. 自动化维修方案

4.1  业务上下线自动化

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

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

图片

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

（1）故障检测与任务生成系统检测到故障后 ，通过自动报修入口触发报修流程，生成维修任务。

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

（2）callback 确认流程自动维修系统通过 callback 接口与业务方进行交互 ，确保维修任务的准确性和可执行性。具体流程如下：故障与维修系统向业务方上报故障信息。业务方确认故障后  ，进行业务下线 ，返回可以维修的反馈 
。自动维修系统完成维修后，通知业务方维修已完成。业务方最终确认维修结果并上线服务 ，完成闭环 。

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

在线维修：适用于无需停机的轻量级故障（如磁盘寿命耗尽） 。在线维修不涉及停机，恢复速度较快 ，能够在业务运行状态下完成操作 ，确保服务的连续性 。离线维修 ：适用于需要停机的硬件故障（如主板维修）。离线维修通常在 48 小时内完成硬件更换
 ，确保业务在维修期间的安全性。

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

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

4.2 维修过程自动化

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

（1）邮件或API通知在维修任务生成后，系统会通过邮件或 API 通知相关人员（如供应商）。通知内容包括故障检测平台输出的故障详情以及附件说明 ，确保信息传递及时准确 。（2）配件更换后的资产自动更新在维修过程中 ，如果涉及硬件更换（如磁盘、网卡、GPU 等），系统会自动更新资产管理系统中的相关信息 。（3）服务器状态的自动流转系统根据维修任务的进展，自动更新服务器的状态（如“报修” 、”交付“等）。状态流转由系统驱动 ，无需人工干预，确保服务器状态与实际情况一致，提升管理效率。（4）健康检测在厂商完成硬件修复后，系统对修复的设备进行二次检测，以确保设备已恢复正常运行状态。通过健康检测 ，可以验证修复效果 ，避免潜在问题再次影响业务运行。

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

5. 总结与展望

5.1  总结

图片

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

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

覆盖率 ：99%

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

准确率：99%

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

召回率：95%

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

5.2  展望

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

智能化监测系统 ： 利用机器学习和人工智能技术，能够更准确地检测潜在的故障迹象，提前预警并采取必要的维修措施。更高效的故障定位与处理 ： 随着技术的发展，故障定位与处理将更加精准和高效。新技术的应用将简化诊断流程，加快故障解决速度 ，从而降低系统维护成本。安全性和可靠性的强化：未来的服务器维护将更注重安全性和可靠性，加强对服务器硬件和软件的安全性管理，预防数据泄露和未授权访问 。