2. 自助目录概念

2.1 什么是自助服务目录

自助服务目录（Self-Service Catalog）是平台工程中面向开发者的统一入口，它将底层基础设施、中间件、运行时环境、安全策略等平台能力封装为“产品化”的服务项，开发者无需理解底层实现细节，即可通过图形化界面或 API 按需申请、配置和使用平台资源。

从本质上讲，自助目录是平台团队与开发者之间的契约层：平台团队定义“能提供什么”，开发者选择“需要什么”，整个过程由平台引擎自动编排交付。

2.2 自助目录在平台工程中的定位

在平台工程的四层架构中，自助目录位于用户体验层与编排层之间，是连接开发者与平台能力的桥梁。下表展示了各层职责与目录的定位：

平台工程强调“开发者体验优先”，自助目录正是这一理念的落地载体——它将平台能力从“文档驱动”转变为“目录驱动”，开发者只需在目录中搜索、选择、填写参数，即可获得标准化的服务实例。

2.3 自助目录的核心能力

一个成熟的自助目录需要覆盖四个关键阶段：发现 → 请求 → 交付 → 治理。这四个阶段构成了服务从“可见”到“可用”再到“可管”的完整闭环。

2.3.1 发现——让服务“找得到”

发现能力是自助目录的入口。开发者需要像逛应用商店一样浏览和搜索服务。平台团队应提供：

• 分类体系： 按用途（数据库、消息队列、CI/CD）、按环境（开发、测试、生产）、按团队（前端、后端、数据）等多维度组织。
• 全文搜索： 支持服务名称、描述、标签的模糊匹配。
• 服务详情： 每个服务项包含描述、版本、SLA、费用归属、使用文档链接。

2.3.2 请求——让申请“填得对”

请求阶段将开发者的需求转化为结构化的参数。平台团队需要设计：

• 参数模板： 使用 JSON Schema 或 OpenAPI 规范定义每个服务的输入参数，包括必填项、默认值、取值范围。
• 配额校验： 在提交前检查开发者是否还有剩余配额（如 CPU 核数、存储容量、数据库实例数）。
• 审批流： 支持自动审批（配额内）、人工审批（超配额或生产环境）、多级审批（涉及安全合规）。

// 参数模板示例（JSON Schema）
{
  "service": "postgresql-14",
  "parameters": {
    "instance_name": { "type": "string", "minLength": 3, "maxLength": 32 },
    "cpu": { "type": "integer", "enum": [1, 2, 4, 8], "default": 2 },
    "memory_gb": { "type": "integer", "enum": [2, 4, 8, 16], "default": 4 },
    "storage_gb": { "type": "integer", "minimum": 10, "maximum": 500, "default": 50 },
    "environment": { "type": "string", "enum": ["dev", "staging", "prod"] }
  }
}

2.3.3 交付——让服务“开得快”

交付是自助目录的价值兑现环节。平台引擎接收到请求后，自动执行编排流水线：

• 基础设施即代码： 调用 Terraform/Crossplane 模块创建云资源或 K8s 命名空间。
• 配置注入： 自动生成连接字符串、密钥、环境变量，并注入到开发者的项目空间。
• 状态通知： 通过 Webhook、邮件或即时通讯工具通知开发者服务已就绪。

2.3.4 治理——让资产“管得住”

治理能力决定了自助目录能否长期健康运行。平台团队需要关注：

• 成本归属： 每个服务实例关联到项目/团队/成本中心，支持按月度生成账单。
• 生命周期管理： 自动检测闲置资源，发送回收提醒；支持开发者自助销毁或延期。
• 版本升级： 当服务模板更新时，目录应提示现有实例是否可原地升级，并提供升级窗口。

2.4 自助目录的成熟度模型

不同组织的平台工程实践阶段不同，自助目录的成熟度也呈现阶梯式演进：