《互联网产品的服务端架构·规模化与架构演进》12.1 团队边界与系统边界

一次“两个团队都说自己负责订单”的排障

「回声」在 2026 年做了一次组织调整，把原来的订单域拆成交易团队和履约团队。调整方案写得很清楚：交易团队负责下单、支付回调与订单状态机，履约团队负责发货、退款与售后。纸面上没有重叠。

三个月后的一次线上事故，把纸面和现实的差距暴露出来。订单状态机里有一个表示“是否已锁定库存”的字段，两个团队在同一周分别提交了含义不同的修改：交易团队把它当成“下单时预占成功”，履约团队把它当成“发货前最终扣减成功”。两边都改了写入逻辑，也都没改对方负责的读取路径。

值班同学在群里问了一句“订单服务谁负责”，两个团队都举手，也都拿出了自己维护的 owner 清单。交易团队的清单里有 order-core，履约团队的清单里也有 order-core。事故本身两个小时就恢复了，但定位责任人花了半天，因为系统层面根本没有唯一答案。

这不是沟通问题，而是边界没有被表达成可检查的数据。团队边界写在组织架构图里，系统边界写在文档里，两者之间没有一张机器能读的表。只要这张表不存在，“谁负责”就只能靠开会确认，而开会确认的结果不会自动同步到下一次变更。

很多团队遇到这种情况的第一反应是拉一个共享表格，让每个团队填自己负责的系统。表格建起来的第一个月很热闹，第三个月开始出现三种情况：新系统没人补登，团队改名后旧名字还留在表里，同一个系统被两个团队各填了一行。共享表格解决了“有没有记录”，没有解决“记录是否一致、是否会被检查”。

团队边界与系统边界为什么会对不上

康威定律经常被引用成“系统结构会复制组织沟通结构”，但它更实用的推论是：如果一个系统没有唯一的负责团队，它的变更就会复制所有相关团队的沟通成本。系统边界不是画在架构图上的框，而是“谁有权改、谁必须被告知、出事找谁”这三件事的交集。

现实中，团队与系统的对应关系会出现五类偏差：

前两类可以直接从结构化数据里算出来，后三类需要先做系统清单归一化：统一命名、合并别名、注册新系统。很多团队一上来就想做全量服务目录，结果目录本身成了新的技术债；更务实的顺序是先把“多 owner”和“空团队”这两个最伤人的信号检测出来，再逐步补齐元数据。

系统清单应该长什么样

一份能用于检测的清单不需要很复杂，但至少要满足三个条件：系统名是唯一的稳定标识，owner 是团队而不是个人，团队与系统的关系是显式的多对多。个人会离职、转岗、换项目，把 owner 写成个人，半年后清单就会变成一张离职通讯录。团队相对稳定，也天然对应值班和审批权限。

团队与系统的关系建议分成两个字段：owns 表示负责，contributes 表示参与。检测函数只读 owns，参与关系留给协作看板。这样既保留了跨团队协作的事实，又不会让唯一责任人被稀释。如果组织暂时分不清两者，宁可先只填 owns，也不要为了“完整”把参与团队混进去。

清单还应该带一个 updated_at 和变更原因。边界调整往往发生在组织变动、系统拆分或重大事故之后，留下变更记录，下一次检测报出异常时才能判断是数据过期还是真的冲突。没有时间戳的清单，只能回答“现在是什么”，无法回答“为什么变成这样”。

还要区分“负责”和“参与”。一个系统可以有多个参与团队，但只能有一个负责团队。负责团队拥有变更审批权和最终解释权；参与团队可以提需求、写代码、值班，但不能在冲突时各改各的。把参与关系也塞进 owner 字段，等于把唯一责任人重新变成复数。

边界不是一成不变的

组织会调整，系统会合并拆分，边界检测不能只做一次。比较稳的做法是把团队与系统清单放进版本库，作为配置随代码评审；每次组织调整、系统拆分或新系统上线，都先改这份清单，再改代码。清单进入版本库之后，冲突检测就可以放到 CI 里，而不是等到事故复盘时才想起来。

一次重复建设引发的事故

2026 年第二季度，「回声」的交易团队和履约团队各自接到了一个“订单导出”需求。交易团队要导出用于对账，履约团队要导出用于仓配。两个团队都不知道对方在做，因为需求分别来自不同的业务方，系统清单里也没有“订单导出”这个条目。

交易团队先上线了一个导出任务，直接读订单主库，按 created_at 增量拉取，写入一张 order_export 表。两周后履约团队上线了另一个导出任务，也写同一张表，但按 updated_at 增量拉取，并且为了“清理脏数据”先执行了一次 DELETE。两个任务的时间窗口重叠，交易团队的增量数据被履约团队反复删掉又补回，最终对账文件里出现了两天的缺口。

财务在对账时发现了差异，追查了两天才定位到两个导出任务。复盘时有几个事实很刺眼：

• 两个任务在监控里各自都是绿的，因为它们只检查自己的写入量，不检查表里的数据是否被别人删过。
• 系统清单里没有“订单导出”，所以冲突检测不可能发现它。
• 两个团队都认为自己只是“临时脚本”，没有走架构评审。
• 表没有明确的 owner，建表语句是交易团队写的，但谁都可以读写。

修复方案不是再写一个更复杂的导出服务，而是先给这张表登记 owner，再把两个任务合并成一个带水位线的导出作业。事故的直接成本是两天的对账返工，间接成本是财务对数据平台的信任下降，之后每个导出需求都要额外走一轮人工确认。

这个事故说明：边界冲突最危险的地方不是“两个团队吵架”，而是两个团队都以为对方知道，于是谁都没有停下来确认。检测函数的价值，是把这种“以为”变成一份必须处理的清单。

值得注意的是，两个导出任务单独看都不算糟糕的工程：增量拉取、写入独立表、有监控。问题出在它们共享了一张没有 owner 的表，而共享资源的变更没有被任何一方视为自己的责任。边界检测如果能早一步发现“订单导出”没有登记 owner，这条需求就会在评审阶段被合并，而不是在上线后靠对账发现。

用检测函数把归属冲突变成清单

配套代码 internal/org/boundary.go 只做一件事：输入团队清单和系统清单，输出所有可检测的归属冲突。它不查数据库、不读配置文件、不调用服务目录，因为这些都会让“同一份输入是否得到同一份输出”变得难以验证。

// file: internal/org/boundary.go
// tier: L1
// verify: go test ./internal/org/

package org

import (
	"fmt"
	"sort"
	"strings"
)

// Team 是一个团队，Systems 是它声明负责的系统名。
type Team struct {
	Name    string
	Systems []string
}

// System 是一个系统及其声明的负责人。
type System struct {
	Name  string
	Owner string
}

// Conflicts 检测团队与系统之间的归属冲突：
//   - 同一个系统被多个不同 owner 声明；
//   - 一个团队没有声明任何系统。
//
// 返回值按字典序排序，保证同一输入每次得到同一份清单。
func Conflicts(teams []Team, systems []System) []string {
	owners := make(map[string]map[string]struct{}, len(systems))
	for _, s := range systems {
		if s.Name == "" {
			continue
		}
		if owners[s.Name] == nil {
			owners[s.Name] = make(map[string]struct{})
		}
		if s.Owner == "" {
			owners[s.Name]["<empty>"] = struct{}{}
			continue
		}
		owners[s.Name][s.Owner] = struct{}{}
	}

	var out []string
	for name, set := range owners {
		if len(set) <= 1 {
			continue
		}
		list := make([]string, 0, len(set))
		for o := range set {
			list = append(list, o)
		}
		sort.Strings(list)
		out = append(out, fmt.Sprintf("system %q has multiple owners: %s", name, strings.Join(list, ", ")))
	}
	for _, t := range teams {
		if len(t.Systems) == 0 {
			out = append(out, fmt.Sprintf("team %q owns no systems", t.Name))
		}
	}
	sort.Strings(out)
	return out
}

代码里有几个刻意的选择，都是为了让检测结果可以被信任、被 diff、被放进 CI，而不是只在复盘会上当一次性的证据。

Conflicts 先按系统名聚合 owner 集合，再判断集合大小。这样同一个系统被同一个团队重复声明不会误报，只有出现两个及以上不同 owner 才算冲突。聚合用的是 map[string]struct{}，去重是天然行为，不需要额外排序再比对。

空 owner 被记为 <empty>，而不是直接忽略。一个系统如果同时有真实 owner 和空 owner，说明清单本身有脏数据；把空值显式暴露出来，比悄悄丢掉一行更容易修。如果业务上确实允许“暂未指定 owner”，应该由调用方在传入前过滤，而不是让检测函数猜。

团队没有系统也会被列出。这一条经常被忽略，因为“没有系统的团队”看起来不像是冲突，更像是组织冗余。但在边界检测的语境里，它意味着这个团队的职责没有落到任何可运维的实体上，后续要么被临时拉去支援别的系统，要么在组织调整时最先失去存在依据。

返回值最后统一排序。map 的迭代顺序在 Go 里是随机的，如果不排序，同一份输入每次运行可能得到不同顺序的清单，CI 对比和人工 review 都会变得不稳定。排序的代价可以忽略，换来的是“这份清单可以逐行 diff”。

代码不检测“系统没有 owner”和“团队引用了不存在的系统”。前者需要一份完整的系统注册表，后者需要先定义什么叫“存在”；在没有元数据治理之前，强行检测会产生大量误报。把检测范围收敛在两个高置信信号上，比做一个什么都能报、但没人看的检查器更有用。

测试：冲突类型与确定性

测试的目标不是覆盖所有组织形态，而是锁住三类行为：多 owner 能被发现、空团队能被发现、干净输入不产生噪音。再加一条确定性检查，防止未来有人把排序删掉。

这四类用例对应四种常见的实现退化：只检查系统清单不检查组队清单、只检查团队不检查系统、把任何输入都报成冲突、依赖 map 迭代顺序。每一种退化都不会让编译失败，只会在真实清单上产生漏报或噪音，所以必须用测试固定住。

// file: internal/org/boundary_test.go
// tier: L1
// verify: go test ./internal/org/

package org

import (
	"reflect"
	"testing"
)

func TestConflictsMultipleOwners(t *testing.T) {
	got := Conflicts(nil, []System{
		{Name: "order", Owner: "team-a"},
		{Name: "order", Owner: "team-b"},
		{Name: "pay", Owner: "team-a"},
	})
	want := []string{`system "order" has multiple owners: team-a, team-b`}
	if !reflect.DeepEqual(got, want) {
		t.Fatalf("Conflicts = %v, want %v", got, want)
	}
}

func TestConflictsTeamWithoutSystem(t *testing.T) {
	got := Conflicts([]Team{
		{Name: "growth"},
		{Name: "order", Systems: []string{"order"}},
	}, []System{{Name: "order", Owner: "order"}})
	want := []string{`team "growth" owns no systems`}
	if !reflect.DeepEqual(got, want) {
		t.Fatalf("Conflicts = %v, want %v", got, want)
	}
}

func TestConflictsClean(t *testing.T) {
	teams := []Team{{Name: "order", Systems: []string{"order", "pay"}}}
	systems := []System{
		{Name: "order", Owner: "order"},
		{Name: "pay", Owner: "order"},
	}
	if got := Conflicts(teams, systems); len(got) != 0 {
		t.Fatalf("Conflicts = %v, want none", got)
	}
}

func TestConflictsDeterministic(t *testing.T) {
	teams := []Team{{Name: "b"}, {Name: "a"}}
	systems := []System{
		{Name: "z", Owner: "x"},
		{Name: "z", Owner: "y"},
	}
	first := Conflicts(teams, systems)
	for i := 0; i < 20; i++ {
		if got := Conflicts(teams, systems); !reflect.DeepEqual(got, first) {
			t.Fatalf("round %d: %v != %v", i, got, first)
		}
	}
}

TestConflictsMultipleOwners 同时放了 order 的两个 owner 和一个正常的 pay，断言输出里只有 order 一条。这样即使实现把“出现过的系统”都当成冲突，测试也会失败。

TestConflictsTeamWithoutSystem 里有一个有系统的团队和一个空团队，期望只报空团队。注意空团队的名字是 growth，它和系统清单没有任何关系，检测函数不需要团队名出现在系统清单里也能判断。

TestConflictsClean 是反向用例：一个团队负责两个系统，系统 owner 与团队名一致，期望零冲突。没有这条用例，实现很容易变成“只要输入非空就报点什么”。

TestConflictsDeterministic 构造了两个空团队和一个双 owner 系统，连续调用二十次并比较结果。二十次不能证明跨进程稳定，但能抓住“每次调用顺序都变”的实现错误。真正跨版本的稳定性要靠清单进入版本库和 CI 对比来保证。

测试没有覆盖中文系统名、超长团队名和 nil 输入。nil 输入在实现里会自然返回空团队循环的结果，不需要特殊处理；中文和超长名称属于字符串处理，不改变冲突判定逻辑。把这些留到集成测试或真实清单的试运行里，比在单元测试里堆边界值更有意义。

运行命令与真实输出

在仓库根目录执行：

cd .local/checks/webapp-lab && go test ./internal/org/ -run 'TestConflicts' -count=1 -v

一次本机运行的真实输出如下，耗时随机器变化：

=== RUN   TestConflictsMultipleOwners
--- PASS: TestConflictsMultipleOwners (0.00s)
=== RUN   TestConflictsTeamWithoutSystem
--- PASS: TestConflictsTeamWithoutSystem (0.00s)
=== RUN   TestConflictsClean
--- PASS: TestConflictsClean (0.00s)
=== RUN   TestConflictsDeterministic
--- PASS: TestConflictsDeterministic (0.00s)
PASS
ok  	webapp/internal/org	0.180s

四个用例全部通过，退出码为 0。-run 'TestConflicts' 只筛选了归属检测相关用例，同包的决策与技术债测试没有被执行；需要全量确认时去掉 -run 再跑一次。

小结

团队边界与系统边界对不上，通常不是谁不负责，而是“负责”这件事没有唯一、可检查的表达。一个系统只能有一个 owner，一个团队至少应该有一个系统；这两条规则不复杂，难的是把它们变成每次变更都会执行的检查。

检测函数不能代替组织设计，但它能把“两个团队都以为自己负责”变成一份必须被处理的清单。清单进入版本库、进入 CI 之后，边界调整就会从事故复盘的一部分，变成变更流程的一部分。

判断一个团队是否真的拥有边界，有一个简单的检验：能不能在不问任何人的情况下，从仓库里查出这个团队负责哪些系统、这些系统最近由谁改过、出事时找谁。三个问题都能答上来，边界才算落地；有一个答不上来，就仍然停留在组织架构图的层面。

下一节讨论决策权：边界划清之后，边界内的决策应该由谁拍板、什么时候必须上评审。

阅读导航：上一节：目录与学习路径 · 下一节：12.2 决策权与评审 。

常见错误与边界

• 把“参与团队”写进 owner 字段。参与可以有多个，负责只能有一个；混在一起会让冲突检测永远报错，最后没人再看。
• 只维护组织架构图，不维护系统清单。团队调整之后系统归属没有跟着改，检测函数读到的还是半年前的快照。
• 系统名不归一就做检测。order、Order、order-core 在数据里是三个系统，多 owner 会被拆散成三条单 owner 记录。
• 检测出冲突后只在群里通知，不进入变更流程。没有负责人和截止时间的清单，会在下一次迭代被遗忘。
• 把空 owner 当成合法值静默跳过。脏数据不会自己消失，隐式容忍只会让真正的问题更晚暴露。
• 用随机顺序输出冲突。map 迭代顺序不稳定，清单无法 diff，CI 也无法做基线对比。
• 期望检测函数覆盖所有边界问题。没有系统注册表之前，先锁住多 owner 和空团队两个高置信信号，比追求全量更可持续。
• 团队没有系统就立刻裁撤。空边界也可能是新团队尚未接手，先确认是过渡态还是长期状态，再决定组织动作。