摘要

  • InterLAN IX 为成员设计的 Lighthouse 自助门户，允许一次申请涉及多台设备，却要求逐台预览配置、启动回滚计时、逐台确认；无法证明安全恢复时，由人接管。
  • AI 助手只能读取资料和写报告，不能改配置。真正的治理问题因此很清楚：按钮人人想按，谁有权决定共享交换网络最终长成什么样？

会员按下按钮之后

自助服务的诱惑，是把复杂事情做得像点外卖：选一项，确认，等通知。可互联网交换点的路由器不是厨房打印机。它们同时承载许多网络的互联安排，一名会员的请求，可能要在几台设备上形成一致的结果。前台做得再顺滑，后台若只顾加速下发，停在半途的配置仍会让人吃到生米。

RIPE 93 公布的 InterLAN IX Lighthouse 演讲摘要把这个尴尬摆到了桌面上。发言人 Andrei Dinu 介绍的设计覆盖 Nokia SR OS 路由器与 Arista EOS 交换机。一个请求可能触及多台路由器；每台先看拟议配置、各有回滚计时器，再逐台确认。系统若不能证明安全地退回原状，就交给人处理。摘要目前没有演讲实录、幻灯片或录像，也没有公开的故障演练与使用量。它公开的是权限设计，不能拿来冒充已验证的运行成绩。

这仍然是一条有新闻价值的线。InterLAN 自己的服务页面列出公共对等互联、两台路由服务器、私有 VLAN 与备用端口。这样的设施服务多个参与者。某个申请在第一台设备成功、第二台失败时，网络不会自动变成“差不多也行”。逐台确认把中间状态暴露出来；计时回滚为单台设备准备退路；无法证明退路时交给人，避免把不确定性伪装成自动化的自信。Lighthouse 尚未公布支持哪些具体变更类型，因此不能把某次 VLAN 改动写成实际发生过的案例。

谁的记录算数

真正有分量的安排，也许不是界面，而是数据库。摘要说数据库保存“预期状态”；工程师直接在设备上手改的配置，会被标成偏差，不会被悄悄吸纳为新的标准。夜班的临时补丁可能救急，但临时补丁不该在下一次自动下发时被洗成永久政策。把现况和意图拆开，才知道该修正设备、修改计划，还是调查那次手动操作为何发生。

卢恒在《Note 73》中追问过“参与”和“授权”的距离。把这个问题放进机房，也一样锋利。会员有申请入口，不等于拥有交换点的共享设备。工程师能在紧急时刻敲命令，不等于那条命令自动成为组织决议。数据库若能忠实记录获批意图，便成了决定谁说了算的证据面。所谓自助服务，首先应该说清“自助到哪一步”。

摘要还提到以生产快照建立数字孪生，用来预演变更。快照的价值取决于它有多新、覆盖哪些依赖，以及预演结果如何进入审批。运营方尚未公开这些材料。要检验机制，不必先看华丽的控制台：拿出一次真实流程的申请、配置差异、快照时间、预演结果、逐台确认、偏差检测和回滚记录，就能看见门户究竟把责任放在哪里。

AI 助手的边界最值得鼓掌，理由倒不科幻。按摘要原文，它只有只读工具，负责报告与迁移方案，碰不到设备配置。模型能把一份错误方案写得仪表堂堂；最后的改网决定仍应留给可追责的人和受控流程。只读权限是一道真正的墙，远比“智能运维”四个字值钱。

另一端的权力也有边界。InterLAN 的常见问题页面写明，会员使用路由服务器并非强制，各自可以选择对等互联政策。交换点管理共享设施，参与者决定自己的对等关系。RIPE NCC 的 RIS 文档将 RRC22 列在布加勒斯特的 InterLAN-IX；它能提供 BGP 观测资料，却不能替代 Lighthouse 的变更审批记录。外部看见路由变化，与内部知道谁批准了改动，是两份不同的账。