Answers:
为什么不从历史上查看系统的并发使用率并确定一天中的最低使用率？然后在您的低使用期中间保留您的更改。
确定变更需要多长时间时，包括实施前/实施后测试和生产验证测试。此外，计算出如果任何测试失败，更改将回退多长时间。
恕我直言，您的“第一用户”不应该是豚鼠。让实时用户基本上进行生产验证来测试您的更改不是一件好事。它破坏了最终用户的信心，意外的结果会破坏生产，这不仅意味着您必须回滚更改，而且还回滚更改可能引起的任何“损害”。
我不了解任何研究论文，但是看看任何IT服务管理框架（ITSM）（例如ITIL），您会发现许多有关软件版本管理的标准和最佳实践。所有系统都是不同的，因此您采用多少种实践的程度以及形式都取决于。ITSM标准考虑了大型系统。
这完全取决于业务的性质。有些办公室每周5天9-5。其他业务是一年365天，一天24小时不间断。人员和资源可用性等其他因素也起着重要作用。没有任何研究论文能够全面涵盖所有可能的时间表或偶然事件。
最终，公司或部门的管理层必须与IT管理部门共同确定最佳方案。
成功的关键是在预定的停机时间开始，与预期的持续时间，用户需要的任何准备以及他们对成功或失败的期望方面与用户进行沟通。其中很大一部分是达到您设定的期望。
最后，什么都没有刻在石头上。如果该过程不起作用，请进行调整。您的灵活性和适应性将不胜感激。
通过在可能的情况下预先对测试设备执行维护和更新程序，可以在准备将其在生产系统上实施时为您做好准备。
我在ISP工作，根据我的经验，我认为大多数人都是沉重的系统管理员，他们选择在假日周末的星期五晚上进行主要的网络检修。这给了他们额外的24小时测试时间，并在必要时回滚他们的更改。但是，在很大程度上，这完全取决于用户的性质和习惯。
就我而言，我们会在凌晨4点安装更新程序，以避免对任何用户产生影响，即使是工作稍晚的用户也是如此。
如果您有一个良好的监视系统，如果出现问题可以向您发出警告，则您应该能够在清晨甚至上班之前对其进行修复。