📚 课程目录第4章 DevOps基础

4. DevOps基础：CI/CD概念、基础设施即代码（IaC）、配置管理、监控与日志

在进入多云AI DevOps端到端自动部署实战之前，必须先厘清支撑整个体系的五大支柱：持续集成（CI）、持续交付/部署（CD）、基础设施即代码（IaC）、配置管理以及监控与日志。这五者并非孤立工具，而是构成一条从“代码提交”到“生产稳定运行”的价值流管道。理解它们之间的数据流与反馈闭环，是后续设计多云流水线的基础。

4.1 核心原理：CI/CD与部署策略

CI/CD的本质是将软件交付过程自动化、可重复、可审计。CI（持续集成）强调开发人员频繁地将代码变更合并到主干分支，并通过自动化构建与测试快速发现集成问题。CD（持续交付）则确保代码随时处于可部署状态，而持续部署更进一步，将每一次通过验证的变更自动发布到生产环境。

在多云场景下，CD的关键在于环境一致性与不可变基础设施。下图展示了从代码提交到多云部署的核心流水线及各阶段反馈回路：

图中特别强调了监控与日志的反馈箭头直接指回代码提交阶段，这体现了DevOps的“持续改进”闭环。在多云环境中，该闭环必须跨云统一采集数据，否则无法形成全局视图。

4.2 基础设施即代码（IaC）与配置管理

IaC是将云资源（虚拟机、网络、负载均衡器等）的定义以代码形式管理，核心工具为Terraform或OpenTofu。其关键价值在于：

幂等性：同一份配置反复执行，结果一致。
版本化：基础设施变更可回滚、可审计。
环境一致性：开发、测试、生产环境通过同一份代码生成，消除“在我机器上是好的”问题。

配置管理则关注运行时状态。IaC负责“创建一台安装Nginx的虚拟机”，而配置管理（如Ansible）负责“确保Nginx配置为反向代理并指向后端服务”。在多云场景中，两者必须协同：

# Terraform 定义多云资源（简化示例）
resource "aws_instance" "app" {
  provider      = aws.region1
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.micro"
  user_data     = file("init.sh")   # 调用配置管理脚本
}

resource "azurerm_linux_virtual_machine" "app" {
  provider            = azurerm.sub1
  name                = "vm-app"
  location            = "eastasia"
  resource_group_name = azurerm_resource_group.rg.name
  custom_data         = base64encode(file("init.sh"))
}

上述代码中，init.sh 通常调用Ansible进行应用配置。这种“Terraform拉起资源 + Ansible配置状态”的组合，是多云AI部署中最常见的实践。

4.3 监控与日志：可观测性三支柱

监控与日志是DevOps的“眼睛”。在多云AI系统中，需要统一采集三类数据：

类型	工具示例	多云关注点
指标监控	Prometheus + Thanos	跨云统一指标查询，避免数据孤岛
日志聚合	Loki / ELK	集中存储各云日志，支持关联Trace ID
链路追踪	Jaeger / Tempo	追踪跨云服务调用链，定位性能瓶颈

一个典型的AI推理服务监控配置片段如下：

# Prometheus 抓取配置（多目标）
scrape_configs:
  - job_name: 'ai-inference-aws'
    metrics_path: '/metrics'
    static_configs:
      - targets: ['10.0.1.5:8000']   # AWS EKS Pod
  - job_name: 'ai-inference-azure'
    metrics_path: '/metrics'
    static_configs:
      - targets: ['20.10.2.8:8000']   # Azure AKS Pod

注意：在多云场景中，必须为每个云环境的指标打上统一的标签（如 cloud="aws"），否则后续的聚合查询和告警规则将无法跨云工作。

4.4 案例场景：跨云AI模型部署的DevOps流水线

假设某AI团队需要将训练好的模型同时部署到AWS（主）和Azure（灾备）。完整的DevOps流程如下：

代码提交：开发者推送模型代码与推理服务代码到Git仓库，触发CI。
CI阶段：GitLab Runner执行单元测试、模型精度验证，构建Docker镜像并推送到镜像仓库。
IaC阶段：Terraform执行 terraform plan 对比当前云资源与期望状态，自动创建或更新两朵云上的Kubernetes节点池。
CD阶段：ArgoCD检测到新镜像版本，自动同步部署到AWS EKS；通过审批后，再部署到Azure AKS。
配置管理：Ansible Playbook在Pod启动后执行，注入模型版本号、数据库连接串等配置。
监控反馈：Prometheus采集两朵云的推理延迟、错误率。若AWS实例故障，告警触发自动故障转移，流量切换至Azure。

该案例中，IaC保证了资源的一致性，配置管理保证了应用的一致性，而监控则提供了切换决策的依据。三者缺一不可。

4.5 常见误区与复盘

误区一：将IaC与配置管理混为一谈。 有些团队只用Terraform安装软件，导致每次执行都重新安装或状态漂移。正确做法是：Terraform只负责资源生命周期，软件状态交给Ansible或容器镜像。

误区二：监控只覆盖单云。 在多云环境中，如果只监控主云，当流量切换到灾备云时，运维将“失明”。必须从一开始就建立跨云的统一监控面板。

复盘建议： 在流水线中加入“配置漂移检测”步骤。例如，每周运行一次 terraform plan 并检查Ansible的 --check 模式，将差异作为告警处理。这能提前发现手动修改云控制台导致的配置漂移。

最后需要强调的是，CI/CD、IaC、配置管理、监控日志并非一次性搭建完成，而是需要随着AI模型的迭代持续演进。建议团队从“最小可行流水线”开始，先打通单云环境，再逐步扩展至多云，每一步都确保监控反馈闭环完整，这样才能真正实现端到端的自动部署与稳定运行。