engineering-devops-automator

DevOps 与基础设施指南

概述

本指南涵盖基础设施自动化、CI/CD 流水线开发、部署策略、监控和云运维。可在配置基础设施、构建流水线、设置可观测性、管理密钥或规划灾难恢复时参考。

前 10 分钟

• 提出变更前，先盘点交付范围：CI 配置、基础设施目录、运行时清单、Dockerfile 和可观测性配置。
• 编辑任何内容之前，先运行现有的验证命令。如果代码库没有用于验证基础设施变更的流程，请将其作为任务的一部分添加。
• 在提出发布变更之前，使用 scripts/analyze_deployment_risk.py 分析代码库根目录，汇总 CI、Docker、Terraform 和 Kubernetes 相关信号。
• 确定当前部署系统的回滚路径。如果无法在 5 分钟内说明如何撤销变更，发布计划就不完整。

拒绝或升级处理

• 如果没有回滚路径、健康信号，或无法在生产环境之外测试变更，请拒绝“直接推上去”的请求。
• 如果计划涉及替换数据库、Terraform 销毁操作、状态迁移、证书轮换，或在没有补偿性控制措施的情况下扩大安全组范围，请在更改生产状态前升级处理。
• 如果代码库混用了多个部署系统，且所有权边界不明确，请升级处理。理清这些问题应作为单独任务。
• 不要默认推荐 Kubernetes。如果工作负载是单个服务，网络简单且规模可预测，请继续使用更简单的运行时。

基础设施决策规则

配置

• 使用带远程状态（S3 + DynamoDB 锁）的 Terraform，以便对每项资源进行版本控制，并避免并发修改。
• 使用 Terraform 工作区，或按环境划分目录并搭配共享模块的布局，以发现预发布环境与生产环境之间的偏差。
• 使用与生产环境相同的 Terraform 模块，通过变量覆盖差异——绝不要通过云控制台创建基础设施。

CI/CD 流水线

• 将流水线划分为独立阶段（lint、test、build、scan、deploy），并明确指定依赖关系，确保安全检查失败时会阻止部署。
• 部署策略：蓝绿部署适用于实现零停机和即时回滚；金丝雀发布适用于逐步转移流量并依据指标推进；当简单性更重要且可接受短暂的混合版本流量时，使用滚动部署。
• 任何手动步骤执行超过两次后都应自动化；删除对应的手动操作手册条目，以免产生偏差。

容器化

• 使用多阶段 Docker 构建，并在最终镜像中使用 distroless 或 Alpine，以尽量缩小攻击面。
• CI 必须运行 Trivy（或同等工具），并在合并前因 CRITICAL/HIGH 级问题而失败。

监控与可靠性

• 对四项黄金信号（延迟、流量、错误、饱和度）进行监测；针对症状而非原因发出告警。
• 每条告警都必须关联操作手册；在一个迭代周期内删除没有操作手册的告警，或将其转换为仪表板指标。
• 强制使用结构化 JSON 日志；将日志发送到集中式系统（ELK、Loki），并按照合规要求设置保留期限。
• 配置存活探针，实现 30 秒内重启；设置 PodDisruptionBudget，确保中断期间的可用性。

灾难恢复

• 自动执行故障转移，并每季度测试操作手册；未经测试的灾难恢复计划等于没有计划。

成本优化

• 每月审查云资源利用率；将连续 14 天平均 CPU 使用率低于 20% 的任何实例降配。

密钥管理

• 将密钥存储在 Vault 或 AWS Secrets Manager 中，并启用自动轮换（最长 TTL 为 90 天）；在运行时注入密钥。
• 绝不要将密钥提交到源代码控制系统或将其烘焙到镜像中。

网络安全

• 默认将所有安全组和 NACL 的入站流量设为全部拒绝；仅开放所需端口/CIDR；每月清理一次。

合规性

• 自动生成审计日志，记录部署者、提交 SHA 和审批信息；在整个保留期内以不可变方式存储。

事件响应协议

• 严重级别 1（站点宕机、存在数据丢失风险）：在 5 分钟内召集事件响应团队。首要行动：缓解影响（回滚、故障转移、扩容），而非诊断。15 分钟内向利益相关方通报状态。48 小时内完成事后复盘。
• 严重级别 2（性能下降、部分服务中断）：值班工程师在 15 分钟内响应。检查：近期部署（如果部署发生在 1 小时内则回滚）、基础设施告警（CPU、内存、磁盘）、依赖项健康状况（下游服务、数据库）。30 分钟内通报状态。
• 严重级别 3（小问题，存在变通方案）：记录问题，创建工单，在下一个冲刺中修复。无需立即响应。
• 回滚决策：如果问题在过去 4 小时内的某次部署后出现，先回滚，再调查。如果问题与部署无关，则升级给相关服务团队。
• 沟通模板：“我们已注意到 [影响描述]。[X 名用户 / Y% 的流量] 受到影响。我们正在[当前采取的措施]。[时间]后更新进展。”

成本估算公式

• 计算（EC2/GCE）：monthly_cost = instance_hourly_rate * 730 * instance_count。对于稳定运行的工作负载，预留实例可节省 30-60%（承诺使用 1 年）。
• 存储（S3/GCS）：monthly_cost = storage_GB * $0.023 + requests * $0.0004 (GET) or $0.005 (PUT)。启用生命周期策略：30 天后转为不频繁访问存储，90 天后转为 Glacier。
• 数据库（RDS/Cloud SQL）：monthly_cost = instance_hourly_rate * 730 + storage_GB * $0.115 + IOPS_provisioned * $0.10。Multi-AZ 会使实例成本翻倍。
• 数据传输：每月前 1GB 免费。向互联网传出数据的费用为 $0.09/GB。跨可用区传输：每个方向 $0.01/GB。跨区域传输：$0.02/GB。数据传输是容易被忽略的成本 — 请持续监控。
• Kubernetes（EKS/GKE）：cluster_cost = control_plane ($73/month EKS) + node_instance_costs + data_transfer。对于容错型工作负载，Spot/可抢占节点可节省 60-90%。
• 经验法则：如果每月云账单 >$5k，请安排 FinOps 审查。如果 >$50k，请使用 AWS Cost Anomaly Detection 或类似工具自动检测成本异常。

服务选择决策树

• 计算：如果执行时间 <15 分钟、内存 <10GB，且由请求驱动，则使用 Lambda/Cloud Functions。对于流量稳定的容器化服务，使用 ECS/Cloud Run。只有在运行 >10 个服务且存在复杂网络需求时，才使用 EKS/GKE。
• 数据库：对于 <10TB 的关系型数据，使用 RDS PostgreSQL。对于 >100k QPS 的键值数据，使用 DynamoDB。使用 ElastiCache Redis 进行缓存和会话存储。如果需要兼容 PostgreSQL 并支持自动 Multi-AZ 故障转移，则使用 Aurora。
• 队列/消息传递：简单的异步任务使用 SQS。扇出场景使用 SNS + SQS。带筛选规则的事件路由使用 EventBridge。只有在需要支持 >10k 条消息/秒且需要重放时，才使用 Kafka (MSK)。
• 存储：对象存储使用 S3。共享文件系统（NFS）使用 EFS。块存储（数据库卷）使用 EBS。根据访问频率选择存储类别。
• CDN：AWS 原生场景使用 CloudFront。多云场景或 DDoS 攻击较多时使用 Cloudflare。所有静态资源以及任何可缓存时间 >5 秒的 API 响应都应使用 CDN。

自我验证协议

进行任何基础设施或流水线变更后，请验证：

• Terraform：运行 terraform plan 并逐行阅读所有差异。如果计划显示要对生产资源执行任何 destroy 或 replace，请停止并确认操作意图。
• CI/CD 流水线：在非生产分支上触发一次完整的流水线运行。确认每个阶段都通过。检查安全扫描门禁是否确实会因发现问题而阻止流水线（故意引入一个已知的 CVE 进行测试）。
• 监控：设置警报后，手动触发每个警报（让 CPU 使用率飙升、终止健康检查、填满磁盘）。确认警报在预期时间内触发，并发送到正确的渠道。
• 灾难恢复：配置备份后，执行一次恢复到测试环境的操作。确认数据完整性。如果无法恢复，就没有备份——你只是有了虚假的安全感。
• 机密信息：确认机密信息不会出现在以下位置：CI/CD 日志（屏蔽变量）、Docker 镜像层（docker history）、Terraform 状态（使用 sensitive = true）或 git 历史记录（git log -p | grep -i password）。

故障恢复

• Terraform 状态漂移：运行 terraform plan 查看漂移。如果漂移出现在非关键资源中，运行 terraform apply 进行协调。如果漂移出现在关键资源中（数据库、负载均衡器），请调查由谁或什么手动更改了该资源，并谨慎进行协调。当状态显示意外变更时，切勿盲目运行 terraform apply。
• CI/CD 流水线故障：检查最近一次成功的运行。对比最近一次成功与当前失败之间的流水线配置差异。常见原因：机密信息/令牌过期、依赖项版本升级、Runner 镜像更新，或注册表限流。
• 生产环境中的容器因 OOM 被终止：检查 kubectl describe pod 中的 OOM 事件。如果内存限制配置不足，请提高限制。如果内存用量随时间线性增长，说明应用存在内存泄漏——应修复应用，而不是提高限制。
• 证书过期：使用 cert-manager（Kubernetes）或 ACM（AWS）自动续期。设置在过期前 30、14 和 7 天触发的警报。如果证书已过期：立即续期，检查所有使用该证书的服务，并确认它们已加载新证书（可能需要重启 Pod）。
• 磁盘已满：找出占满磁盘的内容：日志（轮转并压缩）、Docker 镜像（清理未使用的镜像）、数据库 WAL（检查复制延迟）或临时文件。修复根本原因；扩展磁盘只是临时措施。

脚本

• scripts/validate_dockerfile.sh -- 检查 Dockerfile 是否符合常见最佳实践：多阶段构建、USER 指令、HEALTHCHECK、不使用 latest 标签、优先使用 COPY 而非 ADD，以及是否存在 .dockerignore。运行 --help 查看用法。
• scripts/check_services.sh -- 检查一系列 host:port 对的 TCP 连通性和 HTTP 响应。报告状态、延迟和 HTTP 状态码。运行 --help 查看用法。

代码示例

请参阅 CI/CD 流水线指南，了解包含安全扫描、容器构建以及带冒烟测试的蓝绿部署的完整 GitHub Actions 流水线。

请参阅 基础设施与监控指南，了解 Terraform（启动模板、ASG、ALB、CloudWatch 警报）和带有警报规则的 Prometheus 配置。

工作流

步骤 1：基础设施评估

• 审核现有基础设施、部署流程和监控盲区。
• 梳理应用依赖关系和扩展要求。
• 确定目标环境的安全和合规要求。

步骤 2：流水线设计

• 设计集成安全扫描的 CI/CD 流水线。
• 规划部署策略（蓝绿、金丝雀、滚动）。
• 创建基础设施即代码模板。
• 设计监控和警报策略。

步骤 3：实施

• 搭建带自动化测试的 CI/CD 流水线。
• 使用版本控制实施基础设施即代码。
• 配置监控、日志记录和警报系统。
• 创建灾难恢复和备份自动化流程。

第 4 步：优化与维护

• 监控系统性能并优化资源。
• 实施成本优化策略。
• 创建自动化安全扫描和合规性报告。
• 构建具备自动恢复能力的自愈系统。

交付内容

• 部署策略，明确回滚步骤、健康检查门禁和责任归属。
• 基础设施变更摘要，列出有状态资源、影响范围和审批节点。
• CI/CD 计划，涵盖 lint、测试、构建、扫描、部署和部署后验证。
• 与变更服务相关的监控和告警检查清单，而非泛泛的仪表板愿望清单。

参考资料

• CI/CD 流水线指南 -- GitHub Actions 流水线，包含安全扫描、容器构建和蓝绿部署。
• 基础设施与监控指南 -- Terraform（启动模板、ASG、ALB、CloudWatch 告警）和 Prometheus 配置。
• Kubernetes 模式 -- 生产环境 Deployment、HPA、PDB、ConfigMap/Secret 挂载、带 TLS 的 Ingress、CronJob 和 Helm values。
• Docker 最佳实践 -- 多阶段 Dockerfile（Node.js、Python、Go）、.dockerignore、Docker Compose 和 Trivy 扫描。
• 监控与可观测性 -- 结构化日志、Prometheus 指标、Grafana 仪表板、告警规则、OpenTelemetry 跟踪和健康检查。
• 事件分诊 -- 以代码仓库为先的生产事件处理流程、回滚决策树和证据收集检查清单。
• 部署回滚指南 -- Canary、蓝绿、滚动、架构变更和功能标记回滚模式。