POSTMORTEM / INC-2026-004SEV-232 套。排查了一下午根因简单到有点丢人写出来给做同类项目的参考。先把背景交代了不然很多人不知道这平台是干嘛的。我们园区有两套系统在跑一套是智慧园区管理系统房源、客商、合同、账单、工单全在里面管记数。另一套是上个月新接的数智安全问数平台只读连接运营的人用大白话问库里的数它给结论、给图表、给明细管答数。上线之后用得挺顺问空置、问收缴率、问对账都对得上业务方拿计算器抽查了两周才放行的。十一天。第十一天中午出的事。TIMELINE14:02运营总监在群里发消息问数平台答各楼栋空置 128 套她手工口径是 96 套。差 32 套。原话是「你们这数谁算的」。14:10我先怀疑模型瞎答。查了查询日志它生成的 SQL 完全符合语义模型定义执行结果就是 128。模型没疯。15:20转向怀疑口径。让总监把她的 96 套明细发来两边逐条对。好在平台明细能下钻128 套的清单拉出来交集一算多出来的 32 套全是同一个状态。18:40定位到根因。上周业务系统发了个小版本房源状态字典里新增了「内部预留」和「装修中」两个值。语义模型里空置的定义是「排除已签约、已出租」黑名单漏掉了这两个新值它们全被算进了空置。22:47修复上线回归五连问全过128 变 96。总监回了个「嗯」。这两个字比什么都好使。ROOT CAUSE写细一点因为这是个挺典型的坑。语义模型定义空置的时候我用了黑名单写法逻辑上等价于「状态不在已签约、已出租之内的都算空置」。这套写法在当时的字典值下完全正确五连问回归也过了。业务系统后来加了「内部预留」和「装修中」没通知我们黑名单没有覆盖到这两个状态的房源就顺着 NOT IN 溜了进来。要说谁的锅我的。第 10 期 ADR 里我自己写过语义模型放问数平台侧代价是业务系统发版改字段时语义模型要跟着同步。当时写了同步机制但同步靠人记得没有强制手段。这回就是没记得。ACTION ITEMSDONE空置定义从黑名单改成两族映射。可用族可招租、可预定与不可用族已签约、已出租、内部预留、装修中新字典值按族归类落不进任何族的进未知桶并告警默认不计入任何指标。DONE加了每日字典对账脚本。每天凌晨拉一次业务系统字典和语义模型覆盖值做 diff差值直接进告警群。DONE回归集补了一条。空置 总房源 − 已签约 − 已出租 − 内部预留 − 装修中往后每次配置变更都跑。WIP发版协作流程。和业务系统组约好了动字典、动枚举必须提前一天在共享频道说一声。纯靠自觉不可靠正在评估把字典变更接到 Webhook 通知。TODO关键指标波动告警。总量类指标环比突变超过阈值就提示复核宁可信其有。LESSONS说两句实在的。第一明细能下钻这件事救了整场事故的信誉。要不是那 32 套能精确点出来全是「装修中」这事的结论就会变成「AI 不靠谱」然后平台被打入冷宫。可核对不是锦上添花是这类产品的命。第二黑名单式的口径定义天然有洞字典类字段尽量按族映射别按值枚举。枚举写的时候多爽出事的时候就有多惨。第三业务系统不会主动告诉你它变了。这点很反直觉但就是事实。两套系统再亲中间也得有个自动对账的机制兜底靠人记得的同步迟早要出事这次算是花 32 套房源买了课。复盘会定了两条规矩动字典必发公告关键指标必设波动告警。写进 wiki贴墙上。你们遇到过的最阴的字典类 bug 是啥我怀疑「业务系统偷偷加了枚举值」能排进前三评论区比比。AUTHOR · 值班的那个NEXT · 两族映射实现细节 
长河君 · 2026/10/29 2:13:39 · 阅读 1.2k 问数平台上线第十一天，它给领导答错了一个数
POSTMORTEM / INC-2026-004SEV-232 套。排查了一下午根因简单到有点丢人写出来给做同类项目的参考。先把背景交代了不然很多人不知道这平台是干嘛的。我们园区有两套系统在跑一套是智慧园区管理系统房源、客商、合同、账单、工单全在里面管记数。另一套是上个月新接的数智安全问数平台只读连接运营的人用大白话问库里的数它给结论、给图表、给明细管答数。上线之后用得挺顺问空置、问收缴率、问对账都对得上业务方拿计算器抽查了两周才放行的。十一天。第十一天中午出的事。TIMELINE14:02运营总监在群里发消息问数平台答各楼栋空置 128 套她手工口径是 96 套。差 32 套。原话是「你们这数谁算的」。14:10我先怀疑模型瞎答。查了查询日志它生成的 SQL 完全符合语义模型定义执行结果就是 128。模型没疯。15:20转向怀疑口径。让总监把她的 96 套明细发来两边逐条对。好在平台明细能下钻128 套的清单拉出来交集一算多出来的 32 套全是同一个状态。18:40定位到根因。上周业务系统发了个小版本房源状态字典里新增了「内部预留」和「装修中」两个值。语义模型里空置的定义是「排除已签约、已出租」黑名单漏掉了这两个新值它们全被算进了空置。22:47修复上线回归五连问全过128 变 96。总监回了个「嗯」。这两个字比什么都好使。ROOT CAUSE写细一点因为这是个挺典型的坑。语义模型定义空置的时候我用了黑名单写法逻辑上等价于「状态不在已签约、已出租之内的都算空置」。这套写法在当时的字典值下完全正确五连问回归也过了。业务系统后来加了「内部预留」和「装修中」没通知我们黑名单没有覆盖到这两个状态的房源就顺着 NOT IN 溜了进来。要说谁的锅我的。第 10 期 ADR 里我自己写过语义模型放问数平台侧代价是业务系统发版改字段时语义模型要跟着同步。当时写了同步机制但同步靠人记得没有强制手段。这回就是没记得。ACTION ITEMSDONE空置定义从黑名单改成两族映射。可用族可招租、可预定与不可用族已签约、已出租、内部预留、装修中新字典值按族归类落不进任何族的进未知桶并告警默认不计入任何指标。DONE加了每日字典对账脚本。每天凌晨拉一次业务系统字典和语义模型覆盖值做 diff差值直接进告警群。DONE回归集补了一条。空置 总房源 − 已签约 − 已出租 − 内部预留 − 装修中往后每次配置变更都跑。WIP发版协作流程。和业务系统组约好了动字典、动枚举必须提前一天在共享频道说一声。纯靠自觉不可靠正在评估把字典变更接到 Webhook 通知。TODO关键指标波动告警。总量类指标环比突变超过阈值就提示复核宁可信其有。LESSONS说两句实在的。第一明细能下钻这件事救了整场事故的信誉。要不是那 32 套能精确点出来全是「装修中」这事的结论就会变成「AI 不靠谱」然后平台被打入冷宫。可核对不是锦上添花是这类产品的命。第二黑名单式的口径定义天然有洞字典类字段尽量按族映射别按值枚举。枚举写的时候多爽出事的时候就有多惨。第三业务系统不会主动告诉你它变了。这点很反直觉但就是事实。两套系统再亲中间也得有个自动对账的机制兜底靠人记得的同步迟早要出事这次算是花 32 套房源买了课。复盘会定了两条规矩动字典必发公告关键指标必设波动告警。写进 wiki贴墙上。你们遇到过的最阴的字典类 bug 是啥我怀疑「业务系统偷偷加了枚举值」能排进前三评论区比比。AUTHOR · 值班的那个NEXT · 两族映射实现细节