DataOps 开篇：当数据管道开始“像软件一样”交付

前言

凌晨三点，电话响了。不是线上服务挂了，是老板在群里贴了一张图：昨天的 GMV 报表，比前天少了整整一个零。

查了两小时，原因让人哭笑不得：上游某个接口改了个字段名，ETL 脚本没报错——它只是默默地把那一列全写成了 NULL。报表照常产出，数字照常是错的。

每个跟数据打过交道的人，大概率都经历过这种"静默的错误"。软件工程花了十年，用 DevOps 把"能跑就行"变成了"可靠交付"；而很多数据管道，还停留在"某人笔记本里的 SQL 脚本 + 人肉巡检"的阶段。DataOps，就是要把这一课补上。

一、DataOps 到底是什么

一句话：把 DevOps 的工程化纪律，系统地应用到数据管道上。

它不是某个工具，而是一组实践：

• 一切进版本控制：SQL、dbt models、Airflow DAGs、配置文件，全部 git 管理，告别"最终版_v7.sql"
• CI for data：每次变更自动跑数据测试，烂数据合不进主分支
• CD for data：管道变更可灰度、可回滚，而不是周五下午直接改生产
• 数据可观测性：新鲜度、数据量、分布漂移，异常自动告警，而不是等老板发现
• 协作与复盘：数据事故也写 postmortem，和线上故障同等对待

二、DevOps vs DataOps：一张对照表

软件工程（DevOps）	数据工程（DataOps）
git 管理代码	git 管理 SQL / models / DAGs
单元测试、集成测试	数据测试：非空、唯一、分布、业务规则
CI 流水线	每次 PR 自动跑数据测试
蓝绿/金丝雀发布	管道变更灰度、快照回滚
APM、日志监控	数据新鲜度、量级、血缘追踪

你会发现，思想完全相通，差的只是"把数据当成一等公民来测试和监控"。

三、先尝一口：5 行拦截烂数据

以 dbt 为例，一条数据测试长这样：

# models/orders.yml
models:
  - name: orders
    tests:
      - dbt_utils.expression_is_true:
          expression: "amount >= 0"   # 订单金额不允许为负

从此，"金额为负"这种脏数据在合并代码前就会被拦下，而不是凌晨三点出现在老板的报表里。这就是 DataOps 的日常：把数据的正确性，变成流水线的一部分，而不是人的责任心。

四、这个系列要讲什么

1. 用 dbt 构建可测试的数据管道
2. 数据质量门禁：Great Expectations 实战
3. 数据可观测性：从指标到血缘
4. 数据管道的 CI/CD 与回滚策略

结语

DevOps 让软件交付从"艺术"变成了"工程"。DataOps 要做的，是让数据交付也走完这条路。下周三见，我们从 dbt 开始动手。