DevOps与自动化原理
一、CI/CD
1.1 CI/CD核心概念
┌─────────────────────────────────────────────────────────────────┐
│ CI/CD流水线 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────────────────────────────────────────────────┐ │
│ │ 持续集成(CI) │ │
│ │ │ │
│ │ 代码提交 → 自动构建 → 自动测试 → 代码质量检查 │ │
│ │ │ │
│ │ 核心实践: │ │
│ │ ├── 频繁提交(每日多次) │ │
│ │ ├── 自动化构建 │ │
│ │ ├── 自动化测试(单元/集成/端到端) │ │
│ │ └── 快速反馈(< 10分钟) │ │
│ └──────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────────────────────────────────────────────────┐ │
│ │ 持续交付(CD) │ │
│ │ │ │
│ │ CI通过 → 自动部署到Staging → 验收测试 → 人工审批 → 生产│ │
│ │ │ │
│ │ 核心实践: │ │
│ │ ├── 一键部署 │ │
│ │ ├── 环境一致性 │ │
│ │ ├── 回滚机制 │ │
│ │ └── 特性开关 │ │
│ └──────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────────────────────────────────────────────────┐ │
│ │ 持续部署(CD) │ │
│ │ │ │
│ │ CI通过 → 自动部署到Staging → 自动测试 → 自动部署到生产 │ │
│ │ │ │
│ │ 核心实践: │ │
│ │ ├── 全自动化部署 │ │
│ │ ├── 金丝雀发布 │ │
│ │ ├── 自动回滚 │ │
│ │ └── 全面监控 │ │
│ └──────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘1.2 云原生CI/CD流水线
┌─────────────────────────────────────────────────────────────────┐
│ 云原生CI/CD完整流水线 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 开发者 ──► Git Push ──► CI/CD系统 │
│ │ │
│ ┌───────────────────────────────┼───────────────────────────┐ │
│ │ CI阶段 │ │
│ │ │ │
│ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │
│ │ │ 代码检出│→│ 代码扫描│→│ 编译构建│→│ 单元测试│ │ │
│ │ └─────────┘ └─────────┘ └─────────┘ └─────────┘ │ │
│ │ │ │ │
│ │ ▼ │ │
│ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │
│ │ │ 集成测试│→│ 镜像构建│→│ 安全扫描│→│ 镜像签名│ │ │
│ │ └─────────┘ └─────────┘ └─────────┘ └─────────┘ │ │
│ │ │ │ │
│ │ ▼ │ │
│ │ ┌─────────┐ ┌─────────┐ │ │
│ │ │ SBOM生成│→│ 制品发布│ │ │
│ │ └─────────┘ └─────────┘ │ │
│ └───────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌───────────────────────────────────────────────────────────┐ │
│ │ CD阶段 │ │
│ │ │ │
│ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │
│ │ │清单更新 │→│策略验证 │→│金丝雀部署│→│流量验证 │ │ │
│ │ └─────────┘ └─────────┘ └─────────┘ └─────────┘ │ │
│ │ │ │ │
│ │ ▼ │ │
│ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │
│ │ │全量发布 │→│冒烟测试 │→│监控确认 │ │ │
│ │ └─────────┘ └─────────┘ └─────────┘ │ │
│ └───────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘1.3 Argo CD配置示例
# Argo CD Application
apiVersion:argoproj.io/v1alpha1
kind:Application
metadata:
name:my-app
namespace:argocd
annotations:
notifications.argoproj.io/subscribe.on-deployed.slack:deployments
spec:
project:default
source:
repoURL:https://github.com/org/k8s-manifests.git
targetRevision:main
path:overlays/production
kustomize:
images:
-my-registry/my-app:latest
destination:
server:https://kubernetes.default.svc
namespace:production
syncPolicy:
automated:
prune:true
selfHeal:true
allowEmpty:false
syncOptions:
-CreateNamespace=true
-PrunePropagationPolicy=foreground
-ServerSideApply=true
retry:
limit:5
backoff:
duration:5s
factor:2
maxDuration:3m
---
# AppProject - 多团队隔离
apiVersion:argoproj.io/v1alpha1
kind:AppProject
metadata:
name:team-a
namespace:argocd
spec:
description:TeamAProject
sourceRepos:
-'https://github.com/team-a/*'
destinations:
-namespace:'team-a-*'
server:https://kubernetes.default.svc
clusterResourceWhitelist:
-group:''
kind:Namespace
namespaceResourceBlacklist:
-group:''
kind:ResourceQuota
roles:
-name:admin
policies:
-p,proj:team-a:admin,applications,*,team-a/*,allow
groups:
-team-a-admins二、GitOps
2.1 GitOps核心原则
┌─────────────────────────────────────────────────────────────────┐
│ GitOps核心原则 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 1. 声明式 │
│ ├── 系统描述为声明式配置 │
│ ├── Git仓库作为Single Source of Truth │
│ └── 配置版本化、可审计 │
│ │
│ 2. 版本控制 │
│ ├── 所有变更通过Git提交 │
│ ├── 变更历史可追溯 │
│ └── 回滚=Git revert │
│ │
│ 3. 自动应用 │
│ ├── Git变更自动触发部署 │
│ ├── 控制循环持续调谐 │
│ └── 期望状态vs实际状态持续对比 │
│ │
│ 4. 持续协调 │
│ ├── 软件代理持续监控 │
│ ├── 偏差自动纠正 │
│ └── 确保实际状态=期望状态 │
│ │
│ GitOps vs 传统CI/CD: │
│ ┌──────────────────────────────────────────────────────────┐ │
│ │ 传统: CI系统推送变更到集群(需要集群访问权限) │ │
│ │ GitOps: 集群内代理拉取变更(无需外部访问权限) │ │
│ └──────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘2.2 GitOps工作流程
┌─────────────────────────────────────────────────────────────────┐
│ GitOps工作流程 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ Push模式: │
┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐ │
│ │ 开发者 │───►│ Git仓库│───►│ CI/CD │───►│ K8s集群│ │
│ └────────┘ └────────┘ └────────┘ └────────┘ │
│ 推送部署 │
│ │
│ Pull模式(推荐): │
│ ┌────────┐ ┌────────┐ ┌────────┐ │
│ │ 开发者 │───►│ Git仓库│◄──────轮询/事件────│Argo CD │ │
│ └────────┘ └────────┘ └────┬───┘ │
│ │ │
│ │ 拉取+应用 │
│ ▼ │
│ ┌────────┐ │
│ │ K8s集群│ │
│ └────────┘ │
│ │
│ 完整流程: │
│ 1. 开发者提交代码到应用仓库 │
│ 2. CI构建镜像并推送到仓库 │
│ 3. CI更新配置仓库中的镜像标签 │
│ 4. GitOps工具检测到配置变更 │
│ 5. 自动同步变更到Kubernetes集群 │
│ 6. 持续监控确保状态一致 │
│ │
└─────────────────────────────────────────────────────────────────┘2.3 GitOps工具对比
| 特性 | Argo CD | Flux | Jenkins X |
|---|---|---|---|
| 模式 | Pull | Pull | Push/Pull |
| UI | 丰富的Web UI | CLI为主 | Web UI |
| 多集群 | 原生支持 | 支持 | 支持 |
| RBAC | 内置 | OIDC | 内置 |
| 通知 | 丰富 | 丰富 | 内置 |
| 学习曲线 | 中 | 低 | 高 |
| 社区活跃 | 高 | 高 | 中 |
| 适用场景 | 企业级 | 轻量级 | 全流程 |
三、IaC（基础设施即代码）
3.1 IaC核心原则
┌─────────────────────────────────────────────────────────────────┐
│ IaC核心原则 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 1. 声明式 vs 命令式 │
│ ├── 声明式: 描述期望状态(Terraform/K8s YAML) │
│ └── 命令式: 描述操作步骤(Shell/Ansible) │
│ │
│ 2. 幂等性 │
│ ├── 多次执行结果一致 │
│ ├── 已存在的资源不重复创建 │
│ └── 部分失败可安全重试 │
│ │
│ 3. 不可变基础设施 │
│ ├── 替换而非修改 │
│ ├── 容器镜像不可变 │
│ └── 蓝绿部署/金丝雀发布 │
│ │
│ 4. 版本控制 │
│ ├── 基础设施定义纳入Git管理 │
│ ├── 变更可审计 │
│ └── 可回滚 │
│ │
└─────────────────────────────────────────────────────────────────┘3.2 Terraform配置示例
# EKS集群Terraform配置
module "eks" {
source = "terraform-aws-modules/eks/aws"
version = "~> 19.0"
cluster_name = "production"
cluster_version = "1.28"
cluster_endpoint_private_access = true
cluster_endpoint_public_access = true
vpc_id = module.vpc.vpc_id
subnet_ids = module.vpc.private_subnets
eks_managed_node_groups = {
system = {
min_size = 2
max_size = 5
desired_size = 3
instance_types = ["m5.large"]
labels = {
role = "system"
}
taints = [{
key = "CriticalAddonsOnly"
effect = "NO_SCHEDULE"
}]
}
application = {
min_size = 3
max_size = 20
desired_size = 5
instance_types = ["m5.xlarge"]
labels = {
role = "application"
}
}
}
cluster_addons = {
coredns = {
most_recent = true
}
kube-proxy = {
most_recent = true
}
vpc-cni = {
most_recent = true
before_compute = true
configuration_values = jsonencode({
env = {
ENABLE_PREFIX_DELEGATION = "true"
WARM_PREFIX_TARGET = "1"
}
})
}
}
cluster_security_group_additional_rules = {
ingress_nodes_8443 = {
description = "Node to control plane 8443"
protocol = "tcp"
from_port = 8443
to_port = 8443
source_node_security_group = true
}
}
tags = {
Environment = "production"
Terraform = "true"
}
}3.3 Crossplane配置示例
# Crossplane - K8s原生IaC
apiVersion:aws.upbound.io/v1beta1
kind:ProviderConfig
metadata:
name:aws-provider
spec:
credentials:
source:Secret
secretRef:
namespace:crossplane-system
name:aws-creds
key:creds
---
# 使用Crossplane创建S3 Bucket
apiVersion:s3.aws.upbound.io/v1beta1
kind:Bucket
metadata:
name:my-app-bucket
annotations:
crossplane.io/external-name:my-app-bucket-12345
spec:
forProvider:
region:us-east-1
versioning:
-enabled:true
serverSideEncryptionConfiguration:
-rule:
-applyServerSideEncryptionByDefault:
-sseAlgorithm:AES256
providerConfigRef:
name:aws-provider
---
# CompositeResourceDefinition - 抽象基础设施
apiVersion:apiextensions.crossplane.io/v1
kind:CompositeResourceDefinition
metadata:
name:xapps.example.org
spec:
group:example.org
names:
kind:XApp
plural:xapps
versions:
-name:v1alpha1
served:true
referenceable:true
schema:
openAPIV3Schema:
type:object
properties:
spec:
type:object
properties:
parameters:
type:object
properties:
environment:
type:string
region:
type:string3.4 IaC工具对比
| 工具 | 类型 | 语言 | 状态管理 | 适用场景 |
|---|---|---|---|---|
| Terraform | 声明式 | HCL | State文件 | 通用IaC |
| Pulumi | 声明式 | Python/Go/TS | State文件 | 开发者友好 |
| Crossplane | 声明式 | YAML | K8s CRD | K8s原生IaC |
| Ansible | 命令式 | YAML | 无 | 配置管理 |
| CDKTF | 声明式 | TS/Python | State文件 | 开发者IaC |
四、混沌工程
4.1 混沌工程原则
┌─────────────────────────────────────────────────────────────────┐
│ 混沌工程原则 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 1. 建立系统稳态假设 │
│ ├── 定义"正常"行为的可测量指标 │
│ └── 例如: P99延迟<200ms, 成功率>99.9% │
│ │
│ 2. 假设稳态在控制组和实验组中都会持续 │
│ ├── 控制组: 正常运行 │
│ └── 实验组: 注入故障 │
│ │
│ 3. 引入真实世界事件 │
│ ├── 服务器崩溃 │
│ ├── 网络延迟/分区 │
│ ├── 依赖服务故障 │
│ └── 资源耗尽 │
│ │
│ 4. 观察差异 │
│ ├── 稳态是否被破坏? │
│ ├── 系统如何反应? │
│ └── 恢复时间多久? │
│ │
│ 混沌实验设计流程: │
│ ┌──────────────────────────────────────────────────────────┐ │
│ │ 1. 定义稳态假设 → 2. 选择故障注入 → 3. 执行实验 │ │
│ │ ▲ │ │ │
│ │ └──────── 5. 改进系统 ← 4. 验证假设 ────────┘ │ │
│ └──────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘4.2 Chaos Mesh配置
# 网络延迟注入
apiVersion:chaos-mesh.org/v1alpha1
kind:NetworkChaos
metadata:
name:network-delay
namespace:chaos-testing
spec:
action:delay
mode:one
selector:
namespaces:
-production
labelSelectors:
app:my-service
delay:
latency:"100ms"
correlation:"25"
jitter:"50ms"
duration:"5m"
---
# Pod故障注入
apiVersion:chaos-mesh.org/v1alpha1
kind:PodChaos
metadata:
name:pod-failure
namespace:chaos-testing
spec:
action:pod-failure
mode:one
selector:
namespaces:
-production
labelSelectors:
app:my-service
duration:"30s"
scheduler:
cron:"@every 10m"
---
# IO延迟注入
apiVersion:chaos-mesh.org/v1alpha1
kind:IOChaos
metadata:
name:io-delay
namespace:chaos-testing
spec:
action:delay
mode:one
selector:
namespaces:
-production
labelSelectors:
app:my-service
volumePath:/data
path:"/data/**/*"
delay:"500ms"
percent:50
duration:"5m"
---
# StressChaos - CPU/内存压力
apiVersion:chaos-mesh.org/v1alpha1
kind:StressChaos
metadata:
name:cpu-stress
namespace:chaos-testing
spec:
mode:one
selector:
namespaces:
-production
labelSelectors:
app:my-service
stressors:
cpu:
workers:2
load:80
duration:"3m"4.3 混沌实验安全准则
┌─────────────────────────────────────────────────────────────────┐
│ 混沌实验安全准则 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 实验前: │
│ ├── 明确实验目标和假设 │
│ ├── 确定爆炸半径(影响范围) │
│ ├── 制定回滚方案 │
│ ├── 在非生产环境先验证 │
│ └── 通知相关人员 │
│ │
│ 实验中: │
│ ├── 实时监控系统指标 │
│ ├── 设置自动终止条件 │
│ ├── 限制故障影响范围 │
│ └── 准备随时手动终止 │
│ │
│ 实验后: │
│ ├── 记录实验结果 │
│ ├── 分析系统行为 │
│ ├── 制定改进计划 │
│ └── 验证改进效果 │
│ │
│ 渐进式混沌: │
│ Level 1: 非生产环境,小范围故障 │
│ Level 2: 非生产环境,组合故障 │
│ Level 3: 生产环境,小范围故障(游戏日) │
│ Level 4: 生产环境,自动持续混沌 │
│ │
└─────────────────────────────────────────────────────────────────┘五、平台工程
5.1 平台工程核心理念
┌─────────────────────────────────────────────────────────────────┐
│ 平台工程架构 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────────────────────────────────────────────────┐ │
│ │ 开发者自助服务 │ │
│ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │
│ │ │服务创建 │ │数据库申请│ │环境管理 │ │监控查看 │ │ │
│ │ └─────────┘ └─────────┘ └─────────┘ └─────────┘ │ │
│ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │
│ │ │部署管理 │ │密钥管理 │ │日志查看 │ │告警配置 │ │ │
│ │ └─────────┘ └─────────┘ └─────────┘ └─────────┘ │ │
│ └──────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────────────────────────────────────────────────┐ │
│ │ 内部开发者平台(IDP) │ │
│ │ │ │
│ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │
│ │ │ Backstage │ │ Port │ │ Kratix │ │ │
│ │ │ (Spotify) │ │ (GetPort) │ │ │ │ │
│ │ └─────────────┘ └─────────────┘ └─────────────┘ │ │
│ └──────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────────────────────────────────────────────────┐ │
│ │ 平台抽象层 │ │
│ │ ├── 集群管理(Crossplane/Cluster API) │ │
│ │ ├── 服务网格(Istio/Linkerd) │ │
│ │ ├── 可观测性(Prometheus/OTel) │ │
│ │ ├── 安全(Vault/Kyverno) │ │
│ │ └── CI/CD(Argo CD/Tekton) │ │
│ └──────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────────────────────────────────────────────────┐ │
│ │ 基础设施层 │ │
│ │ ├── Kubernetes集群 │ │
│ │ ├── 云服务(AWS/GCP/Azure) │ │
│ │ └── 物理基础设施 │ │
│ └──────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘5.2 Backstage配置示例
# Backstage应用模板
apiVersion:scaffolder.backstage.io/v1beta3
kind:Template
metadata:
name:microservice-template
title:MicroserviceTemplate
description:创建新的微服务项目
spec:
owner:platform-team
type:service
parameters:
-title:服务配置
required:
-name
-owner
properties:
name:
title:服务名称
type:string
pattern:'^[a-z][a-z0-9-]*$'
owner:
title:团队
type:string
ui:field:OwnerPicker
description:
title:描述
type:string
language:
title:编程语言
type:string
enum: [go, java, python, node]
default:go
steps:
-id:template
name:生成代码
action:fetch:template
input:
url:./skeleton
values:
name:${{parameters.name}}
owner:${{parameters.owner}}
language:${{parameters.language}}
-id:publish
name:发布到Git
action:publish:github
input:
allowedHosts: ['github.com']
description:${{parameters.description}}
repoUrl:github.com?owner=my-org&repo=${{parameters.name}}
-id:register
name:注册到Backstage
action:catalog:register
input:
catalogInfoUrl:https://github.com/my-org/${{parameters.name}}/blob/main/catalog-info.yaml
output:
links:
-title:仓库
url:${{steps.publish.output.remoteUrl}}
-title:打开目录
icon:catalog
entityRef:${{steps.register.output.entityRef}}5.3 平台工程成熟度
┌─────────────────────────────────────────────────────────────────┐
│ 平台工程成熟度模型 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ Level 1: 脚本化 │
│ ├── 手动操作为主 │
│ ├── 少量自动化脚本 │
│ └── 开发者提交工单 │
│ │
│ Level 2: 自助服务 │
│ ├── 标准化模板 │
│ ├── 自助服务门户 │
│ └── 基础自动化流程 │
│ │
│ Level 3: 平台化 │
│ ├── 内部开发者平台(IDP) │
│ ├── 统一技术栈 │
│ ├── 黄金路径(Golden Path) │
│ └── 完整的自助能力 │
│ │
│ Level 4: 智能化 │
│ ├── 自动化治理 │
│ ├── 智能推荐 │
│ ├── 自愈能力 │
│ └── 持续优化 │
│ │
│ 关键指标: │
│ ├── 开发者满意度(DX) │
│ ├── 服务创建时间 │
│ ├── 平台采用率 │
│ └── 平均恢复时间(MTTR) │
│ │
└─────────────────────────────────────────────────────────────────┘六、DevOps度量体系
6.1 DORA四大关键指标
┌─────────────────────────────────────────────────────────────────┐
│ DORA四大关键指标 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 1. 部署频率(Deployment Frequency) │
│ ├── 定义: 成功部署到生产的频率 │
│ ├── 精英团队: 按需(每天多次) │
│ ├── 高绩效: 每周-每月 │
│ ├── 中绩效: 每月-每半年 │
│ └── 低绩效: 超过半年 │
│ │
│ 2. 变更前置时间(Lead Time for Changes) │
│ ├── 定义: 从代码提交到部署到生产的时间 │
│ ├── 精英团队: < 1天 │
│ ├── 高绩效: 1天-1周 │
│ ├── 中绩效: 1周-1月 │
│ └── 低绩效: > 1月 │
│ │
│ 3. 变更失败率(Change Failure Rate) │
│ ├── 定义: 部署导致生产故障的比例 │
│ ├── 精英团队: 0-15% │
│ ├── 高绩效: 16-30% │
│ ├── 中绩效: 31-45% │
│ └── 低绩效: > 45% │
│ │
│ 4. 服务恢复时间(MTTR) │
│ ├── 定义: 从服务中断到恢复的时间 │
│ ├── 精英团队: < 1小时 │
│ ├── 高绩效: < 1天 │
│ ├── 中绩效: 1天-1周 │
│ └── 低绩效: > 1周 │
│ │
└─────────────────────────────────────────────────────────────────┘6.2 DevOps度量仪表盘
# Prometheus规则 - DORA指标
apiVersion:monitoring.coreos.com/v1
kind:PrometheusRule
metadata:
name:dora-metrics
namespace:monitoring
spec:
groups:
-name:dora
rules:
# 部署频率
-record:dora:deployments:count:1d
expr:sum(increase(deployment_total[1d]))
# 变更前置时间
-record:dora:lead_time:seconds
expr:|
time() - on(app) group_left(commit_timestamp)
label_replace(
git_commit_timestamp{branch="main"},
"app", "$1", "repo", "(.*)"
)
# 变更失败率
-record:dora:failure_rate:ratio
expr:|
sum(rate(deployment_total{status="failed"}[7d]))
/
sum(rate(deployment_total[7d]))
# MTTR
-record:dora:mttr:seconds
expr: |
avg_over_time(
(time() - incident_start_time)
[30d:5m]
)参考资料：
-
Argo CD Documentation
-
Flux Documentation
-
GitOps Principles
-
Terraform Documentation
-
Crossplane Documentation
-
Chaos Mesh Documentation
-
Backstage Documentation
-
DORA Metrics