我在当前项目中维护 2 个环境，2 个服务器（1 个 Web 服务器和 1 个 SQL 服务器），用于生产和测试。上个月我们安装/升级到最新的 Microsoft 补丁/安全软件，Reporting Services 中的报告管理器在测试数据库服务器中停止工作。经过几天的故障排除，我发现 ISIS 中的 ASP.NET 2.0 Web 服务扩展已被完全删除，并且所有内容均已设置为禁止。
我不能肯定地说，但我认为这是由我几天前在该服务器上进行的修补/更新造成的。当安装修补程序时，可以做些什么来预测或防止对 SQL Server、Reporting Services、IIS、ASP.NET 的此类影响？
答案1
您应该继续保持尽可能接近生产环境的测试环境，并保存配置的最新文档。然后，当补丁加载发布时，继续在您的测试环境中测试它们。如果某些东西开始失效，则使用您当前记录的配置验证补丁更新后的配置，以查看是否有任何内容/内容发生了更改。然后，如果有必要，尝试再次通过补丁更新复制该更改，以将其确定为罪魁祸首。
至于如何预测和预防，这是一个很难掌握的问题。宁可偏执，也不要安装任何东西，除非你对它进行了充分的测试，并且确信它能像宣传的那样工作。大多数时候一切都会好起来的。确保你的配置得到充分支持，这样你就可以在某些东西崩溃的情况下打电话给支持人员。
当应用于生产时，始终要有一个经过测试的回滚计划，以便在出现问题时可以恢复到原始状态。（这是一个技术术语）
答案2
一种方法是评估补丁，而不是立即安装它们。我们有一组人专门审查微软和其他常见应用程序的补丁，评估漏洞的严重程度，并与应用程序所有者讨论风险等。
有些补丁被视为关键补丁，会在发布后 48 小时（或更短）内应用。去年秋天，我们在 RPC 漏洞发布后 30 分钟内就开始对其进行修补。对于其他漏洞，我们会等待长达 6 周的时间，具体取决于漏洞的严重程度、缓解漏洞利用风险的能力以及所需的测试工作量。
这样你就有时间让其他人受苦，并且避免应用补丁的初始版本。这不是一个完美的过程，对很多人来说可能有点太激烈了，但对我们来说是有效的。
答案3
（从 Linux 的角度看 - 但相当通用）
- 不要让操作系统自动安装补丁 - 只需下载并通知您即可。然后您可以手动安装它们，这样如果出现问题，您可以立即解决。
- 我配置了我所有的关键服务器在簇，这样就可以一次修补一个，然后重新启动而不会停机 - 如果出现问题，它可以为我买一些宽限时间来修复它，并为下一次做更好的计划。
- 我总是先将补丁应用到不太重要的服务器上，这样如果它破坏了一切，没有人会注意到:)
- 我们的环境是虚拟的，这使我们能够快照在对服务器执行任何操作（例如修补）之前，请检查服务器状态。也许等效的做法是在修补之前对主机进行完整备份。
- 制定回滚计划这将允许您回到系统进行任何更改之前的状态。