小型环境中的补丁管理

在企业级 IT 部门中，系统打补丁是一个复杂的流程，涉及大量与生产系统相互映射的测试系统，以便对从操作系统和软件供应商那里收到的每一个新补丁，都能在真实环境中进行测试，看看它们如何与组织中现有的各种硬件和软件组合相互作用。在理想的世界里，每个部门都会拥有一套受管理的补丁流程，能够对新发布的补丁立即做出响应、即时测试，并在补丁被认定为安全且适用后立刻部署。但世界并不理想，在现实生活中，我们不得不在有限的资源下将就：物力、时间和财力都是有限的。

补丁的发布通常出于几个关键原因：安全、稳定性、性能，以及偶尔为了提供新功能。除了新增功能（这通常通过另一套不同的发布流程来处理）之外，补丁代表的是对一个已知问题的修复。这不是一个“没坏就别修”的情形，而是一个“它已经坏了，只是还没有彻底失效”的情形，这种情形需要引起重视–越早越好。对补丁采取“坐等观望”的态度是不明智的，因为一个新补丁的存在意味着恶意黑客有了一个可供分析的“修复方案”，即便此前并不存在相应的漏洞利用手段，它很快也会出现。补丁本身的发布，可能正是立即需要部署该补丁的触发因素。

这套补丁生态系统催生了一种“快速打补丁”的思维。补丁绝不应该搁置，往往应在发布并经过测试后立即部署。拖延打补丁可能意味着系统带着严重的安全漏洞运行，或者让系统毫无必要地处于不可靠的状态。

小型 IT 部门很少（如果不是从不的话）拥有测试环境，无论是针对服务器、网络设备还是桌面机。这并不理想，但现实地说，即便那些环境是可用的，也很少有小型部门拥有富余的 IT 人力资源来及时地运行这些测试。

情况并不像听上去那么黯淡。针对大多数补丁所做的测试，与供应商已经测试过的内容是重复的。供应商不可能测试其产品可能遇到的每一种硬件和软件交互，但他们通常会测试大范围的组合排列，并重点关注最有可能发生交互的领域。一家大型供应商用糟糕的补丁把自己的软件搞瘫痪，这种情况是罕见的。是的，这种事确实会发生，因此拥有良好的备份和回滚方案很重要，但在日常运营中，打补丁是一个相对安全的流程，及时去做远比等待那些可能发生也可能不发生的状况要重要得多。

与任何系统变更一样，补丁最好以频繁、小剂量的方式部署。如果补丁得到及时部署，那么通常每次只需部署一个或少数几个补丁。对于操作系统，你可能仍然需要一次处理多个补丁，尤其是在只做每周一次打补丁的情况下，但以这种方式操作时，很少需要一次给数十个或数百个文件打补丁。这样做时，评估补丁是否带来不良影响、以及在打补丁过程出问题时进行回滚，都会容易得多。

对于缺乏适当补丁测试流程的小型企业而言，最糟糕的情形就是拖延打补丁。拖延意味着系统长时间得不到所需的维护，而当补丁最终被部署时，往往是以大批量、成堆的打补丁流程进行的。一次性部署许多补丁会增加出错的几率，而一旦出错，要识别出是哪个（哪些）补丁的问题、并找出补救的途径，可能会困难得多。

延迟打补丁这一做法对 IT 或企业几乎或根本没有任何好处，却给安全、稳定性和性能带来了重大风险。在小型环境中打补丁的最佳实践，要么是让系统尽可能快地自动打补丁，要么是安排一个固定的打补丁流程（也许是每周一次），选在企业最有准备应对打补丁失败、并处理补丁补救工作的时段进行。无论你选择自动打补丁，还是只是通过手动流程定期进行，都要做到经常且及时地打补丁，方能取得最佳效果。