怎样算做完,怎样不再长回来
用能检查的条目验收,用七层护栏守住,再看三个取舍。

本课目标
读完这一课,你将能够
- 用可检查的条目定义「迁移做完了」
- 说出七层护栏,以及每一层挡住什么
- 说出统一之后要守住的三个取舍
用能检查的话定义「做完」
「以后不会再出现」听起来像一句愿望。要让它成立,得先把「做完」写成能检查的条目,并且每一条都有查法:
| 做完的样子 | 怎么查 | |
|---|---|---|
| 直连数据源的进程和凭证 | 只剩发布端 | 凭证清点,加网络策略 |
| 定时任务 | 只剩登记在工作流里的 | 每天盘点 |
| 数据新鲜度 | 变化后在你定的时限内到页面,例如 1 分钟 | 发布时间戳对数据源时间 |
| 静默失败 | 发布端停了或数据源断了,两分钟内页面能看见 | 演练:停掉发布端 |
| 独立站点 | 全部是 Nexus 应用 | 域名和部署清单 |
| 没人用时的费用 | 只剩必须常驻的那一小部分 | 账单,加计算分钟 |
前四条要持续检查,不是做一次:今天没有直连,不等于下个月没有人再接一个。
七层护栏
护栏放在机器拦得住的地方,不靠自觉。从外到内,七层:
- 网络层
数据源只放行发布端的来源地址;智能体和应用所在的网络没有到数据源的路由
- 凭证层
数据源的只读账号只放在发布端;发布 Key 只能往一条数据流发布
- 引擎层
在智能体引擎的配置里,把
cronjob工具集加进agent.disabled_toolsets,智能体就不能自己新建定时任务 - 发布层
比每 5 分钟还密的定时拒收,5 分钟到 1 小时的告警;用了没登记的 SDK 拒收
- 运行层
每个应用有计算分钟、通知、token 的上限,用完即停
- 巡检层
每天盘点定时任务、常驻进程和直连连接,出现例外就通知负责人
- 变更层
语义本体的改动走分支和提案,由人批准,改动留下记录
七层各管一段:前三层挡住旁路,发布层和运行层管住新增的东西,巡检层发现漏网的,变更层管住改动本身。
三个要守住的取舍
统一不是免费的。收成一个入口以后,有三件事要主动管:
镜像有延迟
通常是几秒到几分钟。看板够用;要一锤定音的操作,回到数据源确认。延迟要让人看得见。
Semantic 成了关键路径
它慢了或停了,看板和触发都受影响。发布端失败会带着幂等 id 重试,订阅端断线按序号续传;数据源本身不受影响。
触发会放大
没有过滤时,运行次数等于变化数乘以订阅数。用条件、冷却、去重和计算分钟上限把它压住。
动旧任务之前
- 先关入口,再清存量:先禁止新增(引擎层、发布层),再清理旧的,否则清得多快,长得就多快。
- 先并行,再停:新旧并行一段时间,对账关键数字,再停旧的。
- 暂停,不要删:暂停的任务保留两周,随时可以恢复。
- 逐条确认:旧的定时任务多半是业务在用的事,动之前让业务负责人逐条确认:删、换,还是留。
要点
- 把「做完」写成能检查的条目,每一条都要有查法;前几条要持续检查,不是做一次。
- 护栏放在机器拦得住的地方:网络、凭证、引擎配置、部署检查、运行上限、巡检、变更审核。
- 先关入口再清存量;新旧并行对账;暂停而不是删除;逐条让业务负责人确认。
- 统一后要主动管三件事:镜像的延迟、Semantic 的关键路径、触发的放大。
练一练
写你自己的验收表
把这一课的表改成你系统的版本。
至少写六行:检查项、现在的数字、目标、怎么查,每一行都要有一个数字。
从七层护栏里选一层,是你这周就能加上的,写下它会挡住什么。
停掉一个发布端,记下多久之后页面出现「数据可能不是最新」,谁收到了通知。
小测
选一个答案,马上看解析。
Q1下面哪一条最能防止「新的定时任务悄悄长出来」?
规范和提醒靠自觉,拦不住机器;引擎层和发布层是机器自己拦得住的地方。
Q2今天数据源上已经没有直连的脚本了,这算「做完」吗?
「今天没有」不等于「以后不会有」。持续检查,才是让结果留得住的部分。
Q3为什么统一之后,触发的运行次数可能比原来的定时任务还多?
所以触发要带条件、冷却和去重,并受计算分钟上限约束。