架构治理：把目标架构变成交付与运行中的反馈机制

统一会员中心已经被列入目标架构。某次大促前，营销团队发现会员中心缺少一个临时等级字段，于是直接在营销系统中复制会员等级和权益规则。活动顺利结束后，两个系统的等级开始漂移，客服无法解释客户为什么在不同渠道得到不同优惠。

架构治理要处理的不是“谁来盖章”，而是当短期交付压力、局部优化和外部变化出现时，组织如何作出可追踪的取舍，并让偏差有补偿、有到期日、有退出证据。

治理的对象是决策和证据

治理范围应覆盖四类对象：

对象	治理问题	可见证据
原则与标准	哪些约束必须统一，哪些允许局部裁剪	标准目录、适用范围、版本和采用记录
架构决策	为什么选择这个边界、协议或路线	ADR、候选方案、取舍和复审条件
实施一致性	项目是否仍然符合目标与过渡架构	契约测试、数据写入来源、发布检查
架构变化	新需求和运行结果是否改变原有假设	变更请求、指标、例外、债务和路线调整

如果治理只登记项目评审意见，无法判断目标架构是否在代码、数据、权限和运行环境中仍然成立。

决策权不等于审批层级

架构委员会（ARB）不是所有技术问题的审批入口。合理的治理要让决策尽量靠近事实，同时保留跨域影响的升级路径。

角色	负责什么	不应该负责什么
架构委员会	组织级原则、重大取舍、跨域冲突和例外授权	逐个审批普通接口和实现细节
企业架构师	目标、过渡架构、能力依赖和投资建议	替项目团队写所有方案
领域架构师	业务、数据、应用或技术域内的一致性	独立决定跨域业务结果
解决方案架构师	项目方案、质量属性、迁移和落地证据	修改企业原则而不升级
Capability/Data Owner	业务结果、事实语义和数据授权	只对本部门系统负责
交付与运维团队	实现、测试、发布、值班和反馈	隐瞒偏差或绕过审计

治理的目标是明确谁有权做哪类决定，而不是把所有人都拉进同一场会议。

架构评审要围绕风险点

评审不应从“请介绍一下系统架构”开始。可以按风险问题组织：

方案阶段

• 这个方案解决哪个业务结果，成功指标是什么。
• 哪些能力、数据和应用责任会发生变化。
• 是否复制了已有事实或绕过权威写入方。
• 关键质量属性和故障语义是什么。
• 迁移范围、过渡状态和回退路径是否明确。

开发阶段

• API 和事件是否与责任边界一致。
• Schema 是否可以兼容演进，消费者是否有契约测试。
• 数据库写入来源是否只有声明的权威方。
• 权限、审计、敏感字段和密钥是否进入实现。

发布阶段

• 压测、恢复、故障注入和数据对账是否通过。
• 灰度和回退是否会产生重复写入或状态冲突。
• 运行指标能否证明业务状态而不仅是资源健康。
• 旧入口、旧任务和旧权限是否有清退计划。

评审结论要记录“通过、带条件通过、拒绝、转为例外”及其证据，不要只记录一个模糊的“原则上同意”。

例外管理保护长期方向

业务有时确实需要暂时偏离目标架构。例外不是违规名单，而是一种带条件的风险决策。

一次合格的例外记录至少包含：

id: EXC-MEMBER-20260718-01
request: 大促前在营销系统临时读取会员等级快照
reason: 会员中心暂不支持该活动所需的批量查询
violated_principle: 会员等级只有会员中心定义和修改
scope: 活动 A、渠道 B、有效期 14 天
compensation:
  - 快照只读，不允许回写会员中心
  - 每日与会员中心对账
  - 权益计算记录来源版本和活动编号
owner: 营销平台负责人
expiry: 2026-08-01
exit_criteria:
  - 活动结束并完成历史对账
  - 营销系统删除临时字段和任务
  - 会员中心提供正式查询能力

没有范围、补偿、负责人和退出条件的临时方案，会自然变成新的长期事实来源。

把治理嵌入流水线

治理不应依赖架构师手工记忆。可以把高风险原则转成自动化检查：

原则	可以自动检查什么
一个事实一个权威写入方	数据库权限、写入来源、Schema Owner 和调用链
事件契约兼容演进	Schema 兼容、必填字段、版本和消费者测试
敏感数据最小权限	服务账号权限、字段访问、导出审批和审计
迁移必须可回退	Feature Flag、流量开关、回退脚本和数据对账
关键能力可观测	业务指标、关联 ID、告警和运行手册
旧责任按计划退出	旧入口流量、定时任务、权限和依赖清单

自动检查不能替代判断，但可以把反复出现的判断固化为护栏，把架构师时间留给真正的取舍。

运行治理需要看偏差而非只看合规率

项目按时上线，不代表架构目标达成。治理看板至少需要覆盖：

• 架构原则的实际采用率和带条件采用率。
• 例外数量、影响范围、平均存续时间和逾期数量。
• 关键数据质量、重复写入和无法解释的对账差异。
• 服务契约破坏、跨边界直接写库和高风险权限。
• 目标能力的业务结果，例如超卖率、接入周期、履约及时率。
• 遗留应用的流量、写入口、任务和下线进度。
• 架构债务的业务影响、偿还计划和新增速度。

“评审通过率 100%”可能说明大家学会了填写表单，并不能证明治理有效。真正有意义的是偏差是否快速暴露、是否有人承担、是否按期收敛，以及业务结果是否改善。

架构债务需要进入投资组合

架构债务不是“以后有空再优化”的技术待办。它应描述：

• 违反了哪项原则或目标。
• 对业务、数据、可靠性、成本或交付速度造成什么影响。
• 哪些项目依赖它，哪些风险会随规模增长。
• 偿还工作的最小可交付增量。
• 不处理的后果和最晚处理时间。

例如“营销系统复制会员等级”不是普通重构任务，它会造成权益冲突、客服成本和审计风险。债务记录应与会员中心正式能力建设、活动计划和例外退出关联，而不是孤立放在技术团队的 backlog 中。

变化管理连接 ADM 的 Phase H

架构治理不能假设目标架构永远正确。以下事件可以触发重新评估：

• 业务指标持续偏离，说明能力设计或优先级不合适。
• 运行约束改变，例如 WMS 接口时效下降或供应商停止支持。
• 新法规改变数据保存、访问或跨境要求。
• 并购、新渠道或组织变化引入新的责任边界。
• 过渡架构长期停留，旧系统没有按计划退出。

变更请求应说明触发证据、受影响的原则和工件、可选方案、路线影响，以及是否需要启动新的 ADM 迭代。治理因此成为反馈机制，而不是目标架构发布后的看守岗位。

用 ADR 记录可复用决策

一份合格的 ADR 可以保持轻量，但要让未来的团队理解上下文：

# ADR-042：库存预占由库存平台负责最终裁决

## 背景
商城、POS 和订单服务分别实现锁定逻辑，出现重复承诺和释放不一致。

## 决策
库存平台负责预占、释放和确认；订单管理保存结果并推进订单状态。

## 取舍
增加一次同步依赖和库存平台容量压力，但收敛事实责任，能够统一幂等、超时和对账。

## 迁移影响
先覆盖商城，再按区域迁移门店；未迁移范围继续由旧系统负责，范围内禁止双写。

## 复审条件
连续四周预占成功率低于目标，或库存平台无法满足峰值容量模型。

ADR 不是会议纪要，也不是最终实现文档。它保留决策、取舍、迁移影响和复审条件，使新团队能够判断当初的约束是否仍然成立。

治理的最小交付物

• 原则、标准、适用范围和版本。
• 决策权矩阵与升级路径。
• 方案、开发、发布和运行阶段的证据清单。
• 例外、补偿、负责人、到期日和退出条件。
• 架构债务及其业务影响和投资计划。
• 业务、数据、服务、运行和遗留退出指标。
• 变更触发器与 Phase H 反馈流程。

常见失效方式

• 架构委员会审查所有小事，真正的跨域风险反而没有足够时间。
• 只审设计图，不看数据库写入、权限、迁移和运行证据。
• 例外只有批准，没有范围、补偿和过期时间。
• 看板只显示评审数量和通过率，不显示偏差和业务结果。
• 架构债务由技术团队独自承担，业务收益和风险没有进入投资决策。
• 目标架构多年不更新，运行证据无法反馈到架构模型。

能力验证

• 能按决策风险设计分层治理，而不是把所有问题送进同一个委员会。
• 能把原则转成契约测试、权限检查、迁移和运行证据。
• 能写出有范围、补偿、负责人和到期日的例外记录。
• 能用业务结果和偏差指标判断治理是否有效。
• 能把架构债务连接到投资组合和业务风险。
• 能依据运行证据触发新的架构迭代。

总结

架构治理的核心是让组织在压力下仍能做出可解释、可追踪、可退出的架构决策。治理不是增加审批，而是把原则嵌入交付，把偏差暴露在运行指标中，把例外限定在时间和范围内，再把真实反馈带回下一轮架构工作。这样目标架构才不会停在图上。