ネットワーク接続障害とリモートワーク

リモートワーク
記事内に広告が含まれています。

 先週、予想だにしていなかったネットワーク接続障害が、突如発生しました。
 余りにも想定外の出来事だっただけに、この経緯と対応について、触れていきたいと思います。
 結論から先に述べさせていただくと、なんとか復旧できたのですが、リモートワークを行う上で、最大の弱点を曝け出したと同時に、色々な教訓を与えてくれた出来事となりました。その状況について、下記に記載させて頂きます。

障害発生時の状況

初期段階の対応及び原因究明に向けた手探り

 障害発生当日、勤務開始時は、いつも通り、なんの問題もなくリモートワークを開始しました。そして、11時過ぎから、担当者とTeamsビデオ通話で確認作業をしていたところ、突然、12時前にTeams通話が切断されました。
 ただ、要件も終了し、雑談コーナー気味であった為、昼食後、通話切断時の状況が気になっていたので、作業部屋へ戻りパソコン画面を確認すると、Wi-Fi接続表示が未接続表示のマークに変わっていました。これは何か変だぞと気になりだし、他の通信機器(スマホ、タブレット)の接続状況を調べる事にしました。すると、他の機器は問題なく接続されていたので、これは、パソコン側の問題ではと思い始め、再起動を試みたのですが接続は回復せず、この状況では、午後からの仕事に支障をきたすと思い、通話切断時の社員にスマホで連絡をとり、状況確認をしました。すると、私と同様の状況である事が判明し、やっと、自分だけの問題ではない事が明らかになって来ました。
 そこで、直部下の他の社員へスマホで状況を確認すると、皆同様の事態に陥っていました
 さらに、他の担当課長へ確認すると、そちらも社員から同様の申告が上がっており、どうも全社的障害が発生しているようだとの話も出だしました。

障害の事実確認、原因の究明及び影響の把握

 上記のような断片的な確認では限界になってきたので、貸与されているiPadを使い、部全体の状況把握を開始すると同時に、当日、出社している社員に、何か情報が届いていないか、確認を取る事にしました。すると、社内ホームページに、11時頃からリモートワーク用PCのネット接続に障害が発生しているとの情報が掲載されている事が判明し、その事実を速やかに全体チャットで周知しました。
 結果、私の部では、1名を除き、全て障害に巻き込まれていました。すなわち、復旧するまで、リモートワークが不可能になった事が判明したわけです。
 そこで急遽、課長打ち合わせを召集しTeams会議を行い、本日の作業内容の確認かつ、会社の社内LAN環境は利用可能であることも判明したので、課長には復旧が完了するまで出社勤務を依頼し、緊急作業対応可能な状態にしました。また、担当者に対しても、作業が残っている場合は、復旧するまでの間、出社対応を依頼しました。
 ただ、障害の原因が「セキュリティーアップデート時の作業ミス」と判明したものの、リモートワーク用PCの復旧作業内容が検討中との掲載があった為、私は、引き続き自宅で状況の把握に努めました。
 私の場合、プライベートPCでVPN接続が可能にしているので、そちらのパソコンから、会社のネットワークへ接続し、復旧に向けた情報を把握しながら、部内の人達へ情報提供をしていました。

リモートワーク用PCの復旧に向けた対応

 障害発生日の夕刻、復旧に向けた対応方法が復旧専用チャットに示されるようになり、翌日、復旧作業マニュアルを提示するとの連絡が掲載されたため、パソコン操作に自信がある人は、在宅勤務で復旧作業をし、自信がない人は、会社へリモートワーク用PCを持参し、復旧作業をするよう指示を出し、当日の作業を終了しました。

初期化による復旧対応

 障害発生翌日、復旧専用チャットに初期化復旧マニュアルが掲載されており、そのマニュアルを共有フォルダーへ格納し、全体チャットでその旨を周知しました。
 その後、私が先に復旧作業をしてから状況を報告しようと思い、復旧作業に入りました。すると、いきなりマニュアルに無い画面が出るなど、復旧難易度が高い事が判明した為、急いで、部内へ復旧作業は難易度が高いので、私の作業が完了するまで、控えるようにとの連絡を行い、一つ一つ問題をクリアしながら、2時間程度の時間を要し復旧初期化作業を完了させました。私の感想では、これは、難易度が高過ぎ、失敗する人が多発すると思い、別の復旧作業が示されるまで、復旧をしないよう部内周知しました。要は、障害発生翌日も復旧作業は中止って事になります。
 私の方は、初期化で何も無い状態に戻ってしまったので、障害前に使用していた状態に戻すための第二弾復旧作業を行い、丸一日がかりで、幸いにも元の状態に戻すことができました。

データ引継ぎによる復旧対応

 私が初期化復旧を行なっている日の夕刻、復旧専用チャットでは、データ引継ぎ可能な復旧方法が判明したため、そのマニュアルを作成中で、翌日、掲載する予定になるとのコメントが掲載されていました。
 そこで、データ引継ぎによる復旧を選択した方が得策であると考え、その方法で復旧作業を行なってもらうよう、部内周知を行いました。
 その当日、専用チャットを確認すると、システム担当がTeams会議を4回開催し、復旧作業を支援するとの書き込みがあったため、データ引継ぎ復旧マニュアルのフォルダー格納と合わせ部内周知を行い、その会議へ参加し復旧作業を行なってもらう事にしました。その会議で使用される復旧マニュアルを見ると、初期化マニュアルより、一定のITスキルがあれば、簡単に復旧できる内容となっていました。先に初期化復旧した身からすれば、とほほ・・・。です。
 データ引継ぎ復旧の当日、私の部では、順次Teams会議へ参加し、システム担当の手厚いサポートを受けながら、全員無事、リモートワーク用PCの復旧に成功しました。
 これで、突然訪れた災いから、解放された事になります。でも、色々と課題を突きつけられた出来事となりました

教訓(まとめ)

 今回のネットワーク接続障害は、リモートワークにどっぷり浸かっていた私達にとって晴天の霹靂となりました。このような事象を全く想定していなかった為、フリーズ状態になり、どう対応すれば良いかわからない状態に陥りました。その事が、大きな反省点です。
 答えは簡単で、リモートワークが不可能になれば、出社勤務に切り替えれば良いだけなのです。でも、一旦、リモートワークが当たり前になってしまうと、それが瞬時に頭に浮かばない思考回路になっていたのです。この変貌ぶりには、驚きました。
 今回は、幸いにも短期間で復旧できた為、事なきを得ましたが、同じような事象が長期間発生した場合を想像すると、ゾッとします。
 なので、今回の事象を踏まえ、障害発生時の対応ルールを作成する事にしました。
 ルールは、「障害発生時は、速やかに出社勤務へ切り替える。」です。

 あと、リモートワークには、一定水準以上のITスキルが必要だという事を、再認識しました。

タイトルとURLをコピーしました