2. 平台工程与 IDP 基础：什么是内部开发者平台（IDP），平台工程的核心原则
2.1 内部开发者平台（IDP）的定义
内部开发者平台（Internal Developer Platform, IDP）是平台工程团队构建的一套技术产品，它通过抽象底层基础设施的复杂性，为开发者提供一条自助式的黄金路径（Golden Path），使其能够快速、安全地交付和运行应用。IDP 不是单一的工具，而是一个由多个能力层组成的乐高式系统。
关键区分：IDP ≠ 门户（Portal）。门户是 IDP 的 UI 界面，而 IDP 本身包含 API、CLI、自动化引擎、策略引擎和制品仓库等后端能力。
2.2 IDP 的核心能力层
一个成熟的 IDP 通常包含以下五个能力层，每一层都对应着平台工程的核心原则：
| 能力层 | 核心职责 | 平台工程原则 |
|---|---|---|
| 开发者门户 | 提供自助服务目录、文档、API 目录 | 降低认知负载 |
| 编排与自动化 | 执行环境创建、CI/CD 流水线、配置变更 | 标准化与自动化 |
| 策略与治理 | 执行合规检查、安全基线、成本配额 | 内置安全与合规 |
| 制品与交付 | 管理制品签名、版本、依赖扫描 | 可追溯与可审计 |
| 基础设施抽象 | 屏蔽 K8s、IaaS、中间件细节 | 抽象复杂性 |
2.3 平台工程的核心原则
平台工程并非简单的工具堆叠，而是遵循以下四项核心原则来构建 IDP：
- 降低认知负载（Reduce Cognitive Load）：平台应封装基础设施决策，让开发者只需关注业务代码和配置，而非网络、存储、集群版本等细节。
- 标准化与自动化（Standardization & Automation）：通过模板、策略和流水线，确保所有环境、部署和配置变更遵循统一标准，消除“雪花”环境。
- 内置安全与合规（Security & Compliance by Default）：安全策略（如制品签名、镜像扫描、网络策略）作为平台默认行为嵌入，而非事后检查。
- 可追溯与可审计（Traceability & Auditability）：所有操作（谁、什么时间、对哪个制品、执行了什么变更）均记录在不可篡改的日志或链路上。
2.4 IDP 制品签名链路与权限变更风险
在本课程关注的制品签名链路场景中，IDP 的核心原则直接映射为以下风险控制点：
- 签名密钥管理：谁有权访问签名私钥？密钥轮换是否自动化？
- 签名策略执行：平台是否强制要求所有制品必须经过签名才能进入生产环境？
- 权限变更审计：当开发者或 CI 流水线的签名权限发生变更时，平台是否自动触发审批和通知？
- 链路完整性：从代码提交 → 构建 → 签名 → 存储 → 部署，整条链路是否可被篡改？
常见误区：许多团队将 IDP 等同于“开发者门户”，忽略了底层的策略引擎和制品签名链路。这导致权限变更缺乏管控，签名密钥可能被滥用，最终破坏软件供应链安全。
2.5 IDP 制品签名链路架构图
下图展示了 IDP 中制品签名链路的核心组件与权限变更风险点：
2.6 平台工程 vs. 传统 DevOps 对比
理解 IDP 的最佳方式是与传统 DevOps 模式进行对比：
| 维度 | 传统 DevOps | 平台工程（IDP） |
|---|---|---|
| 基础设施 | 每个团队自行管理 IaC 和集群 | 平台团队提供抽象后的黄金路径 |
| 安全策略 | 事后检查，依赖人工审核 | 策略即代码，内置在流水线中 |
| 制品签名 | 可选步骤，常被跳过 | 强制签名，未签名制品无法部署 |
| 权限变更 | 手动审批，缺乏审计 | 自动化审批，全链路可追溯 |
| 开发者体验 | 高认知负载，需了解底层细节 | 低认知负载，专注业务代码 |
2.7 小结：IDP 与制品签名链路的关系
在本课程中，IDP 是承载制品签名链路的容器。平台工程的核心原则——尤其是内置安全和可追溯——直接决定了签名链路的健壮性。当权限变更发生时，IDP 的策略引擎必须能够：
- 检测：识别签名密钥或角色的变更请求。
- 评估：根据预定义策略判断变更是否合规。
- 执行：自动批准、拒绝或触发人工审批。
- 记录：将变更事件写入不可篡改的审计日志。