PR

 9月27日の記者の眼で,システム障害発生時の事後対策をテーマにした「システム障害が発生したらどう動く?」という記事を書いた。さらにそこで募集したアンケートの回答を参考に取材を重ね,日経SYSTEMS12月号で「システム・ダウン その時どうする」という特集記事を執筆した。今回は,アンケートの中で印象に残った回答や,その回答をヒントに進めた取材の結果を紹介したい。

 アンケートの中でもっとも印象に残ったのが,「システム障害が起こった想定で,原因特定や復旧作業を実施する“訓練”を行ったことがあるか」という質問に対し,「訓練を実施している」とした回答が多かったことである(回答19件中14件)。この質問は,「訓練は気づきが多かったため,有効だった」という過去の取材からひねり出した質問だったため,同じく事後対策に有効だと考えているITエンジニアが多いと確信を持った。記者は,アンケートの回答者に連絡を取り,訓練の内容を取材することにした。

避難訓練を実施して復旧作業に慣れる

 「何のために訓練をしていますか」。記者がこう質問すると,取材に応じてくれたITエンジニアからは,「障害復旧の作業に慣れていないと,被害が拡大する。しかし実際の障害を経験する機会は多くない。平常時に慣れるためには,原因特定作業や復旧作業を実際にやってみる“防災訓練”しかない」という回答がほとんどだった。さらに,訓練を通じて得られた気づきが,実際の障害復旧では生きるというものだった。ITエンジニアが実施した訓練の内容と,そこから得た気づきの例を紹介する。

ケース1 抜き打ちで訓練を実施

 製造業のA社はシステムの監視体制を強化し,24時間の監視体制にした。その際,従来は社員が監視していたが,協力会社のオペレータに監視を依頼することにした。障害発生時は,そのオペレータに障害内容の切り分けや,簡単な復旧作業を担当してもらうことになった。

 協力会社に作業を委託するため,作業手順書を作成した。そこには,障害の切り分け作業や復旧作業,A社担当者との確認フローなどを記述した。A社はその手順書がうまく機能することを確認するために,本番環境を使って防災訓練を実施することにした。オペレータの上司には伝えておいたが,オペレータには抜き打ちでの訓練だった。

 業務に影響が出ないよう,午前3時に訓練を開始した。A社の担当者が障害に気づいたことにして,オペレータに,「サーバーで障害が発生している。手順書通りにサーバーを停止してほしい」と電話をした。作業は問題なく進んだが,かかった時間は予想より長かった。その原因を調べると,まず,停止作業に入る前の確認作業に時間がかかっていることが分かった。手順書には,「停止の指示が本当にA社の担当者からの連絡なのかどうかを確かめる」とある。そのために「指定の番号に電話をかけて事実を確認する」としていた。

 その連絡先はサーバー停止の指示を出した電話の番号であることから,A社の担当者はすぐに折り返し電話があると思っていた。だが,タイムラグがあった。オペレータはA社担当者の連絡先に間違いがないように,念のため別のオペレータに確認していた。その分時間がかかった。

 また,サーバーを停止するスクリプトの実行にも時間がかかっていた。A社の担当者は5台分のターミナル・ソフトを起動させ,並行でスクリプトを実行すると考えていた。しかしオペレータは,1台ずつ停止を確認してから,次のサーバーを停止していたので時間がかかっていた。

ケース2 作業手順書の漏れが見つかる

 商社B社では大規模なシステム障害に備え,業務パッケージ・ソフトの再インストール作業を防災訓練として実施した。目的は,作業手順書の記述漏れや分かりにくい部分を見つけ出すことだった。

 防災訓練では,意外な穴が明らかになった。バックアップ用サーバーに業務パッケージ・ソフトをインストールし,使えるようにするための「ライセンス・キー」を入力したところ,そのキーは無効だと表示された。そのライセンス・キーは本番サーバー用にインストールしているソフトのキーで,メーカーに連絡していったん本番用キーの無効化の手続きを取らないとバックアップ用のソフトは有効にならなかった。手順書には漏れていた項目だった。防災訓練は,メーカーにテスト用のライセンス・キーを一時的に借りて続行した。

 また,参考になるだろうと,作業手順書にシステム構成の概略を示すネットワーク構成図などを付けていた。だが,そうした資料は訓練で有効に使えるケースがなかっただけでなく,逆に必要な情報が探しにくくなるということが分かった。

ケース3 電源が入らない

 サービス業C社が訓練で体験したのは,本番系から待機系にサーバーを切り替え,さらに復旧後本番系に切り戻した際のことだ。本番系のサーバーを再起動したあと,通信のためにサーバーに接続しているターミナル・アダプタの電源を投入した。すると,サーバーの管理画面には新しいデバイスを認識したことと,デバイス・ドライバのインストールを要求するメッセージが表示されたのだ。担当者は,「すぐに通信が再開すると考えていた。意外だった。本当に障害が起きていたら焦っていたと思う」という感想を抱いた。

やはり障害を想定した対策が必要

 取材からは,システム障害の被害を最小限にするためには,やはり事後対策が必須であることが分かった。さらにその対策を年に数回実行してみると対策の漏れや抜けが判明し,有効に機能することも分かった。システム障害がなくなることはないと思うが,これからも読者の皆様が早く障害復旧するためのこうしたノウハウを取材し,ITPro上や日経SYSTEMSの誌面で紹介していきたいと考えている。