三份互不对齐的盘点表，压出 72 项工作、14 条跨岗接口、10 条流程。回答一个问题：这个部门谁在做什么、谁的产出是别人的输入、哪里只有一个人。
三个组的分工是清楚的，问题在于边界只在组织图上清楚，在流程上不清楚——平台组管入口、应用组管功能、运维组管生产，但一次发布要三组同时在场。
| 组别 | 人员 | 编制口径 | 核心产出 |
|---|---|---|---|
| 平台组 | 顾清源 TL（平台负责人）· 冯致远（网关）· 苏雨桐（中间件） | 3 人 26 项 |
网关、注册配置中心、公共组件库 |
| 应用组 | 郑北辰 TL（应用负责人）· 林知微（订单域）· 何嘉树（支付账务域）· 温若曦（前端） | 4 人 26 项 |
业务功能、对账批处理、支付差异 |
| 运维组 | 陈砚舟 TL（SRE）· 白宇帆（运维）· 技术实习生 | 2 人 + 1 名 20 项 |
生产发布、K8s、监控告警 |
| 技术总监（不在编制内） | 段明川 | 不领事项 只出现在审批链 |
发布终审、演练报告、成本审批 |
逐人对齐三份表。项数不代表负荷——26 / 26 / 20 看着均衡，但运维组的分工表里有 4 行是空的。
| 人 | 主要在做 | 关键词 |
|---|---|---|
| 顾清源平台组 · 平台负责人 | 管方案评审与排期，也是唯一能裁技术争议的人；手里握着技术债台账——但台账 2025 年后没更新过，属于「写了不做」。 | 方案评审技术债台账排期会技术裁决网关可用性 |
| 冯致远平台组 · 后端工程师（网关） | 网关的路由、限流、灰度规则都由他改。42 个服务的入口配置只有他熟，灰度规则是发布链的第一道闸。 | 路由配置限流熔断灰度规则网关压测 |
| 苏雨桐平台组 · 中间件工程师 | Kafka 与 Redis。topic 配额和消息重放是跨组动作——支付对账的差异要靠她重放补数据，但重放没有工单留痕。 | KafkaRedistopic 配额消息重放积压处置 |
| 人 | 主要在做 | 关键词 |
|---|---|---|
| 郑北辰应用组 · 应用负责人 | 需求受理、封板、合并门禁三件事都过他。流程的第 0 步在他手上，但这一步不进任何流程表，也没有时限。 | 需求受理版本封板合并门禁问题定级发布审批 |
| 林知微应用组 · 高级后端（订单域） | 订单域全栈负责人。每天 T+1 跑对账批处理，结果直接进财务部；分库分表规则只有他清楚。 | 订单域状态机对账批处理分库分表慢 SQL |
| 何嘉树应用组 · 后端（支付账务域） | 支付渠道 + 账务记账。与财务部每日对一次支付差异，现网有 4 笔差异挂了 6 天，超过表里自己写的 3 天升级线。 | 支付渠道账务记账回调幂等支付对账安全合规 |
| 温若曦应用组 · 前端工程师 | 全部前端交付。发布前的兼容性与灰度验证由她签字，签完才轮到运维执行——她是发布链上唯一有否决权的非管理者。 | 管理后台H5组件库兼容性验证埋点 |
| 人 | 主要在做 | 关键词 |
|---|---|---|
| 陈砚舟运维组 · 运维负责人 / SRE | 生产变更唯一终审人 + 唯一发布执行人 + 唯一回滚执行人。9 项里 3 项是发布相关，其余是 K8s、云账号、容量成本。 | 生产变更审批发布回滚K8s云账号权限容量成本 |
| 白宇帆运维组 · 运维工程师 | 工单、日志、流水线、堡垒机、DB 变更执行。11 个钩，没有一个是「决策」——全是执行，且都在陈砚舟的审批下游。 | 工单处理CI/CD堡垒机DB 变更执行证书续期 |
| 技术实习生运维组 · 技术支持（实习） | 账号开通、软件安装、会议设备 3 项，与白宇帆完全重合，不构成独立岗，也不该出现在岗位盘点里。 | 账号开通办公网络会议设备 |
只画跨人交接的链。第③行是全篇的重点：审批、执行、回滚三个角色落在同一个人身上。
判定用五条件：跨人、有传递物、有时点、缺了下游会卡住、说清断了会怎样。全中的才收进来。
流程信息全从「内控流程 / 审批系统 / 时点」三列还原。58 项里 26 项写的是「无相关内控流程」——接近一半的工作没有书面节点。
| 谁 | 做什么 | 时点 · 系统 | 产出 / 交接 | |
|---|---|---|---|---|
| 01 | 郑北辰应用组 · 应用负责人 | 从 OA 与群消息收需求，判断是功能需求还是故障工单 | 每工作日 09:30 | 分流结论 |
| 02 | 郑北辰应用组 · 应用负责人 | 按域分派：订单→林知微，支付→何嘉树，前端→温若曦，平台→顾清源 | 当日 | 分派工单 |
| 03 | 郑北辰应用组 · 应用负责人 | 组长确认排期，进迭代池或退回 | 每周一 | 迭代池 |
| 04 | 郑北辰应用组 · 应用负责人 | 回写需求方，告知排期 | 3 个工作日内 | 排期回执 |
断链风险 4 步全部由一个人完成，中间一次交接都没有。按这个部门自己的标准，一个人从头做到尾的叫作职责、不叫流程——所以它没被写进流程库，也就没人给它定时限。
汇总表备注自己写着「无受理时限，平均滞留 2.7 天」：需求从进门到被分派平均卡 2.7 天，比一次自测窗口还长。交接发生在第 4 步之后（分派给林知微/何嘉树/温若曦），但那时时限已经过去了。
| 谁 | 做什么 | 时点 · 系统 | 产出 / 交接 | |
|---|---|---|---|---|
| 01 | 郑北辰应用组 · 应用负责人 | 版本封板，锁定本期需求清单 | 迭代 D0 | 封板清单 |
| 02 | 林知微应用组 · 订单域 | 订单域开发，接口文档先行（D3 交前端） | D1–D8 | 接口文档 + 代码 |
| 03 | 何嘉树应用组 · 支付账务域 | 支付与账务域开发，同步改记账任务 | D1–D8 | 记账任务变更 |
| 04 | 温若曦应用组 · 前端 | 前端开发与联调，兼容性覆盖 | D3–D9 | 自测记录 |
| 05 | 郑北辰应用组 · 应用负责人 | 代码评审，不通过则打回重提 | D9 | 评审记录 |
| 06 | 温若曦应用组 · 前端 | 灰度前兼容性验证，签验证记录 | D10 | 验证记录 |
断链风险 封板后需求再变要二次审批，但表里没写谁批；实际是郑北辰口头默认，变更评估这一项在汇总表里干脆没有（见 06 的 14 项缺口）。
| 谁 | 做什么 | 时点 · 系统 | 产出 / 交接 | |
|---|---|---|---|---|
| 01 | 冯致远平台组 · 网关 | 配置灰度规则（按用户 / 地域 / 比例） | 发布前 1 天 | 灰度规则 |
| 02 | 陈砚舟运维组 · SRE | 执行发布，先放 5% | 发布窗口 | 发布单 |
| 03 | 温若曦应用组 · 前端 | 灰度环境功能与兼容性验证 | T+30min | 验证记录 |
| 04 | 陈砚舟运维组 · SRE | 指标正常则全量，异常则回退到上一版本 | T+60min | 全量或回滚记录 |
断链风险 第 4 步的「异常则回退」和第 2 步是同一个人。回退判断由发布者自己做，没有第二双眼睛。
| 谁 | 做什么 | 时点 · 系统 | 产出 / 交接 | |
|---|---|---|---|---|
| 01 | 郑北辰应用组 · 应用负责人 | 提变更申请，附影响面与回滚方案 | 发布前 1 天 | 变更单 |
| 02 | 郑北辰应用组 · 应用负责人 | 应用侧审批通过 | 发布前 1 天 | 审批记录 |
| 03 | 陈砚舟运维组 · SRE | 运维终审（唯一终审人） | 发布当天 | 终审通过 |
| 04 | 陈砚舟运维组 · SRE | 执行发布（唯一执行人） | 发布窗口 20:00–22:00 | 发布单 |
| 05 | 温若曦应用组 · 前端 | 发布后功能验证并签字 | T+30min | 验证记录 |
| 06 | 陈砚舟运维组 · SRE | 异常则回滚（唯一回滚执行人），正常则关单 | T+60min | 回滚记录 / 关单 |
断链风险 第 3、4、6 步是同一个人。表里内控流程写的是「变更申请 → 组长审批 → 运维审批 → 执行 → 复核」，五个环节看着齐全，实际「运维审批」「执行」「回滚」三个角色压在陈砚舟一人身上，而「复核」这一环没有任何人。他休假 = 全部门停发；他离职 = 没人能回滚。
| 谁 | 做什么 | 时点 · 系统 | 产出 / 交接 | |
|---|---|---|---|---|
| 01 | 林知微应用组 · 订单域 | 提 DB 变更单，附 DDL 与回滚脚本 | 按迭代 | 变更单 |
| 02 | 陈砚舟运维组 · SRE | 复核结构与索引，评估锁表影响 | 1 个工作日内 | 复核意见 |
| 03 | 白宇帆运维组 · 运维工程师 | 在变更窗口执行，留存执行记录 | 变更窗口 | 执行记录 |
| 04 | 白宇帆运维组 · 运维工程师 | 归档执行记录与回滚脚本 | 执行后 | 归档 |
断链风险 复核与执行分了两个人，这一条内控是完整的。唯一的问题是没有多环境顺序约束——预发与生产共用一套 DDL 脚本，跳过预发直接上生产的情况存在。
| 谁 | 做什么 | 时点 · 系统 | 产出 / 交接 | |
|---|---|---|---|---|
| 01 | 何嘉树应用组 · 支付账务域 | 拉渠道对账单与内部记账流水 | T+1 09:00 | 对账结果 |
| 02 | 何嘉树应用组 · 支付账务域 | 逐笔比对，输出差异明细 | T+1 11:00 | 差异明细表 |
| 03 | 何嘉树应用组 · 支付账务域 | 差异挂账，超 3 天升级（升级对象未定义） | T+1 14:00 | 挂账清单 |
| 04 | 苏雨桐平台组 · 中间件 | 消息丢失类差异由她重放补数据 | 按需 | 重放记录 |
| 05 | 张启明财务部 · 对账与结算 | 财务确认挂账或调账 | T+2 | 确认回执 |
断链风险 第 3 步写着「超 3 天升级」，却没写升级给谁——现网 4 笔已挂 6 天。第 4 步依赖苏雨桐手工重放，重放动作没有工单，做过几次查不到。
| 谁 | 做什么 | 时点 · 系统 | 产出 / 交接 | |
|---|---|---|---|---|
| 01 | 林知微应用组 · 订单域 | 批任务失败告警，确认失败范围 | T+1 02:00 | 告警 |
| 02 | 白宇帆运维组 · 运维工程师 | 先看资源与依赖（Kafka / DB） | T+1 02:30 | 排查记录 |
| 03 | 苏雨桐平台组 · 中间件 | 确认是否消息积压或丢失 | 按需 | 积压 / 丢失结论 |
| 04 | 林知微应用组 · 订单域 | 补跑批任务，核对结果 | T+1 08:00 | 对账结果文件 |
断链风险 凌晨 2 点的告警先到白宇帆，但判断「是不是消息丢了」只有苏雨桐能做，判断「批任务本身错没错」只有林知微能做。两个人都在睡觉，第 4 步 08:00 的时限就变成了硬扛。
| 谁 | 做什么 | 时点 · 系统 | 产出 / 交接 | |
|---|---|---|---|---|
| 01 | 全体研发需求方 | OA 提申请，写明权限范围 | 按需 | 申请单 |
| 02 | 陈砚舟运维组 · SRE | 审批云账号与系统权限 | 1 个工作日 | 审批记录 |
| 03 | 白宇帆运维组 · 运维工程师 | 开通并登记权限台账 | 当日 | 权限台账 |
| 04 | 陈砚舟运维组 · SRE | 季度复核权限，回收离职与超范围 | 每季度 | 复核记录 |
断链风险 第 4 步的季度复核近两季没做。权限一旦开通就没人回收，这是审计最常问的一条，也是三条内控里唯一「流程写了但执行断了」的。
| 谁 | 做什么 | 时点 · 系统 | 产出 / 交接 | |
|---|---|---|---|---|
| 01 | 白宇帆运维组 · 运维工程师 | 告警触发，先做初判 | 即时 | 初判记录 |
| 02 | 郑北辰应用组 · 应用负责人 | 按影响面定级 P1 / P2 / P3 | 15 分钟内 | 定级单 |
| 03 | 陈砚舟运维组 · SRE | P1 由顾清源任技术总指挥，陈砚舟负责恢复 | 即时 | 处置记录 |
| 04 | 陈砚舟运维组 · SRE | 组织复盘会，出改进项 | P1 后 3 个工作日 | 复盘报告 |
| 05 | 顾清源平台组 · 平台负责人 | 改进项跟踪与关闭 | 每月 | 改进项台账 |
断链风险 定级在郑北辰、处置在陈砚舟、指挥在顾清源、改进项跟踪又在顾清源——P1 现场有三个决策人，没有唯一指挥。这是双钩最多的场景（监控告警 1 项双钩、发布类 2 项双钩），说明边界在故障场景下是模糊的。
| 谁 | 做什么 | 时点 · 系统 | 产出 / 交接 | |
|---|---|---|---|---|
| 01 | 白宇帆运维组 · 运维工程师 | 人工核对到期时间（无提醒机制） | 每月一次 | 到期清单 |
| 02 | 白宇帆运维组 · 运维工程师 | 提交续期，走财务付款 | 到期前 30 天 | 续期申请 |
| 03 | 张启明财务部 · 对账与结算 | 付款与发票 | 到期前 15 天 | 付款凭证 |
断链风险 三步全靠人工记。表里备注写着「无到期提醒机制」——这类事漏一次就是线上 HTTPS 全站不可用，而它排在白宇帆 11 个钩的最后。
按「出事概率 × 影响面」排序。前三项都不是工作量问题，是结构问题。
如果只做一件：把发布权限拆成两个人。其余按「改动成本 ÷ 风险下降」排序。