📚 课程目录第2章故障域基础概念

2. 故障域基础概念：故障域定义、单点故障风险、故障域与可用性的关系

2.1 故障域定义

故障域（Fault Domain）是指系统中一个组件或一组共享资源的故障会扩散并影响其他组件的物理或逻辑边界。在IDP（内部开发者平台）架构中，故障域定义了“当一个组件失效时，哪些其他组件会连带受到影响”的范围。

故障域的核心特征包括：

共享风险组（Shared Risk Group）：同一故障域内的资源共享相同的故障源（如电源、网络、计算节点、数据库实例）。
故障传播边界：故障域是故障传播的物理或逻辑屏障，域内的故障不应自动扩散到域外。
粒度可调：故障域可以从单个进程、容器、Pod、节点、可用区到整个数据中心，粒度取决于架构设计。

IDP 视角： 在 Backstage 插件架构中，每个插件实例可以视为一个独立的故障域。插件 A 的崩溃不应导致插件 B 的服务中断，这是插件隔离设计的核心目标。

2.2 单点故障风险

单点故障（Single Point of Failure, SPOF）是指系统中某个组件一旦失效，会导致整个系统或关键功能不可用的风险点。在IDP平台中，常见的单点故障风险包括：

风险类型	典型场景	影响范围
共享数据库	所有插件共用同一个 PostgreSQL 实例	数据库宕机 → 所有插件不可用
共享服务进程	所有插件运行在同一个 Node.js 进程中	内存泄漏 → 整个进程 OOM → 全部插件终止
共享网络入口	单一 Ingress Controller 承载所有插件流量	Ingress 故障 → 所有插件外部访问中断
共享认证模块	统一认证服务作为所有插件的唯一身份源	认证服务宕机 → 所有插件无法登录
共享存储卷	多个插件挂载同一持久卷（PV）	存储故障 → 所有依赖该卷的插件数据损坏

关键警示： 在未做插件隔离的 Backstage 部署中，一个插件中的未捕获异常（如无限递归、死循环）可以直接拖垮整个 Node.js 主进程，导致所有插件同时下线。这是最典型的单点故障风险。

2.3 故障域与可用性的关系

故障域的设计直接影响系统的可用性（Availability）。可用性通常用“几个9”来衡量，其计算公式为：

可用性 = (总时间 - 故障时间) / 总时间 × 100%

示例：
99.9%（3个9） → 年故障时间 ≤ 8.76 小时
99.99%（4个9）→ 年故障时间 ≤ 52.56 分钟
99.999%（5个9）→ 年故障时间 ≤ 5.26 分钟

故障域与可用性的核心关系可以归纳为以下三点：

故障域越小，可用性越高：将系统拆分为更小的故障域，单个组件的故障影响范围缩小，整体可用性损失降低。
故障域数量与冗余度正相关：增加故障域的数量（如从单实例扩展到多实例），配合负载均衡和故障转移机制，可以显著提升可用性。
故障域边界决定恢复时间：清晰的故障域边界使得故障定位和恢复操作可以限定在域内，缩短平均修复时间（MTTR）。

下图展示了故障域粒度对可用性的影响：

2.4 故障域在IDP中的实践意义

在IDP平台中，故障域的设计直接决定了平台的稳定性和运维效率。以下是故障域原则在Backstage插件架构中的具体映射：

故障域原则	Backstage插件隔离实现	可用性收益
最小化共享资源	每个插件使用独立的数据库Schema或数据库实例	数据库故障仅影响单个插件
进程级隔离	插件运行在独立的Pod或Sidecar容器中	OOM/死循环不会扩散到其他插件
独立生命周期	插件可以独立部署、升级、回滚	升级故障可快速回滚，不影响其他插件
限流与熔断	每个插件设置独立的资源配额和熔断阈值	流量突增不会拖垮整个平台
可观测性边界	每个插件拥有独立的监控指标和日志流	故障定位时间（MTTR）大幅缩短

  实践要点： 在IDP平台架构中，故障域的设计不是“全有或全无”的二元选择。合理的策略是：

  ① 对核心插件（如目录、权限）采用强隔离（独立进程+独立数据库）；

  ② 对非核心插件（如文档、看板）采用轻隔离（独立进程+共享只读数据库）；

  ③ 对所有插件统一实施资源配额和熔断保护，防止级联故障。