📚 课程目录第3章平台工程与可观测性

3. 平台工程与可观测性：可观测性在平台工程中的角色、三大支柱与可观测性驱动开发

3.1 可观测性在平台工程中的核心角色

在平台工程中，可观测性（Observability）不再是运维团队的专属工具，而是平台自身必须内建的核心能力。平台团队通过可观测性向开发者提供“自助式”的洞察能力，让开发者无需登录服务器或请求运维权限，即可独立诊断应用问题、优化性能、理解系统行为。

可观测性在平台工程中的三大角色：

角色	说明	平台工程价值
自助诊断	开发者通过平台提供的仪表盘、日志查询、链路追踪，自主定位故障根因	降低MTTR（平均修复时间），减少对平台团队的依赖
SLO 反馈闭环	平台内置服务等级目标（SLO）监控，实时反馈服务质量	驱动开发者关注可靠性，形成“开发-部署-观测-改进”循环
成本与资源可视化	展示每个服务/团队的资源消耗、调用量、错误预算	支持成本分摊、容量规划、资源优化决策

关键认知： 平台工程中的可观测性不是“监控的升级版”，而是将观测数据作为平台API的一部分，让开发者通过自助目录（Service Catalog）直接消费，实现“数据驱动开发”。

3.2 可观测性三大支柱：日志、指标、链路

可观测性领域公认的三大数据支柱——日志（Logs）、指标（Metrics）、链路（Traces）——在平台工程中各自承担不同的职责，且需要协同工作才能形成完整的观测视图。

3.2.1 三大支柱对比

支柱	数据类型	典型用途	平台工程中的自助方式
日志	离散事件文本，带时间戳	错误排查、审计、详细行为记录	自助日志查询面板 + 结构化日志搜索
指标	聚合数值，时间序列	性能监控、告警、SLO计算	预定义仪表盘 + 自定义指标查询
链路	请求全路径，span 树	分布式调用分析、瓶颈定位	一键追踪请求 + 服务依赖拓扑图

3.2.2 三大支柱协同关系

单一支柱无法完整描述系统状态。例如：指标显示延迟升高（指标），需要查看具体请求的链路追踪（链路），再深入某个慢 span 的上下文日志（日志），才能定位根因。平台工程需要将三者关联，形成“指标→链路→日志”的下钻路径。

3.3 可观测性驱动开发（ODD）

可观测性驱动开发（Observability-Driven Development, ODD）是一种将可观测性内建到软件开发生命周期中的实践方法。其核心理念是：在编写代码的同时，定义如何观测代码的行为，而不是在部署后再补充监控。

3.3.1 ODD 的核心原则

先定义观测契约：在开发新功能前，明确该功能需要暴露哪些日志、指标和链路信息。
代码即观测：使用 OpenTelemetry SDK 在代码中直接埋点，将观测数据作为 API 的一部分。
测试观测性：在 CI/CD 流水线中验证观测数据是否正确生成，例如断言某个关键路径是否产生了正确的 Span。
自助消费：平台提供自助目录，开发者可随时查询自己服务的观测数据，无需等待运维配置。

3.3.2 ODD 在平台工程中的实践流程

阶段	活动	平台工程支持
设计	定义服务的关键业务指标和错误场景	提供观测模板和最佳实践文档
编码	使用 OpenTelemetry API 添加埋点	提供自动注入的 SDK 和配置中心
测试	验证观测数据是否按预期生成	提供测试框架中的观测断言工具
部署	自动关联服务版本与观测数据	通过 Service Catalog 注册服务元数据
运行	自助查询、告警、SLO 跟踪	统一仪表盘 + 自助查询入口

  实践案例： 某电商平台团队在开发“订单创建”功能时，提前定义了三个关键观测点：① 订单创建成功/失败的指标（counter）；② 订单处理全流程的链路追踪（trace）；③ 异常订单的详细错误日志（structured log）。上线后，通过平台自助目录直接查看这些数据，上线当天即发现一个第三方支付接口的超时问题，MTTR 从 2 小时缩短至 15 分钟。

3.4 平台工程中的可观测性架构

下图展示了平台工程中可观测性数据从产生到消费的完整架构，突出 OpenTelemetry 作为统一数据采集层的核心位置。

3.5 本章小结

可观测性是平台工程中开发者自助服务的核心能力，帮助开发者独立诊断问题、跟踪 SLO、优化成本。
三大支柱（日志、指标、链路）各有侧重，必须协同工作才能形成完整的观测视图。
可观测性驱动开发（ODD）将观测内建到开发流程中，从设计阶段即定义观测契约。
OpenTelemetry 作为统一采集层，是平台工程实现可观测性自助集成的关键技术基础。