1. 平台工程与开发者门户全景

在进入生产实践之前，必须先厘清三个高频混用的概念：平台工程（Platform Engineering）、开发者门户（Developer Portal）与内部开发者平台（IDP，Internal Developer Platform）。它们不是同义词，而是同一体系中的三个不同层次：平台工程是一种工程学科与组织实践，IDP 是这套实践交付的产品化能力集合，开发者门户则是 IDP 面向开发者的统一交互入口。理解这三者的关系，决定了后续所有可靠性治理工作的落点。

一、三个概念的定义与关系

平台工程的核心命题是：把基础设施、交付流水线、可观测性、安全合规等能力，以“产品”的方式提供给应用团队，让开发者通过自助服务获得环境与资源，而不是逐一向运维或云团队提工单。它关注的是能力如何被构建、被度量、被持续运营，其成功指标通常包括开发者上手时间、部署频率、变更失败率与平台采用率。

内部开发者平台（IDP）是平台工程的交付物。它由一组能力域组成，典型包括：服务目录与元数据、环境与资源编排、CI/CD 流水线模板、密钥与配置管理、可观测性接入、策略与合规校验。IDP 的关键特征是自助、标准化、可组合——开发者用声明式描述表达意图，平台负责落地。

开发者门户是 IDP 的“门面”与“控制台”。它通常以软件目录（Software Catalog）为核心，把服务、API、文档、流水线、SLO、告警、负责人等信息聚合到同一处，并提供脚手架（Scaffolder）、模板、评分卡（Scorecard）等交互能力。门户本身不产生底层能力，它负责发现、编排与呈现。

三者的关系可以概括为：平台工程提供方法与组织，IDP 提供能力与自动化，门户提供入口与体验。缺少平台工程，门户会退化为静态文档站；缺少门户，IDP 的能力难以被开发者发现和采用；缺少 IDP，门户只是空壳。

二、与 DevOps、SRE、云原生的边界辨析

平台工程经常被误认为“DevOps 的换皮”或“SRE 的别名”，实际上四者关注点不同，但存在明确的协作接口。

DevOps是一组文化与协作原则，强调开发与运维的融合、快速反馈与持续交付。它回答的是“团队如何协作”。平台工程则回答“协作所需的能力由谁、以什么方式提供”。可以说，平台工程是 DevOps 在规模化组织中的一种落地形态：当每个团队都自建流水线、各自维护环境时，重复成本极高，平台工程把这些共性能力收敛为共享产品。

SRE（站点可靠性工程）关注的是生产系统的可靠性，核心工具是 SLO、错误预算、容量规划与故障复盘。它回答的是“系统应该有多可靠、如何度量与保障”。平台工程与 SRE 的交集在于：平台需要把 SLO 定义、告警接入、变更防护等可靠性能力产品化，让应用团队无需从零搭建。本课程以“生产实践与可靠性治理”为核心，正是站在这个交集上：平台不仅要“好用”，还要“可靠”，并且要能治理平台上运行的所有服务。

云原生是一组技术栈与架构范式，包括容器、Kubernetes、服务网格、声明式 API、不可变基础设施等。它回答的是“用什么技术构建”。平台工程通常构建在云原生技术之上，但云原生本身不等于平台工程——把 Kubernetes 交给开发者并不等于提供了平台，反而可能把复杂度直接转嫁给了开发者。平台工程的价值恰恰在于封装云原生的复杂度，通过门户与 IDP 暴露经过抽象的自助能力。

三、为什么本课程以“生产实践与可靠性治理”为核心

概念辨析之后，需要明确课程的落点。平台工程与开发者门户在演示环境中往往表现良好：目录能展示服务、脚手架能生成仓库、流水线能跑通。但一旦进入生产，问题会集中暴露：门户自身的高可用如何保障？目录元数据与实际部署不一致怎么办？平台变更导致批量服务受影响如何止损？SLO 如何在平台上统一接入并驱动告警？权限与密钥如何做到最小化且可审计？

这些问题不是“功能有没有”的问题，而是“可靠性够不够、治理是否闭环”的问题。因此本课程不满足于介绍工具与概念，而是围绕以下对象展开：

• 平台自身的可靠性：门户、目录、编排服务的可用性、性能与降级策略；
• 平台承载服务的可靠性：通过平台统一接入 SLO、告警、变更防护与容量治理；
• 治理闭环：从元数据准确性、策略合规、权限审计到故障复盘与改进；
• 生产实践：真实场景下的参数、配置、判断依据与结果验证方式。