ディザスターリカバリーに対する危険な思い込み
既存のコードを利用して新しいアプリケーションを作成するための戦略
ディザスターリカバリーについて明らかによくご存じでないと思われるお客様と、以前お話をしたことがあります。このお客様の会社では、ご使用になっているAS/400に全幅の信頼を寄せていました。今まで一度の障害もなく稼動を続けてきているし、IT部門のスタッフが毎晩システムのフル・バックアップを実施しているから大丈夫だ、と。AS/400、iSeries、System i、POWER systemはいずれもすばらしいシステムだと、私たちも皆、信じています。しかし、ご贔屓いただいている、ある社長は、「信頼はしていても、検証はすべきだ」と、よく言われていました。私が担当しているお客様の会社では、システムを信頼されてはいますが、検証をしているかとなると、それほどでもないようです。
いつも通りの朝のことです。AS/400はジョブの実行、印刷物の生成、データの保存と回復などといった、AS/400としてなすべきことを実行していませんでした。端末画面に数字を一つ映し出したまま、琥珀色の明かりの中、静かに佇んでいるだけでした。すぐに担当者が電話で呼び出されました。カスタマー・エンジニアが到着すると、「おや、これはまずい」と呟きました。(カスタマー・エンジニアがこの台詞を呟くのを聞くのは、いいものではありません。)
カスタマー・エンジニアが原因を調べてみたところ、ドライブ装置が故障していただけだとわかりました。これは、RAID保護機能が使える時代では、それほど大きな問題ではありません。まだ話は終ったわけではありません。そのお客様は確かにRAID保護機能をお持ちでした。障害アクティビティ・ログ(PAL: Problem Activitiy Log)やサービス・アクション・ログ(SAL: Service Action Log)など、ごく普通の人間であるシステム管理者たちが手を出したくないサービス・ツールでさらに調査して明らかになったのは、厄介な現実でした。RAIDセットの中で故障しているドライブは、これだけではなかったのです。失われたデータのことが皆の頭によぎったのか、一瞬の沈黙が流れました。
沈黙に続いて、管理者の口から前向きな発言が次々と飛び出しました。「我々は（賢明にも）、毎晩システムのフル・バックアップを取っているじゃないか。だからドライブを交換すれば心配ないさ。」 こうして、故障したドライブを交換し、保護機能を再設定したところ、システムは黄色ランプが消えた状態に戻りました。しかし、それは何の意味もありませんでした。データ、プログラム、ユーザーなど、その他AS/400の存在意義とも言えるデータが失われてしまったのです。早速テープをマウントし、システムを再読込みするオプションを選択したところ、テープが回り始めました。テープは回転し、さらに回転し続けました。そして最後に回転が止まりました。すると、さらに悲しいメッセージが表示されたのです。「必要なファイルがテープ上に存在しません。」
「おそらくドライブが故障したときに、テープが完全には書き込まれていなかったのではないか。もう1本前のテープで試してみよう」と、カスタマー・エンジニアが提案しました。そして、沈黙が流れました。長く、つらい沈黙でした。映画「ウォー・ゲーム」に出てくるジョシュア(核戦略シミュレーション・プログラム)が、自分の世界熱核戦争「ゲーム」が夕方のニュースで流れているのを見るかのように、システム管理者は喘ぎながら、椅子にドスンとすわりこみました。「あの･･･わかっていると思うけど、それがもう1本前のテープなんだ。そしてその前の晩のも、その前の晩のも同じだ。テープを交換していなかったんだよ。」 あの偉大なるアイルランド人、エドワード・マーフィー氏が大喜びしたことでしょう。「失敗する可能性のあることは必ず失敗する」という、マーフィーの法則が実証されたわけですから。
教訓
ここには、明らかに学ぶべき教訓があります。まず1つめは、システムを監視すべきだということです。上の例の場合、最初のドライブが故障してから次のドライブが故障するまで、ほぼ1年が経過していました。これほど重大な故障を1年も見過ごすことは、いかなる理由があっても許されません。2つめの教訓は、テープ1本だけではバックアップの役目を果たさないということです。テープも不具合を起こします。このお客様の場合、考慮が欠けていたのは、テープを初期化してからテープへの保管が完了するまでの時間、何もバックアップしていない、ということです。このテープは8MMで、書き込みを完了するのに6時間かかりますから、このお客様は実際には1日の約25%の間、バックアップを何もとっていなかったことになります(テープ代の節約にはなったでしょうが)。さらに、何年間にも渡って同じテープを使用していたのですから、最初から最後までエラーなしに読み込める確率は、ゼロに近づいていたでしょう。悲しいことに、このお客様はもはやIBMのお客様ではなくなりました。お客様の無知が原因で、「保守が難しくない」他のプラットフォームに移行されました。もちろん、AS/400の保守に必要な時間よりも少ない時間で保守できるようなシステムは、なかなかないと思いますが・・・。
ディザスターリカバリーに関するクイズ
ディザスターリカバリーの最初のルールについて、考えてみましょう。ディザスターリカバリーとは、いわば、火災保険のようなものです。われわれはみな保険料を支払うわ」けですが、その結果として最も好ましいのは、代理店に連絡して保険金を請求したりせずに済むことなのです。ディザスターリカバリーについても同じことが言えます。災害が発生しなければ潜在的な欠陥は表面に現れず、もちろん会社の業務は中断されることなく継続されます。しかし、火災のリスクが低いエリアに住んでいるからといって火災保険に加入しないのと同じように、ディザスターリカバリー計画をテストしないというのは、好ましい考えではありません。
ご使用のシステムを見てみてください。先ほどご紹介した残念なお客様よりは、皆さんの方がずっとしっかり対策をとっていらっしゃることでしょう。それは皆さんが扱っているデータが重要で、システム上で常にユーザーにとって利用可能でなければならないということをご理解なさっているからです。バックアップも保存しておられるでしょうし、ディザスターリカバリー用サイトと契約を結んでおられるかもしれません。すばらしいことです。ではここで、ディザスターリカバリーに関する、ちょっとした非公式のクイズでどのくらい点が取れるか試してみてください。
- 現在所有しているバックアップ・テープを使用して、ゼロからシステムを再構築する計画を備えていますか。(概要、メモ書き、3年間に前任者が書いたノートなどは、計画のうちに入りません。)
- 上記質問1への回答が「はい」の場合、このシステム再構築に必要なテープを具体的にかつ明確に特定することができますか。(テープを特定するのに必要なデータがシステム上にだけ存在している場合、答えは「いいえ」になります。)
- 上記質問2への回答が「はい」の場合、今すぐにそのテープにアクセスできますか。(そのテープがまだ建物内にあるか、または[恐ろしいことに]システム・ユニットのテープ・ライブラリ内にある場合、答えは「いいえ」になります。)
- 上記質問3への回答が「はい」の場合、上記質問2で特定し、3でアクセス可能としたテープを使って、上記質問1で答えた計画をテストした結果、それは成功しましたか。おそらく成功したことはないのではないでしょうか。計画そのものがない。あるいは、計画の考えや見解は持っている。では、レジュメは備えていますか。
システムの再構築はおそらくこうすればできるだろうと頭で考えているのと、実際に所有しているバックアップでシステムを再構築するのとでは、グランド・キャニオン渓谷ほどの差があります。そしてまさかと思われるでしょうが、バックアップがあればディザスターリカバリーができるというものではないのです。いよいよディザスターリカバリー計画を始動するというとき、バックアップ・テープの完全なセットとそれ持ち込む場所を得るということは、ディザスターリカバリー手順リストの最初の項目に過ぎないのです。
ディザスターリカバリー手順リスト
実際のところ、ディザスターリカバリー手順リストは、実際に災害が起こるかなり前から始まります。以下の項目を検討する必要があります。
バックアップ用サイト
計画の最初のフェーズは、業務を継続するのに必要なものがバックアップ用サイトに備わっているか確認することです。十分なディスク容量、十分なメモリ、十分なCPWが必要で、さらに非常に重要なものが2つあります。1つは、使用するテープと互換性のあるテープ・ドライブです。この理由はすぐにおわかりになるでしょう。使用するテープを読めないのでは意味がないですから。2つめは、あなたのオペレーティング・システムを実行できるシステムを、プロバイダが持ちあわせていることです。これは初歩的なことだとお考えになるかもしれません。実際、初歩的なことではあるのですが、使用しているシステム構成に変更があったら、プロバイダにも同様の変更を行ってもらっておかなければなりません。最新のテクノロジーを使用している場合はなおさらです。大丈夫だろうと高をくくっていると、ひどい目に遭うかもしれません。
テープの暗号化
これについては言うまでもないでしょう。暗号化されたテープは適切なドライブとキーがなければ読むことができません。これがポイントです。
通信手段
昔はファックスや電話などといった手段を使用して、他の社員との連絡を簡単に取ることができたでしょう。しかし今日では、サイトへの通信インフラが堅牢であることが重要な要素となっています。この通信手段は性急に構築するわけにはいきません。どこにどれくらいの通信が必要なのかは、皆さんにしかわかりません。場合によってはホット・サイトで常時稼動の専用線が必要になることもあれば、インターネットのVPNをホット・サイトにリダイレクトすれば十分なこともあります。通信に対する要件がどのようなものであっても、バックアップ・システムを稼動状態にした後は、そのバックアップ・システムと通信するための計画を備えておかなければなりません。通信できないということは、そのシステムが存在しないのと同じことです。
ロジスティクス
ディザスターリカバリー用サイトには誰が向かい、指名された人がどうやってそこへ行くのかを明確に知っておかなければなりません。また、コーポレート・カードをサイトに保管しておくとか、封筒に現金を入れて保管しておくなどといった、資金計画も準備しておかなければなりません。ディザスターリカバリー用サイトまでの交通費を社員が自腹で払えるだろうという思い込みは危険です。また、指名された人が不在の場合の代替要員も決めておかなければなりません。私が担当している大企業のお客様は、マシンが利用不能になった場合のみならず、スタッフが不在の場合も想定したバックアップ・プランを作成しておられました。災害が発生したら、まず、ディザスターリカバリー用サイトにも知らせる必要があることを念頭に入れておいてください。誰が誰に連絡できるのか、どんな情報を伝えるのかを、ロジスティクス・パッケージの一部として文書化しておかなければなりません。
文書化
ディザスターリカバリーに関するすべてのプロセスを文書化し、それらの文書を常に最新の状態に保っておかねばなりません。文書がどこにあるかを誰かが知っていなければなりません。計画を処理する最良の方法はおそらく、Lotus Notesデータベースを使用し、チーム全員のノートPCにそれを複製しておくことでしょう。こうしておけば、文書に変更があった場合、わざわざ作業をしなくても、自動的に全員に周知されます。ただし、文書をオンラインでどこかにしまっておいた場合は、計画にアクセスする際そのサイトの設備に依存することができなくなります。これは通信手段も含んでの話です。
変更管理
ディザスターリカバリーに関する心配事には驚かされるかもしれませんが、本来は驚いてはいけないのです。あらゆる変更管理システムはディザスターリカバリー計画を包含したものでなければなりません。今日のビジネス環境においては、変更が頻繁に起こり、しかもディザスターリカバリー計画に影響を与える項目も含まれる場合が多々あります。あなたの変更管理プロセスに、こうしたインパクトの各項目に対するレビューが含まれていることを確認してください。
また変更管理は、システム上のすべてのオブジェクト・タイプを対象にしていなければなりません。たとえば、些細なことがディザスターリカバリー計画を完全に反古にしてしまうような例について考えてみましょう。毎週日曜日の朝にSAVE 21 (Full System Save： システムの完全保存)をして、テープをオフサイトに送付しているとしましょう。ここまでのところは多くの会社でうまくいっているでしょう。データベースのほとんどのジャーナルが取られ、ジャーナルは6時間ごとに更新され、レシーバーをテープにコピーして、そのテープをオフサイトに送付します。夜間にSAVCHGOBJ (Save Changed Objects: 変更のあったオブジェクトの保存)コマンドを実行します。ほとんどのファイルは既にジャーナルがとられているので、このコマンドは短時間で実行されます。次に、開発者のひとりが承認を得ることなく、あるファイルにジャーナルを取り、そのジャーナルを作業ライブラリ中に置いて、トランザクションをトラッキングしてアプリケーションをデバッグし始めたとしましょう。これでバックアップ計画は危機に陥ります。なぜなら、このジャーナルはバックアップされず、オフサイトには存在しないことになるからです。さらに、そのオブジェクトはSAVCHGOBJのテープにも存在しません。これは全く想定外だったのではないでしょうか。
バックアップ
ジム・スローン氏の講演を初めて聴いたのは、かなり昔のことですが、COMMONでのセッションでした。それはQUSERTOOLの最新版についての講演で、同氏はDB2データベース自身が初めてしゃべった単語の話をしてくれました。とある闇夜の研究室でのことです。通路を歩いていると、かすかな声が聞こえてきたそうです。後ろを振り返って耳をそばだてて聞いてみると、DB2が単語を3つささやいていたのです。ゆっくりと、丁寧に、しかもはっきりと、DB2はこう言ったそうです。「バックアップ、バックアップ、バックアップ。」
テスト
バックアップを完了したら、それを使用してテストする必要があります。テスト、テスト、テスト、というわけです。最初のテストは必ずしもリモートのシステムで実施しなくてもかまいません。現在使用しているシステムの他のパーティションや、まだ捨てずに持っていた古いシステム、あるいはビジネス・パートナーがこのような場合に備えて用意しているシステムでテストすれば良いでしょう。要は、テストの初期の段階では必ず何かうまくいかないことがあるので、出張などの手間をかけず時間のロスなく済むように、手元にあるシステムで実施した方が安く済むというわけです。初期段階で出てきた問題点はすぐに解決し、最終的なテストに移ってください。こうすることでテストがうまくいく確率が高くなります。
ISVソフトウェア
ディザスターリカバリーには各ISVのキーが必要となり、そのキーを各ベンダーが生成するステップがどのようなものであるのかを把握しておく必要があります。誰に連絡し、どのようにそのステップを実行すればよいか、理解しておかなければなりません。このプロセスを事前に試行しておかなければなりません。というのも、信じられないかもしれませんが、このプロセスの実行に関しては、ベンダーによってこちらの作業のやりやすさが違うからです。キーが必要になるまで何日か要するというベンダーもあります。通常の業務時間帯でしたら、キーがない状態で起動して稼動させておいてからベンダーに連絡することもできます。事前にキーを教えてくれるベンダーもありますが、毎回同じ物理的なシステムでディザスターリカバリー作業を実施するわけではないという点に、かなり注意が必要です。場合によっては、テストしたのと全く同じシステムであったとしても、パーティション番号が違う場合もあります(キー生成プロセスにパーティション番号を使っているベンダーもあります)。連絡をすればいつでもキーを生成してくれるベンダーもありますが、通常の業務時間帯である8時から5時以外の時間ではカスタマー・サービスのところで止まってしまってキーをもらえない場合もあります。キーがなければソフトウェアは使用できません。ソフトウェアが使用できなければビジネスは継続できません。ディザスターリカバリー計画についてベンダーとよく話し合うか、さもなければベンダーを変更する必要があります。
上記リストはディザスターリカバリー計画に関する完全な文書ではありません。詳細で完全なリストはもっと長くなり、最後まで目を通すと毎回新しい項目が出てきます。準備というのは計画をすればよいというものではなく、そのプロセスを経験するものだということを理解しておかなければなりません。ディザスターリカバリー計画は、すべての計画会議に含まれるという形で日々のルーチン業務の一部となり、変更管理にも組み込まれた重要な部分となっていなければなりません。
ディザスターリカバリーに対する危険な思い込みリスト
IBMのSystem i複製パッケージですべてが最新の状態に保たれているホット・サイトを用意しているから大丈夫だと思っている方もいらっしゃるかもしれません。が、決して安心できません。主要な項目のほとんどが生きているからです。複製サイトを用意している場合でも、通信手段、テスト、変更管理、そして場合によってはISVのソフトウェア・キーが問題となります。
ここまでお読みいただくと、私はディザスターリカバリー計画があまり好きでないという印象をお持ちかもしれません。半分は当たっています。ディザスターリカバリー計画をテストしないのであれば、計画を作成するために時間をかける意味がない、というのが私の考えです。最後に、私からのアドバイスをリストにまとめました。ディザスターリカバリーに対する危険な思い込みのトップ10です。
- 思い込みNo.10：
「バックアップ・テープがどこにあるか、回復に必要なのはどれなのか把握している。」 この思い込みが間違いないことを、少なくとも月1回は必ずテストしてください。システムを再構築するために必要なバックアップ・テープに関する計画の部分を行ってみてください。バックアップ・テープを取り出し、カタログにし、各テープ上になければならない情報が存在するかカタログを調査し、システム再構築に必要な情報がすべて存在することを確かめてください。それらの情報が、データ・センターのテープ・ライブラリではなく、オフサイトにあることを確認してください。 - 思い込みNo.9：
「オフサイトのバックアップ・テープにアクセスする人のリストと、緊急時にバックアップ・テープを取り出す方法が文書化されて最新の状態になっており、およびリストされた人が自分たちはリストに載っているということを認識している。」 このリストを見直して、リストに記載されている人が現在も当該部門の社員であることを確認しなければなりません。行方のわからない人のリストもレビューしなければなりません。バックアップ・テープが鍵のかかる保管庫に格納されている場合は、鍵を持っているはずの人全員が鍵をいつでも提示できることを実際に確認しなければなりません。緊張のない状況で即座に提示できないのであれば、災害が発生した緊張下ではより一層困難になると認識してください。バックアップ・テープが鍵のかかった箱に納められた状態で届き、開けられないのであれば、役に立ちません。オフサイトのロケーションのリストに記載されている各担当者への連絡方法が、手元にあるリストと一致しているかどうかも確認する必要があります。 - 思い込みNo.8：
「バックアップ・サイトに向かうチームに現金、交通手段、宿泊先などの情報が渡される。」 皆クレジットカードを持っているから、数日の宿泊代やレンタカー、食事代くらいは立て替えられるだろうとお考えかもしれません。しかし、クレジットカードを持っている人ばかりではありませんし、カードの利用限度額が超えている人もいるかもしれません。もっとも、どこに向かえばよいのか、どうやって行くのかが分からなければ、全く意味がありませんが。 - 思い込みNo.7：
「業務で使用する書類はすべて事前に印刷されており、バックアップ・サイトで使用可能な状態にある、あるいはバックアップ・サイトに届けられることになっている。」 もちろん大丈夫でしょう。でもバージョンが3代くらい古かったり、小切手は間違った銀行のものだったり、おまけに書類が古くなって乾ききってしまっていて、印刷すると紙詰まりを起こしたりすることもあります。だからどうした、とおっしゃるかもしれません。レーザープリンタしか使っていないから大丈夫だと。なるほどそうかもしれません。では、バックアップ・サイトのプリンターの互換性は大丈夫でしょうか。現在ご使用の2次元のバーコードは印刷できますか。プリンターの要件を伝え忘れていたら、あとで問題になるかもしれません。 - 思い込みNo.6：
「バックアップ・サイトのシステムは十分なサイズがあり、テープ・ドライブの互換性も確認済みである。」 これは非常に重要で、きちんと準備しておくのがそれほど難しいわけではありませんが、回復作業の基礎として絶対に間違えてはならない項目です。テープ・ドライブ、プリンター、光学ライブラリなどの、他に使用する可能性のある周辺機器も必ずチェックしておいてください。 - 思い込みNo.5：
「ベンダー・ソフトウェアがバックアップ・システム上で正常に動作し、キーが簡単に入手できるはずだ。」 キーの入手についてはISVと確認してください。そうでなければISVを変えてください(キーではなくISVを変えてください)。結局のところ、ISVのビジネスはあなたのビジネスをサポートすることであり、彼らはそれで金を稼いでいるのです。 - 思い込みNo.4：
「バックアップ・サイトと自社サイトとの間の通信や取引パートナーとの間の通信が、正しく適切である。」 もちろん、VPN回線をいくつか立ち上げれば大丈夫かもしれません。VPN接続の設置を妨げる問題を解決するのに事実上数ヶ月を要するようなAT&Tなどの企業は稀ですが、事前の計画なしに通信がすべて完全に動作するなどと、決して期待してはいけません。 - 思い込みNo.3：
「バックアップからの回復はエラーなしで終了する。」 バックアップからの回復を一度も試みたことがないとしても、これを信じるほどだまされやすい人はいないでしょう。回復作業が何度も成功している記録を提示できるのであれば、そういう場合に限っては、信じてもいいでしょう。たとえそうだとしても、信用してもいいですが、検証してください。 - 思い込みNo.2：
「まだ十分に洗練されていない詳細項目については、バックアップ・サイトで検討する時間があるだろう。」 そのような時間はどこにあるのでしょうか。問題となっているシステムで作業をするための時間はないでしょう。担当者が手配できない場合のことも考えておいてください。オンサイトの担当者が最前線要員でない、熟練要員ではない、あるいはシステムの詳細について詳しくないのであれば、チェックリストから外してください。こうした担当者が新しい問題を理解して、すぐに対応して解決できるとは思えません。 - 最後に、危険な思い込みNo.1：
「『テスト』というのは、一回でうまくできない人がしかたなく行うものだと思っている。」 どんなに準備していても、何か忘れてしまっていることがあるかもしれません。そうであれば、忘れてしまった項目が些細なことであるために問題にならないか、あるいは時間があるときに後で解決できるようなものであることを確認することが目的になります。検証テストは毎回別の人が行うようにしてください。いつも同じ人がテストしていると、その人が前提を置いてしまっていたり、あるはずの穴を埋めてしまっていたりといったことが、緊急時に判明するかもしれません。
