社内サーバーが本番モードで実行されている場合、定期的な更新を展開するときにユーザーへの影響をできるだけ少なくしたいと考えています (ユーザーのマシンではなくサーバー自体に...ただし、これはかなり似た問題になります)。
私の質問に対する明らかな答えは、「ユーザーが自宅にいる夜間」です。しかし、「夜間」というのは長い時間です。アップデートの問題を早期に発見し、ロールバックできるように、夕方早めに開始すべきでしょうか。それとも、問題をより早く引き起こすために、早朝に開始し、最初のユーザーを「モルモット」として使ったほうがよいでしょうか。あるいは、アップデートを監視する人の集中力はかなり低いが、遅くまで働いているユーザーのファイル ハンドルが開いていないことが保証されている真夜中に開始するほうがよいでしょうか。
このテーマに関する研究論文はありますか?
答え1
システムの同時使用状況を履歴で確認し、一日のうちで使用率が最も低い時間帯を特定してみませんか? 次に、その使用率が低い時間帯の真ん中に変更を加えます。
変更にかかる時間を計算する際には、実装前/実装後のテストと実稼働検証テストも考慮します。さらに、テストが失敗した場合に、変更をロールバックするのにかかる時間も計算します。
私の意見では、最初のユーザーをモルモットにすべきではありません。実際のユーザーに、基本的に本番環境の検証テストを行わせるのは良いことではありません。エンドユーザーの信頼を失わせ、予期しない結果によって本番環境が混乱する可能性があるため、変更をロールバックする必要があるだけでなく、変更によって生じた可能性のある「損害」もロールバックする必要があります。
研究論文は知りませんが、ITIL などの IT サービス管理フレームワーク (ITSM) を調べてみると、ソフトウェア リリース管理に関する標準とベスト プラクティスが多数見つかります。すべてのシステムは異なるため、採用するプラクティスの数の範囲と形式は異なります。ITSM 標準は大規模なシステムを念頭に置いています。
答え2
これはビジネスの性質によって完全に異なります。オフィスによっては、週 5 日、9 時から 5 時までのところもあります。また、1 日 24 時間、1 年 365 日のところもあります。スタッフやリソースの可用性などの他の要因も重要な役割を果たします。あり得るすべてのスケジュールや事態を包括的にカバーできる研究論文はありません。
最終的には、会社または部門の管理者が IT 管理者と協力して、何が最善かを決定する必要があります。
成功の鍵は、ダウンタイムの開始予定時刻、ダウンタイムの予想継続時間、ユーザーに求められる準備、成功または失敗の結果としてユーザーが何を期待できるかをユーザーに伝えることです。その大きな部分は、設定した期待に応えることです。
結局のところ、決まった方法などありません。プロセスがうまくいかない場合は調整してください。あなたの柔軟性と適応力は評価されるでしょう。
可能であれば、事前にテスト機器のメンテナンスと更新の手順を実行しておけば、実稼働システムに実装するときにより適切な準備ができます。
答え3
私は ISP で働いていますが、私の経験では、有能なシステム管理者とみなされる人のほとんどは、大規模なネットワークのオーバーホールを行うのに、休日の週末の金曜の夜を選んでいます。これにより、テストに 24 時間余分にかけ、必要に応じて変更をロールバックできます。ただし、これはユーザーの性質と習慣に大きく依存します。
答え4
私の場合、少し遅くまで働いているユーザーも含めて、すべてのユーザーに影響を与えないように、午前 4 時にアップデートをインストールします。
問題が発生した場合に警告する優れた監視システムがあれば、出勤前の早朝に問題を解決できるはずです。