プロダクションモードで実行されている社内サーバーを考えると、定期的な更新を（ユーザーマシンではなくサーバー自体に）展開するとき、ユーザーへの影響をできるだけ少なくしたいと思いますが、これは非常に似た問題になります。
私の質問に対する明白な答えは、「ユーザーが家にいる夜」です。しかし、「夜」は長い期間です。夕方の早い時間に始めて、アップデートの問題を早期に発見し、ロールバックする準備を整える必要がありますか？または、早朝に開始し、最初のユーザーを「モルモット」として使用して問題をより早くトリガーする方が良いでしょうか？または、更新を監視するユーザーの集中度がかなり低い深夜に、一部の遅い作業ユーザーの開いているファイルハンドルがないことが保証されていますか？
このトピックに関する研究論文はありますか？
回答:
システムの同時使用状況を歴史的に調べて、1日のどの時間帯が最低かを判断してみませんか？次に、その低い使用期間の真ん中に変更を貼り付けます。
変更にかかる時間を検討するときは、実装前/実装後のテストと本番検証テストを含めます。さらに、テストが失敗した場合に変更がロールバックするのにかかる時間を計算します。
私のあなたの「最初のユーザー」はモルモットであってはなりません。ライブユーザーが基本的に本番検証テストを行って変更を行うことは良いことではありません。それはエンドユーザーの信頼を破壊し、予期しない結果が生産を台無しにする可能性があります。つまり、変更をロールバックする必要があるだけでなく、変更が引き起こした「ダメージ」もロールバックする必要があります。
研究論文は知りませんが、ITILなどのITサービス管理フレームワーク（ITSM）を見ると、ソフトウェアリリース管理に関する多くの標準とベストプラクティスが見つかります。すべてのシステムは異なるため、採用するプラクティスの数と形式は異なります。ITSM標準は大きなシステムを念頭に置いています。
これはビジネスの性質に完全に依存しています。一部のオフィスは、週5日9〜5日です。その他のビジネスは24時間年中無休です。スタッフやリソースの可用性などの他の要因が重要な役割を果たします。すべての可能なスケジュールや不測の事態を包括的にカバーできる研究論文はありません。
最終的には、IT管理と連携した企業または部門の管理は、何が最良かを決定する必要があります。
成功への鍵は、ダウンタイムの開始予定時刻、継続時間、ユーザーに必要な準備、および成功または失敗の結果として何が期待できるかをユーザーに伝えることです。その大部分は、設定した期待に応えることです。
結局、何も石にエッチングされません。プロセスが機能しない場合は、調整を行います。あなたの柔軟性と適応性は高く評価されます。
可能な場合は事前にテスト機器のメンテナンスと更新の手順を実行しておくと、本番システムに実装するときの準備がよくなります。
私はISPで働いており、経験上、システム管理者のヘビーヒッターは休日の週末の金曜の夜を選択して主要なネットワークのオーバーホールを行うと考えています。これにより、24時間余分にテストし、必要に応じて変更をロールバックできます。ただし、これは大部分がユーザーの性質と習慣に完全に依存しています。
私の場合、少し遅く作業しているユーザーでさえも影響を避けるために、午前4時にアップデートをインストールします。
問題が発生した場合に警告を発する優れた監視システムがあれば、仕事に行く前に、早朝にそれを修正できるはずです。
それは本当にあなたのビジネスの性質に依存しますが、私は個人的に水曜日の午後5時以降の夜を好みます。金曜日の夜に何かをしたいと思ったことはありません。何か問題が発生した場合、週末に作業することになるからです。水曜日にこれを行うと、木曜日と金曜日に問題があれば修正できます。
もう1つの重要な要素は、変更管理ウィンドウをスケジュールすることです。メンテナンスを実行していることを人々に知らせることは重要です。その間、サービスが中断したり、利用できなくなったりする可能性があります。これにより、ユーザーがサービスの停止について不満を言うのではなく、自信を持って作業できます。もちろん、経営陣は変更ウィンドウを承認する必要があります。