名称: 自服务基础设施 描述: 用于设计基础设施自服务门户、IaC模板或自动化供应系统时使用。涵盖Terraform模块、Pulumi、环境供应和基础设施护栏。 允许工具: 读取、全局匹配、搜索
自服务基础设施
使开发者能够在无需工单的情况下配置基础设施的模式，同时保持治理和控制。
何时使用此技能
- 设计基础设施自服务能力
- 创建可重用的Terraform/Pulumi模块
- 构建环境供应系统
- 实施基础设施护栏
- 减少基础设施请求瓶颈
- 平衡开发者自治与治理
自服务基础
什么是自服务基础设施？
自服务基础设施:
使开发者能够直接配置和管理基础设施，而无需提交工单或等待运维团队。
传统模式:
┌─────────────────────────────────────────────────────────────┐
│ 开发者 → 工单 → 运维审核 → 手动配置 → 完成 │
│ │
│ 时间线: 几天到几周 │
│ 瓶颈: 运维团队容量 │
│ 结果: 影子IT、变通方法、挫折 │
└─────────────────────────────────────────────────────────────┘
自服务模式:
┌─────────────────────────────────────────────────────────────┐
│ 开发者 → 门户/API → 自动配置 → 完成 │
│ │
│ 时间线: 几分钟到几小时 │
│ 瓶颈: 无（自动化） │
│ 结果: 速度、一致性、合规性 │
└─────────────────────────────────────────────────────────────┘
自服务频谱:
├── 完全托管: 点击按钮，获取数据库
├── 基于模板: 从批准的模板自定义
├── 策略约束: 在护栏内编写IaC
└── 完全自由: 任何基础设施（风险高）
最佳点: 基于模板并带有策略护栏
关键好处
自服务好处:
对开发者:
├── 速度: 分钟而非天数
├── 自治: 需要时配置
├── 一致性: 每次相同的基础设施
├── 学习: 更好理解基础设施
└── 所有权: 更多责任，更多控制
对运维:
├── 扩展: 无需更多人处理更多请求
├── 一致性: 自动强制执行标准
├── 聚焦: 专注于平台，而非工单
├── 审计: 清晰的配置记录
└── 合规性: 内置策略执行
对组织:
├── 速度: 更快上市时间
├── 成本: 减少运维开销
├── 治理: 更好的合规姿态
├── 安全: 一致的安全控制
└── 效率: 需要时配置资源
自服务架构
组件架构
自服务基础设施架构:
┌─────────────────────────────────────────────────────────────┐
│ 用户界面 │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ 门户 │ │ CLI │ │ API │ │
│ │ （Web UI） │ │ （Terraform）│ │ （REST/gRPC）│ │
│ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ │
│ └────────────────┼────────────────┘ │
│ │ │
├──────────────────────────┼───────────────────────────────────┤
│ ▼ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 编排层 │ │
│ │ ├── 请求验证 │ │
│ │ ├── 策略评估（OPA/Sentinel） │ │
│ │ ├── 成本估算 │ │
│ │ ├── 审批工作流（如果需要） │ │
│ │ └── 执行编排 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │ │
├──────────────────────────┼───────────────────────────────────┤
│ ▼ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 模板库 │ │
│ │ ├── 数据库模块（RDS、Cloud SQL） │ │
│ │ ├── 计算模块（EKS、GKE、虚拟机） │
│ │ ├── 存储模块（S3、GCS） │
│ │ ├── 网络模块（VPC、子网） │
│ │ └── 复合模块（完整环境） │
│ └─────────────────────────────────────────────────────┘ │
│ │ │
├──────────────────────────┼───────────────────────────────────┤
│ ▼ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 执行引擎 │ │
│ │ ├── Terraform Cloud/Enterprise │
│ │ ├── Pulumi Service │
│ │ ├── Crossplane │
│ │ └── 云原生（CDK、ARM、Deployment Manager） │
│ └─────────────────────────────────────────────────────┘ │
│ │ │
├──────────────────────────┼───────────────────────────────────┤
│ ▼ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 云提供商 │ │
│ │ AWS │ GCP │ Azure │ Kubernetes │ 其他 │
│ └─────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
请求流程
自服务请求流程:
┌─────────────────────────────────────────────────────────────┐
│ 1. 请求 │
│ 开发者: "我需要一个用于暂存的PostgreSQL数据库" │
│ └── 通过门户、CLI或API │
└─────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ 2. 验证 │
│ ├── 用户有权限？ ✓ 团队成员 │
│ ├── 请求格式正确？ ✓ 有效配置 │
│ ├── 在配额内？ ✓ 在团队限制内 │
│ └── 符合策略？ ✓ 允许的实例类型 │
└─────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ 3. 丰富 │
│ ├── 应用默认值 db.t3.medium │
│ ├── 生成名称 myapp-staging-db │
│ ├── 分配网络 staging-vpc │
│ ├── 配置监控 Datadog集成 │
│ └── 估算成本 ~$50/月 │
└─────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ 4. 审批（如果需要） │
│ ├── 自动审批: 暂存、开发 ✓ 自动批准 │
│ ├── 手动审批: 生产 （需要审批） │
│ └── 成本阈值: >$500/月 （需要审批） │
└─────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ 5. 执行 │
│ ├── 生成Terraform 基于模板 │
│ ├── 计划 预览变更 │
│ ├── 应用 创建资源 │
│ └── 验证 健康检查 │
└─────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ 6. 交付 │
│ ├── 连接字符串 → Vault │
│ ├── 通知 → Slack/邮件 │
│ ├── 文档 → 自动生成 │
│ └── 注册 → 服务目录 │
└─────────────────────────────────────────────────────────────┘
IaC模块设计
Terraform模块模式
Terraform模块结构:
组织级模块库:
terraform-modules/
├── 数据库/
│ ├── rds-postgres/
│ │ ├── main.tf
│ │ ├── variables.tf
│ │ ├── outputs.tf
│ │ ├── versions.tf
│ │ ├── README.md
│ │ └── 示例/
│ │ ├── 简单/
│ │ └── 生产/
│ └── elasticache-redis/
├── 计算/
│ ├── eks-cluster/
│ └── ecs-service/
├── 存储/
│ └── s3-bucket/
└── 网络/
└── vpc/
模块设计原则:
1. 有观点的默认值
# variables.tf
variable "instance_class" {
type = string
default = "db.t3.medium" # 合理的默认值
description = "RDS实例类型"
validation {
condition = can(regex("^db\\.(t3|r5|m5)", var.instance_class))
error_message = "仅允许批准的实例系列。"
}
}
2. 最小必要输入
# 只要求不能默认化的内容
variable "name" {
type = string
description = "数据库标识符"
}
variable "environment" {
type = string
description = "环境（开发、暂存、生产）"
}
3. 完整输出
# outputs.tf
output "endpoint" {
description = "数据库连接端点"
value = aws_db_instance.main.endpoint
}
output "connection_secret_arn" {
description = "凭证的ARN秘密"
value = aws_secretsmanager_secret.db_credentials.arn
}
4. 内置最佳实践
# 默认安全加固
resource "aws_db_instance" "main" {
# 始终加密
storage_encrypted = true
# 无公共访问
publicly_accessible = false
# 自动备份
backup_retention_period = var.environment == "prod" ? 30 : 7
# 增强监控
monitoring_interval = 60
}
模块版本控制
模块版本控制策略:
语义版本控制:
├── 主要: 破坏性变更（新必需输入、移除输出）
├── 次要: 新功能（新可选输入、新输出）
└── 补丁: 错误修复（无接口变更）
版本约束:
# 允许自动补丁更新
module "database" {
source = "terraform.company.com/modules/rds-postgres"
version = "~> 2.1.0" # >=2.1.0, <2.2.0
}
# 固定到精确版本（生产）
module "database" {
source = "terraform.company.com/modules/rds-postgres"
version = "= 2.1.3"
}
弃用策略:
┌─────────────────────────────────────────────────────────────┐
│ 模块版本生命周期 │
├─────────────────────────────────────────────────────────────┤
│ 当前（v2.x）: 支持，新功能 │
│ 先前（v1.x）: 支持，仅安全修复 │
│ 弃用（v0.x）: 使用警告，无支持 │
│ 移除: 无法工作 │
│ │
│ 通知: │
│ ├── Slack公告当版本弃用 │
│ ├── terraform plan输出中的警告 │
│ ├── 仪表板显示弃用模块使用 │
│ └── 提供迁移指南 │
└─────────────────────────────────────────────────────────────┘
策略和护栏
策略即代码
策略即代码选项:
1. HashiCorp Sentinel（Terraform Enterprise）
# 要求所有存储加密
import "tfplan/v2" as tfplan
s3_buckets = filter tfplan.resource_changes as _, rc {
rc.type is "aws_s3_bucket" and
rc.mode is "managed" and
(rc.change.actions contains "create" or
rc.change.actions contains "update")
}
encryption_enabled = rule {
all s3_buckets as _, bucket {
bucket.change.after.server_side_encryption_configuration
is not null
}
}
main = rule { encryption_enabled }
2. Open Policy Agent（OPA）
# Kubernetes的Rego策略
package kubernetes.admission
deny[msg] {
input.request.kind.kind == "Pod"
container := input.request.object.spec.containers[_]
not container.securityContext.runAsNonRoot
msg := "容器必须以非root用户运行"
}
3. 云原生策略
# AWS服务控制策略
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "RequireEncryption",
"Effect": "Deny",
"Action": ["s3:CreateBucket"],
"Resource": "*",
"Condition": {
"StringNotEquals": {
"s3:x-amz-server-side-encryption": "AES256"
}
}
}]
}
护栏类别
基础设施护栏:
1. 安全护栏
├── 要求加密（静态、传输中）
├── 默认无公共访问
├── 必需的安全组
├── IAM角色要求
└── 漏洞扫描
2. 成本护栏
├── 实例类型限制
├── 存储大小限制
├── 必需的成本标签
├── 预算阈值
└── 大型资源审批
3. 合规护栏
├── 允许的区域（数据驻留）
├── 必需的日志记录
├── 备份要求
├── 保留策略
└── 审计追踪要求
4. 运营护栏
├── 命名约定
├── 必需标签（所有者、成本中心）
├── 每团队资源配额
├── 监控要求
└── 删除保护
护栏实施:
┌─────────────────────────────────────────────────────────────┐
│ 护栏时机 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 预计划（最快反馈）: │
│ ├── 验证terraform文件 │
│ ├── 静态分析（tfsec、checkov） │
│ └── 模块版本检查 │
│ │
│ 后计划（资源感知）: │
│ ├── OPA/Sentinel策略评估 │
│ ├── 成本估算 │
│ └── 影响半径评估 │
│ │
│ 后应用（验证）: │
│ ├── 配置验证 │
│ ├── 安全扫描 │
│ └── 合规审计 │
│ │
└─────────────────────────────────────────────────────────────┘
环境供应
环境模板
环境供应:
环境类型:
┌─────────────────────────────────────────────────────────────┐
│ 开发环境 │
│ ├── 目的: 个人开发者测试 │
│ ├── 生命周期: 几小时到几天 │
│ ├── 资源: 最小（最小实例） │
│ ├── 数据: 合成或匿名化 │
│ └── 审批: 无（在配额内） │
├─────────────────────────────────────────────────────────────┤
│ 暂存环境 │
│ ├── 目的: 集成测试、QA │
│ ├── 生命周期: 每个服务持久化 │
│ ├── 资源: 类似生产（缩小规模） │
│ ├── 数据: 清洗的生产数据子集 │
│ └── 审批: 无（在配额内） │
├─────────────────────────────────────────────────────────────┤
│ 生产环境 │
│ ├── 目的: 实时客户流量 │
│ ├── 生命周期: 永久 │
│ ├── 资源: 全容量 │
│ ├── 数据: 真实客户数据 │
│ └── 审批: 必需（安全审核） │
└─────────────────────────────────────────────────────────────┘
环境模板:
# environment/main.tf
module "network" {
source = "../modules/vpc"
environment = var.environment
cidr_block = var.network_cidr
}
module "kubernetes" {
source = "../modules/eks"
environment = var.environment
vpc_id = module.network.vpc_id
node_count = var.environment == "prod" ? 5 : 2
}
module "database" {
source = "../modules/rds"
environment = var.environment
vpc_id = module.network.vpc_id
instance_class = var.environment == "prod" ? "db.r5.xlarge" : "db.t3.medium"
multi_az = var.environment == "prod"
}
module "cache" {
source = "../modules/elasticache"
environment = var.environment
vpc_id = module.network.vpc_id
node_type = var.environment == "prod" ? "cache.r5.large" : "cache.t3.micro"
}
临时环境
临时/预览环境:
使用案例:
├── PR预览环境
├── 功能分支测试
├── 演示环境
├── 负载测试环境
└── 事件复现
生命周期:
┌─────────────────────────────────────────────────────────────┐
│ │
│ PR创建 ──► 环境创建 ──► 测试运行 │
│ │ │ │ │
│ │ ▼ ▼ │
│ │ 预览URL PR更新 │
│ │ 发布到PR │ │
│ │ │ │
│ ▼ ▼ │
│ PR合并 ───────────────────────► 环境销毁 │
│ │
│ 超时: 7天无活动后自动销毁 │
│ │
└─────────────────────────────────────────────────────────────┘
实施:
# .github/workflows/preview.yml
名称: 预览环境
on:
pull_request:
types: [opened, synchronize]
工作:
部署预览:
runs-on: ubuntu-latest
步骤:
- 名称: 创建/更新环境
run: |
terraform workspace select pr-${{ github.event.pull_request.number }} || \
terraform workspace new pr-${{ github.event.pull_request.number }}
terraform apply -auto-approve
- 名称: 评论预览URL
uses: actions/github-script@v6
with:
script: |
github.rest.issues.createComment({
issue_number: context.issue.number,
body: '🚀 预览: https://pr-${{ github.event.pull_request.number }}.preview.company.com'
})
技术选项
自服务平台
平台比较:
1. Terraform Cloud/Enterprise
├── 原生Terraform体验
├── 策略即代码（Sentinel）
├── 私有模块注册表
├── 成本估算
└── 企业功能（SSO、审计）
2. Pulumi
├── 真实编程语言
├── 强类型和IDE支持
├── 策略即代码（CrossGuard）
└── 自动化API
3. Crossplane
├── Kubernetes原生
├── GitOps工作流
├── 模块组合
└── 多云抽象
4. Backstage + Terraform
├── 统一开发者门户
├── 软件模板
├── 插件生态系统
└── 服务目录集成
5. Port/Cortex/OpsLevel
├── 商业开发者门户
├── 快速实施
├── 内置集成
└── 自服务工作流
选择标准:
┌────────────────────────────────────────────────────────────┐
│ 因素 │ 最佳匹配 │
├──────────────────────┼─────────────────────────────────────┤
│ 现有Terraform │ Terraform Cloud/Enterprise │
│ Kubernetes优先 │ Crossplane │
│ 开发者门户 │ Backstage或商业平台 │
│ 编程语言 │ Pulumi │
│ 快速启动 │ 商业平台（Port、OpsLevel） │
│ 最大控制 │ 自定义构建 │
└────────────────────────────────────────────────────────────┘
成本管理
成本控制
自服务中的成本管理:
1. 成本可见性
├── 配置前显示估算成本
├── 自动应用成本标签
├── 每团队/项目仪表板
└── 异常检测和警报
2. 成本护栏
├── 实例类型限制
├── 按团队预算阈值
├── 高于阈值需审批
└── 自动关闭未使用资源
3. 成本优化
├── 适当规模建议
├── 预留实例建议
├── 非生产使用Spot实例
└── 计划缩放
成本估算流程:
┌─────────────────────────────────────────────────────────────┐
│ 请求: 暂存PostgreSQL数据库 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 成本估算: │
│ ├── 计算（db.t3.medium）: $30/月 │
│ ├── 存储（100GB gp3）: $10/月 │
│ ├── 备份存储: ~$5/月 │
│ └── 数据传输: ~$5/月 │
│ ───────── │
│ 估算总计: ~$50/月 │
│ │
│ ✓ 在团队预算内（$500/月配额） │
│ ✓ 无需审批 │
│ │
│ [继续] [修改] [取消] │
└─────────────────────────────────────────────────────────────┘
最佳实践
自服务基础设施最佳实践:
1. 从小开始，逐步扩展
├── 从2-3个常见资源开始
├── 根据需求添加
├── 基于反馈迭代
└── 不要试图第一天覆盖一切
2. 平衡自治与治理
├── 护栏而非闸门
├── 安全处自动化审批
├── 明确升级路径
└── 信任但验证
3. 优化开发者体验
├── 最小必要输入
├── 合理默认值
├── 清晰错误消息
└── 快速反馈循环
4. 维护模块质量
├── 自动化测试
├── 文档要求
├── 版本控制策略
└── 弃用流程
5. 监控和改进
├── 跟踪配置成功率
├── 测量配置时间
├── 收集用户反馈
└── 识别自动化机会
6. 处理边缘案例
├── 如果配置失败怎么办？
├── 如何处理孤儿资源？
├── 现有资源怎么办？
└── 如何在版本间迁移？
反模式
自服务反模式:
1. "自服务一切"
❌ 每个可能的配置选项
✓ 批准的精选模式集
2. "安全表演"
❌ 无价值的手动审批
✓ 自动化策略执行
3. "配置爆炸"
❌ 每个资源50个参数
✓ 带有少量覆盖的合理默认值
4. "忽略成本"
❌ 无配置成本可见性
✓ 成本估算和预算
5. "构建与购买错误"
❌ 从头构建一切
✓ 适当时使用现有工具
6. "无逃生舱口"
❌ 阻塞合法例外
✓ 合理偏差流程
相关技能
internal-developer-platform- 平台工程概述golden-paths- 标准化工作流container-orchestration- Kubernetes基础设施serverless-patterns- 服务器less基础设施