怎样算做完,怎样不再长回来

第 7 课 · 共 7 课 约 8 分钟

用能检查的条目验收,用七层护栏守住,再看三个取舍。

本课目标

读完这一课,你将能够

  • 用可检查的条目定义「迁移做完了」
  • 说出七层护栏,以及每一层挡住什么
  • 说出统一之后要守住的三个取舍

用能检查的话定义「做完」

「以后不会再出现」听起来像一句愿望。要让它成立,得先把「做完」写成能检查的条目,并且每一条都有查法:

做完的样子怎么查
直连数据源的进程和凭证只剩发布端凭证清点,加网络策略
定时任务只剩登记在工作流里的每天盘点
数据新鲜度变化后在你定的时限内到页面,例如 1 分钟发布时间戳对数据源时间
静默失败发布端停了或数据源断了,两分钟内页面能看见演练:停掉发布端
独立站点全部是 Nexus 应用域名和部署清单
没人用时的费用只剩必须常驻的那一小部分账单,加计算分钟

前四条要持续检查,不是做一次:今天没有直连,不等于下个月没有人再接一个。

七层护栏

护栏放在机器拦得住的地方,不靠自觉。从外到内,七层:

  1. 网络层

    数据源只放行发布端的来源地址;智能体和应用所在的网络没有到数据源的路由

  2. 凭证层

    数据源的只读账号只放在发布端;发布 Key 只能往一条数据流发布

  3. 引擎层

    在智能体引擎的配置里,把 cronjob 工具集加进 agent.disabled_toolsets,智能体就不能自己新建定时任务

  4. 发布层

    比每 5 分钟还密的定时拒收,5 分钟到 1 小时的告警;用了没登记的 SDK 拒收

  5. 运行层

    每个应用有计算分钟、通知、token 的上限,用完即停

  6. 巡检层

    每天盘点定时任务、常驻进程和直连连接,出现例外就通知负责人

  7. 变更层

    语义本体的改动走分支和提案,由人批准,改动留下记录

七层各管一段:前三层挡住旁路,发布层和运行层管住新增的东西,巡检层发现漏网的,变更层管住改动本身。

三个要守住的取舍

统一不是免费的。收成一个入口以后,有三件事要主动管:

FRESHNESS

镜像有延迟

通常是几秒到几分钟。看板够用;要一锤定音的操作,回到数据源确认。延迟要让人看得见。

KEY PATH

Semantic 成了关键路径

它慢了或停了,看板和触发都受影响。发布端失败会带着幂等 id 重试,订阅端断线按序号续传;数据源本身不受影响。

STORMS

触发会放大

没有过滤时,运行次数等于变化数乘以订阅数。用条件、冷却、去重和计算分钟上限把它压住。

动旧任务之前

  • 先关入口,再清存量:先禁止新增(引擎层、发布层),再清理旧的,否则清得多快,长得就多快。
  • 先并行,再停:新旧并行一段时间,对账关键数字,再停旧的。
  • 暂停,不要删:暂停的任务保留两周,随时可以恢复。
  • 逐条确认:旧的定时任务多半是业务在用的事,动之前让业务负责人逐条确认:删、换,还是留。

要点

  • 把「做完」写成能检查的条目,每一条都要有查法;前几条要持续检查,不是做一次。
  • 护栏放在机器拦得住的地方:网络、凭证、引擎配置、部署检查、运行上限、巡检、变更审核。
  • 先关入口再清存量;新旧并行对账;暂停而不是删除;逐条让业务负责人确认。
  • 统一后要主动管三件事:镜像的延迟、Semantic 的关键路径、触发的放大。

练一练

写你自己的验收表

把这一课的表改成你系统的版本。

至少写六行:检查项、现在的数字、目标、怎么查,每一行都要有一个数字。

小测

选一个答案,马上看解析。

Q1下面哪一条最能防止「新的定时任务悄悄长出来」?

Q2今天数据源上已经没有直连的脚本了,这算「做完」吗?

Q3为什么统一之后,触发的运行次数可能比原来的定时任务还多?

延伸阅读