升级路径
定决策何时须超团队升级——以避卡决策和 rogue 决策。
为什么
有些决策比团队大——影响他团队、公司成本、或不可逆。无升级路径这些决策要么卡（团队不能决）要么独断（团队决伤公司的）。升级路径定触发（跨团队影响、成本 > 1 万/月、不可逆）和路线（技术负责人→架构师→CTO）使大决策获对眼。艺术是升够（非每 500 决策）但不过（每决策去 CTO 造瓶颈）。
何时使用
每组织定义一次。1 小时。提议时应用于每决策。
如何做
1. 定升级触发： - 跨团队影响（改他团队用 API）→ 架构师评审 - 成本影响 > 1 万/月 → 财务+架构师评审 - 不可逆（DB、云供方）→ 主+CTO 签 - 影响跨团队值班 → SRE 评审 2. 定路线：团队技术负责人 → 架构师 → 主/CTO 3. 每 ADR 提议时查触发；任一发则升 4. 升级为评审非许可——团队仍写 ADR 5. 升级评审设 SLA（3 天）使决策不在下级卡 6. 把升级记 ADR（谁审、何时）以可审计
示例
ADR-023："所有存储从 S3 换 GCS" 触发发： - 成本影响：-8 千/月（省）但 > 1 万阈值 → 财务评审 - 跨团队：4 团队用存储抽象 → 架构师评审 - 不可逆：否（S3 API 兼容、可换回）→ 无 CTO 签 升级： 第 1 天：团队写 ADR-023 第 2 天：架构师评审跨团队影响（带迁移计划批） 第 3 天：财评成本影响（批） 第 4 天：ADR-023 已接受、升级记录 无升级：团队换、破 4 团队集成、事故。
常见问题
- ⚠升一切——架构师成瓶颈且决策卡；仅定触发升。
最佳实践
- ✓让升级为评审非批准——团队拥有决策；升级者查盲点、不替其判断。
- ✓年度评审升级触发——团队成熟时更多决策可留团队；公司长时更多须升。