第472章 版本日历与自动再认证（1 / 2）

“目录托管年费××万，帮你长期保持合规，不被版本更新淘汰。”

这句话比“渠道排期”更高级，也更难反驳。因为它看起来像正常服务：你不会说一个人帮你维护系统是坏事。但林远看得更清楚——这不是卖劳动，这是卖焦虑；焦虑的源头不是技术难，而是“更新不可预测”。

只要更新像天气一样飘忽，合规就会变成订阅。

订阅久了，标准就被托管方握在手里：他不需要掌控签名权，他只要掌控“你担心被淘汰”的心。

林远把那段广告打印出来，钉在白板边缘，旁边写了四个字：

更新可预期。

“我们要做的，是把版本更新变成公共产品。”他对陈毅说，“让‘保持合规’不需要买年费，只需要按公开日历走。”

陈毅问：“怎么让更新可预期？入口实现那么多家，一家不配合就碎片化。”

林远点头：“所以靠两件事：日历和再认证流水线。”

一、版本日历：把“更新权”从恐吓变成约定

省信息处拉了一个很短的会，参会的人比以往更务实：试点城市两位技术负责人、数科安全、银行IT旁听、审计旁听。没有协会，没有顾问公司——因为这次讨论的不是“宣传口径”，是“运行节奏”。

林远把提案投到屏幕上，标题很直白：

《版本更新日历（Release dar）与弃用规则（Deprecation Policy）—ING-STD实施细则》

核心只有三条“约定”：

1）月度发布列车（Release Tra）

每月固定一个发布日（例：每月第二个周三）

发布内容包含：ING-STD规范补丁、Ingress测试套件更新、目录字段变更

发布前两周冻结变更（RFC Freeze），只收安全修复

2）双通道：常规更新 vs 安全热修（Hotfix Lane）

常规更新走月度列车

安全热修必须满足：

有漏洞编号/安全事件编号（i_id）

变更单公开（不公开漏洞细节，只公开影响范围与修复版本）

过渡期仍然给足“最低运行窗口”（不让热修变成门票）

3）弃用规则（Deprecation）写死：三段式

公告期：提前公告“将弃用的字段/行为”，给出替代方案

共存期：至少90天共存（新旧都能通过签名与验真）

下线期：到期才移除；移除时必须在Casebook登记“弃用判例编号”

银行IT旁听当场就说：“这三条对我们很重要。银行最怕的是你们今天改字段，明天证据链断。日历+共存期，才能让我们把它写进风控条件。”

审计旁听补了一句更冷的：“弃用必须有编号，编号才能审计。没有编号的弃用，就是静默更新。”

城市技术负责人也说了实话：“我们最怕临时通知。只要你给日历和共存期，我们自己也能安排升级窗口，不需要到处找顾问。”

林远点头：“这就是目的。更新从‘谁掌控’变成‘大家都知道’。”

二、自动再认证流水线：让“合规”像体检，不像考试

日历解决“什么时候变”，流水线解决“谁会掉队”。

陈毅把第二份方案推上去，像一条CI/CD管线图：

AutoReCert｜自动再认证流水线（公开版）

逻辑很简单，但每一步都对准“去订阅化”：

每晚对目录中所有入口实现跑一遍Ingress（含离线补签、隐私边界、错误码可观测等）

结果写入公开目录：

pass / warn / fail

失败原因桶（不暴露内部代码，只暴露条款编号与错误码桶）