第5章：交付与运维——环境、CI/CD 与调度
第 5 章 · 交付与运维：环境、CI/CD 与调度
章节摘要：项目在一个人机器上跑通只是验收，能天天按时、按口径、可回溯地跑在生产环境才算交付。本章讲交付的三根支柱：环境管理回答「开发的东西怎么保证在生产行为一致」；持续集成与部署回答「代码从合并到上线之间谁来把关」；调度与监控回答「上线之后每天凌晨谁来盯着它跑」。读完本章，你的 dbt 项目就从「工程」变成了「每天在生产的系统」。
学习目标
阅读完本章，你应当能够：
- 为项目设计一套多环境方案，说清环境之间隔离什么、共享什么，以及为什么凭据绝不能进版本库；
- 配置一条最简持续集成流水线：合并请求触发「编译检查加受影响模型测试」，把坏代码拦在合并之前；
- 区分「持续集成」与「持续部署」在数据语境下的不同：验证的是代码，交付的是数据；
- 为生产调度选择合适的宿主（仓库定时任务、通用调度平台或托管平台），并说明取舍依据；
- 建立一套四维监控：任务成败、时长趋势、数据新鲜度、行数波动，并为每维定告警阈值。
本章知识点清单
- 环境隔离的三个对象：目标仓库区域、连接凭据、物化参数；
- 环境间共享的部分：代码版本、依赖图、测试定义；
- 持续集成的最小闭环：编译、选择性测试、结果反馈到合并请求；
- 选择性执行：只跑受改动影响的上游链与下游链；
- 持续部署的数据特殊性：验证代码快、验证数据慢；
- 调度三宿主的取舍：定时任务、调度平台、托管平台；
- 四维监控与阈值设计：什么叫「正常波动」，什么叫「该叫人」。
核心概念速览
交付链路是一条流水线：开发者提交代码，持续集成为每次合并请求跑一轮「编译加测试」的体检；合并进入主干后，持续部署把通过体检的代码送到生产环境；生产环境的调度按计划触发构建，监控守在旁边，出事就响。四个环节各自有各自的质量关，前一环放行的东西，后一环默认信任。
一句话锚点：环境管一致性，CI 管把关，调度管节奏，监控管兜底——四样齐了，项目才算真的「在生产上住下了」。
交付阶段的成本观
这一章的许多决定（要不要第三套环境、要不要上调度平台、CI 频率多高）本质都是成本决策，带着一把统一的尺子进场会清醒很多：每一项机制都在花「人力成本」买「事故成本」的下降。环境隔离花一次搭建成本，买的是「我这明明是好的」这类排查时间的归零；CI 花每次数分钟到数十分钟的算力，买的是坏代码进生产的概率下降；监控花阈值调校的耐心，买的是故障发现时间的提前。反之亦然——省掉的机制不会让成本消失，只会把它推迟成更贵的形态：没有 CI，代价出现在生产事故里；没有监控，代价出现在业务方的信任里。
判断一件事情该不该在这一章做，可以问：它预防的事故，历史上在我们团队发生过吗（发生过，优先级高）；它预防的事故一旦发生，影响半径多大（波及业务方，优先级高）；它的维护成本会不会随团队规模失控（会，就要用工具替代人肉）。三问下来，每个团队的最简交付方案都不相同——本章给的是选项与判断依据，不是要你全盘照搬。
子章节导航
5.1 环境管理策略 —— 开发、集成、生产三套环境的隔离清单：目标区域怎么分、凭据怎么注入、哪些东西必须三边一致。环境不一致是「我这明明是好的」型事故的总根源。
5.2 持续集成与部署 —— 把软件行业的 CI/CD 翻译到数据语境：合并请求触发的体检跑什么、怎么只跑受影响的模型、部署到生产时为什么要先验证代码再验证数据。
5.3 任务调度与监控 —— 跑批的节奏与看护：调度宿主的三种选择、构建批次与上游到货的衔接、四维监控的阈值设计。调度的本质不是定时，是「在正确的前置条件满足后执行」。
子章节之间的逻辑关系
三节是交付生命周期的三段：先有一致的环境（5.1），代码才能在流水线里可信地验证与发布（5.2），发布之后由调度与监控接管日常运转（5.3）。前一段的产出是后一段的前提——没有环境一致性，CI 的绿灯没有意义；没有 CI 的把关，调度跑的可能是没体检过的代码。
5.1 环境（地基一致） => 5.2 CI/CD（发布把关） => 5.3 调度与监控（日常运转）
前置知识与后续延伸
前置知识：第三章的项目结构（环境方案直接作用在项目配置上）、第四章的性能概念（调度批次划分与错峰思路来自 4.3 节）。了解 Git 的分支与合并请求机制即可，不需要运维背景。
往后的延伸：交付之后项目的重心转向治理——文档会不会过时、血缘能不能回答影响面问题、权限怎么管，这些是第六章的内容。本章的环境方案在第六章安全一节还会被再次引用：凭据管理与访问控制是同一枚硬币的两面。