鉴于内部服务器在生产模式下运行，我希望在部署定期更新时将对用户的影响尽可能降低（对服务器本身，而不是用户机器......但这是一个非常类似的问题）。
对我的问题，答案显然是“晚上，当用户在家时”。但“晚上”是一段很长的时间。是否应该在傍晚早些时候开始，以便尽早发现更新中的问题并准备回滚？还是最好在清晨开始，使用第一批用户作为“实验鼠”来更快地触发问题？还是在半夜，当监督更新的人注意力很低但可以保证没有一些晚班用户的打开文件句柄时？
有没有关于该主题的研究论文？
答案1
为什么不查看系统历史并发使用情况并确定一天中哪些时间使用率最低？然后将更改放在使用率最低的时间段的中间。
在计算变更需要多长时间时，包括实施前/后测试和生产验证测试。此外，计算如果任何测试失败，需要多长时间才能恢复变更。
我认为您的“第一批用户”不应该是实验对象。让现场用户对您的更改进行生产验证测试并不是一件好事。这会摧毁最终用户的信心，并且意外的结果可能会扰乱生产，这意味着您不仅必须回滚更改，而且还要回滚更改可能造成的任何“损害”。
我不知道有任何研究论文，但看看任何 IT 服务管理框架 (ITSM)，例如 ITIL，你会发现很多关于软件发布管理的标准和最佳实践。所有系统都是不同的，因此你采用的实践数量和形式取决于此。ITSM 标准考虑的是大系统。
答案2
这完全取决于业务性质。有些办公室每周 5 天从 9 点到 5 点上班。其他企业则是全年 365 天、每天 24 小时营业。员工和资源可用性等其他因素也发挥着重要作用。没有一篇研究论文可以全面涵盖所有可能的时间表或可能发生的情况。
最终，公司或部门的管理层需要与 IT 管理层协作来确定最佳方案。
成功的关键在于与用户沟通停机时间预计何时开始、预计持续多长时间、用户需要做哪些准备以及成功或失败后他们能期待什么。其中很大一部分是满足您设定的期望。
归根结底，没有什么是一成不变的。如果流程不奏效，那就做出调整。您的灵活性和适应性将受到赞赏。
通过尽可能提前对测试设备执行维护和更新程序，您将在生产系统上实施它们时做好更充分的准备。
答案3
我在一家 ISP 工作，根据我的经验，我认为大多数重要的系统管理员都会选择在节假日周末的周五晚上进行重大网络检修。这样他们就有额外的 24 小时进行测试，并在必要时回滚更改。然而，这在很大程度上完全取决于用户的性质和习惯。
答案4
就我而言，我们会在凌晨 4 点安装更新，以避免对任何用户产生影响，即使是那些工作到很晚的用户。
如果您有一个良好的监控系统，可以在出现问题时发出警告，那么您应该能够在早上甚至上班之前就修复它。