考虑到内部服务器在生产模式下运行,我希望在部署定期更新(对服务器本身,而不是用户机器)时,尽可能降低对用户的影响。但这将是一个相当类似的问题)。
对于我的问题,最明显的答案是“晚上,当用户在家”。但是“夜”是一段很长的时间。一个人是否应该在晚上早些时候开始,以便尽早发现更新中的问题,并准备回滚?还是早早开始使用第一批用户作为“小白鼠”来更快地引发问题是否更好?还是在半夜,当负责更新的人的集中度很低,但是保证没有一些晚工作用户打开的文件处理时呢?
有关于这个题目的研究论文吗?
发布于 2010-05-31 16:12:38
为什么不回顾一下您的系统的并发使用情况&确定一天中的最低使用率是什么时候?然后把你的零钱放在那个低使用率的中间。
当计算更改将花费多长时间时,包括实现前/后的测试和生产验证测试。此外,如果任何测试失败,则确定回滚更改所需的时间。
你的“第一用户”不应该是小白鼠。拥有活跃的用户--基本上是生产验证测试--您的更改不是一件好事。它破坏了最终用户的信心&意想不到的结果可能会使生产陷入混乱,这意味着你不仅要回过头来改变,而且还要回退变化可能造成的任何‘损害’。
我不知道任何研究论文,但是看看任何IT服务管理框架(ITSM),比如ITIL,您会发现很多关于软件发布管理的标准和最佳实践。所有的系统都是不同的,所以您所采用的实践的范围和形式取决于。ITSM标准有很大的系统。
发布于 2010-05-31 15:47:33
这完全取决于企业的性质。有些办公室每周五天9至5天。其他企业每天24小时,一年365天。工作人员和资源供应等其他因素发挥了重要作用。没有一篇研究论文能够全面涵盖每一个可能的时间表或可能发生的情况。
最终,公司或部门的管理和IT管理必须决定什么是最好的。
成功的关键是在预定的停机时间开始时与用户沟通,预期持续多长时间,用户需要做的任何准备,以及他们因成功或失败所能预期的结果。其中很大一部分是满足你设定的期望。
最后,没有任何东西被刻在石头上。如果流程不起作用,那么就进行调整。我们将感谢您的灵活性和适应能力。
通过在可能的情况下对测试设备执行维护和更新过程,在生产系统上实现这些程序时,您将做好更好的准备。
发布于 2010-05-31 17:31:33
我在一家ISP公司工作,根据我的经验,我认为重量级的系统管理员会选择周五晚上的假日周末来进行他们的主要网络检修。这给了他们额外的24小时的测试时间,如果有必要的话,可以回滚他们的更改。然而,这在很大程度上完全取决于用户的性质和习惯。
https://serverfault.com/questions/146872
复制相似问题