什么是架构治理
架构治理是一组让架构决策真正落地的机制：评审门径、原则与标准、适应度函数、例外流程与度量。它的目标是一致性与可预期性，而不是审批本身。治理强度需要与团队自治程度匹配：流程过重会压垮交付节奏，完全缺位则各团队决策互不兼容，集成成本不断上升。
基本信息
| 治理手段 | 设计评审、原则与标准清单、适应度函数、例外流程 |
|---|---|
| 节奏安排 | 关键决策前置评审，日常变更走轻量流程 |
| 度量指标 | 偏离项数量、例外处理周期、返工比例、评审排队时长 |
| 适用范围 | 跨团队接口、公共契约、数据模型与安全基线 |
落地要点
- 明确治理范围：列出哪些决策必须评审、哪些在团队内自治
- 原则可检化：把原则写成能自动验证的条目，如接口兼容规则与依赖方向约束
- 自动化优先：能用适应度函数替代的人工评审尽量替换，减少排队
- 例外有期限：例外必须写场景、理由与退出计划，到期自动复核
- 按度量校准：用排队时长与返工比例判断治理是过重还是过松
- 允许自治空间：核心域强约束，边缘场景保留团队自主决策
治理强度与信号
| 信号 | 含义 | 调整方向 |
|---|---|---|
| 评审排队时间长 | 门径过窄或评审项过多 | 下放日常变更权限 |
| 返工比例上升 | 约束缺失或标准不清 | 补充可检原则与检查 |
| 例外堆积 | 标准与实际脱节 | 复核标准本身是否合理 |
| 耦合事故频发 | 缺少跨团队接口治理 | 建契约与兼容规则 |
一次评审的最小输入
一次评审的最小输入
# 评审材料（示意，控制在一页内）
1) 决策内容：要引入什么、替代了什么
2) 受影响的架构特征：性能、可用性、安全、成本各有什么变化
3) 备选方案与不选择的原因
4) 验证方式：用什么检查或实验证明结论
5) 例外与退出：哪些是临时妥协，何时回收
6) 影响范围：涉及哪些团队与系统，谁需要知情治理要能回答「这个环节防止了哪类问题」：答不上来的环节就是纯开销，应当简化或取消。
治理指标不能用来考核个人：一旦与绩效挂钩，数据会被美化，偏离项与例外都会被隐藏。