1 背景

上图是B站一站式大数据集群管理BMR的架构图，BMR管理了大数据所有的机器和核心服务，随着B站业务的快速发展，大数据的规模和复杂度也突飞猛进。具体表现如下：

集群规模大：BMR管理的机器数量超过1万台，服务组件超过50个，总存储容量超过1EB，计算资源超过100万核，形成了一个庞大且复杂的集群环境。
服务管理复杂：在同一台机器上，常常混合部署着多种不同业务的服务，如转码和大数据混部、潮汐混部、以及大数据内部各组件的混合部署等。此外，有些服务之间往往存在相互依赖关系，增加了管理难度。
异构的环境：集群中的机器型号、操作系统版本、内核版本等方面存在较大差异，形成了高度异构的环境。

面对超大规模的集群、复杂的服务管理和异构环境，尤其是在任务运行时需要跨越多台乃至成百上千台机器的情况下，故障的及时发现与处理变得困难，这对系统的稳定性和效率构成了挑战。本文将具体讲述如何借助BMR智能运维平台中的故障自愈系统来迎接这一挑战。

2 架构设计

故障自愈系统通过智能化和自动化技术，显著提升了故障处理的及时性、智能化和可分析性，从而将被动响应转变为主动预防。具体来说：

及时性：实现了近实时的故障发现和处理，大幅缩短了故障影响时间，增强了服务的稳定性。
智能化：通过多维分析主机和服务的信息，并运用智能诊断技术，系统能够自动发现和处理故障，显著减少量繁重和重复的工作，提升了故障处理的效率。
可分析：通过对故障数据的深入分析，系统能够提供故障发现的概率、趋势和发展方向等重要信息。这不仅有助于及时调整和优化故障处理策略，还为预防未来的故障提供了科学依据。

如图所示，整个故障自愈主要包括数据采集、故障分析、故障处理、决策定义。我们通过近实时的数据采集，采用智能的故障分析和故障处理最终实现故障的高效处理和快速的自愈恢复。

数据采集：主要收集主机和服务的异常监控指标、异常日志、告警订阅信息、系统组提供的主机故障数据以及业务元数据。这些数据为后续的故障分析和处理提供了全面的数据支持。
元仓：元仓是所有采集数据的汇聚中心，实现了不同数据源之间的互通。通过元仓，可以对多源数据进行整合和预处理，确保数据互通性和完整性。
决策定义: 针对不同的服务和故障类型，定义了具体的处理决策，形成一个全面的知识库
故障分析: 基于采集到的故障信息，结合业务元数据，系统能够确定具体的决策类型（如告警、自动处理等）。
故障处理: 结合业务元数据，系统针对不同的故障类型采用相应的处理流程。

3 技术实现

3.1 数据采集

3.1.1 数据源

故障自愈系统为了确保故障分析的准确性，我们采集了丰富的数据，下面是我们采集的核心数据：

业务元数据：我们对业务进行了四级分类：服务、集群、组件和标签。业务元数据详细记录了每台机器上历史和当前部署的服务情况。
主机故障数据：同步系统组提供的主机故障数据，涵盖CPU故障、内存故障、主板故障、PCIE设备故障、网络故障等13大类，近百个小项故障信息。
业务黄金指标数据：收集大数据组件如HDFS、YARN、Presto、Spark等的核心监控指标数据。
主机核心监控数据：覆盖了主机的核心监控指标，包括CPU使用率、内存使用率、磁盘读写速度、网络流量、进程数、线程数等。
系统异常日志：采集系统日志文件（如/var/log/message、/var/log/syslog、/var/log/kern.log）中的异常日志数据。
告警数据订阅：与公司内部的监控告警系统对接，自动订阅与大数据服务相关的核心告警数据。
业务上报数据：除了主动采集的主机和业务数据外，系统还支持业务方主动上报数据，使得数据采集更加灵活和丰富，能够更好地适配各种业务场景。

3.1.2 元仓

元仓服务把不同来源的数据收集一起，然后对这些数据进行聚合，数据聚合的时候对数据打上业务、主机的标签，每条数据都关联上对应的主机和业务，聚合后的数据让大数据服务复杂的管理变得更简单。聚合后数据通过写入kafka最终同步到StarRocks。元仓数据就是我们实现故障自愈的底座。

3.2 决策定义

我们针对不同类型的服务和故障，制定了差异化的处理策略，构建了一个全面的知识库。这一过程首先涉及定义和维护故障元数据，其中包括故障类别、子类别、故障等级、故障描述、影响范围及故障判断条件等关键信息。接下来是定义业务元数据，因为不同的故障对不同业务的影响各异，所需的应对措施也不尽相同。最终，结合故障元数据和业务元数据的信息，我们能够准确评估故障对业务的具体影响，并给出相应的处理操作。以下是几种典型的决策制定示例：

3.3 故障分析

3.3.1 故障识别

我们定期从StarRocks元仓库中读取最近时间窗口内的数据，利用StarRocks强大的分析能力，整合来自不同源头的数据与故障元数据，进行数据的聚合与过滤处理，从而提取出故障信息。在此基础上，我们会进一步补充故障详情。例如，对于磁盘故障，初始信息可能仅包含故障磁盘的位置和所在节点名称。通过结合主机运行时信息、主机CMDB和业务信息等多维度数据，我们可以完善磁盘的盘符、磁盘类型等详细信息。同时，借助业务元数据，我们还能补充故障对相关服务的具体影响详情。

3.3.2 故障降噪

当相同故障在短时间内频繁出现，或是不同数据源重复报告同一故障时，自愈处理可能会并行执行或在短时间内多次触发。由于自愈过程通常涉及机器或服务的重启，频繁的自愈活动会对服务的稳定性造成负面影响。因此，在接收到故障分析后提交的故障信息时，系统需要先对重复故障和短时间内多次发生的故障进行降噪处理，然后再进行后续步骤。

在本系统中，我们采用故障服务名称、主机名称、故障点以及故障类型作为故障的唯一标识符，实施去重操作。此外，对于同一类型的故障，系统还会执行一段时间的静默处理，避免因短时间内多次触发自愈而导致的服务中断。

这种机制有助于减少不必要的自愈操作，确保服务的稳定运行，同时提高故障处理的效率和精准度。

3.4 故障处理

3.4.1 防呆策略

在故障分析阶段，通过对元仓数据的深入分析来获取故障和异常信息。然而，这些信息在处理过程中有可能对服务的稳定性造成影响。特别是当上游系统或依赖系统的Bug导致故障分析结果不准确时，可能会在短时间内生成大量的故障信息，进而传递至自愈系统。为了应对这类可能影响服务稳定性的场景，我们采取了一系列故障防呆措施，确保自愈操作的安全性和有序性。以下是我们故障自愈系统所采用的主要防呆策略：

异常流量识别：当故障分析阶段检测到的故障数量突然增加，超出正常预期时，系统能够自动识别此类异常情况，暂停故障处理流程，并即时触发自愈异常告警，以便及时介入查找原因。
限流与并发控制：考虑到不同服务对故障的容忍度存在差异，我们对不同服务集群，设置了个性化的并发控制和限流策略。这样做可以在保证故障处理效率的同时，防止因处理过程中的高并发操作而影响服务的稳定性。
主动防御：在执行故障自愈处理前，系统会根据当前服务状态做出综合判断，决定是否立即启动自愈流程。例如，在处理磁盘故障时，若该节点上运行有DataNode服务，则会先检查HDFS中未充分复制的块（Under Replicated Blocks）。如果发现单副本数量较多，系统会选择等待这些副本恢复正常后再继续故障处理，以此避免在关键数据复制不足的情况下进行操作，确保数据安全和服务稳定。

通过实施上述防呆策略，我们能够有效减少误报和不必要的故障处理操作，保障自愈过程既高效又安全，最大限度地维持服务的连续性和可靠性。

3.4.2 流程生成

通过上述决策定义可以看出，不同类型的故障以及同一故障在不同服务中的处理方式各有差异。基于此，我们将故障信息与预设的故障决策相结合，自动生成一个故障处理流程。该流程由多个子任务串联组成，最终形成一个完整的自愈任务执行工作流。为了更加精细地管理这些任务，我们根据任务性质将其分为以下几类：

防御任务：根据当前服务状态判断是否适合启动故障处理流程，确保操作的安全性。
脚本任务：在指定的目标节点上执行脚本，如运行Shell命令，以实现特定的操作需求。
发布任务：利用我们的大数据集群管理平台BMR，执行配置更新、服务节点上线或下线、服务重启等操作。
硬件维修任务：通过调用系统组提供的管理系统接口，发起设备维修请求、执行主机重启等操作，并在确认操作完成后关闭任务。
节点隔离任务：运用内部平台提供的接口，将故障节点设置为不可调度状态，有效阻止故障扩散。
通知任务：发送故障告警通知，对于高风险操作，还需提交审批请求，由人工审核确认后执行。

通过这种分类方法，我们能够更加高效地管理故障自愈过程中的各项任务，确保故障得到及时有效的处理，同时最大程度地减少对服务稳定性的影响。

3.4.3 故障自愈

生成自愈任务执行的工作流后，该工作流会被保存至数据库中。调度中心依据数据库中的记录对工作流任务进行调度和执行。工作流中的子任务遵循串行执行原则，即前一个子任务完成后，下一个子任务才会启动。鉴于异常处理的不确定性和调用各类API时可能出现的网络波动，每种类型的子任务均可配置独立的超时时间和失败重试策略，确保系统能根据设定的策略自动尝试重试。一旦某个子任务最终失败，系统将自动通知相关人员介入，允许其选择重新尝试该任务或手动进行其他干预措施。经过人工干预后，可以选择终止整个自愈流程，或者跳过当前失败的步骤继续执行后续任务。

此外，无论是在自愈流程开始、结束还是遇到异常时，系统均会发送卡片通知，确保相关人员能够及时了解自愈进程的状态，从而迅速作出响应。

通过这样的机制设计，我们不仅能够确保自愈流程的自动化与智能化，还能够在必要时提供灵活的人工干预选项，保障故障处理的高效性和可靠性。

3.5 案例分析

故障自愈产品能力中，由于大数据业务磁盘总数基数大，故障数也最多，我们先从磁盘的故障自愈开始做。我们对三类磁盘异常进行了故障自愈。第一类磁盘有明显硬件故障，这类最容易处理，直接该磁盘上的对应业务，报修换盘，磁盘换盘后上线继续使用。第二类结合业务需求，利用机器学习对磁盘指标数据进行分析和预测，对性能离群且影响到业务的磁盘也做了自愈。第三类是磁盘寿命不足的场景，在大数据shuffle过程中，频繁的读写操作会加速磁盘寿命消耗，需要及时更换shuffle盘。之前避免磁盘寿命耗尽影响到服务，我们根据磁盘寿命剩余多少来判断磁盘是否需要换盘，有时候被换掉的盘实际上还能继续使用一段时间。有了自愈系统之后，我们可以根据磁盘寿命和性能数据综合判断，即使寿命统计数据显示磁盘寿命耗尽，但不影响使用的情况下，我们也可以继续使用，不断提高了换盘的效率，同时也延长磁盘的使用寿命。另外，自愈系统慢慢开始覆盖IO Hang住、服务进程异常、端口异常、访问异常、服务日志异常等越来越多的场景。下图是一个磁盘故障自愈的案例。

在我们的故障自愈产品能力中，考虑到大数据业务中磁盘总数庞大，故障频发的特点，我们首先从磁盘故障自愈入手。目前，我们已对三类磁盘异常实现了自愈处理：

明显硬件故障：对于存在明显物理损坏的磁盘，这类故障相对容易处理。系统会自动将故障磁盘从服务中剔除，同时提交磁盘更换请求。磁盘更换完成后，系统自动将其重新加入到服务中继续使用。
性能离群且影响业务：针对那些虽然没有明显的物理故障，但性能显著下降并对业务造成影响的磁盘，我们采用了机器学习技术对其指标数据进行深度分析和预测，从而提前识别潜在的问题磁盘并实施自愈措施。
磁盘寿命不足：在大数据处理过程中，频繁的读写操作会加速磁盘的磨损，特别是在shuffle阶段。为了防止磁盘寿命耗尽导致的服务中断，我们开发了一套综合判断机制判断是否需要换盘。该机制结合磁盘寿命统计数据和实时性能表现，不仅提高了换盘的及时性和准确性，而且在不影响业务的前提下尽可能延长磁盘的实际使用寿命。例如，即便统计数据显示磁盘寿命已接近耗尽，但如果磁盘仍能保持良好的性能，系统会允许其继续使用直至真正需要更换。

随着自愈系统的不断完善，我们已经逐渐将其应用于更多场景，包括但不限于IO Hang住、服务进程异常、端口异常、访问异常以及服务日志异常等。下图是一个磁盘故障自愈的案例。

如图所示，展示了磁盘故障自愈的完整流程。故障分析后获得的故障详情信息及受影响的服务信息，被系统用来自动生成故障自愈处理工作流。根据部署故障节点部署了DataNode和NodeManager服务，除了基本的磁盘故障维修流程外，我们还在故障处理流程中集成了这两个组件的节点故障隔离与恢复步骤。最开始的单副本检查子任务用于确保在集群中没有其他单副本的情况下再进行后续的故障磁盘下线操作。通过锁机制，保证在同一时间点内，HDFS集群中只有一个故障磁盘处于下线状态，从而最大限度地减少数据副本丢失的风险。DataNode卸载磁盘 和 NodeManager卸载磁盘这两个子任务负责从DataNode和NodeManager的服务配置中移除故障磁盘的挂载点，确保故障磁盘不再被使用。在经过系统组报修，确认磁盘修复并可重新投入使用后，执行 DataNode挂盘 和 NodeManager挂盘 子任务，将之前更改的服务配置恢复，使磁盘重新加入到服务中正常使用。每个子任务均运行成功后，整体流程运行顺利结束，自愈流程正式结束。

4 总结和展望

故障自愈系统极大地简化了复杂的大数据环境中的故障管理过程，不仅能迅速识别和响应各种故障，缩短故障处理时间，还显著增强了服务的稳定性和可靠性。目前故障自愈已应用到NodeManager、DataNode、Flink、ClickHouse、Kafka、Spark等关键大数据组件，涵盖了磁盘故障、磁盘性能下降、SSD/NVME磁盘寿命到期、IO Hang住、端口异常、服务异常日志记录、服务网络连接数异常等多种故障场景。据统计，每日通过该系统自动处理的故障案例超过20起，相当于节省了至少一名专职人员的工作量。

接下来，我们将进一步拓展故障自愈系统的应用范围，涵盖更多服务组件和故障类型。此外，我们计划引入机器学习技术，实现故障的预测分析，以便提前识别潜在风险，确保集群和服务的长期稳定运行。这不仅将进一步提高系统的自动化水平，还将为用户提供更加可靠、高效的服务体验。

本文来自公众号：哔哩哔哩技术