DevOps 自动化

要解决的具体问题

工程团队常在交付链路上遇到几类反复出现的问题：CI 流水线动辄超过 10 分钟，频繁中断且难定位瓶颈；容器镜像随时间膨胀，安全基线不统一；Kubernetes 部署缺少资源约束与健康检查，发布后难以快速发现故障；GitOps 理念停留在口头，生产环境仍依赖手动 kubectl apply；监控只暴露少量指标，告警规则粗放，真正出问题时却看不到关键信号。

技能如何工作

GitHub Actions 流水线优化

通过 concurrency 取消过期运行，使用 needs 明确作业依赖，利用 setup 阶段的 cache 选项缓存依赖，借助 matrix 做跨版本测试，并用 environment 保护规则限制部署门禁。所有 Action 版本都固定为 SHA，密钥统一存入 GitHub Secrets，云厂商认证改用 OIDC，避免长期密钥。

Docker 多阶段构建

构建时始终使用明确镜像标签而非 latest，最终镜像以非 root 用户运行，仅复制必要文件，通过 .dockerignore 排除 node_modules、.git 与测试目录，并为编排器添加 HEALTHCHECK。镜像标签携带 git SHA，保证可追溯。

Kubernetes 与 Helm 规范

清单中强制设置 requests 与 limits，定义 readinessProbe 和 livenessProbe，零停机发布使用 maxUnavailable: 0。Helm 通过 values-{env}.yaml 管理环境差异，部署前必须执行 helm lint 与 helm template 校验。

ArgoCD GitOps 模式

将 Git 作为集群状态的唯一事实源，所有变更通过 PR 合并，ArgoCD 自动同步并启用 selfHeal 回滚手动修改，应用代码仓库与部署清单仓库严格分离。

监控与告警

暴露关键指标：http_request_duration_seconds、http_requests_total、process_resident_memory_bytes 与 db_query_duration_seconds。当错误率高于 1%、P99 延迟超过 2 秒、内存使用超过限制的 80% 或 10 分钟内 pod 重启超过 3 次时触发告警。

适用边界与注意点

该技能聚焦 DevOps 通用实践，不涉及具体语言的业务逻辑，也未覆盖多集群联邦或混合云编排等复杂场景。其效果依赖团队已具备基础的 Git、Docker 与 Kubernetes 使用经验，若尚未建立 CI/CD 流水线，需先从最小可用流水线开始逐步引入。