由于内部服务器运行在生产模式下，我希望在部署定期更新（对服务器本身，而不是用户机器，但这将是一个非常类似的问题）时尽可能降低对用户的影响。
我的问题明显的答案是“在晚上，当用户在家里”。 但“夜”是一段很长的时间。 是否应该在早上开始早些时候或许能够及时发现更新问题并准备好回滚？ 还是一早起床比较好，把第一批用户当作“豚鼠”来加快引发问题呢？ 或者在半夜监督更新的人数相当less的时候，但是保证没有一些迟到的工作用户的开放文件句柄？
有没有关于这个话题的研究论文？
为什么不从历史的angular度来看待系统的并发使用情况，并确定一天中的使用情况是最低的？ 然后在这个低使用期的过程中坚持你的改变。
在确定更改将花费多长时间时，包括前/后实施testing和生产validationtesting。 另外，如果有任何testing失败，那么计算一下这个变化需要多长时间才能回滚。
恕我直言，你的“第一用户”不应该是试验品。 有活的用户基本上是生产validationtesting你的改变不是一件好事。 它破坏了最终用户的信心和意想不到的结果可能会使生产陷入困境，这意味着您不仅必须回滚这一变化，而且还要回滚可能造成的任何“损害”。
我不知道任何研究论文，但是看看任何IT服务pipe理框架（ITSM），比如ITIL，你会发现很多关于软件发布pipe理的标准和最佳实践。 所有的制度都是不同的，所以你采用的做法有多less，forms如何。 ITSM标准有很大的系统。
这完全取决于企业的性质。 一些办公室一周五天九天到五天。 其他业务一年365天，一天24小时。 其他因素如员工和资源的可用性也起着重要的作用。 没有研究报告可以全面涵盖每个可能的时间表或可能性。
最终，与ITpipe理层协调一致的公司或部门的pipe理层必须确定什么是最好的。
成功的关键是在计划开始停机时间，预计持续多长时间，为用户进行任何准备以及成功或失败所能预期的情况下与用户进行交stream。 其中很大一部分是满足您设定的期望。
最后，没有什么是刻在石头上的。 如果该过程不起作用，则进行调整。 您的灵活性和适应性将不胜感激。
在可能的情况下，事先对testing设备执行维护和更新程序，在生产系统上实施时，您将做好充分的准备。
我在一家ISP工作，根据我的经验，我认为大多数人都会select重度打击的系统pipe理员，他们select周五晚上在假期周末进行主要的networking大修。 这给了他们额外的24小时testing，并在必要的时候回滚他们的变化。 但是，在很大程度上，这完全取决于用户的性质和习惯。
我们在晚上9点安装更新，大部分人都迟到了，如果有必要的话，可以提早一点。
就我而言，我们在凌晨4点安装更新，以避免对任何用户造成影响，即使是那些工作稍晚的用户也是如此。
如果你有一个好的监控系统，在出现问题时提醒你，你应该可以在早上甚至上class之前解决问题。
这真的取决于你的业务的性质，但我个人喜欢星期三晚上5点以后。 你永远不想在周五晚上这样做，因为如果出现问题，你会在周末工作。 星期三这样做会给你星期四和星期五解决问题，如果有的话。
另一个重要的因素是安排变更pipe理窗口。 让人们知道您正在进行维护是至关重要的 – 在此期间，服务可能会中断或无法使用。 它可以让你自信地工作，而不必担心用户会抱怨服务中断。 当然，您的pipe理层需要批准更改窗口。