13.09 跨团队交付：网关、客户端与数据变更如何一起过业务门
返回第十三卷 · 问题定义：13.01 · 设计评审：13.07 · 迁移兼容：13.08 · 发布回退：12.09
13.09 跨团队交付：网关、客户端与数据变更如何一起过业务门
DeepTutor 八节初稿经技术与教学审阅后的静态课程。团队、里程碑、接口和验收均为虚构纸上安排；没有运行 Go、IM、数据库、测试、压测、部署或站点。当前 S2
/v1正文非空且最多 6 UTF-8 B、原始 HTTP 请求正文最多 4096 B、同 ID 重复 409、非成员隐藏 404、成功200 accepted_in_memory只表示本进程内存受理。未来 S3/v2的stored_in_teaching_db是提议且仍为 6 B，R9 的 6→9 B 待审。下文m-9/seq9/E9只是未来候选模型。09.02 当前合同
一、每个团队都“完成”了，不等于 A 和 B 的旅程完成
设想一次纸上交付：Go 团队说发送接口已改，数据团队说表已建，客户端说新回执可展示，平台说三副本 Ready，安全说成员权限待定。若 A 仍只拿到当前内存受理而界面写“已保存”，或 B 离线 25h 回来既不能有权补拉也看不到明确的能力限制，这些“各自完成”不能组成用户成功。交付单位应是同一个已定义的用户旅程与确认点，再把它拆给不同责任方。13.01 旅程与利益相关者 · DORA：Loosely Coupled Teams
本例先分两套承诺：当前 /v1 必须继续正确执行 6 B/409/404/accepted_in_memory；未来若产品批准 /v2 与 B 的 25h 目标，才评审“DB 确认 m-9/seq9 → 稳定 E9 派生 → B 从确实保留、按成员规则有权的历史补缺”。教学 broker 只留 24h，不能用它作为 B 25h 完整历史的唯一来源。若历史可见规则或留存期未定，团队仍可准备模式/客户端解析/观测的纸上方案，但不能宣布强合同上线。13.08 唯一权威与阶段门
| 交付结果 | 单个团队能交什么 | 还要谁的证据才闭合 |
|---|---|---|
A 当前 /v1 正确 | Go HTTP 处理与合同样例 | 客户端文案、旧端兼容、安全反例 |
A 未来 /v2 “已存” | Go 用例与 DB 权威写入设计 | 数据唯一/seq、DB 故障、客户端新回执批准 |
| B 25h 后有权补拉 | 历史接口与设备游标设计 | 产品/安全留存与可见规则、数据恢复、客户端能力 |
| 故障时安全交接 | 平台仪表盘和停止/回退路径 | 应用、数据、客户端和值班负责人共同演练 |
二、把每条跨团队箭头写成提供者与使用者都懂的契约
跨团队协作最常丢的不是一个 JSON 字段，而是字段的业务含义和失败状态。契约卡写明提供方、使用方、版本、输入/输出、确认点、错误、超时/重试、兼容窗口与谁维护验证样例。DORA 用“团队能否独立测试、修改、发布”观察松耦合；消费方驱动的契约测试思想可帮助双方把“我以为 200 是已送达”这类误解提前显露，但它本身不证明 DB/设备真正可靠。DORA：Loosely Coupled Teams · Pact：Consumer/Provider Contract
| 契约边界 | 提供者 → 使用者 | 必须写明的可观察结果 |
|---|---|---|
/v1 发送 | Go 网关 → 旧客户端 | 6 B/4096 B、重复同 ID 409、非成员 404、200 仅本进程内存受理 |
未来 /v2 发送 | Go 用例/数据 → 新客户端 | 经批准才返回 stored_in_teaching_db；仍 6 B；DB 不可写时不能冒报 |
| 权威消息 | 数据写入 → Send/History | 稳定 message_id、(c-a,seq9) 唯一、超时结果查证责任 |
| E9 派生 | 权威写入/事件中继 → Transfer | evt:m-9:v1 稳定身份、重投/重复处理、积压观察 |
| 历史与进度 | History/权限 → B 设备 | 谁能看哪段、seq8 缺时游标停 7、25h 保留前提 |
| 运行与回退 | 应用/数据 → 值班平台 | D/K/DB/事件/客户端版本、停止门、已有 stored 消息的兼容读取 |
表里的未来项不是既定 API。例如 R9 不是“E9 重投规则”，它是 6→9 B 独立待审需求；新 /v2 也不因启用 DB 就可接 7 B。契约样例应带正反例与版本，不把“字段存在”当兼容：旧端若不会解释 seq 或新回执，必须另定功能门/升级提示和同一会话跨端可见规则。09.10 协议兼容
三、执行者、决定者、值班者分开写，阻断问题才有人接
同一规则可能由数个团队实现或验证，但决定权不能在“大家一起负责”中消失。可在纸上给每个关键结果列一位业务决定者和参与者，真实项目再由相关人确认。产品决定 B 25h 是否成为承诺及 UI 用词；安全与产品共同确定退出会话后历史可见边界；客户端决定能力协商/多端 ACK 形式；Go 服务落实当前 409/404 与未来确认点；数据负责权威唯一、保留和恢复；平台和值班负责可观察发布与故障交接。Google SRE：Engagement Model
| 待决定的规则/结果 | 决定责任 | 执行/验证参与 | 未决定时仍可做什么 |
|---|---|---|---|
| B 25h 与回执文案 | 产品与客户端负责人 | Go、数据、值班 | 保持当前 S2 文案；设计候选场景，不启用承诺 |
| 退群后的旧历史可见 | 产品/安全按职责共同签定规则 | History、客户端、数据 | 预留时间/身份判断位置，不开放未定读路径 |
/v2 stored 是否可声称 | Go/数据的权威写入责任，经产品批准 | 客户端、值班 | 准备 schema/故障设计，不返回拟议结果 |
| D/K/DB/E9 回退与值班 | 应用/数据/平台明确各轴执行人和值班接手人 | 客户端、安全 | 写演练方案、保持已有 /v1 能力 |
这里“共同签定”不等于模糊：历史可见规则要有一份最终批准的文字和版本，并指明由谁发起、谁有否决权、谁把它变成查询/测试。若产品与安全尚未达成规则，这是进入 B 补拉灰度的阻断项，但不阻止独立完成当前合同测试、日志脱敏和未来 DB 模式的兼容草案。把依赖列出来，才能既避免等所有人再动工，也避免绕过真正的决定。13.07 阻断问题
四、里程碑按前置证据排，不按各团队工期简单拼接
下表是课程计划，不是项目进度或发布日历。它承接 13.08 的 P0–P5 迁移门，但“里程碑 0–4”表示跨团队要交的共同证据，不重定义 S2/S3 阶段号。13.08 扩展/迁移/收缩
| 里程碑 | 可并行准备 | 必须先满足才可进入下一门 |
|---|---|---|
| 0：现状与目标 | /v1 合同、旧客户端清单、B 场景/失败成本 | 25h/历史可见/留存的决定状态清楚，未决项可见 |
| 1：兼容准备 | DB 模式/唯一性方案、客户端新回执解析、E9 字段、观测/告警草案 | P1 结构不改变旧 200；D/K/数据版本可追踪 |
| 2：隔离端到端 | 限定 c-test-v2、稳定 ID、DB 权威、权限、B 补拉和失败反例 | 规则获批；DB commit 才 stored；旧端 7 B 仍拒绝 |
| 3：受控灰度 | cohort 路由、影读对账、热群/长离线与回退演练 | 不能靠随机 Pod 混权威；已有 stored 消息可被兼容读 |
| 4：运行交接 | 值班手册、报警路由、客服/产品说明、关闭阻断项 | 用户结果/异常处置/数据责任有真实证据才可宣布交付 |
有几条关键依赖不能颠倒：成员历史规则→History 授权用例；DB 稳定 ID/序号与确认→/v2 stored 语义；客户端新回执/游标能力→相应 cohort 曝光；故障演练与兼容读→扩大或回退。相反，DB 模式兼容设计、客户端解析样例与只读观测草案可以在规则评审期间各自准备。若“模式完成”却权限规则未定，里程碑 1 可有产物，里程碑 2 仍不能通过。DORA：独立交付与契约
五、跨团队验收以同一场景贯通，不止 mock 绿了
消费方样例与提供方验证可提前锁住格式和错误，例如旧客户端的 6 B/409/404/200、未来客户端如何解析 stored、新事件消费者如何识别重复 E9。但契约测试不能替代真实 DB 原子写入、成员授权、25h 历史保留或故障后恢复；模拟器按预设返回一次“成功”只证明约定的交互形状。Pact：Contract Testing · DORA：Loosely Coupled Teams
| 共同验收场景 | 应由谁提供证据 | 如果只看单团队成功会漏什么 |
|---|---|---|
A 当前 /v1 同 ID 重试/非成员/7 B | Go + 客户端 + 安全 | 409/404/6 B 被新版本偷换、200 文案冒称送达 |
| 未来 DB 已存、E9 未发或重投 | 数据 + Go + Transfer + 值班 | 一条权威消息对应重复事件，或事件缺口无人恢复 |
| B 先见 9 缺 8 | 客户端 + History + 数据 | 最大已见游标错写 9，后续历史永远跳过 8 |
| B 离线 25h、broker 仅留 24h | 产品/安全 + 数据 + 客户端 + 值班 | 历史未保留/无权、补拉与实时流交叉时乱序 |
已确认 /v2 stored 后代码回退 | 发布/数据 + 客户端 + 值班 | D2→D1 后 DB 读被关，用户看不见已确认消息 |
当前没有运行这些测试。未来执行时，结果要按同一批用户、会话、版本、请求/消息 ID、时间窗和确认点关联，不能把 Go 单测、DB migration CI、客户端截图和 Pod Ready 四张绿图拼成“端到端通过”。安全/隐私反例也不应只在理想成员状态下测：成员来源异常或退群历史规则未定时，必须停止相关未来能力，而不是靠服务可用性目标猜权限。11.01 用户确认点
六、发布与事故交接沿用户结果走，不沿组织边界甩锅
未来若真的进入 /v2 灰度，一份联合操作卡至少写：谁宣布开始、谁看 A /v1 正反例与 /v2 stored、谁看 DB 权威/E9 积压/B 历史、谁决定暂停新写、谁保留已确认数据的兼容读、谁通知产品/客服和谁值班。发布资产有D1/D2 镜像、K1/K2 配置、DB 模式/数据、E9、客户端版本五轴；回退任何一轴都不能悄悄撤销另外一轴已经对用户作出的承诺。12.09 多轴回退 · Google SRE：早期参与和值班交接
| 警报/停止门 | 首位接手与共同处置 | 用户结果怎样核实 |
|---|---|---|
新 /v2 DB 写失败/结果未知 | Go + 数据，值班指挥止扩量 | 不冒报 stored，按稳定 ID 查证，旧 /v1 不改义 |
| E9 积压/重投 | Transfer + 数据 + 值班 | 权威唯一、B 设备/补拉缺口与队列年龄分开看 |
| 旧端 7 B 被接纳或非成员泄露 | Go + 安全 + 客户端，产品决定影响 | 恢复 6 B/404 合同，核受影响请求与会话 |
回退后 /v2 已存消息不可读 | 数据 + Go + 客户端，值班协调 | 恢复兼容读/前进修复，不删 m-9/seq9 |
一份值班手册要有可执行的只读诊断顺序、版本与确认点、升级对象、止损权限、恢复/对账方法和退出故障状态的证据。Google SRE 的参与模型强调设计阶段就让运行人员理解依赖与故障，并在限制开放阶段共同学习；这不是“交付当天让平台同学接锅”。Google SRE：SRE Engagement Model
七、交付板记录依赖、证据和未关闭风险
纸上任务卡可以很简单，但每项至少写owner、输入依赖、产物、可验证证据、决定者、停止/升级条件。例如“客户端支持 stored”如果没有 /v2 DB 确认的提供方契约，不能标“端到端完成”；“成员历史规则未定”不能被技术工单的已合并状态自动关闭。里程碑的状态应由共同证据决定，责任图由实际工作需要调整，而非为了把每个人都塞进一列。DORA：Loosely Coupled Teams
| 风险/未决项 | 影响的交付门 | 当前纸上状态 | 需要谁补什么 |
|---|---|---|---|
| 退群后历史可见未决定 | B 有权补拉 | 阻断里程碑 2 的权限验收 | 产品/安全给规则与反例 |
/v2 DB 唯一/超时结果待证 | stored 回执 | 阻断里程碑 2 的强确认 | Go/数据给原子/查证设计与未来实验 |
旧端不理解 seq/新回执 | cohort 扩大 | 阻断相关旧端曝光 | 客户端/产品定能力与提示 |
| B25h、热群和积压 | 目标时延/容量 | 待验证，非现有 SLO | 数据/Transfer/值班给同负载实验 |
| 已存消息的回退兼容读 | 里程碑 3/4 | 阻断扩量与交接 | Go/数据/发布演练保全权威路径 |
固定 openimsdk/open-im-server 提交 f6411a8a1a31d3df36f4c2b3ad28481a94141e1f 的 send.go 选定路径调用 MsgToMQ 后返回；另一 Mongo 消费路径调用 BatchInsertChat2DB。两处只支持所读异步边界，不能推出 OpenIM 的真实团队职责、发布里程碑、产品目标或本章的权威/ACK 设计。OpenIM 阅读地图
八、22 道分层练习：审一张跨团队交付板
先辨提供/消费和决定权，再推前置依赖与事故，最后审业务完成条件。答案均基于本章虚构纸上任务。
基础 1–8：交付与契约
1. 各团队 PR 都合并能证明 B 25h 补拉吗？
不能。还需批准的历史规则、真实保留/权威、客户端能力和端到端结果证据。
2. `/v1` 当前 200 到哪一层？
accepted_in_memory 只表示本进程内存受理。
3. 未来 `/v2` 即使获批，正文上限是多少？
仍为 6 UTF-8 B；R9 6→9 B 独立待审。
4. 契约卡至少写哪两方？
提供者和使用者，还要版本、输入/输出、失败/重试、确认点与验证责任。
5. `E9=evt:m-9:v1` 是第二条权威消息吗？
不是，是未来由权威消息派生的稳定事件身份。
6. 当前同 ID 重复提交应怎样？
按 /v1 合同返回 409，即使正文相同。
7. 成员历史规则由单个 Go 工程师直接拍板吗？
不能。产品/安全要确定规则与例子，Go/History 实现并验证。
8. 三副本 Ready 就代表跨团队交付完成吗？
不能。它不证明消息确认、权限、设备补拉或回退。
推演 9–16：前置关系与反例
9. DB schema 可在历史可见规则未定时设计吗？
可准备兼容草案；不能因此启用 B 历史读取或声称里程碑 2 过门。
10. 哪项证据先于 `/v2` 返回 stored？
经批准的权威 DB 写入确认、稳定 ID/唯一规则和 DB 故障/超时查证合同。
11. 新客户端能解析 seq，就可随机把同一会话一半请求送旧 Pod 吗？
不能。还需单一权威与 cohort/会话路由，避免同 ID 的两套确认与历史。
12. DB 已有 `m-9/seq9`，E9 未发，谁负责什么？
DB 权威不能被否认；Go/数据/Transfer/值班按已定义恢复与告警责任补事件，不冒称 B 已收到。
13. B 连续到 7、先见 9 缺 8，谁的合同被考验？
History 的有序补拉与客户端每设备连续游标；不能推进为 9。
14. B 离线 25h、broker 仅留 24h，谁还要协作？
产品/安全定有权窗口，数据保证真实保留，History/客户端补拉，值班观察恢复。
15. 旧客户端发 7 B，新 Go 版本可直接接纳吗？
不能。/v1 仍为 6 B，R9 尚待独立批准。
16. `/v2` 已确认 stored 后回滚 D2→D1 并关 DB 读，会怎样？
已确认消息对用户不可见；须保留兼容读、暂停新写或前进修复，不能删除权威数据。
决策 17–22：里程碑和故障交接
17. 历史可见规则未定，可把 B 补拉测试记已完成吗？
不能。是权限验收阻断项，可继续其它独立准备。
18. 一份消费者/提供者契约测试能证明 DB 故障可恢复吗？
不能。它可验证交互期望，还需 DB/事件/客户端故障和业务观察证据。
19. 未来 E9 重投，谁保证不变第二条权威消息？
Go/数据守稳定消息 ID 与权威唯一性，Transfer 消费规则处理重复，值班可观察差异。
20. 里程碑 3 扩量前至少关闭哪类风险？
当前合同、DB 强确认、权限/旧端能力、重投/补拉与已存数据的回退兼容读阻断项。
21. 两处固定 OpenIM 源码能证明其团队分工和交付流程吗？
不能；只支持所读发送到 MQ 与另一 Mongo 消费路径的异步边界。
22. 交付板一项真正完成需附什么？
owner、输入依赖、版本化契约与产物、可复核证据、决定人、停止/升级条件和共同用户结果。
本章完成标准与后续路径
能把 A 当前受理与未来 B 有权补拉分成版本化提供/消费契约，按产品、安全、客户端、Go、数据和值班的真实决定权排依赖，解释为何 PR 全绿仍不足以宣布用户结果通过，并写清已确认新数据后的事故交接，才算完成第一轮。下一章13.10 技术债与演进将用变更与故障成本排序偿还工作，审架构是否随时间漂移。