|
ITIL サービスデザイン − 可用性管理３ Vol.012 - 2009年05月15日（月2回発行） いよいよ、可用性のお話も今回で終わりです。まずはあらためて、可用性とは何か？ということに関して考えてみましょう。 ITIL書籍「サービスデザイン」では、可用性を定義する際には、次のようなことを定義しておかないといけない、とされています。
もちろんこれら以外にも決めておかないといけないものはたくさんありますが、ようは「どのような状態になったら『使えない』とみなすか」という定義が必要だ、ということですね。使えなければならないと SLA で定義された時間のうち、実際に使えていた状態のことを「可用性」、使えなかった状態のことを「非可用性」という場合もあります。SLA には可用性の割合を示すことがありますが、例えば「応答時間が10秒を超えたら『使えていない』とみなす」とか「どれだけ時間がかかっても、応答さえすれば『使えている』とみなす」などの定義が異なれば、可用性の割合も違ってきます。可用性の定義は、顧客とプロバイダでその解釈が異なっていてはいけません。互いが十分に議論し、合意する必要があります。 可用性管理が導入されると、プロバイダから顧客に対して定期的にレポートを作成して提出する必要が出てきます。そのためには定期的で正確なモニタリングが必要です。さらには将来の可用性計画や、サービス障害分析（SFA）結果などの様々なレポートを提出し、顧客に対して可用性を報告します。これらのレポートを手作業で作成するには大変なので、通常は自動化するためのツールを用います。 さて可用性管理は、単に可用性レポートを作成することが真の目的ではありません。可用性を高めるための活動が必要です。そのためには、可用性を阻害する部分、言い換えれば「システムはなぜ壊れるのか」とか「どこが壊れやすいのか」といったことを分析し、対策を行う必要があるわけです。 可用性を高める対策を行うにも、分析が必要です。ここでは、いくつかの分析手法をご紹介しておきましょう。 まずはサービス障害分析（SFA：Service Failure Analysis）です。これは非可用性を招くイベントやインシデントを全て調査・分析し、事業とユーザに対してもっとも大きなインパクトを与えているものや事業の中断を余儀なくする原因は何か、ということを調べる活動です。 事業活動においてコスト計算は非常に重要です。可用性のコストといえば、可用性を高めるためにどれだけコストがかかるか、ということばかり計算されがちですが、実際には障害が発生したことによって発生するコストや、逆に障害が発生することで得られなくなった収益なども考慮する必要があります。さらには、障害が発生したときのコストを、明らかに遺失する有形コストだけでなく、隠れた損害である無形コストも考慮に入れなければなりません。無形コストは測定が難しいものばかりです。しかし、サービスの非可用性から生じるコストをトータル的に考慮しなければ、可用性を高めることによって得られる価値を正しく測定することができなくなりますので、無視してはいけません。有形コストと無形コストにはどのようなものが含まれるかは、表１を参照してください。 表１：
次に、コンポーネント障害インパクト分析（CFIA：Component Failure Impact Analysis）です。これは、どの構成アイテム（CI）に障害が発生したときにどのサービスに影響を与えるか、ということを調べることにより、サービスを継続させるために重要なCIと、脆弱なITサービスを識別するための活動です。 CFIAでは、図１のような格子表を作成して、CIとITサービスとの関係を明確にします。どのCIに障害が発生すればどのサービスに影響があるか、ということをはっきりさせるわけです。例えば表１の例では、ロードバランサはすべてのサービスと関係しています。もしロードバランサに障害が発生すると、すべてのサービスに影響を与えます。また、企業が営利目的の活動を行うにあたっては、販売管理システムや在庫管理システムに依存している事業活動は非常に重要な事業機能、すなわち VBF であるといえます。したがって、VBF を支えているサーバシステム１や３は、サーバシステム２や４に比べると重要度が高いといえるでしょう。 これらの特に重要な CI に関しては、可用性を高めるための対策を講ずる必要がある、といえます。もし十分な対策を施しておらず、その CI が障害を起こすことによってサービス全体が停止してしまう、というような状態になったら大変です。「その CI だけに障害が発生した場合でも、サービスの提供に致命的な影響を与える」ようなコンポーネントのことを、単一障害点（SPoF：Single Point of Failure）といいます。 余談ですが、ある組織でこんなことがありました。ある優秀な IT担当者が様々な分析を行い、社内のすべての重要な機器を二重化し、十分な可用性を確保しました。万が一障害が発生した場合でもその復旧計画を策定し、マニュアル化しました。担当者は、自分が陣頭指揮をとって障害対策にあたれば、たいていの障害はすぐに（SLAで合意した範囲内で）復旧できるという自信を持っていました。これで SPOF はすべてなくなった、と思っていました。 次に、故障樹解析（FTA：Fault Tree Analysis）です。これは、ITサービスの中断を引き起こすイベント連鎖を判別するために使用する技法です。図３をごらんください。これは「故障樹」と呼ばれる、故障の内容とその原因をツリー構造で表現したものです。一番上にITサービスの障害の状態を書きます。その下に、そのITサービス障害の原因として考えられるものを列挙します。複数の原因が同時に発生したら障害が起きるという場合は論理積ゲートで、ひとつでも原因が発生したら障害が起きるという場合は論理和ゲートでそれぞれを接続します。さらに、その原因が発生しうる下位の原因を考え、同様につなぎます。この階層をどんどん深くしていって、これ以上分解できないという根本原因まで分析します。 故障樹分析を利用することで、、そのサービスに対して考えられる脅威を割り出すことができます。また、各脅威に対する対策を詳細に計画できるようになるのです。 これ以外にも、システムの可用性を保護するために実施する対策を識別したり定量化したりするための技法がたくさんありますが、代表的なものは上記のとおりです。 図１：格子表の例
さて、今「脅威」という言葉を使いました。読者の方々は、「脅威」と「脆弱性」と「リスク」の区別がわかりますか？ これらを明確にしておかないと、結局どのような対策をとればいいかがあいまいになります。言い換えれば、まもるべき「資産」とそれに対する「脅威」「脆弱性」が明確になれば、その資産にどのような「リスク」があるかがわかり、リスクを取り除いたり、被害を最小限に食い止めたりするための対策を講ずることができるようになるのです。 それぞれを簡単に定義しましょう。まず「資産」とは、守るべきもの、守らなければならないものです。もちろんIT資源（ハードウェア、ソフトウェア、データ、人材）は重要な資産です。そのほか建物や施設、お客様、お金、社会的信用なども、大切な資産です。 その資産に悪影響を与える「原因となる事象」が、「脅威」です。脅威の例としては、以下のようなものがあります（もちろん、これ以外にもたくさんあります）。 ハードウェア：故障、人為的破壊 など ソフトウェア：誤動作、フリーズ、動作しない など データ：盗聴、改ざん、破壊 など 建物・施設：地震、台風、火事、テロ など 次に「脆弱性」とは、その脅威を引き起こしやすくする要因のことです。つまり、脅威と脆弱性とがあいまって、リスクを生み出すのです。脆弱性の例としては、以下のようなものがあります。 図２：故障樹の例 ハードウェア：古い部品を使っている、定期点検していない、設置場所が悪い など ソフトウェア：バグ、設計ミス など データ：暗号化されていない、セキュアな環境に保存されていない など 建物：災害対策を施していない、地盤の弱い場所に建っている、施錠していない など つまり、「資産」に対して「脅威」があり、その脅威を発生させやすくする「脆弱性」があると、「リスク」がある、ということになるわけです（図３）。リスクとは、資産に対する悪影響そのものです。ITサービスが利用できない、情報が漏洩する、といったようなことが代表的なリスクの例でしょう。 図３：資産、脅威、脆弱性 リスク分析とは、すなわち以下のような作業をいいます。
さらに、可用性に対するリスク分析は、それ単独で存在することはありません。ITSCM、セキュリティ管理、サービストランジションなどと連携して活動することになります。 以上で、可用性管理プロセスのお話は終わりです。 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
