半管理式 VPN：这个标签没说清谁在值班

早上八点一条连接断了，第一个问题是这该由谁来修。半管理式 VPN 这个说法回答不了，因为它命名的是商业安排，而不是工作分工。两家供应商可以用同一个说法，却把分工安排得完全相反：一家负责维护客户侧设备，另一家只看自己的网关。只要任务没写下来，这个标签就是披着描述外衣的猜测。

从断掉的那条连接开始

说清楚是哪一端不再应答、发生在几点，以及出问题时用户正在做什么。然后列出这条路径上的组件：笔记本、本地线路、客户侧网关、供应商网关，以及它们背后的资源。每一样要么在协议里有负责人，要么就是个缺口。把它们理一遍只要十分钟，却能定下接下来三个小时。

多个用户共有的症状指向共享组件，而只跟着一台笔记本走的症状指向客户端。这个区分能在任何人打开配置之前，把工单送进正确的队列。

先定两个端点，再谈设置

先决定客户侧网关归谁、远端端点归谁。这两条定下来，双方就都清楚自己能查什么、必须向对方要什么。安排里剩下的部分，也就从那里开始变简单。

供应商可以只监控自己的网关，而本地运营商线路、目录服务或目标应用仍由客户负责。客户自有的设备照样可以落在供应商的维护协议之下，所以归谁所有和谁维护这台盒子是两个不同的问题。每个端点都要把两个答案都写下来，因为续约时吵的通常是第二个。

共享对象只能有一个责任人

身份、凭据、受保护前缀、提案和回程路由协议都是共享对象，而共享对象腐烂得最快。如果双方都能改同一个对象，双方就都会去改，每一次改动在本地看都没错，双方约定的流量却断了。给每个对象一个责任人和一套变更流程，并要求改动落地前先通知对方。否则变更记录读起来，就像两个人在修同一台机器的不同半边。

最典型的故障，是同一周里一边改了选择器、另一边改了 NAT。两位工程师都没做错什么，隧道却还是不再承载应用。

第一通报告由谁接

提前定好先呼谁、各自被授权读什么，以及案件在什么节点移交。提供端点、尝试时间和放行的流量，双方才能对上同一个事件。

一份范围很窄的状态摘要，通常比未脱敏的配置更有用，也不会泄露机密。监控属于组件所有者，而不属于标识所有者，所以要问清楚：哪一方看得到隧道状态，哪一方看得到应用，每条告警又会叫醒谁。把非工作时段的联系路径写在每条告警旁边，因为没人值班的看板只是文档。

变更权限也要同样认真地定义。供应商在改选择器、客户同时在改 NAT，两份本地配置看着都成立，隧道却依然失败。

标签永远不会告诉你的事

把软件维护、凭据轮换、配置的获批备份和恢复路径写进真正的协议里。像 AWS 公布的那套模型 这样的共担责任模型，能说明分工在服务之间可以移动多远，它只是一个例子，不是你供应商条款的定义。从半管理这个说法里推断任何事，正是续约谈判发现缺口的方式。

范围里应当写明日常运维方，以及每一项依赖的升级路径。无论报价把这服务叫什么，实际执行时，指的就是这份清单。