ITエンジニアが最も出会いたくない出来事。一つはシステム開発プロジェクトにおける遅延。もう一つはシステム障害だ。特に緊急対応を迫られるのがシステム障害だろう。ひとたび障害が発生すれば，夜中であろうが早朝であろうが，原因の特定や復旧作業にあたらなければならない。障害によるシステム停止が長引けば，ビジネスにも大きな影響を与えることになる。

　システム障害を回避するために，システムには「サーバーの2重化」「ネットワークの2重化」といった冗長構成をとることが多い。1台の機器が故障しても，もう1台の機器が処理を引き継いで，サービスを継続できるからだ。こうした対策は，1台の機器が故障してもシステムが完全に停止しないように予防しておく対策だと言える。

　予防策を施しておけば，システム障害の発生確率は間違いなく低くなる。しかし，問題なのはこの確率を完全にゼロにすることはできないことだ。例えば，ソフトウエアのバグによる不具合であれば，機器を2重化していても，同じソフトだと両方の機器で同じ不具合が発生する。2004年に発生した東京航空交通管制部の航空管制システム障害がこれにあたる。そのほか，ANAのシステム障害や，toto販売システムの障害からも分かるように，予防策を施していても，想定外のことが起きるのでシステム障害に発展してしまう。

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

　システム障害を完全に回避することはできない。とはいえ，障害が発生したシステムを担当するITエンジニアの職場は凄惨を極める。障害の原因がなかなか分からず混乱している中，社内ユーザーから猛烈なクレームの嵐が来る。停止時間が長引けば長引くほど，ビジネスの大きな機会損失になる。大きなプレッシャーの中，徹夜も辞さずといった体制で復旧することが求められる。

　ならば，「システム障害は起きる」という前提で，障害発生後を見据えた対策が必要になる。例えば，システム障害の原因を調べるためにシステム全体の状況を把握する必要があるが，その方法をあらかじめ決めておくといったものだ。さらに原因を判明しやすくするための工夫をシステムに盛り込んでおく，情報を収集する人と収集した情報に基づいて判断する人をあらかじめ決めておくといったことも必須になるだろう。

　あるデータセンターでは，障害の原因判明にはシステムのログが必須だと考えて，障害発生時は詳細なログをコマンドで取ることを手順として決めていた。しかし，担当者のスキルによって取得するログの内容にばらつきがあった。そのため，障害原因の分析に必要なログが取得できておらず，原因究明に時間がかかったという。そこで，必要なログを取得するコマンドを含んだスクリプトを作成し，どの担当者でもそのスクリプトを実行することで十分なログを取得できるようにした。

　あるECサイトを運営する企業では，実際に障害が発生した際に，あらかじめ決めていた復旧手順があったにもかかわらず，復旧に手間取ってしまった。その反省を生かして半年に1回，システム障害が発生した前提で実際に復旧作業を実施する“防災訓練”を実施することにしている。その企業の担当者いわく，緊急になればなるほど，人間は思ったように動けないので，何度も防災訓練しておくことが重要だという。

　今後，システム障害は増えることはあっても急激に減ることはないだろう。そこで考えたことは，上に挙げたような事後対策の工夫を取材し，読者の皆様と共有することだ。システム障害が起きることを前提とした工夫の例を，ぜひ記者に紹介してもらえないだろうか。そのために「システム障害の事後対策に関するアンケート」のページを開設しているので，ご協力いただければ幸いである。結果は，ITproサイトや日経SYSTEMS誌上で紹介したいと考えている。