考慮到內部伺服器在生產模式下運行，我希望在部署定期更新時對用戶的影響盡可能低（對伺服器本身，而不是用戶電腦......但這將是一個非常相似的問題）。
我的問題的明顯答案是“晚上，當用戶在家時”。但「夜」是一段很長的時間。是否應該在晚上早些時候開始，以便儘早發現更新問題並準備好回滾？還是一大早開始，把第一批用戶當作“小白鼠”，以更快地觸發問題？或者在半夜，當監督更新的人員的注意力相當低時，但保證沒有一些遲到的工作用戶打開的文件句柄？
有關於該主題的研究論文嗎？
答案1
為什麼不查看系統的歷史並發使用情況並確定一天中哪些時間使用率最低？然後將零錢放在低使用期間的中間。
在計算變更需要多長時間時，包括實施前/實施後測試和生產驗證測試。此外，還要計算如果任何測試失敗，則需要多長時間才能回滾變更。
恕我直言，你的「第一批使用者」不應該是白老鼠。讓即時用戶基本上進行生產驗證來測試您的更改並不是一件好事。它破壞了最終用戶的信心，並且意外的結果可能會擾亂生產，這意味著您不僅必須回滾更改，而且還要回滾更改可能造成的任何「損害」。
我不知道有什麼研究論文，但是看看任何 IT 服務管理框架 (ITSM)，例如 ITIL，您會發現很多關於軟體發布管理的標準和最佳實踐。所有系統都是不同的，因此您採用的實踐數量和形式取決於具體程度。 ITSM 標準考慮的是大型系統。
答案2
這完全取決於業務的性質。有些辦公室每週五天朝九晚五。其他業務為一年 365 天、每天 24 小時。人員和資源可用性等其他因素也發揮重要作用。沒有任何研究論文能夠全面涵蓋所有可能的時間表或不測事件。
最終，公司或部門的管理階層必須與 IT 管理階層一起確定什麼是最好的。
成功的關鍵是與用戶溝通停機時間預計何時開始、預計持續多長時間、用戶需要做什麼準備以及他們對成功或失敗的預期結果。其中很大一部分是滿足您設定的期望。
最終，沒有什麼是刻在石頭上的。如果該過程不起作用，則進行調整。您的靈活性和適應性將受到讚賞。
盡可能提前對測試設備執行維護和更新程序，您將在生產系統上實施這些程序時做好更好的準備。
答案3
我在 ISP 工作，根據我的經驗，大多數我認為是重量級系統管理員的人都會選擇週五晚上的假日週末進行主要的網路檢修。這給了他們額外的 24 小時來測試，並在必要時回滾他們的變更。然而，在很大程度上，這完全取決於使用者的性質和習慣。
答案4
就我而言，我們在凌晨 4 點安裝更新，以避免對任何用戶產生影響，即使是那些工作得晚一點的用戶。
如果您有一個良好的監控系統，可以在出現問題時向您發出警告，那麼您應該能夠在清晨上班之前修復它。