职责与服务目录¶
这一页回答一个问题：遇到具体的事，该谁做、能不能自己做、走什么流程。
配套阅读：部门介绍（我们负责什么）、内部台账（哪些还没定）。
一、三种处理方式¶
任何一件事，先判断它属于哪一档。判断不清就按第三档处理——多问一次的成本，远小于自己试坏的成本。
| 档次 | 判据 | 例子 | 怎么走 |
|---|---|---|---|
| 🟢 自助可做 | 做错不影响别人、不需要审批、出问题能自己恢复 | 在自己的账号下装软件、配自己的开发环境；自己机器上的组网客户端重连、服务重启；给自己的项目建目录、写文档、提 PR | 看完文档直接做 |
| 🟡 先问再做 | 影响共享资源或其他人 | 占用 GPU 或长时间跑任务；在共享服务器上装系统级依赖、改全局配置；新增常驻服务、占用端口；改共享目录的权限；让某台机器对组网或公网暴露服务 | 开服务请求 Issue，等回复 |
| 🔴 必须走流程 | 出错的后果超出单台机器或单个人 | 改服务器网络配置（路由、防火墙、组网策略）；动共享存储（迁移、扩容、删除策略）；变更访问控制；创建或删除账号、轮换凭据；让服务对公网开放；变更备份策略 | 不能自己动，先开服务请求 Issue |
读文档、查资料、在共享库里找现成的做法属于 🟢。判断不清时，宁可当成 🟡 走一次 Issue。
🔴 类操作没有「我先试试」这个选项。试坏一次的恢复成本经常是几小时到几天，而且可能已经影响到别人。
二、服务目录¶
「谁处理」按流程直接判定，不依赖个人分工：要先审批的走责任人转批，🔴 类当天响应，其余由值班人接单。具体值班安排见第五节。
2.1 服务器与算力¶
| 需求 | 档次 | 流程 | 谁处理 |
|---|---|---|---|
| 申请服务器账号 | 🔴 | 服务请求 Issue → 负责人审批 | 值班人立即响应 |
| 申请 GPU 算力 / 排队 | 🟡 | 服务请求 Issue，说明用途与时长 | 值班人 |
| 在共享服务器装系统级依赖 | 🟡 | 服务请求 Issue，说明为什么不能在容器里装 | 值班人 |
| 新增常驻服务 | 🟡 | 服务请求 Issue，注明端口与监听地址 | 值班人 |
| 装自己的 Python/Node 环境 | 🟢 | 自己装，建议放自己的目录或用虚拟环境 | — |
| 服务器扩容、加盘、换硬件 | 🔴 | 服务请求 Issue → 部门负责人 → 采购 | 值班人立即响应 |
| 存储迁移、备份策略变更 | 🔴 | 服务请求 Issue + 方案评审 | 值班人立即响应 |
| 恢复误删的文件 | 🔴 | 立即找值班人，不要继续写盘 | 值班人立即响应 |
2.2 网络与设备互联¶
| 需求 | 档次 | 流程 | 谁处理 |
|---|---|---|---|
| 新设备接入组网 | 🟡 | 服务请求 Issue，提供设备类型与用途 | 值班人 |
| 需要访问实验室内网整段地址 | 🟡 | 服务请求 Issue，说明要访问什么 | 值班人 |
| 让某台设备/服务被组网内其它设备访问 | 🔴 | 服务请求 Issue + 说明暴露范围与鉴权方式 | 值班人立即响应 |
| 对公网暴露服务 | 🔴 | 服务请求 Issue + 评审 + 必须带访问控制 | 值班人立即响应 |
| 改防火墙 / 路由 / 组网策略 | 🔴 | 服务请求 Issue + 方案评审；改动前先备份配置 | 值班人立即响应 |
| 自己机器的组网客户端重连 | 🟢 | 看Tailscale 组网的常见问题 | — |
| 校园网线路、出口 IP 问题 | ➡️ | 不归我们，报学校网络中心 | — |
2.3 Agent 平台与工具链¶
| 需求 | 档次 | 流程 | 谁处理 |
|---|---|---|---|
| 接入共享 Agent 平台 | 🟡 | 服务请求 Issue | 值班人 |
| 新建/修改共享技能 | 🟡 | 服务请求 Issue，或直接提 PR（首选 PR） | 值班人 |
| 往共享知识库加内容 | 🟢 | 直接提 PR，见仓库根的 CONTRIBUTING.md |
— |
| 平台本身故障 | 🔴 | 立即找值班人 | 值班人立即响应 |
| 工具选型建议 | 🟢 | 先看参考的选型说明 | — |
2.4 ComfyUI 与生成式工作流¶
| 需求 | 档次 | 流程 | 谁处理 |
|---|---|---|---|
| 申请 ComfyUI 使用权限 | 🟡 | 服务请求 Issue | 值班人 |
| 装新的自定义节点 / 模型 | 🟡 | 服务请求 Issue，说明来源与体积 | 值班人 |
| 显存不够、队列卡住 | 🟢 | 先看ComfyUI 专题的常见问题 | — |
| 清理占用的大文件 | 🔴 | 先问，不要自己删共享模型 | 值班人立即响应 |
2.5 边缘设备¶
| 需求 | 档次 | 流程 | 谁处理 |
|---|---|---|---|
| 借设备 / 申领设备 | 🟡 | 服务请求 Issue | 值班人 |
| 在设备上部署 Agent 或推理服务 | 🟡 | 服务请求 Issue + 说明供电与网络条件 | 值班人 |
| 设备无法启动、连不上 | 🟡 | 服务请求 Issue，附现象与日志 | 值班人 |
| 送修、采购 | 🔴 | 服务请求 Issue → 部门负责人 | 值班人立即响应 |
2.6 账号权限与数据服务¶
| 需求 | 档次 | 流程 | 谁处理 |
|---|---|---|---|
| 开通/停用账号 | 🔴 | 服务请求 Issue + 审批 | 值班人立即响应 |
| 修改共享目录权限 | 🔴 | 服务请求 Issue + 审批 | 值班人立即响应 |
| 申请凭据（token、密钥等） | 🔴 | 线下对接；文档里只记录「在哪、谁管」 | 值班人立即响应 |
| 保管自己的凭据 | 🟢 | 凭据放进自己的凭据存储，任何仓库里都不留 | — |
| 怀疑凭据泄露 | 🔴 | 立即找值班人轮换；不要在 Issue 里贴出凭据 | 值班人立即响应 |
三、一次服务请求的完整流程¶
① 开 Issue（用「服务请求」模板填全要素）
↓
② 三个工作日内首次回复：排期 / 补充信息 / 说明为什么做不了
↓
③ 执行（🟡 与 🔴 都要有明确的负责人）
↓
④ 按事先约定的验收标准确认做完
↓
⑤ 回填文档：这次操作里有可复用的部分吗？有就写进【参考】或【经验】
**第 ⑤ 步是必做的。**如果跳过它，这个部门就会不断重复解决同一个问题，并且依赖记得住的人。判断一次服务请求做得值不值，看的正是第 ⑤ 步有没有产出。
请求被拒，通常会是因为¶
| 原因 | 怎么办 |
|---|---|
| 用途说明不清 | 补充「要做什么事」，需要的资源由我们据此判断 |
| 资源排不上 | 协商时间窗口，或说明为什么必须现在 |
| 有更简单的做法 | 按建议的做法走；如果确实不行，说明为什么不行 |
| 有安全或合规风险 | 与负责人一起设计一个可控的替代方案 |
| 不属于本部门 | 我们帮你转给对的人，或直接告诉你找谁 |
四、故障上报怎么写¶
**先说影响，再说现象。**顺序反了会让人判断不出紧急程度。
【影响】哪些人/哪些项目现在做不了事？有没有波及正在跑的长任务？
【现象】什么时间开始的？之前做过什么改动？
【范围】一台设备还是一个服务？别人也遇到吗？
【已尝试】试过什么、结果如何
【原文】报错信息原文（不要转述）
不要只说「XX 用不了了」——那需要三轮追问才能开始处理。
不要在公开 Issue 里贴：内网 IP、主机名、账号名、报错里带的 token 或路径。转成描述性文字，需要细节时我们线下要。
五、值班与响应¶
| 场景 | 找谁 | 期望响应 |
|---|---|---|
| 影响多人的服务中断 | 值班人（值班表见内部台账） | 当日内 |
| 一般服务请求 | 对应职责负责人 | 三个工作日内首次回复 |
| 咨询与上手 | 文档优先 → 部门讨论群 | 一周内 |
| 安全事件（泄露、入侵迹象） | 部门负责人 + 指导老师，同时停止相关服务 | 立即 |
时限与值班表以内部台账补齐后为准。上面是拟定的约定，写在这里是为了先有一个可以被讨论和被修改的对象——没有约定的「尽快」到最后等于没有约定。