放行与否决策流程：上线就绪决策树
上线就绪的放行与否决策树模板：每个问题由谁回答，以及通往放行、附条件放行、限定试点、不放行与中止这五类结果的各条分支。
运作方式
把泳道改成你们真实的决策权
把发布负责人、研发与质量保证、运维与支持以及高管发起人换成在你们组织里真正握有答案的角色。泳道只写谁回答，不写谁参与：如果有三个团队为同一个问题提供证据、但由一个人拍板，那这个问题就属于拍板者那条泳道。任何一条你叫不出具体人名或角色的泳道，都应当合并掉。
在需要之前就把门槛写下来
这棵树的质量取决于它的判定。在“缺陷是否在严重级别门槛之内？”上，记下本次发布范围内每个严重级别的上限、谁可以推翻一次超限，以及计数是否包含从此前版本带过来的已知问题。对“验收标准是否全部满足？”做同样的事：在范围冻结时就把每一条标准标为必须或期望，这样关口才不会在当天被重新谈判。
定义“回滚已测试”到底指什么
“回滚是否已成功测试？”应当意味着在类生产环境中演练过、计过时、有指名的人能够执行，并且有一条写下来的触发条件用于决定何时启动。请把数据问题写明白，因为往往正是一次表结构或数据迁移的变更，把“这次变更究竟能否回退？”的答案变成否，而这条分支是通往中止的唯一一条路。
让附条件放行和试点结果成为真实的结果
只有当每个条件都带着指名的责任人、一个截止日期和一条未做到时的后果，附条件放行才与普通放行有所区别。试点放行则需要定义好人群、写下曝光比例或客户名单，以及扩大范围的判定条件。把这两样都写进“获准的范围是多大？”的备注栏，评审就无法以一个含糊的点头收场。
把不放行与中止分开
不放行意味着同一次发布晚些时候仍会上线，因此在散会之前需要一个改定的日期和一个具名的阻断项。中止意味着这次发布被撤回，其内容退回返工或重新评估。把两者作为不同的终点，可以避免一次真正的中止被记录成一次两周的延期，然后悄无声息地重复下去。
把它发布出去，并在每次关口之后复核
把这棵树发布到评审真正发生的地方，与证据包放在一起，并取得泳道所指名那些人的签署确认。每次发布之后，检查是否有问题在没有证据的情况下被回答了，以及是否缺少一个你们需要的结果。保留此前的版本，这样你们能说明判定标准是什么时候改的、为什么改。
常见问题
放行与否决策树和发布流程图有什么区别？
发布流程图回答“接下来会发生什么、由谁去做”。它在泳道上按顺序展示任务——范围冻结、构建、测试、部署、监控——并把放行与否这项决策当作一个节点。决策树回答“我们选哪一个选项、由谁决定”。它的主干是一连串问题而不是任务，它的分支以“已满足”“超出门槛”“可豁免”或“暂不签署”这类答案命名，而不是以下一项活动命名，并终止于若干个彼此不同的结果，而不是汇回同一条顺畅路径。两者都要用：用流程图看端到端的流程，用这棵树看流程内部的这道关口。
放行与否决策应当包含哪些问题？
七个问题覆盖多数上线。所有必须满足的验收标准是否都已满足？未关闭的缺陷是否在约定的严重级别门槛之内？依赖项与第三方是否就绪？回滚是否已经过测试，而不只是写过？支持与运维是否已针对预期量级完成培训并配齐人手？变更窗口在业务日程与技术日程上是否都空出？高管签署是否到位？每一个问题都应当能从会前收集的证据得到答案——这也正是这棵树从一份就绪证据包开始、而不是从第一个问题开始的原因。
放行与否由谁来拍板？
应当由一位指名的人主持，通常是发布负责人或生产环境的责任人，但真正有用的纪律是把每一个问题分派出去，而不是把整项决策交给一个人。研发与质量保证回答验收与缺陷问题，运维与支持回答回滚与人手问题，发布负责人回答依赖项与变更窗口，高管发起人回答签署。这样写下来之后，主持人的工作就是把这棵树跑一遍并记录结果，而不是亲自裁决每一个问题。记录下谁回答了什么，对取证同样重要：SOC 2 这类控制框架要求变更经过授权、测试、批准并留有文件，而一棵标明了决策权的决策树是一种直截了当的呈现方式。
什么时候应该给出附条件放行而不是不放行？
当遗留事项不会让这次发布面临风险，并且上线之后有人接手它的时候。只有当每个条件都带着指名的责任人、一个截止日期和一条未做到时的后果，附条件放行才是一个真实的结果；否则它只是多了几张纸的普通放行。把不放行留给任何会让用户暴露于风险或失去支持的情况。在这棵树里，阻断性的验收缺口、一个未达成一致的超门槛缺陷、一项没有它就无法发布的硬依赖、一个尚未准备好的支持职能，以及变更窗口冲突，都通向带改定日期的不放行。
不放行和中止有什么区别？
不放行意味着发布被推迟：同样的范围在阻断项清除之后于改定的日期上线。中止意味着它被撤回，内容退回返工或重新评估，且不附带日期。把两者分开之所以重要，是因为一次根本无法回退的发布，或者一次高管出于业务理由暂不签署的发布，并不是在等一个修复——把它记成延期，只会导致两周之后拿着同样的证据再开一次同样的会。
我该怎样把上线限制在试点或灰度人群？
把它当作决策的一个结果，而不是会议室里妥协出来的折中。在这棵树里，最后一个问题“获准的范围是多大？”分出“全量”“附条件”和“仅试点”，因此限定范围的发布是在所有就绪问题都得到回答之后被有意选择的，而不是一种回避不放行的办法。评审之前先定义试点在你们的产品里意味着什么：哪一批人群或多大的曝光比例、运行多久、监控什么，以及哪一条判定条件才准许扩大范围。