在内部生产服务器上安排定期更新的最佳时间是什么时候？

Question

鉴于在生产模式下运行的内部服务器，我希望在部署定期更新时对用户的影响尽可能低（到服务器本身，而不是用户机器......但这将是一个非常相似的问题）。

我的问题的明显答案是“晚上，当用户在家时”。但“夜”是一段很长的时间。是否应该在晚上早些时候开始，以便尽早发现更新的问题并准备回滚？还是一早开始，把第一批用户当“小白鼠”来更快地触发问题更好？或者在半夜监督更新的人的注意力非常低，但保证某些迟到的工作用户没有打开的文件句柄？

有没有关于这个主题的研究论文？

Answer 1

这完全取决于业务的性质。有些办公室每周工作五天，朝九晚五。其他业务是一年 365 天，一天 24 小时。其他因素，例如人员和资源可用性，也发挥着重要作用。没有研究论文可以全面涵盖所有可能的时间表或可能性。

最终，公司或部门的管理人员必须与 IT 管理人员一起确定什么是最好的。

成功的关键是与用户沟通计划何时开始停机、预计持续多长时间、用户需要做的任何准备以及他们对成功或失败的预期结果。其中很大一部分是满足您设定的期望。

最后，没有什么是刻在石头上的。如果该过程不起作用，则进行调整。您的灵活性和适应性将不​​胜感激。

通过在可能的情况下事先对测试设备执行维护和更新程序，您将在需要在生产系统上实施它们时做好更好的准备。

Answer 2

为什么不从历史上查看系统的并发使用情况并确定一天中使用率最低的时间？然后在那个低使用期的中间坚持你的变化。

在确定变更需要多长时间时，包括实施前/实施后测试和生产验证测试。此外，计算出如果任何测试失败，更改需要多长时间才能回滚。

恕我直言，你的“第一批用户”不应该是豚鼠。让实时用户基本上进行生产验证测试您的更改并不是一件好事。它破坏了最终用户的信心，意外的结果可能会扰乱生产，这意味着您不仅必须回滚更改，还必须回滚更改可能造成的任何“损害”。

我不知道任何研究论文，但看看任何 IT 服务管理框架 (ITSM)，例如 ITIL，您会发现许多关于软件发布管理的标准和最佳实践。所有系统都不同，因此您采用的实践的程度和形式取决于。ITSM 标准考虑了大系统。