预测/防止数据库/ Web服务器上的修补程序或升级问题

您应该继续保持一个模拟您的生产环境的testing环境，并保持最新的configuration文档。 然后，当发布补丁程序时，请继续在testing环境中对其进行testing。 如果有事情开始死亡，那么使用当前logging的configurationvalidation修补程序更新后的configuration，以查看是否有任何/更改。 然后尝试通过补丁更新再次复制该更改，如果有必要将其指定为罪魁祸首。

就预防和预防他们而言，这是一个难以应付的问题。 在偏执狂的一面犯错，不要在生产中安装任何东西，直到你已经完全testing它，并且很舒服，它是按照广告的方式工作的。 大部分时间都会好起来的。 确保完全支持您的configuration，以便在发生炸弹的情况下调用支持。

应用于生产时，总是要有一个经过testing的回滚计划，以便在出现问题时能够恢复到原始状态。 （这是一个技术术语）

一种方法是评估补丁，不要马上安装。 我们有一组专门审查微软和其他常见应用程序的补丁的人，评估漏洞的严重程度，并与应用程序所有者讨论风险等。

一些补丁被认为是关键的，并在48小时内（或更less）发布。 我们在去年秋天发布的30分钟内开始修补RPC漏洞。 其他我们将根据严重程度，减轻开发风险的能力以及所需的testing工作等待6周。

这样你就有时间让其他人被烧毁，而且你可以避免使用补丁的最初版本。 这不是一个完美的过程，对许多人来说可能有点激烈，但对我们来说却是有效的。

（从linux的angular度来看 – 但很通用）

1. 不要让操作系统自动安装补丁 – 只需下载并通知您。 然后，您可以手动安装它们，如果出现问题，您可以马上解决
2. 我将所有重要的服务器都configuration成集群 ，这样他们可以一次一个补丁，并在没有任何停机时间的情况下重新启动 – 如果出现问题，它会给我一些宽限期来修复它，并为下一个更好地计划。
3. 我总是先把补丁应用到一个不太重要的服务器上，这样如果它破坏了一切，没有人会注意到:)
4. 我们的环境是虚拟的 ，这使得我们可以在做任何事情之前快照服务器状态（比如修补）。 也许相当于在修补之前对主机进行完整备份。
5. 有一个回滚计划 ，使您可以在进行任何更改之前回到系统所在的状态。