所有问题都发到同一个群，工程师一天被 @ 二十次。值班制度回答的是"系统坏了谁修"，它回答不了另一半：系统没坏，但有人不会用、要一份数、想要个新功能。这一半量更大、更碎，长期以"顺手帮一下"的形式存在，成本从不进任何账。
通道设计要处理的正是这一半。它的核心不是"态度好不好"，而是三类决定：入口在哪、多久回应、谁负责。
1. 四类求助混在一个通道里，最急的会先被埋掉
| 类型 | 判据 | 时效 | 该谁接 | 混流的后果 |
|---|---|---|---|---|
| 故障 | 系统行为与预期不符，且影响多人 | 分钟级 | 值班 | 被"怎么用"刷走，告警被埋 |
| 使用疑问 | 功能正常，用法不清 | 小时级 | 文档/自助入口 | 消耗团队最贵的注意力 |
| 数据取数 | 一次性报表、口径询问 | 天级 | 数据 owner，进排期 | 被当成本职工作插进当天 |
| 需求 | 想要新能力 | 周级 | 需求池 | 与故障同池，优先级失真 |
混流的本质错误不是"人多吵"，是响应时限被统一了。一个通道只有一个隐含承诺；四类共用它，分钟级的那类必然被周级的那类拖住，而拖住的证据只出现在"用户抱怨慢"里。
判据很简单：看同一个通道里是否并存"分钟级"和"周级"的请求。并存，就一定出现急救排队。
// 一个入口，两档承诺：只有第一档能叫人
lane_p1: // 分钟级，触发寻呼
match: {kind: fault, impact: [team, all-users]}
lane_p2: // 小时到天级，只进队列
match: {kind: [usage, data, request]}
sla: {usage: 1d, data: 3d, request: next-plan}
通道的成本不在建，在维护：每多一个入口就多一份记录、多一次"这个该发哪里"的判断。所以正确方向是收窄入口、增加档位，而不是给每类问题开一个群。
2. "不是故障但很急"是最难的一类
它不满足故障判据：指标正常、只影响一个人。但当事人的工作在等它，所以它比很多故障更急。判定必须写成可执行条件，靠感觉判会把每一件都判成急。
| 条件 | 处置 |
|---|---|
| 有对外承诺的截止时间 | 按故障响应，可触发寻呼 |
| 阻断资金、合规或上线动作 | 按故障响应 |
| 单用户、存在绕行方案 | 普通求助，先给绕行路径 |
| 无承诺时间、可延后 | 进排期，给一个时间量级 |
// 求助单模板：字段本身就是分流器
kind: fault | usage | data | request // 请求方自选，接单方可改判
impact: single-user | team | all-users
deadline: none | 2026-11-12T18:00 // 只在有对外承诺时填
blocking: yes | no // 是否卡住正在进行的事
tried: "已查文档 §3，已重启客户端" // 排除项比描述更有价值
blocking: yes 加真实 deadline 是唯一该插队的组合。只有 blocking 没有截止时间，说明它在等一个可以商量的时间，不该打断连续工作——这类请求的正确答复是"今天下午给你"，而不是立刻切过去。
3. 通道的三个要素，与开始写文档的临界点
| 要素 | 定义不清时的表现 | 最小可行做法 |
|---|---|---|
| 入口 | 私聊、群、邮件、走到工位当面说 | 只留一个入口，其余一律回"贴到那里" |
| 时限 | 求助方不知道要等到什么时候 | 按类型给量级承诺，超时自动升级 |
| 归属 | 谁都能接，等于没人接 | 每类一个 owner；可拒收，但要指下一站 |
| 同一问题出现次数 | 判断 | 动作 |
|---|---|---|
| 1 次 | 个案 | 回答，留一行记录 |
| 2 次 | 可能是个案 | 回答，顺手补一条 FAQ 片段 |
| 3 次 | 系统性问题 | 停止重复回答，写进文档或做自助入口 |
| 5 次以上 | 入口设计错了 | 改入口、加校验、加进新人上手材料 |
─── 条目模板：判据 + 一步动作，写不成两行的说明还没写完
问题：上传附件报 415
判据：请求头 Content-Type 不含 multipart/form-data
一步：客户端显式设置 boundary，不要复用表单默认值
仍失败 → 贴请求头到入口，标 kind: usage
临界点是计数，不是感觉。"等有空再整理"意味着第四次还会被同一个人问，而这一次的成本会被记到"答疑"而不是"文档缺失"上，所以永远排不上优先级。
4. "帮我看一下"的成本：被打断的是连续时间
五分钟的忙，记的是处理时长。真实成本是恢复原任务所需的重新加载，典型量级是十几分钟到半小时，并且随当天已打断次数上升——第三次打断之后，很多人干脆不再回到原任务。
| 成本构成 | 是否进工时 | 说明 |
|---|---|---|
| 处理时长 | 进 | 唯一被看见的部分 |
| 上下文重建 | 不进 | 重新加载思路的固定开销 |
| 排队效应 | 不进 | 别人的等待变成你的插队 |
| 质量损失 | 不进 | 被切碎后判断更容易出错 |
// 响应承诺写成窗口，而不是"随时"
support_windows:
- "10:30-11:00" // 集中答疑，批量处理 usage 与 data
- "16:00-16:30"
quiet_hours:
- "09:00-10:30" // 只接 fault + all-users
- "13:30-16:00"
窗口不是拒绝，是把"随时"换成"可预期"。给了全时承诺，等于用故障响应能力补贴使用疑问——这种补贴不进报表，所以会一直补下去，直到有人开始躲消息。
5. "谁负责接"与"谁有能力接"的错位
| 错位形态 | 表现 | 修正 |
|---|---|---|
| 负责接的人不是能解决的人 | 转派三次才到对的人 | owner 前置到一线，或给一线一张判定脚本 |
| owner 写成某个人 | 离职、转岗后工单停在无人队列 | owner 写成角色，随组织调整同步 |
| 能者多劳 | 同一个人接走八成求助 | 用转派次数做指标，把知识做成入口 |
| 模式 | 收益 | 代价 | 适用 |
|---|---|---|---|
| 固定 | 积累深、答得快、能预判 | 疲劳；休假即断档 | 求助集中在少数子系统 |
| 轮转 | 知识扩散，无单点 | 前期慢，同类问题被重复问 | 求助面广、团队五人以上 |
| 混合 | 一人主责 + 一人影子 | 交接与影子期成本 | 新人期、转岗期 |
轮转最典型的失败方式，是把"接求助"当成排班而不是技能：轮到一个不熟的人，求助方被礼貌退回原通道，等于这一轮什么都没发生。轮转要成立，前提是上一轮已经把答案留在文档里，否则只是把等待重新分配一次。
固定与轮转的选择判据是问题的集中度：八成求助落在两三个子系统上，固定的人能提前预判并写文档；求助均匀散布在十几个模块上，固定的人会被迫每天切换十次上下文，轮转反而更省。混合模式只在过渡期成立——影子期结束还没有明确主责，就等于两个人都不负责。
6. 五个度量，和求助记录作为知识来源的价值
| 度量 | 口径要点 | 它能改变什么决定 |
|---|---|---|
| 求助量 | 按四类分开计，不合并成一个总数 | 判断入口是否过窄、哪类在涨 |
| 平均响应时长 | 按类型分别算，别算总平均 | 承诺是否兑现、哪类在拖 |
| 重复问题占比 | 同题归一后再算占比 | 下一条文档该写什么 |
| 被转派次数 | 每转派一次记一次 | 归属是否错位 |
| 自助解决率 | 文档/工具侧闭环数 ÷ 总量 | 分流投资是否见效 |
─── 周聚合：按类型分组，避免总平均把两类抵消掉
kind,count,p50_resp_min,p90_resp_min,reassigned,self_served
fault,12,3,11,2,0
usage,64,95,320,9,21
data,18,240,900,4,2
request,7,-,-,1,-
求助记录是唯一按真实提问频次排序的知识清单。文档通常按作者的想象排序：写得最细的是最熟悉的模块，而被问最多的往往是配置、权限、导出这类边角。把记录做一次同题归一，得到的顺序就是文档该有的顺序。
五个数里只有"重复问题占比"能直接指导投资，因为它指向具体一条待写的内容；其余四个是健康度指标，用来发现机制在退化。
"自助解决率"要特别小心口径：它统计的应是在文档或工具侧闭环、没有产生人工回复的请求。把"发了链接但对方没再问"算作自助，会把一堆实际上没人看懂的请求记成成功，这个数字越好看，通道越可能在漏人。
排错：五种失效现场
| 现象 | 原因 | 处理 |
|---|---|---|
| 故障告警被聊天刷走 | 通道混流，没有分级入口 | 只留一个能触发寻呼的规则，其余走工单 |
| 求助无人回应 | 归属是"大家" | 每类指定 owner，超时自动升级 |
| 同一问题每周被问 | 三次法则没执行 | 把回答写成条目，挂到入口第一屏 |
| 工程师开始躲消息 | 全时承诺 + 打断成本未计价 | 改成窗口承诺，保留故障入口 |
| 转派三次才解决 | 一线无判定能力 | 给一线一张判定表，owner 前置 |
边界：这些情况专门设计通道是过度管理
| 场景 | 做法 | 理由 |
|---|---|---|
| 团队极小（三四人） | 一个群 + 口头约定 | 分工靠默契，流程成本更高 |
| 求助量每天不足几条 | 谁看到谁答 | 分流与统计没有样本 |
| 业务只有单一系统 | 一条入口就够 | 分类维度不存在 |
| 求助方与实现方是同一批人 | 不需要通道 | 没有跨边界传递 |
| 已有服务台且质量可用 | 接进去，不另建 | 双入口会让记录分裂 |
判据是求助量 × 单次打断成本与流程维护成本之比。一天二十次、每次打断半小时，设计通道是省钱；一周三次，设计通道只是给自己找活干。
自测
- 四类求助混在一个通道里，最先坏掉的是什么——为什么不是"噪音"？
blocking: yes但deadline: none的请求，为什么不该立刻插队？- 三次法则为什么以"次数"而不是"感觉麻烦"为触发条件？
- 一次五分钟的"帮我看一下"，真实成本由哪几部分组成？
- "谁负责接"与"谁有能力接"错位时，最省成本的修正是什么？
- 五个度量里，哪一个能直接决定"下一条文档写什么"，为什么？