场景 您的团队使用GitLab CI/CD部署到Kubernetes。一天，一个开发者合并了一个引入关键错误的补丁。流水线通过了所有测试（因为测试过时了），触发了生产部署，错误导致间歇性故障，您的SRE团队在凌晨3点被叫醒。
症状 应用程序在运行，但特定端点返回500错误。部署日志显示成功，但监控显示错误率上升。部署已完成，没有人工干预——在预发和生产之间没有安全检查。
诊断 CI/CD流水线缺少防护栏：没有模拟生产依赖的自动集成测试，没有安全扫描，没有生产前的审批步骤。工件从任意分支自动提升。没有金丝雀分析或自动回滚。
命令
要解决此问题，实施具有质量门禁的流水线：
1. 在 .gitlab-ci.yml 中添加 linting、单元测试、集成测试阶段（npm run test，jest --coverage）。
2. 添加安全扫描阶段（例如 trivy image analyze myimage:tag）。
3. 对生产部署引入手动批准：在生产作业中使用 when: manual 并要求主管工程师批准。
4. 启用金丝雀部署：先部署到10%的pod，运行冒烟测试，然后提升。
5. 使用工件提升：构建一次，通过签名认证跨环境提升。
示例命令：
# 构建并打标签
docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
# 部署金丝雀
kubectl set image deployment/app app=$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA --record
kubectl rollout pause deployment/app
# 运行冒烟测试
# 测试通过后，恢复部署
kubectl rollout resume deployment/app
风险控制 - 默认关闭功能标记。 - 在关键时段实施部署冻结窗口。 - 使用GitLab的合并请求批准和流水线成功作为先决条件。 - 将密钥存储在保险库中，并在运行时注入，而不是在CI变量中。
回滚
- 如果错误率超过阈值，自动回滚：kubectl rollout undo deployment/app。
- 使用GitLab的自动回滚，通过部署后作业检查部署健康状态。
验证 - 确认回滚恢复到了之前稳定的版本。 - 检查应用程序日志和指标。 - 对应用程序运行合成测试。
何时提交OpsGlobal工单 - 如果您的团队需要帮助设计具有适当防护栏的弹性CI/CD流水线。 - 如果尽管有现有防护栏仍发生事件，需要根因分析。 - 如果您需要Kubernetes回滚策略或金丝雀部署的协助。
适用场景
适合正在处理 CI/CD、Kubernetes, SRE 相关问题的团队，用于快速建立排查路径和交付标准。
问题背景
学习如何通过质量门禁、自动化测试和回滚流程，防止有缺陷的部署进入生产环境。
排查步骤
先确认影响范围和最近变更，再收集日志、配置、指标和链路数据，最后按风险从低到高执行修复。
命令示例
示例命令请替换为你的真实资源名，并使用环境变量保存账号、密码、token 等敏感信息。
风险说明
生产环境操作前需要确认备份、权限边界、变更窗口和回滚路径，避免扩大故障影响。
回滚方案
保留原配置和发布版本；如修复后指标异常，立即回退配置、镜像或数据库变更并复核日志。
交付清单
问题定位记录、关键命令、修复步骤、验证结果、后续优化建议。
遇到类似技术问题？
如果你的服务器、K8s、Docker、CI/CD、数据库或监控系统出现类似问题，可以提交日志和配置文件，我们帮你远程诊断。