1. 课程导论与背景：可靠性评审在可观测性中的核心价值，OpenTelemetry 自助目录的愿景与挑战
1.1 可靠性评审：从“事后灭火”到“事前防御”
在微服务与云原生架构下，系统故障的根因往往隐藏在数十个服务、数百个依赖与海量指标、链路、日志的交织中。传统的可观测性建设常陷入“数据多、洞察少”的困境——团队投入大量资源采集遥测数据，却缺乏一套系统化的机制来验证这些数据是否真正服务于可靠性目标。
可靠性评审（Reliability Review） 正是填补这一空白的关键实践。它并非一次性的架构审查，而是一个持续、结构化的评估流程，旨在回答三个核心问题：
- 覆盖度：关键业务路径是否已被可观测性数据完整覆盖？
- 有效性：现有的告警、仪表盘、SLO 是否能够准确反映真实用户体验与系统健康度？
- 可操作性：当故障发生时，团队能否基于现有数据在 MTTR 目标内完成定位与恢复？
1.2 可观测性成熟度模型：评审的锚点
为了量化评审效果，我们引入一个四阶段成熟度模型。该模型将作为后续课程中评估组织可观测性水平的基础框架。
| 阶段 | 名称 | 特征 | 可靠性评审介入点 |
|---|---|---|---|
| L1 | 数据采集 | 已接入基础指标、日志，但数据孤岛严重，无统一关联 | 评审数据源完整性、采集稳定性 |
| L2 | 可视化与告警 | 建立了仪表盘和基础告警，但告警风暴频发，误报率高 | 评审告警有效性、仪表盘 SRE 就绪度 |
| L3 | 关联分析 | 实现 Trace、Metric、Log 关联，具备初步根因分析能力 | 评审关联规则、采样策略对故障场景的覆盖 |
| L4 | 自动化闭环 | 基于 SLO 的自动弹性伸缩、故障自愈、变更风险评估 | 评审自动化策略的可靠性边界与回滚机制 |
1.3 OpenTelemetry 自助目录：愿景与架构挑战
OpenTelemetry（OTel） 作为云原生计算基金会（CNCF）的顶级项目，已成为遥测数据采集与传输的事实标准。然而，标准化的协议并不天然等于标准化的实践。在大型组织中，不同团队对 OTel 的使用方式千差万别：有的团队过度采集导致成本失控，有的团队遗漏关键 Span 属性导致链路断裂，有的团队自定义 Resource 标签导致数据无法关联。
自助目录（Self-Service Catalog） 的愿景是：将 OTel 的最佳实践、组织内部的可靠性标准、以及经过评审验证的配置模板，封装为一套可搜索、可复用、可治理的“可观测性组件市场”。开发团队无需从零开始配置 OTel SDK，而是通过目录选择符合其服务可靠性等级的预置方案。
这一愿景面临的核心挑战包括：
- 标准化与灵活性的平衡：目录不能过于僵化，扼杀团队的创新需求；也不能过于松散，失去治理意义。
- 评审流程的嵌入：如何将可靠性评审自然地融入目录的“发布-使用-反馈”生命周期，而非成为额外的审批负担。
- 多租户与成本治理：在共享的 OTel Collector 和 Backend 集群中，如何通过目录实现租户级别的数据隔离与成本分摊。
- 版本管理与向后兼容：OTel 规范本身仍在快速演进，目录中的组件如何平滑升级，避免破坏现有服务的遥测管道。
1.4 课程核心脉络：从评审到目录的闭环
本课程将围绕以下主线展开，每一章都对应一个可独立交付的实践模块：
- 可靠性评审方法论：定义评审的输入（SLO、错误预算、故障演练报告）、评审流程（周会、变更触发、事故后复盘）以及评审输出（改进项、风险登记册）。
- OTel 数据模型与语义约定：深入 Resource、Span、Metric、Log 的语义约定，这是目录模板标准化的技术基础。
- 目录架构设计：包括目录的数据模型（模板、策略、版本、租户）、API 设计（搜索、订阅、审批）、以及与 OTel Collector 的集成模式。
- 评审驱动的目录治理：如何将评审结果自动转化为目录策略的更新（例如：提升某个组件的采样率、强制添加某个 Span 属性）。
- 案例实战：基于开源项目（如 Backstage、OTel Operator）构建最小可行目录，并模拟一次完整的可靠性评审循环。
1.5 本章小结：为什么从“评审”开始？
在可观测性领域，我们往往过度关注“如何采集更多数据”，而忽略了“如何确保采集到的数据是正确的、有用的、可行动的”。可靠性评审正是这一质量保障的核心机制。OpenTelemetry 自助目录则提供了将评审结果规模化、资产化的技术载体。
接下来的章节，我们将首先深入可靠性评审的具体执行方法，并同步搭建一个轻量级的目录原型。请准备好你的 OTel 环境和 SRE 思维——这不是一次理论课，而是一场工程实践。