修补程序影响分析（2019 及更新版本）

修补设备时，很难知道修补程序会影响哪些文件和应用程序。 损坏修补对象或影响其他应用程序的修补程序，可能带来严重的问题。 如果您有一种简单的方法可以确定组织中的哪些设备会受到修补程序的影响，结果会如何？ 如果您可以基于一组修补程序对该组中设备造成影响的可能性，轻松地为这些修补程序创建最佳试点组，结果又会如何？ 借助 Endpoint Manager 和 Endpoint Security 2019.1 版本中引入的修补程序影响分析，这些操作您都可以执行。

修补程序影响分析依赖于客户端用户反馈代理（默认情况下禁用）。 此代理可实时监控修补程序所做的文件更改和删除。 此代理会检测应用程序崩溃并将数据报告至核心服务器。 而且还配备一个可选的客户端用户界面，支持用户手动报告应用程序崩溃。

修补程序影响分析需要一个学习周期，这有助于它更有效地发挥作用。 在尽可能多的设备上启用客户端用户反馈代理可以缩短学习周期。

最终用户必须运行在设备上进行修补的应用程序，以便通过此技术了解和确定应用程序和修补程序之间的依赖关系。 为了让影响分析算法做出更准确的预测，用户需要报告出现故障的应用程序，或者此技术需要自动检测由于修补程序而崩溃的应用程序。

  1. 单击工具 > 配置 > 代理配置 > 分发和修补程序。 双击现有配置，或右键单击并创建新的配置。
  2. 选择用户反馈页面，然后启用允许用户报告出现故障的应用程序。 如果要隐藏托管设备上的用户界面，也应选择该选项。
  3. 单击保存。
  4. 部署已更新的代理设置。
  1. 在工具 > 安全和遵从性 > 修补程序和遵从性中，选择要分析的修补程序。 您可以选择一个或多个修补程序。 右键单击选定的修补程序，然后单击修补程序影响分析。
  2. 在修补程序影响分析窗口中，添加要分析的设备。 此操作可通过选择目标类别并单击添加按钮来完成。
  3. 单击计算风险按钮。 计算过程可能需要一些时间。

  4. 风险计算完成后，最佳试点组选项卡会显示所选设备中最有可能受到修补程序影响的设备。 在其他因素中，影响是按照受影响的文件或应用程序是否存在来计算。 基于分析结果，每个设备都会显示计算出的风险系数。 本节的后文中会介绍这些风险系数。

  5. 双击设备可查看更多详细信息。

  6. 要查看所有受影响的应用程序的摘要，请单击面临风险的应用程序选项卡。 使用隐藏有 0 个机器需要修补的应用程序选项对列表进行筛选，以便只显示受影响的应用程序。
  7. 在最佳试点组选项卡中，单击建议试点组按钮可生成建议列入试点组的设备列表。 可以使用此试点组来测试选定的修补程序。 单击按钮后，按钮标签会更改为全部显示，而且您还可以切换视图。
  8. 选择想要列入试点组的设备，接着右键单击选中对象，然后再单击生成修复任务。
  9. 随即修补程序和遵从性修复任务对话框会打开。 其中包括所选的要修补的设备和要应用的修补程序。
  10. 运行修复任务并监控受影响的设备。 修补程序和遵从性目录树的出现故障的应用程序和报告的错误修补程序项目能够帮助您执行此操作。

修补程序影响分析会为所选设备分配风险系数。 通常来说，您应该先将测试工作集中在处于严重级别的风险系数上，然后再处理中高等级别的预期风险。

以下为风险系数级别：

  • 中等：选定的修补程序中至少有一个会对此应用程序产生直接影响，但用户反馈代理还未收集到任何关于所选修补程序损坏此应用程序的报告。 由于修补程序和应用程序之间存在直接依赖关系，建议在部署修补程序之前测试此应用程序。
  • 高等：出现一份崩溃报告，内容是关于受影响的应用程序或用户报告的修补程序不当行为，但该报告针对的是同一系列的其他修补程序。 例如，用户之前报告的是 Java 修补程序 JDK8-211_INTL 正在损坏应用程序 X，但是修补程序影响报告正在分析修补程序 JDK8-212_INTL（ 另外一个 Java 修补程序）对同一应用程序 X 的影响。 由于修补程序影响分析算法了解到之前的修补程序损坏了应用程序，因此强烈建议使用新的修补程序测试同一个应用程序。
  • 严重：修补程序影响分析算法已经确定，之前已针对受影响的应用程序提交过崩溃报告，报告方式可能为由用户反馈代理自动报告，或通过客户端用户反馈应用程序手动报告。 由于已报告过此应用程序的损坏是由修补程序造成，因此在修补之前需要对具有相同应用程序的其他设备进行测试，这一点很重要。
  • 未知：应用程序已在安装时按照清单进行过检测，但分析并未发现该应用程序与所选修补程序之间存在任何依赖关系。 这通常不会造成任何影响或造成的影响非常小。