11月2日(水) ITIL & BC/DRセミナーで講演します
ITサービスマネジメントのベストプラクティス集として人気が高まっているITIL（IT Infrastructure Library）には、事業継続に関する項目としてITサービス継続性管理が含まれています。
これは事業継続計画（BCP）の中で言うと、情報システムの復旧計画部分に相当します。
この度、NECのITソリューションであるプラットフォーム最適化ソリューションのお客様向けワークショップの一環で、11月2日に「ITIL&BC/DR」セミナーを開くことになりました。
私はその中で、最後のセッションで講演することになりました。
ここではBCやBCPは初めてという方向けに、災害時のBCミニ体験も行いながら、BCPの必要性を体感していただき、ビジネス影響分析（BIA）やBCPの基本的考え方、NECのITに関する取組み事例、NECのBCサービスをご紹介する予定です。
このブログをお読みの方は既にBCに詳しくなられている方が多いと思いますが、BCの基本的なことを聞いてみたいという方にはお勧めです。
また社内でBCを推進する立場にあり、同僚の方やご友人にもBCのことを知って欲しいと思われている場合、それらの方にもご紹介頂ければ幸いです。
『プラットフォーム最適化ワークショップ
「ＩＴＩＬ」＆「ＢＣ／ＤＲ」』
===================================================================
◆日時：11月2日（水） 13：00～16：30
◆場所：NEC本社ビル 地下1階 多目的ホール
◆費用：無料
◆プログラム；
◇13:30－14:15 「ITILによるリスク管理について」（NEC 大畑 毅）
ITILにおけるリスク管理はセキュリティ管理やサービスデリバリなど複数の書籍に分散しています。本セッションでは、それらの全体像をご紹介します。
◇14:15－15:05 「ITILセキュリティ管理 」（NEC コンサルティング事業部）
本セッションでは、セキュリティ管理とは何か、ＩＳＭＳとは何が違うのか？
ITSMの中での「ＩＴＩＬセキュリティ管理」の位置付けを明確にするとともに、実際のシステム運用において「情報をどう守り、どう活用していくか」についてご紹介します。
◇15:15－16:45 「ITサービス継続性管理と事業継続計画(BCP) 」（NEC 上野 勝之）
経済産業省や内閣府などが事業継続計画（BCP: Business ContinuityPlan）の策定を促進し始めています。今回はBCPについては初めてという方向けに、BCミニ体験を通じてBCPの必要性を理解していただき、NECでの事例も交えながら、ITILでいうITサービス継続性管理の位置づけ、BCPとしてまとめていく場合の注意事項などをご紹介します。
最終更新時間 20:00 | コメント (0) | トラックバック
事業継続のための代替システムを考える（テストの重要性）
前回共用システム環境のホットサイトをご紹介しましたが、利用の際の注意点を考えてみたいと思います。
共用ということなので、もう既にお気づきの方もいらっしゃると思いますが、マシンのハードウェア構成は市場に良く出回っている機種が基本になります。これをユーザ毎に用意していくと専用ということになり、コストが下げられません。
よって共用の場合は、自分の普段使っているハードウェア環境と異なる機種や機器構成でソフトウェアをインストールして使わなければならないということです。
でもホットサイトサービスを使わずに自ら遠隔地に代替マシンを用意する場合を考えても、現実には同様のことが起こるのが多いかと思います。恐らく代替マシンは使わなくなった旧型マシンや何か余剰マシンを再利用することが多いからです。
厳密に言うと、例え同じ機種で同じ性能や容量のマシンを用意できたとしても、マシン固有の番号は異なるわけで、やはり全く同じということにはなりません。
となるとソフトウェアをインストールする際に、そのソフトウェアはハードウェア固有の情報をチェックしていたりするとライセンス関連で問題が発生する場合があります。また機器構成が異なることにより、ソフトウェアが期待していた環境との違いからうまく動かないことが起こる可能性もあります。
突き詰めていうと、共用であれ専用であれ、テストしてみないと本当に期待していた通りの結果が得られるかはわからないということです。元の環境との差分は共用の方が大きいので、なお更綿密に事前テストをしておき、潜在的な問題を解決しておく必要があります。
米国SunGard社はこのホットサイトサービスの最大手ですが、そのデータセンタには常にどこかのユーザが来て、システムの復旧テストをしています。
これが専用システムであったとしても、その切替にはマシンの問題だけでなく、ネットワークの切替や人間系の判断、操作などが絡むので、やはりテストは重要なのです。
BCP（事業継続計画）は作っただけでは絵に描いた餅なので、テストを実施して中身を叩いていくのが鍵です。
最終更新時間 16:16 | コメント (0) | トラックバック
事業継続のための代替システムを考える（ホットサイト編）
BC(事業継続)の場合、最悪の事態に備えてITの代替システムを遠隔地に用意し、IT面からの事業継続を図るわけですが、この代替システムの確保というのが容易ではありません。
理想をいうと元の場所にあるITシステムと同一のマシンとソフトウェアが遠隔地にあると、ITシステムの運用や技術的な面を考えても最良の解ということになります。
しかし、めったに使わないマシンを資産として持ったり、いつでもディザスタリカバリ（災害復旧）が発動できるよう24時間体制を構築したり、専用の場所を遠隔地に確保するのはコストも労力もかかるので、中々代替システムを持てないのが日本の現状です。
では代替システムが無い場合どういうことが起こるのでしょうか？
恐らくデータのバックアップのみは取っていることが最低条件です。
磁気テープをどこか遠隔地に保管しておき、事が起こったらその時になってマシンを手配することになります。
しかし希望のマシンがすぐに手に入るとは限りません。ちょっと古いマシンや普段あまり数が出ないものだと数週間の単位での納期になる可能性もあります。
地震のように地域レベルで災害が発生すると、マシンの手配合戦が起こり、短納期で入手することはきわめて困難になります。
こういった課題を解決するため、自分で遠隔地にマシンを予め用意する代わりに、同等の機能をベンダがサービスとして提供しようというのがあります。ホットサイトと呼ばれており、米国では広く一般的に利用されています。日本でもNECなど一部のベンダが同等のサービスを提供しています。
これは、共用マシンをベンダのデータセンタに用意しておき、契約ユーザはテストの時や実際に災害が起こったときに磁気テープを持ち込んで、それらのマシンを使って自分のためのIT環境を構築し、システムを立ち上げるというものです。
このサービスの主なメリットは以下の通りです。
(1)自分で資産を持たなくて良い
(2)自分で代替場所を確保しなくて良い
(3)24時間体制を構築しなくて良い
(4)システムの復旧訓練が出来る
この中で案外見過ごされがちなのが(3)と(4)です。どこかのビルの空いている場所に古いマシンを置いておけば、同等のことができそうに思えるのですが、物と場所だけ確保していれば十分というものではありません。
いつ起こるかわからない災害に対して、人を24時間体制で貼り付けるというのは、複数人でないといけませんし、シフト勤務も必要です。
また普段使っていないマシンだと、いざ電源を入れたときに故障が起こって立ち上がらない、なんてことも起きかねません。
代替マシンを使って実際に立ち上げたことが無いと、災害時にはてんやわんやのことになります。やはりシステムの復旧訓練ができる環境を持つということも、物を持つ以上に大事なことです。
こう見ていくとホットサイトはいい事づくめのようですが、課題が無いわけでもありません。次回はその辺りを考えて行きたいと思います。
最終更新時間 11:06 | コメント (0) | トラックバック
バックアップをとれば安心か
失うと元に戻らないものは人命とデータです。事業を継続するのにも両者は不可欠ですがデータのバックアップがあるからといって安心は出来ません。
どこの会社でもサーバにたまった重要なデータは磁気テープにバックアップ（複製）を取っていると思います。いざというときにデータさえあれば何とか復旧できるからです。
しかしどちらかというと、このバックアップは日頃のシステム障害への備えの意味が強いのも現実ではないでしょうか？障害対応のためにはバックアップデータは近くにある方が便利なので、ついつい同じマシン室に置いておくという運用になりがちです。
仮にシステム障害が起こった場合、ソフトウェアのバグなり、ハードウェアの故障さえ修復できれば、失われたデータ部分をバックアップテープから復旧することが可能になります。 とは言うものの、実際にはデータベースの破壊が起こったり、データの前後関係の矛盾が起こったりと、その復旧作業には情報システム部門の方が大変な思いをされていることも多いのではと思います。
ではいわゆる災害もしくはそれに相当するような影響の出る事象が起こったらどうなるのでしょうか？
元のシステム自体が使えなくなるので、別の場所での復旧を考えねばなりません。
即ちデータは同じ場所に保管されていると意味が無いということになりますし、別の場所で新たにシステムをもう1式準備もしなければいけません。
ということはデータだけでなく、システムレベルでのバックアップも考えておく必要があります。
ではここでまずデータのバックアップはどう取れば良いか、今一度考え直してみましょう。
遠隔地に保管するのであれば、どういう周期で送り届けるのかが重要になってきます。毎日バックアップを取っていても、週に一度しか送らなければ、いざ使おうと思ったときには、そのデータの鮮度は最悪1週間前ということになってしまいます。
またあるシステムと別のシステムが連携して動いていることもあるでしょう。ところがそれぞれのシステムの管理者が異なるため、バックアップのタイミングや送り届けるタイミングの整合性が取れておらず、いざ使おうと思ったときには、実は片方のデータの鮮度が古過ぎるために、毎日送っていた方の意味が無くなってしまった、なんてことにもなりかねません。
うーん、全体最適を図りつつ整合性の取れた意味のあるバックアップ運用を確実にこなしていくことは、大変なことのようです。でもこれは運用改善を行うだけで復旧レベルがアップできる、いわゆる金のかからない改善にもなります。
事業継続には、新たなIT投資だけでなく、こういった地道な運用設計という部分が結構鍵になりそうですね。
