作者王贯扬干数仓运维这些年我早上有一套固定仪式打开调度平台看昨晚有没有任务挂掉切到监控大盘扫一眼数据量开个查询窗口跑几条 SQL 确认核心表的数据到位没有最后翻翻告警记录。顺利的话二十分钟。不顺利就说不好了某张表数据量掉三成或者一个任务连挂三次接下来看日志、查执行计划、捋上下游依赖有时候还得翻历史数据比对一个上午就交代进去了。这些事不难难的是每一步都得有人盯着由人决定下一步看哪里。上周一次值班这套流程我只花了两小时顺手还多干了两件事。快是真快但让我琢磨的不是这个。把巡检交出去那天我没自己动手把活儿交给了 AI。prompt 就一句话对账单 workspace 做一次运维巡检查连接状态、过去 24 小时的任务健康度、核心账单表的数据时效性、最近 7 天的数据量趋势、主要字段的数据质量最后给我一份结构化报告。我没说查哪张表连字段名都没提。它先确认连接巡检使用的用户身份巡检目标的工作空间。然后开始跑。过去 24 小时的任务SUCCEED 755,294 条FAILED 1,690 条成功率 99.66%平均执行 0.15 秒最长的一个跑了 422 秒。99.66% 听着挺好它却把这条标成了需要关注理由是 1,690 条失败是个绝对数字比率好看不等于没事。422 秒那个任务也被单独拎出来了。查时效性的时候出了个小插曲。它猜 billing_summary_mv 上有 billing_month 和 updated_at 这两个字段账单表嘛一般都有。结果查询报了语义分析错误字段不存在。它没回头问我字段名是什么自己跑了条 DESCRIBE拿到全部 36 个字段看到分区字段是 ds换 ds 重查最新数据就是当天时效正常。我是事后翻执行记录才看到这段的心想这也行顺带它还翻出一个盲点created_at 全表是 NULL。谁以后想拿写入时间判断时效这条路走不通。它记了一笔建议确认要不要补写入逻辑。最近 7 天的数据量前六天稳定在 8,700 到 9,700 之间当天只有 4,375 条日均的一半不到。我心里咯噔一下“上游不会断了吧”。它给的标注要平和得多当天数据尚未完整写入建议下午再次确认。想想也对先放着。然后是那个数字。amount 为 NULL 的记录占 17.4%。这个比例放在哪张核心表上都不小。可能是历史迁移留下的也可能某些内部计量项没有对客收费。它标注了“严重”结论等着我来做。报告最后分六个部分每部分都有具体数字没有一个含糊的形容词。我直接转给了团队一个字没改。但我盯着其中两条记录看了很久。猜错字段名的时候它连问都没问我一声自己就改了碰到 17.4%它明明可以顺嘴编一句“历史遗留无需处理”却一个字的结论都不给。同一个 AI一边胆子大得吓人一边又谨慎得过分。同一套规矩的两面后来我想明白了这两个行为是同一套规矩的两面。“怎么做”这一层整个归AI。我说要什么它负责找方法挑哪张表、写什么 SQL、猜字段名、猜错了改全是它领域里的事。字段名猜错属于领域内部矛盾翻不出它的手心也轮不到我操心。它的大胆是这么来的。“判断”这一层AI的权力依赖上下文context。15 个离线同步失败该不该关注把数字摆一起算上下文全在数据里它直接给出判断了。17.4% 是不是问题答案显然不在任何一张表里在账单系统当年的设计决定里在上游团队的记忆里。上下文在它够不着的地方就只把数字摆出来无从下手判断。AI做不到克制因为上下文没有相关信息。别误会它不是不出错。字段名照样猜错SQL 照样可能写歪。只是这些错落在它自己的领地里随着AI能力越来越强错误率是可以改进的十几条 SQL 都是它写的连字段名猜错了都自己改了。但 17.4% 算不算问题AI的报告里留空等我填。18.7 分钟的刷新链路真正值得拆的是05刷新明细表这条链路。它不是一条 SQL 慢而是 26 条刷新语句串行跑完整条任务耗时 18.7 分钟。AI 先没急着下结论而是把每个物化视图和动态表的耗时排了一遍结果很直观vc_cru_calculate 308 秒igs_detail_mv 206 秒ai_gateway_token_billing_detail_mv 178 秒前三个加起来占了 62%。这就把问题从“任务慢”改成了“哪几步慢”。再往 profile 里看三步慢法还不一样。vc_cru_calculate 的问题是数据倾斜一个 stage 的倾斜比到了 15.46后面还有 DOP1 的串行阶段igs_detail_mv 更像被单点卡住了前面 1.9GB 数据 5 秒扫完最后 208MB 输入却在单线程 stage 上跑了 185 秒ai_gateway_token_billing_detail_mv 则是全表扫描60.1GB 扫进去最后只剩 100MB 输出。这些数字摆出来以后优化方向也跟着变清楚了。倾斜的要查 GROUP BY 和 JOIN key热点 key 该预聚合就预聚合该加 salt 就加 salt单线程的要看是不是无分区 ORDER BY、单值 DISTRIBUTE BY或者写入阶段被强制串行全表扫描的优先补时间分区过滤能只刷当天就别把 60GB 全扫一遍。这份分析我自己也能做但通常要在任务列表、SQL、job profile、stage 明细之间来回切。它省掉的是这段体力活先把 26 条链路排出优先级再把前三个瓶颈拆成倾斜、串行、全表扫描三类最后给出能落地的改法。报告里甚至把预期收益也排了出来先动 igs_detail_mv 的单线程阶段和 ai_gateway_token_billing_detail_mv 的全表扫描收益最直接。但最后那一步还是不能替我拍板。加 salt 会不会影响账单口径增量刷新能不能覆盖迟到数据按当天分区裁剪会不会漏掉补写数据这些答案不在 profile 里。AI 能把慢拆成几个可验证的技术原因也能告诉我先动哪一刀最划算刀该不该落下还是得有人知道这条账单链路到底承诺了什么。顺手补个数下午等数据追上来的空档我把第三件事做了。billing_summary_mv 有张下游汇总表 daily_report 缺数据要补跑。我让它包办全程建表、建任务、配调度、上线、执行、验证。有个细节我记了下来。建任务前它发现系统里已经躺着一个叫 daily_report_etl 的草稿态任务不知道谁哪次留下的。它没另建直接复用改了 SQL 和调度配置。换我自己做八成图省事新建一个回头系统里两个同名任务下一个值班的人得猜哪个是真的。验证完它把任务下线了。这步没人提醒。忘了下线这任务每天凌晨两点会自己跑一遍重复数据就来了。从保存任务到下线一共八步每步都有理由没有一步多余。多出来的半天三件事干完下午三点不到。多出来的半天让我想明白一件以前没想过的事。我们不是不知道主动巡检好。查得勤问题发现得早修起来就便宜道理谁都懂。但一次完整巡检要写十几条 SQL在四五个工具之间切来切去最后还得把结果攒成报告。这么贵的事谁天天做所以才形成了痼疾巡检长期靠告警兜底靠值班人的手感补漏。现在一句话换一份报告巡检便宜了频率才上得去。往前追一步便宜是因为写 SQL、切工具这些活儿都不归我了。归属变了我的时间成本才降下来的。频率提高、发现得早都是从这儿来的。这条判断的边界也不是固定的。17.4% 今天要我拍板是因为“哪些账单类型没有 workspace 维度”这类知识只存在人脑子里。哪天有人把它写进文档文档进了它的上下文下次巡检它就自动把这条判掉了。上下文挪到哪边界就到哪。顺着想下去有个结论让我自己自己也觉得后背发凉以后运维文档的第一读者可能是 AI不是下一个值班的同事。文档写得全它能替你判断的多那条线就越往后退退到只剩没法写成文档的部分——没发生过的事没定过的规矩。写文档这件常年被当负担的事快要变成给自己扩产能了。干这行的人也在变。会写 SQL、记得住调度平台哪个菜单藏着什么按钮这些本事在贬值能看着一份报告能说出“这个数不对去查上游”这个在升值。下午四点我又看了一眼那张表。4,375 变成了 8,900今天的数据追上来了虚惊一场。这个“再看一眼”还是我的活儿。文中的活儿是谁干的那天值班用的是云器 Lakehouse 的命令行工具 cz-cli。文章里它干的三件事对应三块能力巡检报告来自自然语言直接查数——查哪张表、写什么 SQL 都是它自己定的字段猜错了自己 DESCRIBE 纠错慢查询那段分析来自异步执行加 job profile——算子级耗时直接在会话里读不用切去控制台翻回填过程来自任务和调度管理——建表、配调度、上线、下线一个会话走完中途不用碰第二个工具。如果你也想试试可以参考我那天用的 prompt 对 XX workspace 做一次运维巡检检查连接状态、过去 24 小时任务健康度、核心表数据时效性、最近 7 天数据量趋势、主要字段数据质量最后输出一份结构化巡检报告。一句话就够了试用入口请访问cz-cli.ai体验或扫描下方二维码加入cz-cli交流群云器科技官网 - 改变数据的使用方式更多内容欢迎关注「云器科技」官网云器科技-多云及一体化数据平台提供