# 高级 DevOps 工程师生产级DevOps工程工具包涵盖整个基础设施生命周期：CI/CD管道设计、容器编排、基础设施即代码、云平台架构、部署策略、可观察性、安全强化、成本优化和事件响应。 ** ** ## 目录 * 关键词 * 快速启动 * Docker 和容器化 * 库伯内特斯 * CI/CD 管道 * 基础设施即代码 * 监控和可观察性 * 云平台 * 部署策略 * 安全 * 成本优化 * 事件响应 * 参考文档 * 整合点 ** ** ## 关键词当你遇到以下情况时，请使用此技能：类别 |条款 ---|--- **CI/CD** |管道、GitHub Actions、GitLab CI、Jenkins、CircleCI、构建自动化、工件注册表、持续集成、持续交付、持续部署 **容器** | Docker、Dockerfile、docker-compose、容器镜像、多阶段构建、OCI、容器注册表、ECR、GCR、ACR **编排** | Kubernetes、k8s、kubectl、Helm、pod、部署、服务、入口、HPA、VPA、StatefulSet、DaemonSet、CronJob **IaC** | Terraform、OpenTofu、CloudFormation、Pulumi、Ansible、状态管理、tfstate、模块、工作区、漂移检测 **云** | AWS、GCP、Azure、EC2、EKS、GKE、AKS、Lambda、云函数、S3、VPC、IAM、负载均衡器、自动扩展 **监控** | Prometheus、Grafana、Datadog、ELK、Loki、Jaeger、OpenTelemetry、警报、SLO、SLI、SLA、仪表板 **部署** |蓝绿、金丝雀、滚动更新、功能标志、回滚、零停机、A/B 部署、渐进式交付 **安全** | Vault、秘密管理、RBAC、网络策略、供应链安全、SBOM、图像扫描、Trivy、Falco **可靠性** |事件响应、操作手册、事后分析、SRE、错误预算、混沌工程、灾难恢复、RTO、RPO **成本** | FinOps、合理规模、现货实例、预留容量、成本分配、标记策略、节省计划 ** ** ## 快速入门该技能提供了三个核心自动化工具： # 为任何平台生成 CI/CD 管道（GitHub Actions、GitLab CI、Jenkins、CircleCI） python 脚本/pipeline_generator.py <项目路径> --platform github-actions --verbose # 具有模块、状态配置和环境分离的 Scaffold Terraform 基础设施 python 脚本/terraform_scaffolder.py <目标路径> --provider aws --env production --verbose # 通过策略选择、运行状况检查和回滚支持来管理部署 python script/deployment_manager.py <目标路径> --strategy canary --verbose ### 工具详细信息工具|目的|关键标志 ---|---|--- `pipeline_generator.py` |从项目分析生成 CI/CD 管道配置 | `--platform`、`--stages`、`--json` `terraform_scaffolder.py` |使用最佳实践模式创建 Terraform 模块结构 | `--provider`、`--env`、`--modules` `deployment_manager.py` |通过策略选择和回滚来协调部署 | `--strategy`、`--target`、`--dry-run` ** ** ## Docker 和容器化 ### Dockerfile 最佳实践每个生产 Dockerfile 都应遵循以下分层模式： # 第一阶段：构建 FROM节点：20-alpine AS构建器工作目录/应用程序 # 首先复制依赖清单（缓存层）复制 package.json package-lock.json ./ RUN npm ci --only=生产 && npm 缓存清理 --force # 复制源码并构建复制。。 RUN npm 运行构建 # 第二阶段：生产 FROM节点：20-alpine AS生产工作目录/应用程序 # 以非 root 身份运行运行 addgroup -g 1001 应用组 && \ adduser -u 1001 -G appgroup -s /bin/sh -D appuser # 仅复制生产工件复制 --from=builder --chown=appuser:appgroup /app/dist ./dist 复制 --from=builder --chown=appuser:appgroup /app/node_modules ./node_modules 复制 --from=builder --chown=appuser:appgroup /app/package.json ./ USER 应用程序用户曝光 3000 HEALTHCHECK --间隔=30s --超时=3s --start-period=10s --retries=3 \ CMD wget --no-verbose --tries=1 --spider http://localhost:3000/healthz || 1号出口 CMD [“节点”，“dist/server.js”] **关键规则：** * 始终使用特定的图像标签，切勿在生产中使用“最新” * 从最少到最常更改的顺序对 COPY 指令进行排序（最大化层缓存） * 使用 `.dockerignore` 排除 `.git`、`node_modules`、测试文件、文档 * 永远不要在镜像中存储秘密——通过环境或安装的秘密使用运行时注入 * 固定包管理器版本：“npm ci”而不是“npm install”，锁定文件始终被复制 * 多阶段构建可将最终图像尺寸减少 60-80% ### Docker 组合模式典型微服务堆栈的生产就绪组合：版本：“3.9” x-常见：&常见重新启动：除非停止记录：驱动程序：json 文件选项：最大尺寸：“10m” 最大文件：“3” 服务：应用程序： <<：*常见构建：上下文： . dockerfile: Dockerfile 目标：生产端口： - “3000:3000” 环境： - NODE_ENV=生产 - DATABASE_URL=postgresql://app:${DB_PASSWORD}@db:5432/appdb - REDIS_URL=redis://redis:6379 取决于：数据库：条件：服务健康雷迪斯：条件：服务健康部署：资源：限制：中央处理器：“1.0” 内存：512M 预订：中央处理器：“0.25” 内存：128M 健康检查：测试：[“CMD”，“wget”，“--spider”，“-q”，“http://localhost:3000/healthz”] 间隔：15秒超时：5秒重试次数：3 数据库： <<：*常见图片：postgres：16-alpine 卷： - pgdata:/var/lib/postgresql/data 环境： POSTGRES_DB：应用程序数据库 POSTGRES_USER：应用程序 POSTGRES_PASSWORD：${DB_PASSWORD} 健康检查：测试：[“CMD-SHELL”，“pg_isready -U app -d appdb”] 间隔：10秒超时：5秒重试次数：5 雷迪斯： <<：*常见图片：redis:7-alpine 命令：redis-server --maxmemory 128mb --maxmemory-policy allkeys-lru 卷： -redisdata:/数据健康检查：测试：[“CMD”，“redis-cli”，“ping”] 间隔：10秒超时：3秒重试次数：3 卷： PG数据：重新分配数据： ### 容器安全检查表 * 仅来自可信注册中心的基础镜像（Docker 官方、Chainguard、Distroless） * 推送前使用 Trivy 或 Grype 扫描的图像：`trivy image --severity HIGH,CRITICAL myapp:latest` * 容器内没有根进程——始终使用“USER”指令 * 尽可能只读根文件系统：`--read-only --tmpfs /tmp` * 强制实施资源限制（CPU、内存）以防止噪音邻居攻击 * 镜像层中没有包含任何秘密——使用“docker History --no-trunc”进行验证 * 最小化基础镜像（Alpine、Distroless）以减少攻击面 ** ** ## 库伯内特斯 ### Pod 设计模式 **Sidecar 模式** \-- 在不修改主容器的情况下添加功能： api版本：apps/v1 种类：部署元数据：名称：应用程序标签：应用程序：网络规格：副本：3 选择器：匹配标签：应用程序：网络模板：元数据：标签：应用程序：网络注释： prometheus.io/scrape：“真实” prometheus.io/端口：“9090” 规格：服务帐户名称：app-sa 安全上下文： runAsNonRoot: true FS组：1001 容器： - 名称：应用程序图片：myapp：1.2.3 端口： - 集装箱端口：3000 资源：要求：中央处理器：250m 内存：256Mi 限制：中央处理器：“1” 内存：512Mi 活性探针： http获取：路径：/healthz 端口：3000 初始延迟秒数：15 周期秒：20 失败阈值：3 准备情况探针： http获取：路径：/准备好端口：3000 初始延迟秒数：5 周期秒：10 启动探针： http获取：路径：/healthz 端口：3000 失败阈值：30 周期秒：10 环境： - 名称：DB_PASSWORD 值来自：秘密密钥参考：名称：应用程序秘密 key: 数据库密码 - 名称：日志托运人图像：流畅/流畅位：2.2 体积安装： - 名称：应用程序日志挂载路径：/var/log/app 卷： - 名称：应用程序日志空目录：{} **探索决策框架：** * **startupProbe** ：用于缓慢启动的应用程序（JVM、大型模型加载）。防止活性杀死尚未完成启动的容器。 * **livenessProbe** ：检测死锁和挂起。保持简单（检查进程运行状况，而不是下游依赖项）。 * **readinessProbe** ：控制流量路由。此处包括依赖性检查（数据库可访问、缓存热）。 ### Helm 图表结构图表/myapp/ Chart.yaml 值.yaml 值-staging.yaml 价值观生产.yaml 模板/ 部署.yaml 服务.yaml 入口.yaml hpa.yaml 网络策略.yaml 服务帐户.yaml _helpers.tpl 关键的“values.yaml”模式：副本数量：3 图片：存储库：myapp 标签：“1.2.3” 拉取策略：IfNotPresent 资源：要求：中央处理器：250m 内存：256Mi 限制：中央处理器：“1” 内存：512Mi 自动缩放：启用：真最少副本数：3 最大副本数：20 目标CPU利用率：70 目标内存利用率：80 入口：启用：真类名：nginx 注释： cert-manager.io/cluster-issuer: 让加密产品主持人： - 主机：app.example.com 路径： - 路径：/ 路径类型：前缀 : - 秘密名称：app-tls 主持人： - app.example.com ### 资源管理和自动扩展 **HPA（水平 Pod 自动缩放器）：** api版本：自动缩放/v2 种类：HorizontalPodAutoscaler 元数据：名称：app-hpa 规格：缩放目标参考： api版本：apps/v1 种类：部署名称：应用程序最少副本数：3 最大副本数：20 指标： - 类型：资源资源：名称：中央处理器目标：类型：利用平均利用率：70 - 类型：资源资源：名称：记忆目标：类型：利用平均利用率：80 行为：扩大规模：稳定窗口秒：60 政策： - 类型：百分比值：50 周期秒：60 缩小：稳定窗口秒：300 政策： - 类型：百分比值：25 周期秒：120 **决定：HPA vs VPA vs KEDA** 洁牙机 |使用时间 |避免何时 ---|---|--- **HPA** |无状态服务、可预测的 CPU/内存模式 |有状态工作负载、突发事件驱动负载 **VPA** |调整请求/限制大小、批处理作业、单副本工作负载 |单独用于延迟敏感的服务 **科达** |事件驱动的扩展（队列深度、HTTP 速率、cron）|简单的基于CPU的扩展（HPA更简单） ** ** ## CI/CD 管道 ### GitHub 操作具有缓存、矩阵测试和部署门的生产管道：名称：CI/CD 于：推：分支：[主要] 拉请求：分支：[主要] 权限：内容：阅读包：写 id 令牌：写入环境：注册表：ghcr.io IMAGE_NAME：${{ github.repository }} 职位：测试：运行：ubuntu-latest 策略：矩阵：节点版本：[18, 20] 步骤： - 使用：actions/checkout@v4 - 使用：actions/setup-node@v4 与：节点版本：${{ 矩阵.节点版本 }} 缓存：npm - 运行：npm ci - 运行：npm run lint - 运行：npm test -- --覆盖率 - 使用：actions/upload-artifact@v4 如果：matrix.node-version == 20 与：名称：覆盖范围路径：覆盖范围/ 安全：运行：ubuntu-latest 步骤： - 使用：actions/checkout@v4 - 名称：运行 Trivy 漏洞扫描器用途：aquasecurity/trivy-action@master 与：扫描类型：fs 严重性：高、严重退出代码：1 构建：需求：[测试、安全] if: github.ref == 'refs/heads/main' 运行：ubuntu-latest 输出：图像标签：${{steps.meta.outputs.tags}} 步骤： - 使用：actions/checkout@v4 - 使用：docker/setup-buildx-action@v3 - 使用：docker/login-action@v3 与：注册表：${{ env.REGISTRY }} 用户名：${{ github.actor }} 密码：${{secrets.GITHUB_TOKEN}} - ID：元使用：docker/metadata-action@v5 与：图片：${{ env.REGISTRY }}/${{ env.IMAGE_NAME }} 标签： | 类型=sha 类型=参考，事件=分支 - 使用：docker/build-push-action@v5 与：上下文： . 推：真标签：${{steps.meta.outputs.tags}} 缓存来源：类型=gha 缓存到：类型=gha，模式=最大部署暂存：需求：构建运行：ubuntu-latest 环境：舞台步骤： - 使用：actions/checkout@v4 - 名称：部署到暂存运行：| helm Upgrade --安装应用程序charts/myapp \ --命名空间暂存\ --values 图表/myapp/values-staging.yaml \ --set image.tag=${{ github.sha }} \ --wait --超时300s 部署生产：需求：部署阶段运行：ubuntu-latest 环境：生产步骤： - 使用：actions/checkout@v4 - 名称：部署到生产（金丝雀）运行：| helm Upgrade --安装应用程序charts/myapp \ --命名空间制作\ --values 图表/myapp/values-product.yaml \ --set image.tag=${{ github.sha }} \ --set canary.enabled=true \ --设置 canary.weight=10 \ --wait --超时300s ### GitLab CI 阶段： - 测试 - 建造 - 部署变量： DOCKER_BUILDKIT：1 测试：阶段：测试图片：节点：20-alpine 缓存：键：${CI_COMMIT_REF_SLUG} 路径： - 节点模块/ 脚本： - npm ci - npm 运行 lint - npm 测试 -- --覆盖率覆盖范围：'/Lines\s*:\s*(\d+\.?\d*)%/' 文物：报告：覆盖率报告：覆盖率格式：cobertura 路径：coverage/cobertura-coverage.xml 构建：阶段：构建图片：码头工人：24 服务： - 码头工人：24-dind 仅： - 主要脚本： - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA 。 - docker 推送 $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA 部署暂存：阶段：部署环境：名称：舞台表演网址：https://staging.example.com 仅： - 主要脚本： - helm升级--安装应用程序charts/myapp --命名空间暂存 --set image.tag=$CI_COMMIT_SHA --等等部署生产：阶段：部署环境：名称：生产网址：https://app.example.com 仅： - 主要时间：手动脚本： - helm升级--安装应用程序charts/myapp --命名空间制作 --set image.tag=$CI_COMMIT_SHA --等等 ### 管道设计原则 1. **快速失败**：在昂贵的集成测试之前运行 linting 和单元测试 2. **积极缓存**：节点模块、Docker 层、Go 模块、pip 包 3. **不可变的工件**：构建一次，将相同的工件部署到每个环境 4. **门促销**：生产前需要手动批准或自动烟雾测试 5. **尽可能并行**：同时运行独立的测试套件和安全扫描 6. **本地重现**：每个 CI 步骤都应该可以在开发人员计算机上运行 ** ** ## 基础设施即代码 ### Terraform 模块结构基础设施/ 模块/ 专有网络/ 主.tf 变量.tf 输出.tf 埃克斯/ 主.tf 变量.tf 输出.tf rds/ 主.tf 变量.tf 输出.tf 环境/ 分期/ main.tf # 使用暂存值调用模块 terraform.tfvars backend.tf # S3 + DynamoDB 状态后端生产/ 主.tf terraform.tfvars 后端.tf ### 状态管理带锁定的远程状态 (AWS)： # 后端.tf 地形{ 后端“s3”{ 桶=“mycompany-terraform-state” key =“生产/基础设施.tfstate” 区域 =“us-east-1” dynamodb_table = “terraform-locks” 加密=真 } } **状态管理规则：** * 每个组件每个环境一个状态文件（爆炸半径控制） * 切勿在本地或 git 中存储状态 * 启用静态和传输中加密 * 使用DynamoDB (AWS) 或Cloud Storage (GCP) 进行状态锁定 * 在CI中运行`terraform plan`，只有批准后才执行`terraform apply` * 使用 `terraform state list` 和 `terraform state show` 进行调试，切勿手动编辑状态 ### 工作空间与目录模式图案|使用时间 |权衡 ---|---|--- **工作空间** |相同的配置，不同的规模（具有相同拓扑的开发/暂存/生产）|共享状态后端，易于切换，但难以分散配置 **目录** |不同的环境需要不同的资源或拓扑 |完全隔离，边界清晰，但样板重复 **建议** ：使用目录进行环境隔离。使用模块来共享逻辑。工作区更适合临时环境（PR 预览、负载测试环境）。 ### 漂移检测将漂移检测集成到 CI 中： # 按计划在 CI 中运行（每天） terraform plan -detailed-exitcode -out=plan.tfplan # 退出代码 0 = 没有更改（干净） # 退出代码 1 = 错误 # 退出代码 2 = 检测到更改（漂移） # 退出代码 2 时发出警报如果 [ $? -eq 2 ];那么 # 向 Slack/PagerDuty 发送警报卷曲-X POST“$SLACK_WEBHOOK”\ -H '内容类型：application/json' \ -d '{"text":"在生产中检测到 Terraform 漂移。需要审核。"}' 菲 ### Terraform 反模式 * **整体状态**：整个基础设施的一个状态文件。按组件和环境划分。 * **硬编码值** ：使用变量和 tfvar。切勿对 AMI ID、实例类型或 CIDR 块进行硬编码。 * **无生命周期规则** ：对关键资源（数据库、包含数据的 S3 存储桶）使用 `prevent_destroy`。 * **忽略计划输出** ：在应用之前始终检查计划差异，尤其是“销毁”和“替换”操作。 ** ** ## 监控和可观察性 ### 三大支柱支柱|工具|目的 ---|---|--- **指标** |普罗米修斯 + Grafana |数值时间序列数据（CPU、延迟、错误率） **日志** | Loki / ELK（Elasticsearch、Logstash、Kibana）|用于调试的结构化事件记录 **痕迹** | Jaeger/Tempo + OpenTelemetry |跨服务的请求流以进行延迟分析 ### Prometheus 警报规则团体： - 名称：应用程序规则： - 警报：高错误率表达式: | sum(rate(http_requests_total{status=~"5.."}[5m])) / 总和（速率（http_requests_total[5m]）） > 0.05 用于：5m 标签：严重程度：严重注释：摘要：“5分钟错误率超过5%” 运行手册：“https://wiki.example.com/runbooks/high-error-rate” - 警报：高延迟P99 表达式: | histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[5m])) by (le)) > 2.0 适合：10m 标签：严重性：警告注释：摘要：“P99延迟超过2秒持续10分钟” - 警报：PodCrashLooping 表达式: | 增加（kube_pod_container_status_restarts_total[1h]）> 5 用于：5m 标签：严重程度：严重注释：摘要：“Pod {{ $labels.pod }} 频繁重新启动” - 警报：磁盘空间低表达式: | (node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"}) < 0.15 适合：10m 标签：严重性：警告注释：摘要：“{{ $labels.instance }} 上的磁盘空间低于 15%” ### SLO/SLI 定义 **首先定义 SLI，然后设置 SLO：** 服务 | SLI（您测量的内容）| SLO（目标）|错误预算 ---|---|---|--- API网关|成功请求/总请求 | 99.9% 可用性（43.8 分钟/月停机时间）| 0.1% API 延迟 | 500 毫秒以下的请求数/总请求数 |第 99 个百分位数 < 500 毫秒 | 1% 数据管道|成功的管道运行/总运行 | 99.5% 成功率 | 0.5% 部署|成功部署/总部署 | 99% 成功率 | 1% **错误预算策略**：当错误预算耗尽时，冻结功能部署并优先考虑可靠性工作，直到预算恢复。 ### Grafana 仪表板要点每个服务仪表板都应包含这些面板（“四个黄金信号”）： 1. **延迟**：P50、P90、P99 响应时间（直方图） 2. **流量**：按端点和状态代码列出的每秒请求数 3. **错误**：5xx 率、4xx 率、特定于应用程序的错误代码 4. **饱和度**：CPU使用率、内存使用率、连接池利用率、队列深度 ** ** ## 云平台 ### 服务比较矩阵能力|亚马逊AWS | GCP |天蓝色 ---|---|---|--- **托管 Kubernetes** | EKS | GKE | AKS **无服务器计算** |拉姆达 |云功能/云运行| Azure 函数 **集装箱服务** | ECS/Fargate |云跑|容器应用程序 **对象存储** | S3 |云存储|斑点存储 **托管数据库** | RDS / 极光 |云 SQL / AlloyDB | Azure SQL/Cosmos DB **消息队列** | SQS / SNS |发布/订阅 |服务总线 **CDN** |云前 |云CDN | Azure CDN/前门 **DNS** | 53 号公路 |云域名解析 | Azure DNS **秘密** |秘密经理 |秘密经理|密钥库 **IAM** | IAM + STS | IAM + 工作负载身份 |内部 ID + RBAC **IaC** |云形成/CDK |部署经理 |二头肌/手臂 ### 多云战略决策框架 **当多云有意义时：** * 监管要求强制要求地域或供应商多样性 * 收购将工作负载引入不同的云上 * 特定的最佳服务（例如，用于机器学习的 GCP、用于广度的 AWS） **如果没有：** * 避免将供应商锁定作为唯一动机（运营税超过节省的费用） * 无法承担复杂性开销的小团队 * 没有监管驱动程序进行分发的工作负载 **如果您采用多云：** * 使用 Terraform（不是特定于提供商的 IaC）作为抽象层 * 将 Kubernetes 标准化为跨云计算平面 * 集中可观察性（Datadog、Grafana Cloud）以避免可见性碎片化 * 投资平台工程团队来管理抽象 ** ** ## 部署策略 ### 策略选择框架战略|风险|回滚速度|基础设施成本|最适合 ---|---|---|---|--- **滚动更新** |中等|分钟 | 1x |无状态服务、内部 API **蓝绿** |低|秒（DNS/LB 切换）|部署期间 2x |关键任务，需要零停机 **金丝雀** |低|秒（将流量移回）| 1.1 倍 |面向用户的服务，逐步验证 **功能标志** |最低|即时（切换）| 1x |精细控制、A/B 测试、基于主干的开发 ### 蓝绿实施 # 蓝色（当前生产） api版本：v1 种类：服务元数据：名称：应用程序制作规格：选择器：应用程序：我的应用程序 version: blue # 指向当前版本端口： - 端口：80 目标端口：3000 --- # 绿色（新版本）——与蓝色一起部署 api版本：apps/v1 种类：部署元数据：名称：应用程序绿色规格：副本：3 选择器：匹配标签：应用程序：我的应用程序版本: 绿色模板：元数据：标签：应用程序：我的应用程序版本: 绿色规格：容器： - 名称：应用程序图片：myapp：2.0.0 **切换步骤：** 1. 部署绿色和蓝色（两者都在运行，只有蓝色提供流量） 2. 通过内部服务或端口转发对绿色运行冒烟测试 3. 将服务选择器从 `version: blue` 切换到 `version: green` 4. 监测15分钟 5. 如果健康，则缩小蓝色。如果没有，请将选择器切换回蓝色。 ### Canary 与 Istio/Nginx # 用于金丝雀路由的 Istio VirtualService api版本：networking.istio.io/v1beta1 种类：虚拟服务元数据：名称：应用程序金丝雀规格：主持人： - app.example.com http： - 路线： - 目的地：主机：应用程序稳定港口：数量：80 重量：90 - 目的地：主机：应用程序金丝雀港口：数量：80 重量：10 **金丝雀晋升阶梯：** 1.部署金丝雀，流量5% 2. 监控10分钟的错误率和延迟 3.提升至25%，监控10分钟 4.提升至50%，监控15分钟 5.提升至100%（金丝雀变得稳定） 6. 如果任何步骤的错误率超过基线 2 倍，则自动回滚 ### 功能标志使用功能标志将部署与发布分离： # LaunchDarkly / Unleash / 简单配置示例 if feature_flags.is_enabled("new-checkout-flow", user_context): 返回 new_checkout_handler(请求) 其他：返回legacy_checkout_handler（请求） **标记生命周期：** 1. 创建标志（默认：关闭） 2. 为内部用户/beta测试人员启用 3. 逐步推出：5% -> 25% -> 50% -> 100% 4. 在全面部署的 2 个冲刺内删除标志和死代码路径 ** ** ## 安全 ### 秘密管理 **决策矩阵：** 工具|最适合 |避免何时 ---|---|--- **HashiCorp 金库** |动态机密、PKI、加密即服务、多云 |小团队，简单的应用程序 **AWS Secrets Manager** | AWS 原生工作负载，自动轮换 |多云或混合需求 **AWS SSM 参数存储** |非敏感配置，低成本秘密存储 |大规模轮换或审计要求 **Kubernetes 的秘密** | Pod 级注入（启用静态加密）|长期存储秘密或跨集群共享 **SOPS/年龄** | git 中的加密秘密（gitops 工作流程）|团队不熟悉关键管理 **Kubernetes 的 Vault 集成模式：** # 使用 Vault 代理注入器 api版本：apps/v1 种类：部署元数据：名称：应用程序规格：模板：元数据：注释： Vault.hashicorp.com/agent-inject：“真实” Vault.hashicorp.com/role：“应用程序角色” Vault.hashicorp.com/agent-inject-secret-db：“秘密/数据/应用程序/数据库” Vault.hashicorp.com/agent-inject-template-db：| {{- 带有秘密“secret/data/app/db”-}} 导出 DB_HOST={{ .Data.data.host }} 导出 DB_PASSWORD={{ .Data.data.password }} {{-结束-}} 规格：服务帐户名称：app-sa 容器： - 名称：应用程序图片：myapp：1.2.3 命令：[“/bin/sh”，“-c”，“源/vault/secrets/db &&节点server.js”] ### 网络政策默认拒绝并显式允许： # 默认拒绝所有入口和出口 api版本：networking.k8s.io/v1 种类：网络策略元数据：名称：默认拒绝所有命名空间：生产规格： pod选择器：{} 政策类型： - 入口 - 出口 --- # 允许应用程序从入口控制器接收流量并与数据库通信 api版本：networking.k8s.io/v1 种类：网络策略元数据：名称：应用程序网络策略命名空间：生产规格： pod选择器：匹配标签：应用程序：网络政策类型： - 入口 - 出口入口： - 来自： - 命名空间选择器：匹配标签：名称：ingress-nginx 端口： - 协议：TCP 端口：3000 出口： - 至： - pod选择器：匹配标签：应用程序：postgres 端口： - 协议：TCP 端口：5432 - to: # 允许 DNS 解析 - 命名空间选择器：{} 端口： - 协议：UDP 端口：53 ### RBAC 最佳实践 * 遵循最小权限原则：授予所需的最小权限 * 对集群范围的资源使用 ClusterRoles，对命名空间范围的资源使用 Roles * 将服务帐户绑定到角色，而不是用户（服务帐户是可审计和可轮换的） * 使用以下方式审核 RBAC：`kubectl auth can-i --list --as=system:serviceaccount:product:app-sa` * 切勿将“cluster-admin”授予应用程序服务帐户 ### 供应链安全 # 使用 cosign 对容器镜像进行签名余弦符号 --key cosign.key ghcr.io/myorg/myapp:1.2.3 # 部署前验证共同签名验证 --key cosign.pub ghcr.io/myorg/myapp:1.2.3 # 生成SBOM syft ghcr.io/myorg/myapp:1.2.3 -o spdx-json > sbom.json # 扫描 SBOM 是否存在漏洞 grype sbom:sbom.json --失败高 **准入控制**：使用 Kyverno 或 OPA Gatekeeper 执行策略： * 只允许来自受信任的注册表的图像 * 需要图像签名 * 阻止以 root 身份运行的容器 * 对所有 Pod 实施资源限制 ** ** ## 成本优化 ### 规模调整方法 1. **收集** ：从 Prometheus/CloudWatch 收集 2-4 周的 CPU 和内存利用率数据 2. **分析**：识别运行平均 CPU 利用率低于 40% 的实例 3. **推荐**：建议小一号（例如，m5.xlarge -> m5.large） 4. **验证**：应用于staging、负载测试，确认没有性能回归 5. **应用**：在维护时段调整生产规模 6. **监控**：更改后跟踪 1 周以确认稳定性 ### Spot/抢占式实例策略工作负载类型 |现货合适吗？ |图案 ---|---|--- 无状态 Web 服务器（LB 背后）|是的 |混合 70% 现货 + 30% 按需 CI/CD 运行程序 |是的 | 100% 准确并具有重试逻辑批处理/ETL |是的 |带检查点的现货车队数据库/有状态|没有 |使用预留实例 Kubernetes 控制平面 |没有 |按需或预留开发/测试环境 |是的 | 100% 现场，接受干扰 ### 金融运营实践 * **标记策略** ：对所有资源强制添加“团队”、“环境”、“服务”、“成本中心”标签 * **预算提醒**：将 CloudWatch/GCP 预算提醒设置为每月预算的 50%、80%、100% * **预留容量**：为基准工作负载购买 1 年预留（节省 30-40%） * **储蓄计划** ：使用计算储蓄计划 (AWS) 获得灵活的承诺折扣 * **计划扩展** ：在工作时间之外缩小非生产环境的规模 * **存储生命周期**：用于将旧数据移动到 Glacier/Archive 层的 S3 生命周期策略 * **未使用的资源清理**：每周扫描未附加的 EBS 卷、空闲负载均衡器、过时的快照 ** ** ## 事件响应 ### 严重程度分类严重性 |定义|响应时间 |示例 ---|---|---|--- **SEV-1** |全面服务中断、数据丢失风险 | 15 分钟 |生产数据库宕机、支付系统故障 **SEV-2** |严重退化、部分中断 | 30 分钟 |高错误率，API 延迟 > 正常的 10 倍 **SEV-3** |轻微性能下降，可用解决方法 | 4小时|非关键功能损坏，错误率升高 < 1% **SEV-4** |化妆品/信息|下一个工作日 |仪表板渲染问题，日志详细程度激增 ### 运行手册模板 # Runbook: [服务名称] - [问题类型] ## 症状 - 发生火灾时的警报 - 用户报告的内容 - 仪表板显示什么 ## 影响 - 哪些用户/服务受到影响 - 收入影响估计 ## 诊断步骤 1. 检查服务运行状况：`kubectl get pods -n production -l app=myapp` 2. 查看最近的部署：`helm History myapp -n production` 3.检查错误日志：`kubectl messages -l app=myapp -n production --tail=100` 4. 验证数据库连接：`kubectl exec -it app-pod -- pg_isready -h db-host` 5. 检查资源利用率：查看 Grafana 仪表板 [链接] ## 修复 ### 快速修复（< 5 分钟） - 重新启动 Pod：`kubectl rollout restart deployment/myapp -n production` - 扩展：`kubectl 规模部署/myapp --replicas=10 -n 生产` ### 回滚（< 10 分钟） - `helm 回滚 myapp [先前修订] -n 生产` ### 根本原因修复 - [针对此问题的文档修复步骤] ## 升级 - L1：值班工程师 (PagerDuty) - L2：团队领导/服务负责人 - L3：工程副总裁（仅限 SEV-1） ## 通讯 - SEV-1/SEV-2 后 15 分钟内更新状态页面 - Slack 频道：#incidents ### 事后分析过程每起 SEV-1 和 SEV-2 事件都需要在 3 个工作日内进行无过失的事后分析： 1. **时间轴**：每分钟重建所发生的事情 2. **根本原因**：使用“5 Whys”技术来识别根本原因 3. **影响**：受影响的用户、持续时间、收入影响 4. **进展顺利**：有效的检测、沟通和解决方案 5. **哪里不好**：监控空白、反应缓慢、所有权不明确 6. **行动项目**：具体任务的负责人和截止日期，按影响优先排序 7. **经验教训**：未来采用或避免的模式 **模板** ：将事后分析存储在共享 wiki 中。从事件通道将它们链接起来以提高团队可见性。 ** ** ## 参考文档该技能包括三个深入主题的参考指南：参考|路径|封面 ---|---|--- **CI/CD 管道指南** | `references/cicd_pipeline_guide.md` |管道模式、平台比较、优化技术、测试策略 **基础设施即代码** | `references/infrastruction_as_code.md` | Terraform 模式、模块设计、状态管理、提供者配置 **部署策略** | `references/deployment_strategies.md` |策略对比、实施细节、回滚流程、流量管理使用参考文件来获取超出本技能文件涵盖范围的扩展示例和边缘情况处理。 ** ** ## 集成点该技能与库中的其他技能一起使用：技能|整合 ---|--- **高级安全警察** | CI/CD 管道中的安全扫描、容器镜像扫描、合规性检查 **高级建筑师** |基础设施设计决策、服务拓扑、依赖性分析 **高级后端** |应用程序容器化、健康检查端点、配置管理 **高级云架构师** |云平台选型、多区域架构、灾备规划 **事件指挥官** |事件升级程序、通信协议、事后协助 **代码审阅者** |基础设施即代码审查标准、Terraform 计划审查、管道配置审查 **aws-解决方案架构师** | AWS 特定的基础设施模式、服务选择、成本优化 ** ** **最后更新时间：** 2026 年 2 月 **版本：** 2.0.0 **工具：** 3 个 Python 自动化脚本 **参考资料：** 3 个深入指南

高级开发运维人员

包含技能