先の東日本大震災については、数多くの被災者に向ける適切な言葉も見つからず、一刻も早い復旧を叶えるために、ただ自分の立場で出来ることを探し続けるのみの日々です。多くの犠牲を無駄にしないためにも、素直な視点で起きた事実を捉え、復旧のために出来ることから着手し、また今後に備えていきたいと考えています。

震災の後、様々なメディアで「数百年に1度の」とか「未曾有の」、「想定外」といった言葉が数多く聞かれました。これらの言葉は、単に惨事の大きさを伝える場合にも使われましたし、「ある程度はリスクに備えていたのだが」という言い訳の様な意味合いでも使われていたと感じています。確かに、この度のような震災は予想だにできないものですが、起きたことは事実として認め、今後の振舞いを真摯に考えなければならないと考えます。そこで今回は「コンピューターシステムにおいて、災害に備えて何をしておくべきか？」という話題を取り上げてみます。

一般に、災害や障害に備えたコンピューターシステムを考える場合、RAS（Reliability ： 信頼性、Availability ： 可用性、Serviceability ： 保守性）やRASIS（RASに加え、Integrity ： 保全性、Security ： 安全性）の観点で評価が行われます。この中で直接的に震災に結びつく話をすれば、信頼性、可用性、保守性の3つの検討が中心になりますが、それぞれは「故障や性能劣化を起こさない能力」が信頼性、「システムが稼動を継続できる能力」が可用性、「障害時の復旧能力」が保守性と理解すれば良いかと思います。

さて、システムを検討する上で特徴的なことは、「台風（強風や豪雨）と地震などの2種以上の災害が同時に発生する二重災害は考慮しない」という原則（検討上のルール）があることが挙げられます。これはそもそも、「多様な災害に同時に耐えうる万能なシステムを構築するには膨大な投資が必要になる。これを考えることは（IT投資の面で）非現実的である。」という考え方に基づいています。しかし、先の震災では「地震」「水害（津波）」「汚染（放射能漏れ）」という災難が立て続けに起きましたし、福島第一原発自体が、フェイルセーフの為に用意されていた非常用ディーゼル発電機が浸水のために機能しなかったという問題が指摘されました。つまり「現実の災害においては、二重災害は起きるものだ」ということが証明されている訳です。
そのため、現実論として言えることは、「過去の災害や事故に学び、単一の災害か二重災害かは関係なく、起こると想定しうる事象に対しては、備えを持つべきである」といったことかと思います。

では、ニュートラルに考えた場合、どのような事象の発生が想定されるのでしょうか。

図1は、災害で発生することが予想される様々な事象を表現しています。自然災害を発端に考えると、大雨などの水の害、風の害、揺れなどがあり、それを発端に火事や停電などが発生します。こういった状況が人・モノの動きを止め、連絡手段を断ちます。これらの事象に対して一つでも、少しでも備えることが、コンピューターシステムのRAS向上の意義と考えます。

それでは、現実的な対策から紹介してみます。

1. 先ずは、情報資産を保護する

取り急ぎ行うべきことは、データのバックアップです。ハードディスク装置を二重化しているとか、RAID構成にしている、と言っても過度に揺れたり、水を被るようなことがあると、全てのデータは失われてしまいます。安全で確実な方法は、データを外部の記憶媒体に退避し、その媒体を物理的に安全な場所に保管しておくことです（図2参照）。

また、データの退避時に考慮すべきことは、それが確実に復元・復旧できる方法かどうかを確認するという点です。大規模な災害では、建屋が倒壊し、システム全体が失われる場合もあるので、それらの場合も含めてデータの復旧／システム全体の復旧についても、備えておくべきでしょう。

2. 弱みを見つける

企業のコンピューターシステムはほとんどの場合、それぞれの機器毎に導入時期にばらつきがあり、冗長性や運用、耐用期間も種々雑多な状況です。自社のシステム／ネットワークの構成についてまとめた資料を用意し、システム関係者で「大きな災害が来た場合には、何が起きるか？」を議論して、「弱みは何か？」を見つけることが肝要です。必ずしも、全ての災害ケースを抽出する必要はなく、想定できる範囲での情報整理であったとしても、その意義はあります。

現実には、災害の大小に応じて、部分的な電力の供給停止や一部機器の破損となる場合もありますし、浸水や（対策がされていない場合）落雷のようなものでも、ネットワークが丸ごとダメになる場合も想定されます。シミュレーションできる範囲で、ボトルネックやアキレス腱となる部分を探り、明確にすることで、実際の災害が起きた場合も落ち着いて対応がとれるようになります。検討した結果は、図3のように影響度や対策も含めて、まとめられると良いでしょう。

3. 対策を練る、対策を講じる

明確になった弱みについては、対策を具体化します。対策は、災害に対する直接的な対抗策であるハードウェアの増強の場合もあるでしょうし、設置場所や環境を変えるという物理的な条件を変えることによる手段による場合もあります。項1で提案したバックアップを利用しての「被災後に早期復旧できることが対策である」というものもあるでしょう。

例を挙げてみます。ファイヤーウォールやプロキシーサーバ、DNS、ルーターといったネットワーク関連のシステムや通信機器が停止すると、外部と遮断されて業務が回らなくなるという話であれば、その冗長化（二重化）を考えるべきでしょうし、それがかなわないならば別のネットワークを敷設することが必要かもしれません。可能であれば、非常時のシステム構成における業務運用も検討して、「いざ」という場合に備えることが必要です。

BOM（部品表システム）やPDM（製品データ管理システム）など、データベースとなる中核のサーバについては、少なくとも無停電々源装置（停電時に電源供給する機器）の利用や、停止時の業務運用を明確にしておくべきです。意外に見落としやすい問題は、CADなどのライセンスを管理するサーバ（ライセンスサーバ）やファイル共有サーバ（ストレージ）などが停止すると、数多くのCAD利用者が業務をできなくなることです。実際的に設計が止まってしまうことになると、大きな被害になるので、スレーブサーバなどの代替機を用意しておくことも考えるべきでしょう。

これらに関しては、バランス感覚を持って対策を進めていくことが、最も必要とされることのように思います。やはり、業務は縦横に様々な連携があるものなので、企業内外のネットワークシステムの中で、部分的に構成要素の信頼性や可用性を高めたとしても効果は期待できません。モノづくりのプロセス全体が機能し、流れてこそ事業の中での効果となります。図4のように多様な検討の切り口を設けて、検討を深めていくことが望まれます。

近年、各企業では事業継続の視点からリスク管理の検討が進み、BCP（Business Continuity Plan ： 事業継続計画）の策定が進められています。日本企業におけるBCPの検討では他でもなく、「震度6強の地震が会社を襲った場合に、事業継続できるか？」といったシナリオがガイドラインとなっていますが、今回の震災を機に、事実に即した現実的な計画を考えられる企業が増えてくると考えられます。私どもとしても、ものづくりを現場で支援するベンダーとして、災害対策のテーマにおいても、お客様のお手伝いをさせていただければ幸いに存じます。

（技術ソリューション部 部長SE 吉野）