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

1. 课程导论：SLO驱动变更失败率的概念、为什么需要服务目录、课程目标与学习路径

1.1 从可用性到可靠性：SLO 驱动变更失败率的提出

传统运维关注“系统是否可用”，通常用 Uptime（如 99.9%）来衡量。但在微服务和云原生架构下，变更（发布、配置修改、扩缩容）是导致故障的首要原因。单纯监控可用性无法提前发现变更引入的风险。

SLO（Service Level Objective，服务等级目标） 驱动变更失败率的核心思想是：
将每一次变更对服务 SLI（Service Level Indicator） 的实时影响作为判断变更是否成功的依据。如果变更导致 SLI 在短时间内（如 5 分钟）偏离 SLO 阈值，则判定为 变更失败。

  关键公式：

  变更失败率 = （导致 SLI 违反 SLO 的变更次数） / （总变更次数） × 100%

这一指标比“回滚率”更敏感、更客观，因为它直接关联用户体验，而非仅依赖运维人员是否手动回滚。

1.2 为什么需要服务目录？

在拥有数百个微服务、数千个实例的大型系统中，如果没有一个统一的 服务目录（Service Catalog），SLO 驱动变更失败率将面临三大障碍：

障碍	具体表现	服务目录的解决方案
数据孤岛	SLI 数据分散在 Prometheus、Datadog、ELK 等不同平台，无法关联变更事件。	统一注册 SLI 数据源、变更事件源，建立标准化元数据模型。
依赖关系不透明	一个上游服务的变更可能影响下游多个服务，但缺乏拓扑感知。	服务目录维护服务依赖图（Service Dependency Graph），支持级联影响分析。
SLO 归属混乱	同一个 SLO 可能被多个团队共用，变更失败后难以确定责任方。	每个服务在目录中绑定唯一的 SLO 和 Owner，变更失败自动告警到对应团队。

实践建议： 服务目录不是 CMDB 的简单替代，而是以“SLO 可观测性”为核心，将变更、指标、依赖、团队四者关联起来的元数据平台。

1.3 核心概念关系图

下图展示了 SLO 驱动变更失败率在服务目录中的核心数据流与判定逻辑：

1.4 课程目标

完成本课程后，你将能够：

设计并落地 基于 SLO 的变更失败率指标体系，覆盖从指标采集到告警的全链路。
构建服务目录 作为故障排查的元数据底座，实现服务依赖、SLO 归属、变更事件的统一管理。
建立故障排查方法论，在变更失败发生时，通过服务目录快速定位根因，缩短 MTTR（平均修复时间）。
量化变更风险，通过变更失败率趋势指导发布节奏和回滚策略。

1.5 学习路径与章节地图

课程共 30 章，分为四个阶段：

阶段	章节范围	核心产出
基础篇	第 1-8 章	SLO/SLI 概念、变更失败率公式、服务目录数据模型
构建篇	第 9-16 章	服务目录平台搭建、SLI 采集管道、变更事件集成
排查篇	第 17-24 章	故障树分析、依赖拓扑追踪、根因定位算法
运营篇	第 25-30 章	变更失败率看板、SLO 复盘、持续改进机制

前置要求： 建议学员具备基本的 Prometheus/Grafana 使用经验，了解微服务架构和 REST API 概念。无需精通编程，但理解 YAML/JSON 配置格式会有帮助。

1.6 本章小结

SLO 驱动变更失败率将运维视角从“事后可用性”转向“变更中实时健康度”。服务目录是这一体系落地的关键基础设施，它解决了数据孤岛、依赖不透明、SLO 归属混乱三大问题。接下来的课程将逐步带你从理论走向工程实现。