1.3. できる限りコミュニケーションを持つ

1.3.1. これからの作業予定をユーザーに知らせる

必ずユーザーに十分な通告を与えてから作業を開始します。変更タイプ(必要とされるオペレーティングシステムをアップグレードするには、システムのログイン画面のデフォルトカラーを変更するより長いリードタイムが必要)の他にも、ユーザーコミュニティの性質(技術的に熟知したユーザーグループは、最低限の技術知識しかないユーザーに比べ迅速に変更に対応できる)などにより通告に必要な時間は変わってきます。

最低限、通告には次のような事項を入れてください。

• 変更の種類

• 施行日

• 目的

• 予定作業時間

• 変更によって予測される影響

• 問い合わせ先

仮に次のような状況だったとします。ファイナンス部門では時々データベースサーバが非常に遅くなることがあるとします。このため、サーバをダウンさせてCPUモジュールを高速モデルにアップグレードしてから再起動することにしました。これを行った後、データベース自体を高速の RAID ベースストレージに移動する予定です。つぎのような告知が考えられます。

システムのダウンタイムが金曜日の夜に予定されています。

開始は今週の金曜日、6:00pm (ベルリン支社の場合は深夜)です。約 4 時間、すべてのファイナンシャルアプリケーションが使用不能になります。

この間、ファイナンスのデータベースサーバ上にあるハードウェア及びソフトウェアに変更が加えられます。この変更により買掛金アプリケーション、売掛金アプリケーション、ウィークリーバランスシートレポートの実行にかかる時間が大幅に短縮されます。

ランタイムにおける変更以外は、ほとんど気づかない程度の変更です。ただし、自分のSQLクエリを記述している方はインデックスのレイアウトがいくらか変更されますのでご了承ください。これについては社内イントラネットのウェブサイト、ファイナンスのページに文書化されています。

ご意見、ご質問に関しては、内線4321、システム管理までお問い合わせください。

注意すべき点:

• 変更に伴い、可能性があるダウンタイムの開始時間と所要時間をはっきりと通知します。

• 所属場所に関係なく、必ずすべてのユーザーに判りやすいように変更時間を通知するようにします。

• ユーザーが理解できる用語を使います。この作業で影響を受ける人にとって、新しい CPU モジュールが L2 キャッシュの 2 倍の 2GHz ユニットであることやデータベースが RAID5 論理ボリュームに格納されることなどは関係ありません。

1.3.2. 何を作業しているかユーザーに知らせる

このステップは主に変更を行う直前の最終通告になります。例えば、最初のメッセージを要約したものでありながら、変更の実施が差し迫っていることを明瞭に伝えている必要があります("システムのアップグレードが実施されるのは『今夜』です。")。また、この最終通知の中に、最初に送ったメッセージに対する質問への回答を入れるとよいでしょう。

例えば、

システムのダウンタイムは今夜の予定です

メモ: 月曜日に通知されたシステムダウンタイムは予定通りに今夜の PM 6:00 に行われます(ベルリンオフィス時間では深夜)。オリジナルの通知は会社のイントラネットウェブサイト、システム管理ページで確認できます。

バックアップがダウンタイム前に確実に実行されるように、作業を早めに終了する必要があるかというお問い合わせを何件か受けております。今夜行われる作業は、個々のワークステーションで処理された作業には影響しませんので、早めに終了して頂く必要はありません。

自分のSQLクエリを記述している方はインデックスのレイアウトがいくらか変更されますのでご注意ください。これに関しては社内イントラネットのウェブサイト、ファイナンスのページに文書化されています。

ユーザーに、作業に対して準備が整っているかを警告しています。

1.3.3. 何の作業が完了したかをユーザーに知らせる

変更作業が完了したら、何が行われたかをユーザーに知らせなければなりません。この通知もまた前回のメッセージ(こうしたメッセージを読んでいない人が必ずいます)の概要となります。[1]

しかし、ひとつだけ付け加えなければならないことがあります。ユーザーに現在の状態を伝えることが非常に重要です。アップグレードが予定通りに円滑には行われなかった場合、新しいストレージサーバがエンジニアリング部門しか使用できずファイナンス部門では利用できなかった場合などは、ここで知らせる必要があります。

当然、現在の状況が以前に通知したものと異なる場合、この点を明らかにしてから最終解決策として何が行われる予定であるかを説明する必要があります。

先に仮定した状況では、ダウンタイムに問題がありました。新しい CPU モジュールが機能せず、システムのメーカーに問い合わせたところその分野のアップグレードには特殊バージョンのモジュールが必要であることが判明しました。プラス面では、RAID ボリュームへのデータベースのマイグレーションがうまく完了しました(CPUモジュールの問題があったため予定時間を少しオーバーしましたが)。

この場合の通知例です。

システムダウンタイムの完了

金曜日の夜に予定されたシステムのダウンタイムが完了しました(社内イントラネットのウェブサイトにあるシステム管理のページを参照)。残念ながら、ハードウェアの問題のため作業の1つが完了されませんでした。このため、その他の作業が当初に予定していた4時間を越えてしまいましたが、すべてのシステムが深夜(ベルリン支社では土曜日の6:00am)までに実稼働状況に戻りました。

ハードウェアに問題があるため、売掛金アプリケーション、買掛金アプリケーション、バランスシートレポートのパフォーマンスは若干改善されますが当初の予定ほどではありません。作業完了の障害となったハードウェアの問題が解決次第、次回ダウンタイムの予定を通知致します。

今回のダウンタイムによりインデックスが変更になっているデータベースがありますので注意してください。SQLクエリを記述した方は社内イントラネットのウェブサイトにあるファイナンスのページを参照してください。

お問い合わせは、内線4321、システム管理までお知らせください。

こうした内容から、ユーザーは個々の作業を続行しながら変更がどのように影響してくるのかを理解するために十分なバックグラウンド情報を得ます。