发布检查实操方法：项目成员提升发布管理效率的协同管理方法与模板

发布检查最容易失效的时刻，往往不是发布当天，而是“大家都以为别人检查过了”的那一刻：测试说功能通过，研发说代码已合并，产品说文案没问题，运维却在上线前才发现回滚包没有验证。发布检查实操方法的关键，不是多加几张表，而是把发布条件、责任人、证据和停止发布的权力连成一条可追溯的协作链。本文会给出一套可按团队规模裁剪的检查流程、判断逻辑、风险分级方法和模板，并用明确标注的情景模拟说明它怎样减少等待、遗漏和返工。

一、先讲核心结论：发布检查不是“签字”，而是风险决策

1. 检查项必须连接到发布风险

我判断一项发布检查是否有价值，通常先问三个问题：它要降低什么风险？谁能提供可信证据？发现异常后，团队具体采取什么动作？如果某个检查项只有“确认完成”，却说不清它防范的风险，也没有证据和处置动作，它更像形式性签字，不是有效控制。

例如，“确认测试完成”并不充分。测试负责人需要说明测试范围、未覆盖的场景、阻断缺陷数量，以及关键业务链路是否通过；发布负责人再根据风险决定继续、延期或增加验证。检查的产物不是一排绿色勾选，而是可复核的发布决定。

2. 把发布拆成条件、证据、责任和决策

一项可执行的检查至少有四个字段：条件、证据、责任人、异常动作。条件描述必须达到的状态；证据说明怎样证明状态成立；责任人负责提交或复核；异常动作定义未达标时怎么办。缺少任何一项，到了时间紧张的发布窗口，团队都可能用口头承诺替代事实。

3. 按风险配置检查深度，不要让每次发布都一样重

内部工具的低风险文案调整，与支付、权限、数据迁移相关的变更，不应承担相同的检查成本。我的建议是先划分风险级别，再决定需要哪些证据、哪些角色参与，以及是否要求分批放量和回滚演练。检查清单不是越长越可靠，真正有效的是高风险环节有更强的验证，低风险环节不被不必要的流程拖慢。

风险等级需要依据团队的业务影响来定义，不存在适用于所有组织的固定阈值。上表是工作方法示例，不是行业统计标准。团队应结合故障影响范围、恢复难度、数据可逆性和用户受影响程度，定期调整分级规则。

二、发布检查为什么容易失灵：真实协作场景里的断点

1. 信息散落在不同位置，状态看似完整却无法核实

在跨产品、研发、测试、运维协作的发布中，信息常常分散在任务系统、群聊、文档和个人记忆里。研发说“已合并”，测试不知道对应的构建版本；运维拿到部署包，却不确定它是否包含最后一轮修复；产品看到缺陷已关闭，但没有确认关闭的是哪个环境里的问题。

这种状态的危险之处在于，每个人说的可能都是真的，但他们说的不是同一个版本、同一套范围或同一时点。发布检查需要把信息收束到同一发布对象上：发布编号、版本号、变更范围、负责人、证据链接和决策记录应能互相对应。

2. 临近发布时间才检查，导致问题没有处置窗口

如果所有检查都集中在发布当天，发现缺少回滚验证、监控告警未配置或关键用例未执行时，团队只剩下两个不理想的选择：冒险上线，或临时延期。两种情况都会增加沟通成本，前者扩大故障风险，后者可能影响业务安排。

我更倾向于把检查分成三段：发布准备期验证输入是否齐备，发布前确认准入条件，发布后检查运行结果。这样做的目的不是提前制造更多审批，而是把可预见的问题移到仍有修复时间的阶段处理。

3. “负责人”含糊，导致每个人都在等待别人

“研发负责”“测试确认”“产品跟进”这类描述通常不够。多人协作时，需要进一步明确谁执行、谁复核、谁作决定、谁在异常时被通知。尤其是暂停发布的权限，如果没有提前约定，团队成员可能发现风险却不敢提出，也可能因为意见不一致而陷入临时争论。

可采用轻量责任划分：任务执行人提交证据，领域负责人复核，发布负责人综合判断，业务负责人确认影响和窗口。一个人可以兼任多个角色，但每个关键决定必须能找到明确的责任主体。

4. 只记录“通过”，没有记录“为什么通过”

检查表上写“通过”并不能解释当时的判断依据。若发布后出现问题，团队既无法还原当时掌握的信息，也难以区分是检查漏项、证据不完整、风险接受不当，还是执行过程偏离计划。发布记录应保留关键依据，而不是只保存最终颜色或状态。

例如，某个低优先级缺陷没有修复时，记录中至少应说明影响范围、已知规避方式、接受该风险的负责人，以及后续处理时间。让例外透明，比要求所有事项看起来都完美更有助于控制风险。

三、常见误区：清单变长，不等于发布更安全

1. 误区：把所有历史问题都塞进同一张检查表

每发生一次故障就增加一项永久检查，看似是在吸取教训，长期却会造成清单膨胀。低风险发布也要逐项确认几十个无关事项，成员很容易形成机械打勾，真正重要的检查反而被淹没。

我会把检查项分成三类：每次发布都必须验证的基础项、特定技术或业务场景才触发的专项项、事故复盘后暂时观察的改进项。新增检查项应写清触发条件、负责人和复核日期；若证据显示它不再有价值，就应合并、改写或移除。

2. 误区：用一次会议替代异步证据准备

发布会议的价值是处理争议和作出决定，不是现场逐条询问“做完了吗”。如果大家在会议中才打开文档找测试结果，会议就会变成信息搜集过程，最重要的风险讨论反而被压缩。

更有效的做法是会前提交证据，会中只讨论未满足条件、接受的例外、回退方案和发布窗口。低风险变更可异步完成确认；高风险变更则保留同步评审，但要求参与者先阅读材料。

3. 误区：把“有回滚方案”当成“能回滚”

文档里写着回滚命令，不代表回滚经过验证。应用版本可以退回，但数据结构已经变更；配置恢复了，缓存或消息队列仍保留新格式；部署失败能够恢复服务，却无法恢复用户已提交的数据。这些情况都说明“可回滚”必须按系统实际状态定义。

我会把回退能力拆成三个问题：能否恢复旧版本？数据和配置能否兼容？谁在什么信号出现时执行，预计多久恢复？涉及不可逆数据迁移时，还要说明替代处置路径，例如前向修复、功能关闭或流量隔离。

4. 误区：只盯缺陷数量，不看影响范围和暴露概率

一个低优先级、极少触发的显示问题，未必比一个只影响少量用户但会造成数据错乱的问题更轻。缺陷数量只是线索，不是发布结论。判断时至少要考虑发生概率、影响严重程度、受影响人群、可探测性和恢复成本。

相反，零缺陷也不自动代表安全。如果核心链路没有覆盖、测试环境与生产配置差异明显，或者发布后缺少观测手段，零缺陷可能只是“没有发现”，不是“风险已经消失”。

5. 误区：把工具状态当作实际状态

任务被标为完成，可能只是流程状态更新；文档链接存在，也不意味着文档对应当前发布版本。工具能帮助团队减少重复整理、关联任务与证据、提醒责任人，但它无法替代清楚的准入标准和专业判断。

对 100 人以上、多个团队并行交付的组织，采用某项目管理平台管理发布记录，通常有助于把需求、缺陷、测试任务和版本关联起来。选择 PingCode 等协作工具时，我会重点检查字段配置、权限边界、状态流转、证据链接和审计能力是否支持团队的实际发布流程，而不是只比较功能列表。先统一发布对象和责任定义，再考虑工具怎样承载它们。

四、专业判断逻辑：把“能不能发”变成一套可复核的决策

1. 先界定发布对象，避免不同人检查不同范围

发布对象不应只是一个版本号。对于复杂交付，我会同时记录发布窗口、目标环境、包含的变更、依赖服务、构建标识、数据变更和受影响业务流程。涉及多个子系统时，还要说明哪些部分同批发布、哪些部分独立开关。

范围一旦变化，就应触发对应检查项重新评估。例如发布包临时增加修复，测试负责人需要确认新增变更是否纳入验证，运维负责人需要确认部署顺序是否变化。范围不清，后续所有“已检查”都可能失去意义。

2. 将准入条件写成可验证的门槛

“测试充分”“性能正常”“文档齐全”都太含糊。门槛应描述验证对象、观察范围和通过标准。比如，不写“性能正常”，而写“在约定的压测负载下，关键接口延迟和错误率处于团队发布标准内”；不写“回滚准备完成”，而写“回退步骤已由值班人员复核，关键依赖和数据兼容策略已确认”。

门槛可以依据团队历史基线建立，但不能把某个数字机械复制到所有系统。重要的是让团队知道标准从何而来、适用哪类服务，以及超出标准时由谁判断。

3. 检查证据的时效性、对应性和可复核性

一份证据是否可信，我会从三个维度看。时效性：它是否来自当前候选版本和当前环境？对应性：能否关联到具体变更和检查项？可复核性：其他成员能否依据材料重新判断，而不是只能相信提交人的口头说明？

截图可以帮助说明操作结果，但不应成为唯一证据。对于关键链路，测试报告、构建编号、监控面板、缺陷记录或变更审计信息往往更容易追溯。证据不必追求形式复杂，应优先做到准确、关联和可查。

4. 把风险判断拆成影响、概率、可发现性和恢复能力

对风险的判断不宜只靠“感觉比较危险”。我会先描述失败会影响什么，再估计它出现的可能性；接着确认故障能否及时发现，最后评估系统和团队是否能够迅速恢复。可能性很低但后果极重的故障，仍然需要强控制；影响可控且容易恢复的变更，可以采用更轻的检查。

5. 明确暂停发布的条件和决策权限

发布决定不能只靠“大家都同意”。团队应提前规定哪些情况属于硬性阻断，例如核心流程验证失败、数据备份未确认、构建版本与测试版本不一致、重大安全问题未解决。其他风险则可进入例外评估，明确影响、补偿措施、接受人和复查日期。

任何成员都应能报告风险，但最终决策权要明确。否则，要么无人敢叫停，要么所有人都可以无限期否决。对于高风险发布，可指定发布负责人综合技术、业务和运营意见作决定，并留下理由。

五、发布检查实操流程：从变更登记到发布后关闭

1. 发布准备期：建立唯一发布记录

发布准备开始时，先建立一个唯一的发布记录，避免不同团队各自维护一份互不一致的清单。记录中至少包含发布名称、版本或构建标识、计划窗口、变更范围、业务负责人、技术负责人、风险级别和当前状态。

随后将需求、缺陷、测试任务、配置变更、数据迁移和运维操作关联到这个记录。若某个变更还无法对应到发布对象，就先不要把它当作“已纳入检查”。这一步看起来像资料整理，实际是在确定后续所有证据的边界。

2. 开发完成前：确认变更范围和依赖

在进入发布前检查之前，研发负责人需要确认代码、配置和依赖是否冻结，是否存在未纳入记录的临时改动。跨服务变更还要核对接口兼容性、部署顺序和上下游准备情况。数据变更应说明迁移方式、预计影响、备份策略和失败后的处理路径。

冻结并不意味着绝对不能变更，而是每次新增变更都要重新判断范围和风险。临时修复如果未经测试和记录，可能让团队原本已完成的检查失去对应关系。

3. 发布前：按风险级别提交检查证据

测试负责人提交覆盖范围、关键链路结果和未解决缺陷；研发负责人提交构建版本、变更清单和已知限制；运维负责人确认部署顺序、配置、监控和回退准备；业务负责人确认发布时间和业务影响安排。每项材料要能关联到具体发布对象，而不是散落在无法追溯的对话中。

发布负责人检查证据是否满足准入门槛。未通过项要标为阻断、待整改或可接受例外，并写明下一步动作。不要用“风险可控”代替解释，至少要补充风险是什么、由什么措施降低、谁接受剩余风险。

4. 发布决策会：只讨论未决问题

会议前先发布状态摘要：通过项、阻断项、例外项、未确认依赖和决策请求。会中优先处理影响最大的未决事项，不逐项朗读已经核实的清单。会议结束时记录明确结论、参与人、发布窗口、执行负责人和触发暂停的条件。

低风险、范围清楚且证据齐备的变更，可以由责任人异步确认，不必为每个小改动召开会议。高风险变更则需要跨职能沟通，尤其是发布窗口影响业务、数据不可逆或依赖方较多时。

5. 发布执行中：观察信号并保留叫停通道

执行期间，发布负责人应确认实际部署版本与批准版本一致，并按既定顺序执行。观察的不是“页面能打开”这一项，而是与变更风险相关的关键业务指标、错误信号、调用链和用户反馈。若异常达到预设阈值，应按预案暂停、缩小流量、关闭功能或回退。

谁观察、观察多久、谁可以下达停止指令，都要在发布前确定。否则出现异常时，团队可能一边等待授权，一边继续扩大影响范围。

6. 发布后：验证结果，再关闭记录

发布完成不等于检查结束。发布后应确认关键功能、数据状态、监控和用户反馈是否正常，记录验证时间、验证人、发现的问题及后续事项。高风险变更可安排分阶段观察，低风险变更可采用抽查或自动监控。

关闭发布记录前，确保未处理事项有负责人和期限；若出现偏差，则将其转成缺陷、改进任务或复盘事项。这样发布检查才能形成反馈闭环，而不是每次重新从空白表格开始。

六、可直接改造的发布检查模板与协同约定

1. 发布记录主模板

模板的作用是让团队不用每次重新发明字段，而不是强迫所有发布填满同一份长文档。建议先保留核心字段，再按风险级别增加专项模块。下面的表格可以复制到项目管理工具或团队文档中使用。

2. 检查项模板：把“完成”改成“证据加动作”

检查项应短而可判断。下面的示例用于演示填写方法，团队可以根据系统类型替换条件和证据。遇到无法在发布前完成的事项，要写明例外处理，而不是把状态改成通过。

3. 责任矩阵模板：避免多头负责和无人决策

下表是一个简化的责任示例。“执行”表示实际提交材料或操作，“复核”表示检查结果，“决策”表示作出发布结论，“知会”表示需要及时获得状态。一个人可以承担多个角色，但高风险变更最好避免关键证据由同一人提交并独自复核。

4. 状态设计：少而明确，比状态繁多更好用

可以从“准备中、待检查、待决策、已批准、执行中、观察中、已关闭、已暂停”开始。每个状态都应有进入条件和责任人。比如“已批准”不是某个负责人点了按钮，而是准入条件满足或例外已被明确接受；“已关闭”则意味着发布后验证完成，遗留事项已经转交。

如果团队需要更多细分状态，先确认它们是否会触发不同动作。只为展示进度而不断增加状态，通常会增加维护负担。状态名称越多，越需要明确迁移规则和超时提醒，否则工具看起来很细，实际协作仍然靠追问。

七、案例与数据观察：用一次模拟发布检验流程是否有用

1. 案例背景：三支团队共同完成一项核心流程变更

以下案例是为了说明方法而构造的情景模拟，不是某家企业的真实生产事故，也不代表行业平均值。场景是一家有多个业务团队的企业计划更新一段核心下单流程，改动同时涉及应用代码、接口依赖和部分配置。参与者包括产品、研发、测试和运维，团队原本习惯在发布当天集中确认。

在第一次模拟推演中，测试报告对应的是较早的候选构建，最新修复未关联到测试记录；另有一项配置变更没有进入发布清单。每个角色都完成了自己的工作，但发布对象没有统一，导致“测试通过”和“可以部署”之间出现断层。

2. 调整方式：提前冻结范围，发布前只处理未决风险

团队没有增加大量审批，而是增加了三项约束：每个变更关联唯一发布编号；测试证据必须标明构建版本；新加入的变更必须重新评估受影响的用例与依赖。发布前一天，发布负责人查看未决项列表，只召集相关责任人讨论构建不一致和配置影响。

通过这种安排，会议从逐项点名改为聚焦两个真正未决的问题。构建重新验证后，团队按照修改后的范围批准发布；发布后再检查关键下单指标和依赖服务告警，并将验证记录关联到同一发布对象。

3. 怎样评估效率改善，而不是只看“会议少了”

会议时长下降不一定代表效率提升，也可能是讨论被省略。评估发布检查改进，我会同时观察准备耗时、发布前阻断项发现时间、证据关联率、发布后异常数和返工人天。指标要有明确口径，并区分变更规模和风险级别，否则一次大版本与多次小修复直接比较，容易得出误导结论。

以下数字是情景模拟，用于展示如何定义指标，并非来自外部调查。假设团队对比一段时间内的相近复杂度发布，可记录每次从准备启动到决策所用时间，以及关键证据是否关联到目标构建。真实使用时应以团队自己的记录替代。

这些示意数字不能直接作为绩效目标。若团队为了压缩会议而把问题推迟到发布后，决策会议变短了，整体风险反而可能上升。评估时应结合阻断项发现时间、异常影响和复盘结论，确认变化来自流程改善，而不是检查被弱化。

4. 指标解释要看趋势、分布和例外原因

建议至少按发布类型分组观察，不要把所有变更合并成一个平均数。高风险发布本来就需要更长准备时间；低风险发布如果同样要求完整专项评审，可能说明流程过重。对于发布前阻断项，还要记录它们是在什么时候发现的：提前数日发现，通常比临近窗口才发现更有处置空间。

也要关注“零阻断”是否反常。如果团队每次都显示所有项通过，却仍频繁出现发布后补救，可能是门槛过松、证据不实或成员不愿暴露问题。检查指标的目的不是追求漂亮数字，而是帮助团队发现控制措施与实际故障之间的偏差。

八、不同团队与不同发布类型的行动建议

1. 小团队、低频发布：先把最关键的四件事做好

人手有限、发布频率不高的团队，不需要一开始就建立复杂审批链。先统一发布记录，写清范围、版本、测试结果和恢复路径，再指定一个发布负责人。对于低风险改动，异步确认通常足够；但涉及用户数据、权限或核心流程时，应提高检查深度。

小团队最常见的陷阱不是缺少工具，而是负责人身兼数职却没有明确交接。即使只有三五个人，也应在发布记录中写明谁验证、谁执行、谁决定，以及执行人缺席时由谁接手。

2. 多团队并行、发布频繁：优先解决依赖与版本关联

多个团队同时交付时，清单本身不是瓶颈，依赖关系和发布范围才是。应明确服务之间的兼容关系、部署顺序、共享窗口和跨团队联系人。每个团队提交的证据需要能关联到同一发布对象，避免各自确认“没问题”，但没有人对整体结果负责。

这类组织可以用某项目管理平台把需求、缺陷、测试和发布任务串起来，自动提醒逾期责任人，并统一保存决策记录。使用 PingCode 作为协同管理案例时，适合关注其在多团队需求追踪、任务协作和状态可视化方面是否符合组织流程；不要因平台功能齐全，就忽略发布规则本身的设计。实际采用前，应通过小范围试点验证字段维护成本、权限配置和跨团队数据一致性。

3. 高风险、数据不可逆的发布：把恢复能力放在发布前验证

涉及数据迁移、权限模型、资金流程或外部接口的大变更，发布前不仅要确认“方案存在”，还要确认恢复策略适用于实际状态。对于不可逆操作，团队应明确是否采用分阶段迁移、双写验证、功能开关、流量隔离或前向修复，并指定负责观察和决策的人。

如果无法证明发生异常后怎样控制影响，就应把发布窗口推迟到恢复方案可接受，或把变更拆小。时间压力是需要管理的约束，不是跳过关键验证的理由。

4. 低风险、频繁的小改动：把流程自动化，但保留例外通道

对于重复、可逆且影响范围小的变更，可以把基础检查转为自动校验，例如构建状态、必填字段、测试结果关联和发布记录完整性。自动化的价值在于减少重复提醒，不是把所有判断交给系统。

当自动检查失败时，应给出具体原因和责任人，而不是只显示红色状态。若团队通过例外机制绕过自动门槛，应记录原因与批准人，后续分析例外是否正在变成常态。

九、流程、模板和工具如何取舍：不要把控制成本转嫁给成员

1. 清单取舍：减少重复检查，保留高价值门槛

每增加一个检查项，都会产生填写、复核和维护成本。新增项应优先对应明确的故障模式或审计要求，并说明检查责任和预期动作。若两项检查验证的是同一个风险，应考虑合并；若某项长期无人使用，也要判断它是无价值、难执行，还是团队缺少必要能力。

检查项数量不是成熟度指标。成熟的清单通常更关注触发条件和证据质量：常规项保持轻量，专项项在相关风险出现时启用，历史事故项则通过复盘确认是否需要长期保留。

2. 会议取舍：同步解决争议，异步完成信息传递

会议适合处理跨团队取舍、发布窗口冲突、风险接受和暂停决策，不适合替代证据提交。若一场会议大部分时间都在追问状态，说明信息准备方式需要改进，而不是单纯要求成员“开短一点”。

当风险较低、责任明确、检查结果可复核时，异步决策成本更低。若涉及多个关键依赖、不可逆变更或不同角色对影响判断不一致，同步讨论更合适，但要设置明确的决策人和结束条件。

3. 自动化取舍：先自动化稳定规则，再处理复杂判断

必填字段、构建标识、测试任务关联和审批超时等规则，适合自动提醒或校验；业务影响是否可接受、缺陷是否可以带风险发布、恢复策略是否充分，通常仍需要专业人员判断。不要把难以量化的判断硬做成一个看似精确的分数。

自动化应减少重复劳动，而不是制造新的状态维护工作。试点时观察成员是否需要重复录入、证据是否能复用、失败提示是否可行动，再决定是否扩大覆盖范围。

4. 平台取舍：先看协作链是否连通，再看功能数量

选择管理工具时，我会先检查五件事：发布对象能否唯一识别；需求、缺陷、测试和版本能否关联；权限是否符合分工；例外与决定能否留痕；发布后问题能否回到改进任务。对于中大型企业和 100 人以上的组织，还应评估跨部门视图、审计记录、流程配置和数据维护成本。

如果现有工具已经能够稳定支持这些环节，贸然迁移可能带来更高的培训与数据整理成本。反之，当信息长期散落、跨团队状态无法汇总、证据重复维护时，才值得评估更适合的协同平台。工具选型应通过真实发布试点验证，而非依据演示环境里的理想流程作判断。

十、发布管理落地的四周推进法

1. 第一周：盘点最近的发布记录和典型失误

不要先设计一套完美流程。先选取近期若干次不同风险等级的发布，查看延期原因、临时阻断项、版本不一致、发布后补查和例外接受情况。重点不是追究个人责任，而是识别信息在哪个交接点丢失、哪项证据经常无法找到，以及哪些检查造成重复劳动。

样本数量由团队情况决定。若发布频率较高，可以按业务类型抽取；若频率较低，则可结合复盘记录和桌面演练。分析时标明样本范围，不要把少数案例包装成普遍规律。

2. 第二周：选出一套最小检查模板

先保留影响最大、最容易遗漏的基础项目，例如范围、版本、关键测试、依赖、监控、恢复路径和发布后验证。对不同风险等级设置触发项，不要要求所有发布填写所有专项字段。每个检查项都要指定责任人和不通过时的动作。

邀请研发、测试、运维和业务代表共同走读模板。若某个字段大家理解不同，先把字段定义写清楚，再要求填报。模板能否被执行，取决于成员是否知道什么时候填写、怎样通过，而不是文档格式是否精美。

3. 第三周：在真实发布中试运行并记录摩擦

选择一个范围适中、风险可控的发布试运行。观察成员是否重复录入、证据是否能对应版本、检查项是否过多、异常动作是否清晰。遇到流程阻塞时，先判断是规则必要但执行方式不合适，还是规则本身没有带来风险控制价值。

试运行期间，不要同时改变太多变量。若一周内又换工具、又改责任、又改准入门槛，结果很难解释。先稳定流程，再逐步调整承载工具和自动化方式。

4. 第四周：复盘数据，决定保留、修改还是扩展

复盘时至少比较准备耗时、证据关联情况、阻断发现时点、发布后追查成本和例外数量。不要只统计“按时发布率”，否则团队可能通过降低检查门槛来改善表面指标。把流程收益和维护成本放在一起讨论，确认哪些措施值得推广。

若试点有效，再分批扩展到相似业务；若没有改善，查找原因并调整。目标是让发布更可预测、更容易发现风险，而不是为了证明流程正确而要求成员适应不必要的复杂度。

十一、结尾：好的发布检查，让风险更早显形，让决定有据可查

我对发布检查的核心判断是：团队效率不取决于清单有多长，而取决于风险能否在仍有处置时间时被发现。统一发布对象，明确条件和证据，分清执行、复核与决策责任，再按风险配置检查深度，通常比临时增加审批更有效。

下一步可以从最近一次发布开始，选出一个最难追溯的问题：是范围不清、版本不一致、证据缺失、责任模糊，还是恢复方案未经验证？先针对这个断点改造一条检查项，并在下一次发布中验证它是否减少了追问或晚发现。有效的发布管理不是把每个人变成流程管理员，而是让每个人都知道自己应提供什么证据、何时提出风险，以及谁有权作出有依据的发布决定。