描述投放系统的CI/CD流程，包括代码提交、自动化测试（单元测试、集成测试）、部署到生产环境，以及如何监控部署后的系统状态（如使用Prometheus、Grafana等工具）。

【一句话结论】
投放系统的CI/CD流程遵循“代码提交→安全扫描→代码审查→自动化测试（单元/集成/端到端）→测试环境验证→生产蓝绿部署→生产监控（Prometheus+Grafana）”的流水线，通过工具链（如GitLab CI）实现全流程自动化，确保代码安全、环境隔离，并借助动态告警及时响应生产问题。

【原理/概念讲解】
CI/CD是持续集成与持续部署的缩写，核心是将开发、测试、部署等环节自动化。具体环节如下：

• 代码提交：开发者将代码推送到Git仓库（如feature/xxx分支）。
• 安全扫描：提交后，通过SonarQube等工具进行静态代码分析（检查代码质量、安全漏洞，如SQL注入、XSS），并设置质量门禁（如漏洞率超过0.5%则阻止部署），确保代码安全。
• 代码审查：通过GitLab的Code Review功能，由团队评审代码（检查逻辑、规范、潜在问题，如代码可读性、性能优化点）。
• 单元测试：针对单个模块的测试（如业务计算函数），验证核心逻辑（例如，计算投放预算的函数，输入不同参数，输出正确结果）。
• 集成测试：多个模块组合的测试（如调用“任务调度服务”接口，验证数据交互正确性，例如，提交投放任务后，数据库记录是否更新）。
• 端到端测试：模拟用户完整业务流程（如投放任务从创建到执行完成），验证系统整体功能（例如，用户创建投放计划，系统自动分配资源并执行，最终返回结果）。
• 测试环境部署：测试通过后，通过K8s将代码推送到测试K8s集群，验证业务逻辑（例如，测试投放任务是否能正常创建和执行）。
• 生产部署：测试环境验证通过后，采用蓝绿部署（或金丝雀）：先启动新版本（绿），通过Prometheus检查新版本服务健康状态（如请求延迟<200ms，错误率<1%），再切换流量（如Nginx反向代理从旧版本（蓝）切换到新版本（绿）），最后下线旧版本（蓝）。
• 生产监控：生产环境部署后，用Prometheus采集系统指标（如请求延迟、错误率、QPS、资源使用率），通过Grafana可视化，设置动态告警阈值（如错误率超过1%时触发告警，并设置10分钟抑制时间避免误报，Slack通知运维团队）。

【对比与适用场景】（测试类型对比）

对比项	单元测试	集成测试	端到端测试
定义	单个模块的测试	多个模块组合的测试	完整业务流程的测试
特性	快速（秒级），覆盖核心逻辑	检查交互，较慢（分钟级）	模拟真实场景，验证整体功能
使用场景	日常提交，快速反馈	集成后验证接口正确	部署前验证业务流程
注意点	覆盖关键逻辑，避免冗余	模拟真实环境，覆盖边界条件	控制测试频率，避免资源浪费

【示例】
假设代码提交到Git的feature/new_strategy分支，触发GitLab CI：

1. 安全扫描：GitLab CI调用SonarQube，检查代码质量（如代码重复率>15%则提示优化）和安全漏洞（如发现SQL注入风险，标记为高危），若漏洞率超过0.5%，则停止后续流程。
2. 代码审查：团队通过GitLab Review Board评审代码，通过后进入测试阶段。
3. 单元测试：执行mvn test，测试用例覆盖核心逻辑（如计算投放预算的函数，输入1000和0.5，输出500），全部通过。
4. 集成测试：调用“任务调度服务”接口，提交投放任务，验证数据库记录是否正确（如任务状态为“待执行”），通过。
5. 端到端测试：模拟用户创建投放计划，系统自动分配资源并执行，最终返回成功结果，通过。
6. 测试环境部署：执行kubectl apply -f test-deployment.yaml，启动测试环境服务，验证投放任务功能正常。
7. 生产部署：测试通过后，触发生产部署，采用蓝绿部署：
   • 启动新版本（绿），通过Prometheus检查指标（如请求延迟P99<200ms，错误率<1%），满足条件后，Nginx反向代理将流量从旧版本（蓝）切换到新版本（绿）。
   • 切换流量后，监控新版本指标，若稳定运行1小时，则下线旧版本（蓝）。
8. 生产监控：Prometheus采集指标，Grafana可视化，设置告警规则（如错误率>1%时，Slack发送告警，运维团队在10分钟内响应，若问题持续，触发K8s回滚）。

【面试口播版答案】
投放系统的CI/CD流程是全链路自动化的，具体步骤是：代码提交到Git仓库后，首先触发安全扫描（用SonarQube检查代码质量和安全漏洞，设置质量门禁），通过后进行代码审查。接着执行自动化测试，包括单元测试（验证核心逻辑）、集成测试（验证模块间交互）、端到端测试（模拟完整业务流程），测试通过后部署到测试环境验证。测试环境验证通过后，采用蓝绿部署到生产环境，通过Prometheus检查新版本健康状态，再切换流量。生产环境部署后，用Prometheus+Grafana监控指标（如请求延迟、错误率），设置动态告警（如错误率超过1%时触发告警并抑制10分钟，避免误报），确保系统稳定运行，及时响应问题。

【追问清单】

• 问：安全扫描工具具体如何配置？答：使用SonarQube集成到GitLab CI，配置规则（如漏洞等级为高危时阻止部署），并设置质量门禁（如漏洞率>0.5%则停止流程）。
• 问：测试环境与生产环境的隔离措施？答：测试环境使用测试数据库（如MySQL测试实例），生产环境使用生产数据库；测试环境配置与生产环境隔离（如测试环境配置文件中数据库地址为test-db，生产环境为prod-db），确保数据隔离。
• 问：部署后流量切换的健康检查具体怎么做？答：通过Prometheus的ServiceMonitor检查新版本服务的健康状态（如检查http://new-service:8080/health端点返回200），若健康，则通过Nginx反向代理切换流量，否则回滚。
• 问：监控告警策略如何设置？答：设置动态阈值（如错误率>1%时触发告警，并设置10分钟抑制时间避免误报），告警通过Slack通知运维团队，若问题持续，触发K8s回滚机制（如kubectl rollout undo）。
• 问：如何保证测试覆盖率？答：通过代码审查（如SonarQube检查核心逻辑覆盖率达到80%以上）和自动化测试工具（如JUnit、Postman），确保关键接口100%覆盖。

【常见坑/雷区】

• 忽略安全扫描：直接跳过代码安全检查，导致生产环境出现漏洞（如SQL注入）。
• 环境隔离不足：测试环境与生产环境数据未隔离，导致测试数据污染生产数据，影响测试结果。
• 健康检查缺失：部署后未验证新版本服务健康状态，导致流量切换到故障版本，影响用户体验。
• 告警阈值设置不合理：阈值过高导致告警无效（如错误率>5%才告警，但问题已发生），阈值过低导致误报（如错误率>0.1%就告警，影响运维效率）。
• 回滚机制缺失：部署后出现问题时，无法快速回滚，导致业务中断（如K8s部署后无回滚脚本，需手动操作）。