2. 平台工程基础：内部开发者平台(IDP)架构、平台工程与DevOps/SRE的关系、平台成熟度模型
2.1 内部开发者平台（IDP）核心架构
内部开发者平台（Internal Developer Platform, IDP）是平台工程的核心交付物。它并非单一工具，而是一套由平台团队构建和维护的技术层，旨在通过抽象基础设施复杂性、提供自助式服务能力，降低开发者的认知负荷，同时保障组织级的治理与合规要求。
关键认知： IDP 不是“开发者门户”（如 Backstage、Port），门户是 IDP 的“前端界面”；IDP 本身包含门户、编排引擎、基础设施抽象层、黄金路径模板以及可观测性后端。
一个典型的 IDP 架构包含以下核心组件：
| 组件层 | 职责 | 典型技术选型 |
|---|---|---|
| 开发者门户 | 服务目录、自助申请、文档聚合、API 调用入口 | Backstage, Port, Cortex |
| 编排引擎 | 工作流执行、资源编排、环境生命周期管理 | Terraform, Crossplane, Pulumi, Argo Workflows |
| 黄金路径模板 | 预定义的应用脚手架、CI/CD 流水线、基础设施模板 | Cookiecutter, Copier, Backstage Scaffolder |
| 基础设施抽象层 | 统一 API 屏蔽多云/混合云差异，提供 IaC 标准化 | Crossplane, AWS CDK, Terraform Modules |
| 可观测性后端 | 统一日志、指标、链路追踪，提供 SLO 仪表盘 | Grafana, Prometheus, Loki, Tempo, Datadog |
| 权限与治理引擎 | RBAC/ABAC、策略即代码、合规检查、配额管理 | Open Policy Agent, Kyverno, Vault |
2.2 平台工程与 DevOps / SRE 的关系
平台工程并非取代 DevOps 或 SRE，而是对两者在规模化场景下的能力补充与组织级抽象。三者形成互补的“三位一体”协作模型：
| 维度 | DevOps | SRE | 平台工程 |
|---|---|---|---|
| 核心关注 | 文化 + 流程 + 自动化 | 可靠性 + 可观测性 + 运维工程化 | 开发者体验 + 抽象 + 自助服务 |
| 主要产出 | CI/CD 流水线、协作规范 | SLO/SLI、错误预算、事故响应流程 | IDP、黄金路径、开发者门户 |
| 服务对象 | 整个交付团队 | 服务所有者 + 值班团队 | 应用开发者 + 内部用户 |
| 与平台工程的关系 | 平台工程将 DevOps 实践固化为可复用的平台能力 | 平台工程将 SRE 的可靠性需求嵌入黄金路径 | — |
实践映射： 在 SRE 值班台场景中，平台工程通过 IDP 提供“一键创建可观测仪表盘”、“自动生成事故复盘报告”、“自助扩容/回滚”等能力，将 SRE 的重复性操作封装为开发者可调用的 API，从而降低值班负担。
2.3 平台成熟度模型
平台工程并非一蹴而就。业界通常将平台成熟度划分为 5 个阶段，帮助组织评估当前状态并规划演进路径：
| 成熟度级别 | 名称 | 关键特征 | 典型痛点 |
|---|---|---|---|
| Level 1 | 临时脚本 | 运维人员编写脚本手动操作；无标准化；知识仅存于个人 | 单点故障、知识流失、操作不可审计 |
| Level 2 | 工具链集成 | 引入 CI/CD、监控、IaC 工具；但工具间缺乏统一编排 | 工具碎片化、上下文切换频繁、学习成本高 |
| Level 3 | 内部平台雏形 | 构建统一门户；提供黄金路径模板；初步自助服务能力 | 平台团队成为瓶颈、模板灵活性不足 |
| Level 4 | 产品化平台 | 平台作为产品运营；有明确的用户反馈闭环；SLA 保障 | 跨团队协作成本、平台演进与业务需求对齐 |
| Level 5 | 自适应平台 | 平台具备智能推荐、自动修复、动态治理能力；AI 辅助 | 技术复杂度高、组织文化需高度适配 |
常见误区： 很多团队试图直接从 Level 1 跳到 Level 4，跳过工具集成和平台雏形阶段，导致平台与组织实际能力脱节，最终被开发者弃用。建议按成熟度模型逐步演进，每阶段至少运行 1-2 个迭代周期。
在 SRE 值班台场景中，平台成熟度直接影响值班效率：
- Level 1-2： 值班人员需手动登录多套系统排查问题，平均 MTTR 较长，且容易遗漏关键指标。
- Level 3： 值班台可通过 IDP 门户一键查看服务拓扑、运行日志、SLO 状态，自助执行常见运维操作。
- Level 4-5： 平台可自动关联告警与变更事件，推荐修复方案，甚至自动执行回滚或扩容，值班人员只需审批或兜底。
评估平台成熟度时，建议从以下四个维度进行自评：
- 开发者体验： 从申请资源到上线部署需要多少步骤？平均等待时间是多少？
- 自动化覆盖率： 日常运维操作中，自动化完成的比例是多少？
- 治理与合规： 权限管理、成本控制、安全策略是否通过平台统一执行？
- 可观测性集成： 是否所有服务都能通过统一界面查看 SLO、日志、链路和告警？
推荐实践： 每季度进行一次平台成熟度评估，将结果可视化并同步给所有利益相关者。使用“平台成熟度雷达图”展示四个维度的得分，帮助团队聚焦改进方向。