服务器故障管理实践

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 来表示相同的硬件状态或故障类型。这种不一致性可能导致 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  展望

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

-End-

作者丨旋风