1.5 决策制定与治理

概述与动机

每一个软件系统都是成千上万个决策的总和：选哪个数据库、选哪种架构、选哪个库、是自建还是购买、何时承担技术债务、何时偿还。治理就是你如何把这些决策做得好、做得一致，让合适的人参与其中而不制造瓶颈，并把推理过程保存下来，使未来的团队不至于被迫重新摸索一遍。在一个小团队里，决策发生在对话中，存在于共享的记忆里。到了一定规模，这份记忆就会蒸发。人员离职、团队重组，一次关键选择背后的”为什么”随之丢失，继任者要么盲目照搬，要么盲目推倒重来。好的治理，正是让决策变得可见、经过深思熟虑、并能在一个庞大且不断变化的组织中持久存续的那套机制。

对大型团队而言，核心挑战是在自主权与一致性之间取得平衡。把所有决策都上交给一个中央委员会，你会得到一致性，但代价是让人瘫痪的瓶颈和被剥夺权力的团队。把所有决策都下放，你会得到速度，但代价是混乱：不兼容的技术、重复的努力，以及反复犯下同样的错误。成熟的答案既不是中心化，也不是无政府状态，而是一种分层模型。团队在一条清晰标注的”标准化通路”之内自行决定大多数事情，而一套轻量、透明的流程则治理那些真正跨领域、且难以逆转的选择。目标是让做出好决策成为轻松的默认选项，并把稀缺的治理注意力，只花在真正重要的地方。

企业和政府承担着更高的风险。它们必须满足要求文档记录、有理有据的决策的审计人员、监管机构和监督机构。它们的运作跨越很长的时间跨度，一次糟糕的架构选择或一堆失控的技术债务可能拖累它们长达十年。而采购和合规义务，让自建还是购买的决策格外举足轻重、也格外难以逆转。对这些组织而言，有纪律、被妥善记录的决策制定，不是为了官僚主义而官僚主义，而是风险管理、机构记忆，以及问责制的基石。

关键原则

记录决策及其推理过程；一个没有理由说明的决策就是一项负债。
把决策下放到拥有相应背景信息的最低层级，同时设定清晰的护栏。
让流程的分量与决策的分量及其可逆性相匹配。
区分可逆的（“双向门”）决策与不可逆的（“单向门”）决策，并以不同方式治理它们。
优先选用标准化通路和默认选项，而不是逐案审批。
把技术债务当作一个被管理的投资组合来对待，而不是一件需要遮掩的道德过失。
让治理保持透明；隐蔽的决策制定会滋生不信任和返工。

建议

采用架构决策记录，并配一套恰如其分的 RFC 流程

架构决策记录（Architecture Decision Record，ADR）是一份简短、不可更改的文档，用来记录一项重大决策：它的背景、考虑过的选项、最终的选择，以及后果。把 ADR 与代码一起存放在版本控制中，这样推理过程就会与系统一同流转。对于需要在做出决策之前征求意见的情形，使用一套轻量级的 RFC（request for comments，征求意见稿）流程：分发一份提案，在限定的时间内邀请评论，然后做出决策并记录下来。让这两者都保持轻量。价值在于思考过程和持久的记录本身，而不在于精致的模板。ADR 和 RFC 合在一起，把心照不宣、终将被遗忘的推理，变成了一份可检索的机构记忆。

通过标准化通路来治理，而不是靠看门人

与其逐一评审每一个决策，不如投资于一条”标准化通路”：一套被认可、得到充分支持的默认选项（）获批的编程语言、框架、部署流水线和模式（）让团队能几乎不费力气地采用，并获得充分的支持。留在标准化通路上的团队几乎不需要治理，因为安全合规的选择同时也是轻松的选择。有正当理由要偏离它的团队也可以偏离，但要承担额外的责任，并接受一次轻量级的评审。这种”黄金路径”模式的扩展能力，远胜于一个要批准一切的中央委员会，因为它把治理从逐案把关，转变为精心设计的默认选项。

谨慎而透明地使用架构评审委员会

架构评审委员会，或与之等价的机构，对于那些规模最大、最跨领域，或最不可逆的决策，以及对于制定那些定义标准化通路的标准，有其正当的角色。要让它的范围保持狭窄、标准公开，流程快速、以咨询为主，而不是让常规工作也必须排队等候的强制瓶颈。委员会的职责是守护一致性、共享知识，而不是批准每一个选择。当一个委员会变成每个项目都必须排队等待的队列时，它就已经失败了。要大胆下放权力，把中央评审留给那少数真正需要它的决策。

把自建、购买还是采用当作一次审慎的分析来对待

对任何重要的能力，都要权衡三条路径：自己在内部构建、购买一款商业产品，或者采用一个开源方案。当这项能力是真正的差异化因素、是你使命的核心时，选择自建。购买或采用那些别人做得更好、且不构成差异化的能力。要计算总拥有成本（total cost of ownership，TCO），而不只是前期价格。购买会产生授权许可、集成和供应商锁定的成本。自建会产生永无止境的维护和人员配置成本。采用开源会产生支持和安全跟踪方面的义务。把这个决策及其假设条件记录成一份 ADR，以便在情况发生变化时能够重新审视它。

把技术债务当作一个投资组合来管理

技术债务本身并非天生就是坏事。有时候，为了更早交付而承担债务，是正确的选择。真正糟糕的是那种失控、看不见、被遗忘的债务。要保留一份明确的重大债务清单。对每一项债务，记录它带来的成本（持续产生的”利息”）以及修复它的成本。然后像管理一个金融投资组合那样管理它。偿还那些每天都在拖慢团队的高息债务。容忍那些存在于稳定角落里的低息债务。要有意识地做出债务相关的决策，而不是稀里糊涂地陷入其中。预留一部分固定产能用于偿还债务，这样它就永远不会累积成一场危机。

区分可逆决策与不可逆决策

并非所有决策都值得同等程度的深思熟虑。可逆的”双向门”决策很容易被撤销，所以要让它们做得又快又本地化，由团队自行决定，并倾向于行动而非纠结。在这类决策上反复纠结，只会浪费时间、拖慢学习速度。不可逆或撤销成本高昂的”单向门”决策（）一份公开的 API 契约、一个大规模的数据模型、一份多年期的供应商承诺（）则值得慢下来、审慎地、由资深人员深思熟虑，并留下书面理由。以这种方式对决策进行分类，是你所拥有的杠杆最高的治理习惯之一。它把稀缺的审视力，瞄准了真正值得的地方，并为其他一切放行。

权衡：利与弊

治理方式	优点	缺点
一切都由中央评审委员会评审	一致性和监督力最强	严重的瓶颈；剥夺团队权力；缓慢
标准化通路配合局部自主权	可扩展、快速、安全的默认选项，赋能团队	需要前期的平台投资；部分团队会偏离通路
团队完全自主，没有治理	快速、归属感强	碎片化、重复劳动、反复犯错
ADR／RFC	持久的记忆、更好的决策、透明度	有书写方面的开销；若不维护则会被忽视

采购来源选择	优点	缺点
自建	完全掌控、完全贴合需求、能形成差异化	永无止境的维护和人员配置成本
购买	快速、有支持、由别人负责维护	授权许可成本、锁定、贴合度不完美
采用（开源）	没有许可费、可检视、有社区	支持和安全方面的负担落在自己身上

统一的权衡在于掌控与速度之间，以及中央一致性与局部自主权之间。每一个治理选择都落在这个光谱之上。这里推荐的姿态（）标准化通路加上基于可逆性的授权（）刻意地买下了自主权带来的大部分速度，同时保留了真正重要的那份一致性。它的做法是让对齐的选择成为轻松的选择，把重量级的流程留给那少数真正不可逆的决策。

需要与团队讨论的问题

谁来判断某个决策是不是”单向门”，你们如何在两个方向上都能发现误判？ 按可逆性对决策分类，是杠杆最高的治理习惯之一，一旦贴错标签，它的价值就会崩塌：把一个可逆的选择当成不可逆的，你会让它淹没在无谓的深思熟虑里；把一个不可逆的选择当成可逆的，你会交付一个无法轻易撤销的数据模型或公开 API 契约。这里相互竞争的风险是：离工作最近的人可能偏向速度，而一个中央委员会可能偏向谨慎。带上具体的例子来讨论：撤销每一项决策，实际上要花多少时间和金钱，由谁来承担这份代价。在企业和政府场景中，采购承诺和大规模数据会把许多本来看似可逆的选择，变成事实上的单向门。就”谁来分类”达成一致，并养成对任何接近边界的决策快速寻求第二意见的习惯，让稀缺的审视力落在那些撤销成本真正高昂的地方。
谁拥有、资助并配备人手来维护这条标准化通路，又是什么阻止它退化成一个看门人？ 标准化通路只有在被认可的默认选项真正得到充分支持、且比其他替代方案更容易采用时才有效，而这需要持续的投资，而这类投资很容易被低估。这里的权衡很尖锐：一条资源不足的标准化通路，会变成一堆没有支持的强制命令（）这正是这套模型原本要取代的那种把关行为（）于是团队就会绕开它另寻出路。带上关于这条通路健康状况的证据：采用率、获批工具的更新程度、平台团队响应的速度，以及团队申请偏离通路的频率。对于大型和受监管的组织而言，标准化通路也是让合规选择变成轻松选择的方式，所以对它的投资是一项合规投资，而不仅仅是图个方便。要确定一位明确的负责人和一份固定预算，并衡量团队选择这条通路，是不是因为它确实是最轻松的路径。
团队在哪些地方绕开了你们的治理，这种影子 IT 在告诉你什么？ 当认可的路径比绕道而行更痛苦时，团队就会规避它，因此广泛存在的影子 IT，与其说是一个纪律问题，不如说是对你们治理体系的一份设计判决。这里相互竞争的考量是真实存在的：有些规避是鲁莽的，而更多的规避，则是对一个已经变成要排队数周的评审委员会的理性回避。带上证据：哪些审批环节被跳过了、哪些非官方工具已经悄悄蔓延开来，以及官方路径实际要花多长时间。在企业和政府场景中，利害关系更高，因为未经批准的工具可能违反具有法律分量的审计、安全和采购义务。如果这种模式表明人们是在绕开一个瓶颈，那么解决办法是加快并拓宽这条标准化通路，把委员会的范围收缩到少数真正跨领域、不可逆的决策上，而不是再加一层审批。
我们的交付产能中，有多少真正用在了偿还技术债务上，我们能否说出应该优先偿还的那几项高息债务？ 技术债务的行为方式就像复利，是对未来每一次变更的隐性征税，而一个大型组织可能在无人察觉的情况下背负它多年，直到系统变得又慢又脆、难以修改。这里相互竞争的压力很直白：每一小时花在偿还债务上的时间，就是一小时没有花在领导层能看见的功能上，所以当截止日期收紧时，偿债往往是第一个被砍掉的东西。带上真实的证据来讨论：一份成文的重大债务清单、对每一项债务持续产生的成本和修复成本的诚实估算，以及最近的产能中，实际有多大比例用于偿债、而不是新工作。对于以十年为时间尺度运作的企业和政府机构而言，失控的债务最终会迫使一次代价高昂的重写，或酿成一次审计问题，因此要把固定的偿债预算当作风险管理来对待，并决定当进度收紧时由谁来守住这份预算。
当我们需要两年前某个决策背后的推理时，我们真的能找到它吗，有没有人在持续维护这份记录？ 架构决策记录的全部价值在于，推理过程比做出决策的人存续得更久，而如果 ADR 只写一次、从不被检索、又悄悄过时，这份价值就会崩塌。这里的张力在于，在决策那一刻捕捉背景、选项和后果所需要的书写纪律，与每天赶着交付、继续前进的压力之间。带上具体的检验方法来讨论：挑三个最近做出的重要决策，看看是否有人能在几分钟内找到记录在案的理由，并检查那些已被取代的 ADR 是否被相应标注，而不是悄悄地与当前实践相矛盾。在企业和政府场景中，这份可检索的记录，正是审计人员和监督机构所要求的、站得住脚的证据，所以要确定 ADR 存放在哪里、由谁评审，以及一个决策要重要到什么程度才值得被记录。
我们上一次依据最初的假设条件，重新审视一项重大的自建还是购买决策，是什么时候，那些假设条件过期时我们会注意到吗？ 采购来源的选择，是你所做的最昂贵、也最难以逆转的决策之一，而其背后的假设条件（一家供应商的定价、你自己的人员配置、某个开源选项的成熟度）会在决策被冻结在原地的同时悄悄过时。这里相互竞争的考量，是切换带来的沉没成本和干扰，与锁定、不完美的贴合度，或一份你已不想再背负的维护负担所带来的不断累积的成本之间的权衡。带上最初的那份 ADR 及其陈述的假设条件、针对每条路径的、涵盖授权许可、集成、人员配置和退出成本在内的当前总拥有成本估算，以及任何表明某个前提已经发生变化的信号，比如一次价格调整或一次支持降级。对政府和受监管的采购方而言，采购规则和多年期合同让这些单向门格外具有约束力，所以要提前就触发条件和节奏达成一致，以此强制进行一次审慎的重新决策，而不是盲目续约。

行业视角

初创公司。 几乎不做任何治理，坚定地依靠速度：对于可逆的双向门选择，在座位上就做出决定，然后继续前进。把你唯一的治理习惯，留给那少数几个单向门（）一个核心数据模型或一个基础供应商（）把每一个都用一段话记录下来，这样未来的队友就不必从零开始重新辩论一遍。完全跳过评审委员会和标准化通路，因为在你们这个规模下，它们是你们负担不起的开销，而且整个团队本来就共享着背景信息。

小型企业。 由于没有专职架构师，把自建还是购买当作你们核心的治理问题，并依据总拥有成本、而不是个人偏好来回答它。对任何非核心差异化因素的东西，默认购买或采用有良好支持的工具，因为永无止境的维护是你们最负担不起的成本。保留一份轻量级的决策日志，这样即便关键人员离职，你们那几个重大选择背后的推理也能存续下来。

企业。 你们的问题是在众多团队之间平衡自主权与一致性，因此要投资于一条有资金支持的标准化通路，并把一个范围狭窄、行动迅速的架构评审委员会，留给那些真正跨领域、不可逆的决策。把 ADR 标准化，让推理变成可检索的机构记忆，并把技术债务和采购来源选择，当作带有固定预算的投资组合来管理。要衡量团队选择这条通路，是不是因为它最轻松，并收缩任何已经退化成排队队列的委员会。

政府。 在这里，有文档记录、有理有据的决策不是可选项：审计人员和监督机构期望看到每一个重大选择背后的推理过程、被权衡过的选项，以及所依据的假设条件。把自建还是购买的分析，做成一份有记录的总拥有成本分析，遵守限制排他性锁定的采购规则，并把 ADR 作为审计就绪的证据链保留下来。要认真对待长时间跨度，因为今天做出的一个数据模型或供应商承诺，可能会束缚这个组织长达十年，所以要把它归类为单向门，并相应地深思熟虑。

示例

初创公司。 一家四人规模的初创公司，大多数决策都是在共享的办公桌旁几分钟内做出的，对于可逆的双向门选择而言，这份速度是一项真正的优势，因此他们抵制任何治理开销。但当他们选择一个日后很难更改的数据库和数据模型（一个单向门）时，他们会停下来，写一段简短的笔记：选项、最终选择，以及背后的假设条件。一年后，当他们触及扩展性的瓶颈时，正是这一份笔记，让他们免于从零开始重新辩论这个问题。他们几乎不做任何治理，只把唯一的轻量级习惯，留给那少数几个真正撤销成本高昂的决策。

企业。 一家大型企业的平台团队，曾被一个必须批准每一项技术选择的架构评审委员会拖得动弹不得，排队数周之久。这家企业围绕一条标准化通路重新构建了治理体系：一份经过筛选、获批、有全面支持的编程语言、数据存储和流水线目录，团队可以立即采用。任何偏离通路的决策都会以 ADR 的形式被记录下来，一次快速、以咨询为主的评审只处理偏离通路的选择。委员会的范围收缩到制定标准和那少数真正跨领域的决策上。交付速度大幅提升。一致性反而得到了改善，因为轻松的路径现在正是合规的路径。而 ADR 档案库，给这个组织留下了一份可检索的记录，说明了事物为何是现在这个样子被构建的。

政府。 一个政府部门，在严格的采购和审计规则下，面临一项针对案例管理平台的重大自建还是购买决策。它没有凭喜好做决定，而是针对三个选项（）自建定制方案、购买商业产品，以及采用一个开源底座（）进行了一次有文档记录的总拥有成本分析。它权衡了授权许可、集成、长期维护、人员配置和锁定，并把这个决策及其假设条件记录成一份 ADR。多年之后，当一家供应商的条款发生变化时，这个部门重新审视了那份 ADR，发现原始的假设条件已经不再成立，于是在充分了解此前推理过程的基础上重新做出了决定，避免了一次盲目而代价高昂的迁移。这份记录在案的理由，同时也正是审计人员所要求的、站得住脚的证据。

商业理由：动机、投资回报率与总拥有成本

决策，是软件领域杠杆最高、也最不显眼的成本。一次糟糕的、不可逆的架构或采购选择，可能带来长达数年的拖累，或一次九位数的补救开支。而把它治理好（）花几个小时深思熟虑，并留下一份书面记录（）相比之下几乎不花什么成本。ADR 和基于可逆性的授权所带来的回报，来自两个方面：避免在单向门决策上犯下代价高昂的错误，以及避免在其他一切事情上浪费深思熟虑的精力和返工。记录在案的理由，同样能大幅削减反复辩论已经解决的问题、以及团队逆向工程继承下来的系统背后意图所带来的持续性成本。

技术债务让总拥有成本这个论点变得具体可感。失控的债务的行为方式，与复利如出一辙：对未来每一次变更征收不断增长的税，直到这个系统实际上变得无法维护，并要求一次代价高昂的重写。把债务当作一个投资组合来管理，配上一份固定的产能分配用于偿还高息项目，远比最终爆发的危机便宜得多。好的治理采纳成本很低，主要是把决策写下来的这份纪律，以及对一条标准化通路的前期投资。跳过它则代价高昂：你会为本可避免的重写、锁定带来的意外、审计不通过，以及丢失的机构记忆买单。要说服领导层，就用他们的语言来阐述治理：降低风险、避免返工、通过标准化通路加快交付，以及审计就绪的可辩护性。要展示的目标不是更多的流程，而是瞄得更准的流程（）只在撤销成本高昂之处施以重度审视，在其他一切地方都畅行无阻。

反模式与陷阱

未被记录的决策：一旦做出决策的人离开，推理过程就随之丢失。
审批委员会瓶颈：一个每个项目都必须排队等候的中央机构。
一刀切的流程：强行让琐碎的可逆决策也走一遍重量级评审。
分析瘫痪：在容易逆转的双向门决策上反复纠结。
影子 IT：因为认可的路径太痛苦，团队干脆完全绕开治理。
看不见的技术债务：债务从未被清点、从未被偿还，悄悄地不断复利累积。
“全部自建”或”全部购买”的反射性习惯：凭习惯而非总拥有成本分析来决定采购来源。
治理表演：为了做样子而存在、却并不真正影响决策的文档和委员会。

成熟度模型

第 1 级（启动）：决策是临时的、未被记录的；治理要么缺失，要么是一刀切的瓶颈；技术债务看不见，选择背后的推理会在人员离开时蒸发。
第 2 级（发展）：一部分决策被记录下来，也存在一些评审，但这种做法在各团队之间参差不齐，流程也常常与决策的分量和可逆性不匹配。
第 3 级（标准化）：ADR、标准化通路、基于可逆性的授权，以及一份债务清单，都被记录下来并在全组织范围内强制执行，因此合规的选择就是轻松的默认选项，推理过程也可以被检索。
第 4 级（管理）：治理依据基线被度量：标准化通路的采用率、ADR 覆盖率、决策周期时间、债务占产能的比例，以及偏离通路的例外率都被追踪，而偿还债务或重新审视采购来源的决策，是由这些证据触发的，而不是由危机触发的。
第 5 级（编排）：治理被持续调优，并与交付和风险规划整合在一起；审视力被精准地瞄准不可逆的决策；债务和采购来源的选择，作为投资组合被主动地重新平衡，并随着情况的变化依据证据重新决策。

讨论思路

对于我们最近做出的最重要的决策，我们能找到记录在案的推理过程吗？
我们的治理在哪里成了瓶颈，又在哪里该有却没有？
我们当前的哪些决策属于单向门，我们是否把它们当作单向门来对待？
我们有多少产能用于偿还技术债务，这够吗？
我们的团队遵循标准化通路，是因为它确实是最轻松的路径，还是在绕开它？
我们上一次依据最初的假设条件重新审视一项重大的自建还是购买决策，是什么时候？

关键要点

用 ADR 记录重大决策及其理由；让推理过程持久存续。
通过标准化通路和默认选项来治理，而不是逐案把关。
让流程的分量与决策的分量及其可逆性相匹配；下放双向门决策的权力，对单向门决策审慎深思熟虑。
依据总拥有成本来分析自建、购买还是采用，并记录相应的假设条件。
把技术债务当作一个明确的投资组合来管理，配上一份固定的偿债预算。
保持治理透明且轻量；把稀缺的审视力，瞄准撤销成本高昂之处。

参考资料与延伸阅读

Michael Nygard，“Documenting Architecture Decisions”（ADR 模式的最初出处）
Gregor Hohpe，“The Software Architect Elevator” 与 “37 Things One Architect Knows”
亚马逊致股东信中关于第一类与第二类（单向门与双向门）决策的论述
Ward Cunningham，“技术债务”这一隐喻的最初提出者
Martin Fowler，关于技术债务和演进式架构的相关著述
Neal Ford、Rebecca Parsons、Patrick Kua，“Building Evolutionary Architectures”
Nicole Forsgren、Jez Humble、Gene Kim，“Accelerate”（松耦合架构与自主权）
ISO/IEC/IEEE 42010 架构描述标准