上周帮朋友看他们数据平台的架构图。A3 纸打出来，我数了数，二十七个组件。Kafka、Spark、dbt、Airflow、Iceberg、Fivetran、Great Expectations，还有一个我到现在都念不顺名字的数据目录。
我问了一句：出问题的时候，谁知道看哪层？
没人。这就是问题。
我入数据这行不算早，之前写后端。当年最烦数据团队那套——改个报表口径走两周流程。跳进来才知道，不是他们慢，是这条链路天生就长：源头一个业务库，中间 CDC、入湖、三层 medallion、dbt 转换，最后落到 BI。bronze、silver、gold，听着像炼金，实际是每一层都可能悄悄坏掉。
坏得很安静。
这是数据管道最阴的地方。在线服务挂了就告警，人来。它不挂，它慢慢地错——上游改个字段含义，中间没人发现，gold 层指标偏了 3%，三个月后某次对账才炸出来。然后呢？凌晨一屋子人对着 lineage 图找那条断掉的边。
说到 lineage。这词被吹得很玄，OpenLineage 都成简历热词了。我见过的真实情况：lineage 图 99% 的时候是给领导看的架构装饰品，1% 的时候救命。而那 1% 救不了——因为平时没人维护，图早跟现实脱节了。真排障的时候，靠的还是那个唯一记得“这张表谁建的”的老员工。他正在休假。
扯远了，回到 A3 纸。
朋友说想上 Monte Carlo 做数据质量监控，理由是「人工写 dbt tests 太累了」。我说行，先答我一个问题：异常告警出来谁看？他说……应该还是他。
这就是我一直想说的。这十年数据平台的方向就俩字：加工具。ingestion 用 Fivetran 省手写管道，转换用 dbt 省存储过程，编排用 Airflow 省 cron，监控再买个 SaaS 省人眼。每步单看都合理，都提效。
合起来呢？一条没人能从头讲到尾的链路，加一排彼此不通气的 dashboard。
厂商卖的时候都叫「self-service」——自助式数据平台，业务同学自己取数。真到数字不对，self 就没了，service 的是那一个倒霉的数据工程师。这剧本我看过：十年前 BI 工具卖的 self-service analytics，卖点一样，分析师不用求工程师写 SQL。十年过去，需求没少，工程师也没少，只是多了几个排版漂亮的错误仪表盘等着人查错。换皮而已。
我的判断，说出来可能得罪人：这堆工具里真正值钱的不是任何单个组件，是“这张表归谁”这个问题有没有答案。数据治理那帮人管这叫 ownership，配了一堆流程。流程没用——除非那个人知道，表错了，pager 找的是他。
好的团队我见过。规模不大，工具少得可怜，一个 warehouse、一个 dbt、一个 Airflow，数据目录就是 wiki 上一页。但每张核心表名字后面跟着一个具体的人。烂的也见过：全套 lakehouse 加实时链路，Slack 里问“这个指标谁负责”，沉默十分钟，有人回：可能是数据组吧。
后者出事故是必然的，时间问题。而且我赌它坏在凌晨——白天大家都在改东西，问题被变更掩护着，夜里没有新变更了，它才浮出来。
朋友最后问，那要不要砍几个组件。我说先别砍。这是我要收回的一句：前面骂了一堆工具，说句实话，有些烂不是工具的错，是人手本来就不够、deadline 本来就紧，工具是被当救命稻草买进来的。砍工具容易，砍完活还是那些活，接电话的还是同一个人。
该做的只有一件小事：拿那张 A3 纸，圈出核心链路上必须活着的五个组件，每个写一页 runbook——坏了看哪、找谁、回滚几步。写不出来的那个，就是下一个事故现场。
runbook 让 AI 起草可以，人得逐条签字。
起草归它，半夜归你。