对账与质量运营

明·如归 · 宿舍管理白皮书 ｜ 第三篇 数据篇

第七章讲了接入的那一刻——数据怎么进来、怎么当场拦下错误。进来之后的事：数据不会一劳永逸地正确。学生会转专业、会休学、会换身份证号；床位会从"空闲"变成"维修"再变回"空闲"但忘了释放人；闸机记录进来了但对不上任何床位。这些问题不是"接入时没拦住"、是"数据活着就会生病"——所以系统需要周期性的体检和一套有人认领的治疗流程。

15.1 五条规则：从"可能有问题"到"确认是问题"

系统内置五条数据质量规则、每条只做一件事、只检测一种确定的错误模式：

15.1.1 规则一：一人多占

判定：同一个学生在同一时间挂着两张以上有效床位。

典型成因：换床流程中断留下的半截子事务——新床位已经分配、旧床位没释放；批量导入时重复导入同一学生两次；毕业搬迁时新床位先分配了、旧床位没退。

修复动作：管理员在问题详情里选择"哪一张是应该保留的"、系统自动释放另一张。

频率：每日扫描一次。学期中每天不会有新的命中（换床是白天的事、晚上扫描时已经稳定）；学期末和开学季命中会集中出现。

15.1.2 规则二：性别不符

判定：男生挂在女生楼或反之。

典型成因：性别隔离是第九条讲过的那条硬规则、写死在求解器里；万一哪天有绕开求解器的手工改动、扫描是第二道眼。这一条几乎不该出现——一旦出现就是重大事故、要么录入错、要么权限被绕。

修复动作：立即联系操作者核实、撤销分配、必要时启动人工重分配。

频率：每日扫描一次。这一条规则命中一条就要立刻处理、不能等到周报。

15.1.3 规则三：离校在住

判定：学生学籍状态已变为"离校"（毕业、退学等）、但住宿分配仍是"在住"。

典型成因：学籍变动从教务同步过来时、宿舍端没触发退住；毕业生离校手续没走完、宿舍先释放了但学籍未变更；退学处理时教务改了学籍、宿舍端没同步。

为什么必须清理：这种记录如果不清、考勤表上永远多出一批"未归"的人、而他们已经不在学校了——晚归率虚高、预警刷屏、上级检查会问"这些人是谁"。

修复动作：管理员核实后触发一次退住、或反向修正学籍状态。

15.1.4 规则四：证件校验位

判定：身份证号的最后一位校验码与前面十七位算出来不符。

典型成因：录入时的手误（少一位、多位、错位）；从旧系统迁移时字符丢失；数据来源本身就是脏的（比如教务库里的身份证号本来就错）。

这一条是"数据源健康度"的探针：一所学校如果每次导入都有 5% 的身份证号校验不过——那问题不在宿舍系统、在学籍数据源本身。

修复动作：不能由宿舍系统单方面"修正"（改错了责任更大）、必须回到源头（学生本人、教务处）核对。

15.1.5 规则五：通行无主

判定：设备通行记录里出现了匹配不上任何在住人员的学号或卡号。

典型成因：人走了数据没清；设备侧推送了错误数据；临时卡没有对应人员绑定；跨校区卡号冲突。

这一条反映的是"设备和宿舍系统之间的映射完整度"——一所学校刚接入闸机时命中会很多、运行半年之后应该趋近零。

修复动作：如果人确实已离校、清记录；如果卡有主、在系统里补人员绑定；如果卡无主、设备侧禁用。

五条规则不多、但每一条都指向一种在宿舍管理里确实反复发生、确实会导致判断出错的数据病变。规则可以逐条启用或停用、每条规则有可选参数（"通行无主"可以配时间窗天数、"证件校验位"可以配是否阻塞入库）。

15.2 问题工作台：不是扫完就完了

扫描命中一条问题、系统生成的不是一行日志、而是一条有状态的任务记录。

15.2.1 去重键

去重键 = 规则编码 + 实体类型 + 实体 ID + 状态为"待处理"。

同一个人同一条规则连续七天都命中、工作台里只有一条待处理、不会变成七条重复轰炸。这一条设计和归寝异常预警的四元组去重逻辑一致——"扫描可以每天跑、但任务不会因此膨胀" 是所有周期性质量工具的硬要求。

15.2.2 记录内容

每条问题记录带着：

• 检出时间：第一次被扫描命中的时刻；
• 命中次数：这一条被后续扫描重复命中了几次（用于评估问题严重度）；
• 人类可读的明细："张三（学号 2024001）持有两张在住床位 A-302-1 和 B-105-3"——不是 EntityId=12345 BedId=67890；
• 处理人：谁点了修复或忽略；
• 处理时间：什么时候点的；
• 处理备注：为什么这样处理。

15.2.3 三态状态

状态只有三种：待处理、已修复、已忽略。

• 待处理：新命中、没人动；
• 已修复：处理人修好了、下次扫描还会重新检查——问题可能再次出现、那时候会生成一条新的；
• 已忽略：处理人判断这不是问题、写了忽略理由；已忽略不参与去重、下次扫描同一个人同一问题会重新生成新记录（防止一次误忽略永久豁免）。

15.2.4 处理流程

定位 → 修复或忽略 → 留痕。没有"知道了但不处理"这个选项——要么修掉、要么写一句为什么忽略。处理备注留在记录里、下次审计能看到这个人不修的理由。

四个维度分类：值域（Range）、完整性（Completeness）、一致性（Consistency）、时效性（Timeliness）。维度用于工作台筛选与统计——"本学期检出的所有一致性问题处理率多少"这种话能问出来。

15.3 幂等：扫描一百次和一次结果相同

质量扫描的设计约束是幂等：

• 同一天跑两次、第二次不产生任何新增待处理问题（因为去重键已存在）；
• 修完之后第三天跑、发现同一人又出同样问题、生成新的一条；
• 手动触发和定时触发共用同一套去重逻辑；
• 服务器重启、多实例并发跑、结果一致。

幂等是自动任务的前提品质。一个不幂等的扫描、跑两周就产生几百条重复、运维人员看到工作台第一反应是"不想打开"、整个质量运营就死了。

幂等四道防护（贯穿所有自动任务）：

• 数据层唯一约束：去重键落在数据层的唯一约束上、不依赖应用判断；
• 执行历史表：每次跑留下"什么时候跑的、结果如何、影响多少条"；
• 状态跟踪：任务本身有状态（运行中 / 完成 / 失败）、防止重复触发；
• 手动兜底：管理员能随时点"立即执行一次"、不用等定时。

15.4 对账：质量的镜像面

质量扫描面向的是"本库数据自己有没有错"、对账引擎面向的是"本库和源系统之间有没有差"。

15.4.1 对账四类

• 新增：源系统有、本库无 → 建议本库补一条；
• 更新：两边都有、字段不同 → 建议本库按源更新；
• 冲突：两边都有、但差异超阈值或方向矛盾 → 进冲突册、人工裁决；
• 跳过：本库有、源系统无 → 不主动删除、只标注"源缺失"（学校可能有正当理由保留）。

15.4.2 冲突册：治理健康度探针

冲突册的厚度就是治理的健康度：

• 长期为零：不一定是好事、可能是映射配错了根本没比出来——要检查映射表；
• 长期几十条：说明两边业务流程该统一口径了——宿舍端和教务端要开一次治理会；
• 短期集中爆发：说明上游刚做了一次批量动作（毕业批量处理、学期学籍状态刷新）——要观察一周再看。

15.4.3 两条腿一起走

对账和质量扫描共同构成数据运营的两条腿：一条看外面（和源头一致不一致）、一条看里面（自己有没有生病）。两条腿都要周期执行、都有人认领、都有历史可查。

15.5 十八个迁移脚本：结构变更也不能出错

数据表结构本身也在变——加字段、加索引、改枚举值。系统的迁移机制走幂等结构化查询脚本：

• 18 个脚本按序执行、启动时自动建库与序列同步；
• 每个脚本带条件判断（"表里没有这一列时才加"）、跑两遍和跑一遍终态相同；
• 性能索引单独一条脚本、上线后手动加——因为索引重建期间会锁表、要选维护时段；
• 回滚脚本可选配、生产环境一般不回滚（回滚比前滚更危险）。

幂等迁移的价值在一次事故：某次迁移跑到一半网络断了、重启后再次执行——不报错、不重复、不丢数据。做不到这一点的系统、每次变更都是一次赌博。

15.6 三条关于质量的常见误解

误解一：扫描出得多说明系统好。恰恰相反——扫描出得多说明源头差。一所学校上线第一个月检出 500 条问题不是"系统的功劳"、是"过去五年积累的账"。健康的曲线是：首月 500、第二月 100、第三月 20、一个学期后基本归零。如果半年后还在检出几百条——说明修复没跟上、扫描只是徒劳。

误解二：所有问题都要修复。有些问题就该忽略——比如"离校在住"里的一条记录、学生是休学保留学籍、住宿也合法保留——这时候正确动作是忽略并写理由。忽略不是偷懒、是判断。系统里的处理备注字段就是给这种判断留的。

误解三：质量规则越多越好。当前是 5 条、有学校要求扩到 20 条。规则扩得越多、每规则的命中率越低、工作台的信噪比越差。健康的规则数量是"每一条被扫到时都有人真的会去修"——低于这个门槛的规则应该停用。

15.7 一张表：质量运营能力清单

能力	当前状态	说明
五条质量规则	已投产	一人多占、性别不符、离校在住、证件校验位、通行无主
四元组去重	已投产	规则 + 实体 + ID + 待处理
三态工作台	已投产	待处理 / 已修复 / 已忽略
四维度分类	已投产	值域 / 完整性 / 一致性 / 时效性
对账四类差异	已投产	新增 / 更新 / 冲突 / 跳过
冲突册与人工裁决	已投产	长期厚度反映治理健康度
幂等迁移脚本	已投产	18 个脚本按序 + 可重跑
自定义质量规则	未投产	规则当前固定 5 条、不开放扩展
自动修复	不做	修复永远由人执行、系统只提供定位与留痕

15.8 给学校的一件事

打开问题工作台（或要求厂商给你看）、回答三个问题：

• "上一次全量扫描是什么时候？" —— 如果不是最近一周内、那这个工作台是"看着好看"；
• "当前有多少条待处理？" —— 如果超过 100 条、说明修复跟不上扫描；
• "待处理里最久的那一条已经多少天了？" —— 如果超过一个月没人动过、说明问题工作台没有 owner——没有 owner 的质量运营等于没有质量运营。

数据是活的、它会生病。系统的责任是每天量一次体温、有问题当天开单子、开完有人签字。

质量管住了"数据对不对"、下一章要谈"这些数据能拼出什么"：一人一档与住宿画像。