个人买一条节点，记住到期日也许够用；团队同时管理多个项目、地区和协议时，靠群消息和个人表格很快就会失控。常见后果是节点到期无人续费、离职员工仍持有密码、同一凭据被多处复制，或者出现故障时没人知道它服务哪个系统。
解决方法不是再建一个“账号密码大全”，而是把订单、节点、业务、责任人和权限分开管理。
一、先给每条资源一个内部编号
内部编号不要直接使用完整IP或密码，可以采用“业务-地区-序号”的形式，例如 API-CN-03。它用于工单、日志和交接，实际节点参数存放在受控系统中。
| 台账字段 | 示例内容 | 用途 |
|---|---|---|
| 内部节点ID | 项目、地区、序号 | 避免在普通文档暴露凭据 |
| 订单号 | 平台订单的可查询编号 | 关联付款与售后 |
| 产品字段 | 协议、地区、IP属性 | 防止相似套餐混用 |
| 业务系统 | 获批使用该节点的应用 | 明确影响范围 |
| 负责人 | 业务与技术各一名 | 区分需求和运维责任 |
| 生命周期 | 开通、到期、提醒、停用 | 避免突然过期 |
| 凭据位置 | 密码库记录ID | 不在台账写明文密码 |
二、订单台账和技术台账不要混成一张表
采购台账关注供应商、产品、金额、周期、发票和合同；技术台账关注节点、协议、认证、业务映射、监控和变更。二者通过订单号和内部节点ID关联。
这样财务人员无需看到代理密码，运维人员也不必访问完整支付信息。权限越清楚，泄露面越小。
三、团队中至少分开三类角色
- 采购/财务：负责订单、预算、付款和发票；
- 网络管理员：负责节点验收、凭据、白名单和监控；
- 业务使用者：只获得被批准的连接方式和使用范围。
一个人可以兼任，但系统权限仍应按角色分配。普通使用者不需要看到所有节点，也不应拥有改绑、退款或删除资源的权限。
四、代理凭据应该放在哪里
使用企业密码管理器、密钥管理服务或受控配置系统。台账只记录密钥条目ID，不记录明文用户名、密码、预共享密钥或完整代理URL。
需要自动化部署时，通过运行环境注入凭据，禁止写进Git仓库、群文件、镜像、普通日志和截图。凭据轮换的具体流程可参考站内后续的代理认证轮换指南。
五、来源IP白名单也需要负责人
如果节点采用来源IP白名单认证，台账应记录：
- 获准的办公或服务器出口；
- 申请人、审批人和业务目的；
- 添加时间和到期时间；
- 主备出口及切换顺序；
- 离职、迁移或合同结束时的撤销动作。
家庭和公司出口是否同时添加，应按平台限制和企业审批决定，可参考天行IP多地点白名单管理。
六、到期提醒设置几个时间点
不要只在到期当天提醒。可根据业务重要性设置提前30天、7天和1天的提醒：
- 提前30天：确认业务是否继续、预算和原地址保留规则；
- 提前7天：完成审批、付款和备用方案检查；
- 提前1天：确认订单状态、监控和业务联系人；
- 到期后：核对是否停用，清理旧凭据与白名单。
具体时间可按团队采购周期调整。关键是提醒要进入工单或任务系统，不能只依赖某个人手机日历。
七、人员交接时要做什么
- 核对该人员拥有的账户、节点、白名单和密码库权限；
- 将业务责任转给新的明确负责人；
- 撤销原人员的登录会话、API令牌和共享权限；
- 对其曾接触的高权限凭据评估是否轮换；
- 更新台账、通讯录和故障升级路径；
- 让接任者用测试环境完成一次连接和回退演练。
离职撤权不能只删除WordPress或办公账号。代理平台账户、浏览器保存密码、本地配置和CI变量都应检查。
八、节点变更要留下哪些记录
任何更换地区、协议、IP、端口、认证或业务映射的操作，都应记录变更前值、变更后值、原因、审批、时间、执行人、验证和回退方式。涉及固定IP白名单时，先增加新地址并验证，再撤销旧地址。
节点首次验收可按天行IP订单交付验收清单执行。
九、每月做一次资源盘点
| 盘点项 | 判断 |
|---|---|
| 业务仍在使用吗 | 无流量且无负责人时进入停用评估 |
| 节点容量合适吗 | 长期闲置或持续超限都需要调整 |
| 凭据是否过度共享 | 发现群发或多人共用应拆分和轮换 |
| 订单和实付一致吗 | 核对优惠、余额和续费记录 |
| 白名单是否过期 | 撤销已停用地点和旧服务器出口 |
| 监控是否有数据 | 没有健康记录的备用节点不算可用备用 |
十、邀请码和渠道信息怎么进入台账
注册时若使用blsj，可在采购台账中记录渠道字段、注册时间和账户确认，但不要把“四折”直接写成未来每笔订单的固定预算。每次购买仍要保存结算页和最终订单，核算方法见blsj优惠金额计算。
一个成熟的节点台账应该让团队在负责人休假、员工离职或节点故障时，仍能在几分钟内回答：谁批准的、谁在用、何时到期、参数在哪、怎么切换、怎么撤销。
