1. 课程导论：平台工程与SRE的关系、值班台服务目录的价值、课程目标与受众
1.1 平台工程与SRE：从对立到共生
在云原生与微服务架构大规模普及的今天，平台工程（Platform Engineering）与站点可靠性工程（SRE）常被误认为是两条平行线。实际上，二者在组织能力上形成了清晰的“构建-运行”闭环：平台工程负责提供内部开发者平台（IDP），SRE 则基于该平台保障生产环境的稳定性与可观测性。
核心观点：平台工程是 SRE 的“上游基础设施”，SRE 是平台工程的“最终用户与质量守门人”。没有平台工程，SRE 的运维工作将陷入重复造轮子；没有 SRE，平台工程将失去可靠性基线。
下表从五个关键维度对比二者的定位差异与协作关系：
| 维度 | 平台工程 | SRE | 协作关系 |
|---|---|---|---|
| 核心目标 | 提升开发者体验与交付效率 | 保障服务可用性与可靠性 | 平台为 SRE 提供自助化运维能力 |
| 主要产出 | 内部开发者平台（IDP）、服务目录、黄金路径 | SLI/SLO/SLI 仪表盘、告警规则、故障预案 | SRE 将可靠性需求反馈到平台建设中 |
| 关注指标 | 部署频率、变更前置时间、开发者满意度 | MTTR、MTBF、错误预算消耗率 | 平台通过标准化减少 SRE 的认知负载 |
| 工作模式 | 产品化思维、抽象与封装 | 值班轮转、事件响应、容量规划 | 值班台是 SRE 使用平台的核心入口 |
| 典型工具 | Backstage、Kratix、Crossplane | PagerDuty、Grafana、Prometheus | 服务目录成为工具链的“统一数据平面” |
1.2 值班台服务目录：SRE 的“作战地图”
在传统 SRE 值班场景中，新接手值班的工程师往往需要花费 30 分钟以上翻阅 Wiki、Confluence 或聊天记录，才能搞清楚“这个告警属于哪个服务”、“该找谁”、“有没有现成的预案”。值班台服务目录正是为了解决这一痛点而设计的统一信息枢纽。
一句话定义：值班台服务目录是一个面向 SRE 值班场景的、结构化的服务元数据聚合层，它将服务名称、负责人、依赖关系、告警规则、运行手册（Runbook）等关键信息以标准化格式呈现，帮助值班人员快速定位问题并执行恢复操作。
服务目录在值班台中的核心价值体现在以下四个层面：
- 降低认知负载：将分散在多个系统中的服务信息统一收敛，值班人员无需切换多个工具即可获取上下文。
- 加速事件响应：通过关联告警与 Runbook，将 MTTR 从“小时级”压缩到“分钟级”。
- 保障交接质量：标准化的服务目录格式确保每次值班交接时信息不丢失、不模糊。
- 驱动持续改进：通过记录每次值班对目录的查询与修改，反向优化服务元数据的准确度。
1.3 课程目标与受众
本课程旨在帮助平台工程团队与 SRE 团队建立一套可落地、可扩展、可度量的值班台服务目录体系。课程内容覆盖从设计原则、数据模型、技术选型到持续运营的全生命周期。
重要提示：本课程不是纯理论课程。每章均包含可执行的代码片段、配置示例以及真实案例复盘。建议学员在学习过程中同步搭建实验环境。
课程目标
- 理解平台工程与 SRE 在服务目录场景下的协作模型。
- 掌握值班台服务目录的元数据模型设计方法（服务、组件、依赖、SLO、Runbook）。
- 学会使用 Backstage、Kratix 等工具构建服务目录的实战技能。
- 建立服务目录的持续治理与质量度量机制。
目标受众
| 角色 | 学习收益 |
|---|---|
| 平台工程师 | 掌握服务目录的设计范式与工程化落地方法 |
| SRE / 运维工程师 | 获得值班场景下的统一信息视图与快速响应能力 |
| 技术管理者 | 理解服务目录对组织效率与可靠性的杠杆效应 |
| DevOps 工程师 | 打通 CI/CD 与值班运维的数据链路 |
课程大纲速览
- 课程导论（本章）—— 平台工程与 SRE 的关系、服务目录价值
- 服务目录元数据模型设计
- 基于 Backstage 构建服务目录
- 服务目录与告警、Runbook 的集成
- 服务目录的持续治理与质量度量
- 案例复盘与最佳实践
前置要求：建议学员具备基础的 Kubernetes 操作经验，了解 SRE 核心概念（SLI/SLO/错误预算），并熟悉至少一种编程语言（Python/Go/TypeScript）。