📚 课程目录第1章课程导论

1. 课程导论：可靠性评审与混沌工程基线核验的关系、课程目标与适用人群

1.1 为什么需要“可靠性评审驱动的混沌工程基线核验”？

在云原生与微服务架构日益复杂的今天，系统故障不再是“会不会发生”的问题，而是“何时发生、如何快速恢复”的问题。传统的可靠性评审（Reliability Review）往往停留在架构文档审查、SLA 指标核对和人工经验判断层面，缺乏对系统真实韧性边界的量化验证。而混沌工程（Chaos Engineering）虽然能够主动注入故障、暴露系统弱点，但若没有明确的可靠性基线作为参照，实验结论容易陷入“为了混沌而混沌”的盲目状态。

本课程提出的核心理念是：将可靠性评审的量化指标（如错误预算、MTTR、P99 延迟）作为混沌工程实验的输入条件，通过基线核验环境对系统进行可重复、可度量的韧性验证，最终形成“评审→实验→校准→再评审”的闭环。

  核心命题： 可靠性评审提供“应该达到什么水平”的目标，混沌工程基线核验提供“实际达到什么水平”的证据。两者结合，才能从“感觉可靠”走向“可证明可靠”。

1.2 可靠性评审与混沌工程基线核验的关系

两者并非替代关系，而是输入-验证-反馈的协同关系。下表从多个维度对比了传统可靠性评审与引入混沌工程基线核验后的差异：

对比维度	传统可靠性评审	混沌工程基线核验
输入依据	架构文档、历史故障记录、SLA 承诺	可靠性评审输出的量化基线（错误预算、SLO 阈值）
验证手段	人工审查、走查、静态分析	主动故障注入、压力测试、可观测性数据采集
输出结果	评审报告、风险清单、改进建议	基线核验报告、韧性评分、失效模式图谱
可重复性	低（依赖评审人员经验）	高（环境与参数可版本化、可自动化执行）
反馈闭环	通常为一次性活动	持续集成/持续交付（CI/CD）门禁，每次变更触发核验

下图展示了可靠性评审与混沌工程基线核验在系统生命周期中的协同流程：

实践提示： 在首次建立基线核验环境时，建议从可靠性评审中选取1~2 个核心 SLO（如 P99 延迟 ≤ 200ms、错误率 ≤ 0.1%）作为混沌实验的通过/失败判据，避免一开始就追求全面覆盖。

1.3 课程目标

完成本课程学习后，学员将能够：

理解可靠性评审与混沌工程基线核验的协同原理，掌握将评审指标转化为可执行实验参数的方法。
独立搭建基线核验环境，包括混沌工程平台（如 Chaos Mesh、Litmus）、可观测性栈（Prometheus + Grafana）、以及参数配置中心。
编写与维护基线核验参数配置，涵盖故障注入类型、持续时间、目标服务、熔断阈值等关键参数。
执行基线核验并解读报告，能够根据核验结果反向校准可靠性评审中的 SLO 设定。
将基线核验集成到 CI/CD 流水线，实现每次代码变更后的自动韧性验证。

1.4 适用人群

本课程面向以下三类核心角色：

角色	关注点	前置要求
可靠性架构师 / SRE	如何用量化手段验证系统韧性，建立可审计的可靠性证据链	熟悉 SLO/SLI/错误预算概念，有基本的 Linux 和 Kubernetes 操作经验
混沌工程工程师	如何将混沌实验从“随机探索”升级为“基线驱动”的标准化流程	至少使用过一种混沌工程工具，了解故障注入的基本原理
平台工程 / DevOps 工程师	如何在 CI/CD 流水线中嵌入可靠性门禁，实现自动化核验	有 Jenkins/GitLab CI/GitHub Actions 等流水线工具使用经验

注意： 本课程不包含基础 Kubernetes 安装与运维教学。学员应具备独立部署和管理 Kubernetes 集群的能力，或能够使用托管的 Kubernetes 服务（如 AKS、EKS、GKE）。

1.5 课程内容概览

全课程共 30 章，按以下四大模块组织：

模块一（第 1~5 章）： 基础概念与关系建立——可靠性评审、混沌工程、基线核验三者的理论框架与协同模型。
模块二（第 6~15 章）： 环境搭建与参数配置——从零搭建基线核验环境，涵盖混沌工程平台、可观测性栈、参数配置中心的部署与调优。
模块三（第 16~25 章）： 实验设计与执行——基于可靠性评审指标设计混沌实验，编写参数配置模板，执行核验并生成报告。
模块四（第 26~30 章）： 集成与持续改进——将基线核验集成到 CI/CD 流水线，建立评审-核验-校准的自动化闭环。

下图展示了四大模块之间的依赖关系与学习路径：

学习建议： 如果你已经具备混沌工程基础，可以直接从第 6 章开始；但建议至少阅读第 2~3 章，确保对“可靠性评审驱动的基线核验”这一核心理念有统一理解。