1. 课程导论：多租户架构概述、故障域隔离的重要性、演练与风险控制的关系
1.1 多租户架构概述
多租户（Multi-Tenancy）是一种软件架构模式，允许单个软件实例同时服务于多个独立的租户（Tenant）。每个租户在逻辑上相互隔离，拥有专属的数据、配置、用户身份与资源配额，但共享底层的基础设施与平台服务。
| 维度 | 单租户架构 | 多租户架构 |
|---|---|---|
| 资源利用率 | 低，每个租户独占实例 | 高，共享实例与资源池 |
| 运维成本 | 线性增长，每租户独立部署 | 亚线性增长，统一运维 |
| 隔离粒度 | 物理/虚拟机级 | 进程/容器/命名空间级 |
| 故障半径 | 小，单实例故障不影响其他 | 大，共享层故障可能波及多租户 |
| 典型场景 | 私有化部署、政企专有云 | SaaS 平台、公有云、混合云 |
关键认知：多租户不是简单的"多用户"，而是资源复用 + 逻辑隔离 + 安全边界三位一体的架构设计。租户间共享计算、存储、网络层，但必须保证数据不串、性能不争、故障不扩散。
1.2 故障域隔离的重要性
故障域（Failure Domain）是指系统中一个组件失效后，会连带影响的其他组件集合。在多租户环境下，故障域隔离的目标是：将单个租户或单个组件的故障限制在最小范围内，避免级联扩散至整个平台。
故障域隔离的核心价值体现在三个层面：
- 可用性保障：防止"一颗老鼠屎坏了一锅粥"，某个租户的异常流量、代码缺陷或配置错误不会拖垮其他租户。
- 安全合规：满足金融、医疗、政务等行业的合规要求，确保租户数据与操作边界不可越狱。
- 运维可控：支持灰度发布、蓝绿部署、金丝雀测试，降低变更风险。
实践原则：故障域隔离应遵循"最小爆炸半径"原则——每个故障域内的资源数越少，整体可用性越高。在 Kubernetes 集群中，通常将不同租户的 Pod 调度到不同节点组、不同可用区，甚至不同集群。
1.3 演练与风险控制的关系
故障域隔离不是"配置完就生效"的静态属性，而是需要持续验证与动态调整的运行时能力。演练（Drill）是检验隔离措施是否真正有效的唯一手段，风险控制则是演练的最终目的。
二者关系可概括为以下闭环：
- 设计阶段：定义故障域边界、隔离策略、熔断阈值。
- 演练阶段：注入故障（网络分区、节点宕机、资源耗尽），观察隔离是否生效。
- 复核阶段：通过指标面板（Metrics Dashboard）验证故障域内的关键指标是否在预期范围内。
- 改进阶段：根据演练结果调整隔离策略、扩容资源、优化调度。
| 演练类型 | 验证目标 | 风险控制手段 |
|---|---|---|
| 网络隔离演练 | 租户间网络策略是否生效 | NetworkPolicy、服务网格 mTLS |
| 资源争抢演练 | CPU/内存配额是否硬限制 | ResourceQuota、LimitRange、HPA |
| 节点故障演练 | Pod 是否被正确驱逐到其他故障域 | PodDisruptionBudget、拓扑分布约束 |
| 存储故障演练 | 数据卷是否跨可用区冗余 | PV 反亲和、快照与备份策略 |
常见误区：很多团队只做"功能演练"（验证业务是否正常），不做"故障域隔离演练"。结果线上真实故障发生时，隔离策略形同虚设——熔断未触发、限流未生效、Pod 调度到了同一故障域。指标面板复核是发现这些"假隔离"的关键环节。
1.4 本课程定位
本课程聚焦于多租户故障域隔离演练的指标面板复核与风险控制，面向 SRE、平台工程师、架构师。你将学到：
- 如何设计面向多租户的故障域隔离指标面板（覆盖计算、网络、存储、限流、熔断等维度）。
- 如何通过演练数据复核隔离策略是否真正生效，识别"假隔离"与"盲区"。
- 如何基于复核结果制定风险控制措施，形成可度量的隔离能力成熟度模型。
前置要求：建议具备 Kubernetes 基础操作经验，了解 Pod、Namespace、NetworkPolicy、ResourceQuota 等核心概念。无需精通混沌工程，但需要理解故障注入的基本原理。