发布检查落地方案：研发团队开展发布管理的最佳实践案例解析

不少研发团队把发布检查理解成“上线前再过一遍清单”，结果检查表越做越长，事故却没有明显减少：检查项有人勾选，关键配置仍然漏改；审批记录齐全，回滚方案却从未演练；发布窗口准时结束，用户问题要到第二天才被发现。发布管理真正要解决的，不是“有没有人检查”，而是团队能否在正确的时间发现足以改变发布决策的信息，并据此暂停、缩小范围、继续或回退。下面以一个明确标注为情景模拟的中型研发团队案例，拆解发布检查如何从一张表变成可执行、可度量、能改进的工作机制。

一、核心结论：发布检查不是清单，而是一组决策门

1. 检查的目标是做出正确决定

我设计发布检查时，首先问的不是“还缺哪些检查项”，而是“哪些信息会改变当前的发布决定”。如果一项检查无论结果如何都不会影响发布范围、发布时点或回退动作，它就不该占据发布门禁的核心位置。

例如，“代码已提交”通常不能证明可以发布。它只说明变更进入了版本管理。真正影响决策的，是本次提交是否包含在目标构建中、相关测试是否通过、数据库变更是否兼容、关键指标是否有基线、异常时是否能够停止扩量。

发布检查的核心产物不是一串勾选框，而是四种明确结论：继续、限制范围、暂停、回退。每个检查项都应能对应其中一种或多种行动，否则它更像留档要求，而不是风险控制。

2. 把发布过程拆成相互独立的检查门

我倾向于将发布过程划分为准备、放行、观察和结束四道检查门。准备阶段确认变更和依赖条件是否齐备；放行阶段确定是否具备开始发布的条件；观察阶段根据实时信号决定是否扩大范围；结束阶段确认发布已稳定、临时措施已清理、问题已归档。

这四道门不一定需要四场会议，也不一定由四个部门分别审批。小团队可以在一张发布记录中完成，大团队可以由不同角色负责。但每一道门都要有责任人、输入信息、判定标准和失败后的动作。

• 准备门：确认版本、影响范围、依赖服务、数据变更和发布窗口。
• 放行门：确认测试证据、监控信号、回滚条件和当班人员可用。
• 观察门：确认错误率、延迟、业务指标和用户反馈是否在阈值内。
• 结束门：确认发布结果、遗留风险、临时开关和复盘事项。

3. 发布检查必须同时管住“开始”和“继续”

许多流程只设一个上线前审批点，默认批准后就一路执行到底。这种做法忽略了发布过程中的新信息：部分用户出现错误、某个下游服务变慢、队列积压突然上升，都可能让原本合理的发布变成不合理的继续扩量。

因此，放行不是一次性授权。团队还需要在发布过程中设置观察节点，并写清楚何时停止扩量。更成熟的做法是把“允许开始”和“允许进入下一阶段”分开判断，让每次扩大用户范围或流量比例都基于新的观测结果。

这会让发布检查从静态审批转为动态控制。它不是为了增加审批次数，而是为了减少一次错误判断影响全量用户的机会。

二、背景与真实场景：检查表为什么会变成形式

1. 情景模拟：一个团队的发布检查从何处失效

以下案例是用于说明机制的情景模拟，不是对真实客户或生产事故的披露。假设一家约 160 人的产品研发组织，有多个业务小组共用发布平台，每周进行多次小版本发布，每月进行一次较大范围的功能上线。团队此前已经有发布清单，但线上问题仍常在发布后数小时内出现。

复盘发现，失败并非因为大家不知道需要测试，而是信息没有在决策点汇合。测试记录放在测试平台，数据库脚本在代码仓库，运维参数在工单里，业务负责人通过聊天工具确认验收。发布负责人要在窗口开始前临时拼接信息，却很难判断这些材料是否针对同一个版本。

更隐蔽的问题是清单里的状态词过于宽泛。“已测试”可能代表冒烟通过，也可能代表测试人员看过页面；“已回滚”可能只是写了回滚步骤，并不代表回滚路径经过验证。表面上所有项目都完成了，实际含义却不一致。

2. 发布风险来自多个条件同时失配

发布风险通常不是由一个孤立因素决定。变更规模、依赖关系、数据可逆性、验证能力和恢复速度共同塑造了风险。小改动如果涉及不可逆数据迁移，风险可能高于一项范围较大的前端文案更新；一个经过充分验证的复杂功能，也可能比一个没人确认配置来源的小修补更可控。

我不会把变更行数、故事点或开发工时直接当作风险等级。它们可以帮助估计影响范围，却不能替代对失败后果和可恢复性的判断。更有用的问题是：失败会影响谁、能否隔离、多久能发现、能否恢复到可服务状态。

3. 组织规模改变的是协作成本，不是检查原理

十几人的团队往往可以依靠固定搭档和短沟通完成发布；跨产品线、跨时区或拥有多个共享服务的组织，信息同步成本会迅速增加。规模变大以后，不能简单地把所有审批都增加一层，而要把上下游依赖、责任边界和例外路径显式化。

对 100 人以上的组织，项目管理平台可以承载需求、缺陷、测试结果、发布记录和责任人之间的关联。以 PingCode 这类研发协作平台为例，适合将需求变更、测试任务和发布事项放到可追踪的工作流中；但工具只提供信息关联和流程执行能力，是否能降低风险，仍取决于检查项是否有清晰标准、信号是否及时、负责人是否拥有暂停权限。

小团队不必为了“像大公司”而先购买复杂工具。只要能明确版本标识、发布负责人、关键证据、观察指标和停止条件，一份结构化文档或轻量看板就可以起步。工具选型应跟随协作复杂度，而不是跟随组织的想象。

三、常见误区：看起来更严格，实际不一定更安全

1. 误区一：清单越长，遗漏就越少

清单变长有时只是把模糊要求拆成更多格子。检查人需要逐项确认，时间被状态维护占用，重要风险反而淹没在低价值项目里。尤其当不同类型发布共用一张表时，文案修改、数据库迁移和核心交易功能都要填相同字段，填写者会逐渐学会机械勾选。

我会先删掉无法改变决策的项目，再补足能够捕捉高后果失败的检查。比如“是否已通知相关人员”可以是协作项；而“变更是否能在目标版本中被准确识别”“回滚是否会导致新旧数据不兼容”，才可能是高优先级门禁。

清单质量不应由条目数量衡量。更实用的观察是：每项检查是否有证据、证据是否绑定当前版本、未通过时是否有人知道下一步做什么。

2. 误区二：审批人数越多，责任越清楚

多人审批看似降低个人判断风险，却可能制造责任稀释。所有人都看到记录，不代表有人对关键条件负责。跨团队发布时，最容易出现的情况是“每个人都认为另一个团队已经确认”。

我更愿意为不同判断指定唯一的最终责任人，同时允许多个角色提供专业意见。例如，测试负责人对验证证据负责，服务负责人对依赖风险负责，发布负责人对是否满足放行条件负责。责任人可以听取意见，但不能把最终判断藏在“大家都同意”后面。

审批也要区分知会、建议和否决权。每个参与者不必都拥有阻止发布的权限，但高风险条件必须有明确的阻断角色和升级路径。

3. 误区三：测试通过等于可以上线

测试通过只能回答“在某些输入、环境和断言下，测试结果符合预期”，不能独立回答生产环境的配置是否正确、数据是否兼容、依赖服务是否处于健康状态，也不能证明故障能够被及时发现。

我会把测试证据与生产准备度分开审视。功能测试验证行为，部署验证验证安装过程，监控验证验证风险可见性，恢复验证验证出问题后的处置能力。它们的组合才构成发布判断。

4. 误区四：有回滚文档就等于能回滚

回滚说明如果只写“恢复上一版本”，可能遗漏数据库模式、缓存格式、消息结构和外部副作用。代码回退不一定能够撤销已发送的通知、已触发的资金动作或已经按新格式写入的数据。

对可逆性有疑问时，我会把策略改成“前向修复优先，回退作为经过验证的备选”。数据库采用兼容性迁移，先新增再切换、最后清理；对难以逆转的业务动作，则通过限流、开关、补偿流程和人工核对控制影响。

5. 误区五：只看系统指标，不看业务结果

服务存活、CPU、内存和请求延迟很重要，但它们无法单独证明用户体验正常。某些发布会让接口保持成功，却造成订单状态未更新、搜索结果不完整或关键流程转化下降。

监控应覆盖三个层次：基础设施是否工作，服务链路是否健康，用户任务是否成功。发布前确定这些指标的基线与观察窗口，才能区分正常波动和发布相关异常。

四、专业判断逻辑：怎样决定检查什么、由谁检查

1. 用影响、可逆性和可发现性评估风险

我采用一个简单的风险讨论框架：影响范围、故障后果、恢复难度、发现速度。它不需要伪装成精确的数学模型，也不建议机械地把分数相乘。评分的价值在于暴露分歧：某个团队认为影响范围很小，另一个团队认为该服务承载多个产品的关键流程，这个差异本身就是需要解决的信息。

如果团队希望量化，可将每项按 1 至 5 分评估，并把结果用于分层，不把总分当成绝对真理。比如影响范围和不可逆程度均为高分时，应升级检查级别；即使总分不高，只要缺少关键监控，也不能视为低风险。

2. 将检查项写成“证据、阈值、责任人、动作”

一个有效检查项至少包含四部分：需要看到什么证据，什么条件算通过，谁负责判断，不通过时如何处理。缺少任何一项，团队就可能在发布窗口临时争论其含义。

例如，“监控已就绪”过于含糊。可以改成：“发布负责人确认核心接口错误率、尾延迟和关键业务成功率的发布前基线；观察期间任一指标超过约定阈值，暂停扩量并通知服务负责人。”具体阈值应由服务历史数据、业务容忍度和告警能力决定，不应从一篇通用模板里照搬。

对于依赖服务，也不要只写“已通知”。更好的记录包括依赖接口、变更版本、兼容方式、依赖方联系人和失联时的处理方案。信息越能支持行动，检查就越有价值。

3. 按变更类型分层，而不是所有发布走同一条路

我通常把发布分成常规、受控和高风险三类。常规发布采用自动化检查和抽样复核；受控发布增加灰度、业务验收或依赖确认；高风险发布要求更完整的恢复验证、值守安排和明确的暂停权限。

分层不等于给发布贴永久标签。同一服务的小幅文案修改可能是常规发布，涉及该服务关键数据模型的改动则可能升级为高风险。团队应依据实际变更重新判断，而不是沿用项目的历史等级。

• 常规：影响局部、数据可逆、监控成熟，优先用自动化证据快速放行。
• 受控：涉及多个组件或重要用户流程，采用分批发布并设观察节点。
• 高风险：涉及不可逆数据、核心交易或复杂依赖，需要额外审查与恢复准备。

4. 检查门要允许“有条件放行”

现实发布并不总是简单的通过或不通过。有时一个低优先级问题可以在范围受限、观察加强、功能开关默认关闭的前提下放行。关键在于把条件写清楚，包括适用范围、到期时间、责任人和撤销条件。

但“有条件放行”不能成为绕过门禁的常态。若团队连续多次依靠临时豁免发布，说明检查标准或发布节奏存在结构性问题。豁免需要留下可检索记录，并在发布结束后决定是补齐机制、接受风险，还是改变方案。

权限设计也要与决策相匹配。发现风险的人应能暂停扩量；发布负责人应知道谁可以恢复；高风险发布要有明确的升级联系人。没有暂停权的检查岗位，往往只能在事故复盘中说明自己曾经看见问题。

五、案例与数据观察：从一次性清单到发布控制回路

1. 案例设定与口径边界

以下数据均为情景模拟，用于展示如何建立观察口径，不代表行业统计或真实企业结果。假设上述团队在 8 周内逐步调整发布机制，发布频率平均为每周 6 次。团队没有单纯追求“零故障”，而是同时记录发布后问题、平均恢复时间、门禁耗时和检查证据完整度。

调整前的模拟基线为：每 20 次发布出现 3 次需要紧急修复的问题，问题发现中位时间约 75 分钟，发布准备平均耗时约 42 分钟。调整后观察期记录到每 20 次发布 2 次紧急修复问题，发现中位时间约 28 分钟，发布准备耗时约 31 分钟。

这个变化不能证明检查机制单独造成了改善。发布频率、系统复杂度、人员经验和同期技术改造都会影响结果。它更适合作为团队内部的对比观察：发布检查是否让问题更早暴露，是否让发布准备更可预测，是否把时间花在了关键风险上。

2. 最有效的改变不是多加审批，而是统一版本证据

情景模拟中的第一个调整，是为每次发布建立唯一版本标识，并将需求、代码提交、构建产物、测试结果和发布记录关联起来。过去，发布负责人要从多个渠道拼接信息；调整后，关键证据可以围绕同一个版本查看。

第二个调整是把“测试已完成”拆成可验证证据：本次版本包含哪些自动化测试、哪些场景需要人工验收、未覆盖的场景是什么、风险由谁接受。团队没有要求每个改动都写长篇报告，而是要求高风险项留下足以复核的证据。

第三个调整是把观察指标前移。在发布前确认要看哪些信号、从哪里看、由谁盯、多久复核一次。这样发布后不必临时讨论“现在看什么才算正常”。对于关键业务流程，团队还补充了业务成功率，避免系统存活但用户任务失败的情况。

3. 发布窗口里的决策顺序比表格设计更重要

一次受控发布可以按以下顺序执行：确认版本和变更范围，确认依赖和当班人员，核验放行条件，发布到小范围，观察约定信号，再决定暂停、继续扩量或回退。顺序设计要减少“先上线再找证据”的冲动。

1. 发布负责人核对版本标识、目标环境和本次变更清单。
2. 服务负责人确认依赖状态、数据兼容性和恢复动作。
3. 测试负责人提供与当前版本对应的验证证据及未覆盖范围。
4. 业务代表确认关键用户流程的验收口径和风险容忍度。
5. 值守人员确认告警、仪表盘、沟通渠道和暂停权限可用。
6. 发布到约定范围后，按观察窗口评估信号，再决定是否扩量。
7. 发布结束后记录结果、遗留事项和临时控制的清理时间。

这套顺序不是要求每次开会逐条朗读，而是把决策依赖关系固定下来。自动化能够提供证据时，应由系统生成结果；人工把关应集中在自动化难以判断的业务影响、例外和风险接受上。

4. 观察窗口要根据风险和信号延迟决定

观察 10 分钟还是 2 小时，不能靠固定模板决定。若关键指标在数分钟内就能反映问题，低风险改动可能使用较短观察窗口；若业务事件需要经过完整交易周期才可见，窗口就应覆盖该周期。观察期间如果流量很低，指标稳定也不一定代表安全。

因此，观察窗口应与指标更新频率、用户行为周期、流量规模和回退成本挂钩。若样本量不足，团队可以延长观察、增加合成验证、分时段扩量，或选择对用户影响更小的窗口。不要把“没有告警”直接等同于“没有异常”。

5. 用领先指标和滞后指标共同解释结果

事故次数、修复时长是重要的滞后指标，但它们容易受样本量影响。团队还应看领先指标，例如高风险发布的恢复演练覆盖率、发布证据与目标版本的匹配率、关键告警覆盖率、发布暂停执行次数和豁免到期率。

领先指标也可能被“做漂亮”。证据完整率提高，不代表证据正确；暂停次数减少，不代表发布更稳，也可能代表团队不敢暂停。指标应配合抽样复核和复盘解释，不能直接变成个人绩效排名。

六、落地方法：按阶段建立能运行的发布检查

1. 第一步：先梳理最近几次发布，而不是先写制度

启动时，我会选取最近 10 至 20 次发布记录，检查实际发生过的问题、临时沟通、等待时间和补救动作。重点不是追究谁漏了哪一项，而是找出信息在哪个节点不可见、判定标准在哪里含糊、异常发生后谁不能及时行动。

如果团队没有完整历史记录，就从接下来 4 周建立轻量记录。至少记录发布时间、变更类型、影响范围、关键证据、发布结果、发现问题的时间、恢复耗时和例外项。先获得可讨论的基线，再决定制度细节。

2. 第二步：定义发布分类与最小门禁

分类的目标是避免低风险发布承受高风险流程，也避免高风险发布使用常规检查。每类发布都应有明确升级条件，例如涉及不可逆数据变化、跨多个关键服务、影响核心业务链路、缺少回滚能力或监控覆盖不足时，升级到更严格的路径。

起步阶段的最小门禁可以只包含版本准确、验证证据、影响范围、监控与暂停条件、恢复方案、责任人与沟通渠道。运行几周后，再根据实际问题增删项目。团队应保留“为什么需要这一项”的解释，避免检查逐渐失去目的。

3. 第三步：让检查项拥有证据和处置动作

检查项不必全都自动化，但必须减少含糊表达。将“已确认”改成具体证据，将“无风险”改成风险说明，将“可以回滚”改成回退条件与验证记录。若某项只能依赖人工判断，要说明判断依据和责任角色。

对于自动化检查，应明确数据源和失败处理。例如，流水线失败是阻止发布、提醒复核，还是允许经授权豁免；测试结果是否绑定当前构建；依赖服务状态是否足够新鲜。自动化能降低重复劳动，但错误或过期的自动化结论同样会放大风险。

4. 第四步：设置发布中止条件与指挥角色

许多团队写了“异常时回滚”，却没有定义什么算异常、谁能叫停、如何协调。建议在发布前明确至少三类信号：技术信号，例如错误率和延迟；业务信号，例如关键流程成功率；运营信号，例如用户投诉或下游积压。

中止条件要能执行，例如超过阈值持续多长时间、影响范围达到什么程度、哪些指标出现组合异常。避免阈值只有数字没有窗口，也避免只用“显著恶化”这样的主观词。具体阈值需要由服务历史基线和业务容忍度确定，并经过演练。

5. 第五步：通过复盘更新机制，而不是不断加条目

每次问题都不应自动变成一条新检查。复盘时先区分：是检查缺失、检查失效、证据不可靠、判定错误、执行权限不足，还是观察时间不够。只有根因确实需要新控制时才加项目；如果问题来自流程含糊，就应改写责任和动作。

复盘要把“人的失误”转化为系统改进。例如，配置项漏改不一定需要再增加人工确认，可能更适合在构建时生成配置差异报告；回滚失败不一定需要更长的说明文档，可能需要定期执行恢复演练。

6. 第六步：选择合适的信息载体

团队可以从发布记录模板、任务看板或现有研发协作平台开始。关键是一个发布对象能够关联到需求、代码版本、测试证据、变更审批、观察结果和复盘事项，且参与者能看清当前状态与责任人。

当组织跨多个产品组、角色和服务时，某项目管理平台可以用于关联研发流程、测试任务与发布记录。比如在采用 PingCode 等研发协作工具时，应重点验证工作流是否支持不同风险等级、证据是否能追溯到版本、异常是否能升级到责任人，以及数据权限是否适配组织治理要求。不能仅凭功能清单或演示界面判断落地效果。

无论选用哪种工具，都应先用一条真实发布路径做试点。若使用者需要重复录入、审批状态与实际执行脱节、监控链接无法关联版本，工具就可能增加维护负担。先解决信息断裂，再考虑扩展更多自动化能力。

七、不同情况下的行动建议：先解决当前最大的约束

1. 小团队、发布频繁、协作链路短

优先建立轻量发布记录和自动化门禁。不要把每次发布都做成会议，也不要要求低风险变更写长报告。每次只保留版本标识、变更范围、验证结果、观察指标和暂停责任人；高风险变更再升级审批路径。

如果团队只有少数关键服务，固定观察指标比堆叠通用模板更有效。每周抽样检查记录质量，关注是否出现“全绿但没人能解释”的状态。可以先通过脚本或流水线自动采集构建、测试与部署信息。

2. 中大型团队、依赖多、职责分散

优先做统一版本关联、依赖确认和责任矩阵。跨团队发布最容易在边界处失败，所以必须明确变更涉及哪些服务、谁提供兼容性确认、谁负责业务验收、谁拥有暂停权。

对于 100 人以上的研发组织，建议按产品或服务风险分层，而不是建立一个覆盖所有团队的超长审批清单。平台可以集中呈现流程状态，但服务团队仍应对本服务的阈值、恢复策略和业务影响负责。

3. 数据迁移或不可逆业务动作较多

把重点放在兼容、分阶段迁移和恢复能力上。大规模数据变更应尽量拆成扩展、回填、切换、清理等阶段，避免一次部署同时改变应用逻辑和数据结构，使失败后无法判断回退边界。

发布前检查样本校验方式、备份可用性、迁移耗时、锁影响和中断后续跑能力。若外部动作不可逆，应设计补偿流程和人工核对清单；把“代码回退成功”误当作业务恢复成功，是高风险盲点。

4. 服务监控薄弱、历史基线不足

不要假装精确地设置阈值。先补充基础业务指标、建立发布前基线，并采取更小范围的发布策略。若当前没有办法判断发布后的业务变化，应降低首批流量、缩短反馈链路，必要时推迟高影响变更。

同时要区分“没有数据”和“数据正常”。一个没有告警的仪表盘可能只是没有足够的观测覆盖。高风险发布应由人工抽样验证关键流程，并把监控建设纳入后续改进事项。

5. 组织处于强合规或审计要求环境

将证据保留、审批权限和变更可追溯性纳入发布设计，但不要用审计记录替代技术验证。审计需要回答谁在什么时间基于哪些证据作出判断；生产安全则还需要回答失效时怎样发现和恢复。

对紧急变更设计可审计的快速通道，包括授权角色、最小必要记录、事后补充时限和复核责任。把紧急流程完全禁止，可能导致团队在现实故障中绕开正式机制；合理设计例外，比假设例外不会发生更可靠。

八、不同情况下的取舍：速度、覆盖、自动化与治理

1. 发布速度与检查深度之间的取舍

增加检查通常会提高单次发布的准备成本，但也可能减少问题发现后的恢复成本。真正需要比较的不是“检查多还是少”，而是检查是否针对高后果风险，以及它的成本是否低于风险暴露后可能付出的代价。

低风险、高频发布更适合靠自动化和小批量发布提升速度；高风险、低频发布可以承受更深入的人工审查。不要用统一门禁把两种场景压成同一个流程。

2. 自动化与人工判断之间的取舍

自动化适合稳定、可重复、证据来源明确的检查，例如构建产物、静态扫描、自动化测试、配置差异检测。人工判断更适合评估新业务影响、跨团队依赖、异常的可接受性和复杂恢复方案。

自动化门禁不是越多越好。错误率高、解释困难或经常需要绕过的门禁，会让使用者形成“反正可以忽略”的习惯。每个自动化门禁都应定期检查误报率、漏报风险、执行耗时和例外频次。

3. 集中治理与团队自治之间的取舍

组织级规范应统一最小证据、术语、权限和审计要求；服务团队则要保留定义业务阈值、观察窗口和恢复策略的空间。全部集中容易让规则脱离具体系统，完全自治又会导致跨团队接口无法对齐。

实务上可以采用“共同底线加服务级附录”：组织规定版本追溯、责任人、异常处置和例外记录；各服务补充自己的关键指标、依赖、数据风险和恢复步骤。变更边界清楚，治理成本也更可控。

4. 严格门禁与快速恢复之间的取舍

门禁不能发现所有风险，恢复能力也不能代替预防。若团队把全部资源用于发布前检查，仍可能在生产异常中反应迟缓；若依赖快速回滚，却从不验证数据兼容和用户影响，也会在真正需要回退时发现路径不存在。

我更重视两者的组合：高后果风险用门禁减少暴露，剩余风险用灰度、监控、暂停和恢复机制限制损失。衡量成熟度时，既看问题是否发生，也看问题是否能被及时发现、限制和恢复。

九、结语：把检查从“证明做过”变成“帮助做决定”

1. 发布管理的价值在于缩短判断链路

发布检查落地后，团队不一定会立刻达到零事故，也不该把零事故当作唯一目标。更现实的进步是：同一版本的证据能被快速找到；风险与责任边界不再靠临时猜测；发布中的异常有明确暂停条件；问题出现时，团队能更快限制影响并恢复服务。

发布记录若只是证明流程走过，它会越来越像行政材料。发布记录若能让团队理解“为什么继续、为什么暂停、为什么接受例外”，它才是研发运营中的决策资产。

2. 下一步：从一次真实发布开始验证

下一次发布前，选一项有代表性的变更，不必先改造全组织。明确版本标识、影响范围、测试证据、观察信号、暂停条件和责任人；发布后记录实际耗时、问题发现时间、例外事项和恢复动作。

随后复核三件事：检查有没有发现原本看不到的风险，证据是否真正支持了发布判断，新增流程成本是否值得。把答案转成下一轮流程调整，而不是直接增加更多勾选项。

我对发布检查的判断很简单：如果一项检查不能改变团队的行动，它就不该成为核心门禁；如果一个风险无法被检查发现，就要通过范围控制、监控或恢复能力来管理。发布管理不是让每次上线看起来更谨慎，而是让团队在不确定条件下仍能做出可解释、可暂停、可恢复的决定。