Comments
Description
Transcript
運用管理のお手本 ISO/IEC 20000
JIP-ITSMS122-1.0 運用管理のお手本 ISO/IEC 20000 ～事例から学ぼう～ 構成管理 編 新規サービス又はサービス変更の設計及び移行 平成 24 年 9 月 20 日 一般財団法人日本情報経済社会推進協会 JIPDEC の許可なく転載することを禁じます JIP-ITSMS122-1.0 ～ はじめに ～ IT サービスマネジメントシステム（以下「ITSMS」）とは、サービス提供者が提供す る IT サービスのマネジメントを効率的、効果的に管理するための仕組みです。 ISO/IEC 20000 は ITSMS の国際規格として制定されました。 ISO/IEC 20000 を実践することは、運用のあるべき姿の実現に向けて取り組むこ とに他なりません。ISO/IEC 20000 は運用プロセス群において、必須で対応すべき 項目をプロセス毎に体系的に整理した「仕様」であり、単に “あるべき姿”を紹介す るものではなく、システム運用管理の“お手本”として利用できるものなのです。 本書は ISO/IEC 20000 の持つ運用管理のお手本としての“エッセンス”を事例を 通じて紹介することで、運用管理のあるべき姿の実践に関心を持って頂く事を目的 に作成しました。 JIP-ITSMS122-1.0 当社のITサービスは ITSMSを導入し、 認証を取得しています!! それなら、安心だ。 おたくに、わが社のシステムの 運用管理をお願いするよ!! 読者としては、IT サービスの提供にかかわるすべての方を意識していますが、と りわけ、運用管理の実務者・実践者の方々にとって有用でありたいと願っていま す。 また、本書作成に至った背景には「ISO/IEC 20000 認証を取得しても、発注側が ISO/IEC 20000 とは何かを全く知らないというケースもあり、結果として“対外的な信 頼性確保の表明”につながっていない」という現状があることを、少しでも改善した いという意図もあります。 さらに、ISO/IEC 20000 への関心はあるものの、「ISO/IEC 20000 の導入は大 変!!」というイメージを持たれている方にも、本書を通じて ISO/IEC 20000 導入に対 する“しきい”を下げ、ISO/IEC 20000 をもっと身近なものに感じて頂くことも目指し ています。 本書は「事例から学ぼう ISO/IEC 20000」をコンセプトに、運用の現場でよく出く わす事柄や失敗事例を題材に、ISO/IEC 20000 導入の効果を知って頂けるよう構 成しており、また、「非常に結びつきの強いプロセス」をセットにして紹介していま す。 ※ISO/IEC 20000 は、日本においては国内規格として JIS Q 20000 が発行されており、本 書では、JIS Q 20000 を引用しています。 JIP-ITSMS122-1.0 ～ 目次 ～ 1. 構成管理 .................................................................................................... 1 2. 失敗から学ぼう構成管理 ........................................................................ 5 2-1 ケース 1:どこに、何があるのかわからない ..................... 5 2-2 CIを定義しよう ................................................................ 7 2-3 ケース 2：そのシステムが止まるとどうなるの？ ........... 9 2-4 ケース 3：こっちの変更があっちに影響 ....................... 12 1. 構成管理 JIP-ITSMS122-1.0 運用管理の実践には多くのプロセスを必要とします。例えば、IT システムのハー ドウェアの交換、あるいはソフトウェアを改修するには複数のプロセスの関与が必要 です。前回の変更管理編でも紹介したように、提供している IT サービスのどこかに、 何らかの変更を加える場合には、変更管理、リリース及び展開管理を中心としたプ ロセスの連携が必要となります。 さらに、変更の出発点である変更要求の書類が、何らかの不具合の結果から起 票されているとすれば、インシデント管理、問題管理の関与も想像できます。 このように、運用管理の実践には多くのプロセスが連携しあい、互いにコミュニケ ーションを取りあうことが必要なのです。 ISO/IEC 20000 規格で規定している運用管理プロセスの数は 14 にのぼりますが、 各プロセスは、その実行場面において様々な情報を必要としています。 例えば、変更管理は変更しようとする対象が現在どのような状態にあるのかを知 らなくては、変更に着手することが出来ないでしょう。インシデント管理は、過去のイ ンシデントの記録を参照できないと、既知のエラーなのかどうかを判定できません。 構成管理は、運用管理の多くのプロセスに対して、プロセスの実行に必要な情 報を提供します。ただし、その情報は正確で、かつ最新でないといけません。極端 な表現をすれば、構成管理は他のプロセスに対して情報を提供することが責務で あり、自分からは何もしないプロセスともいえます。 1 JIP-ITSMS122-1.0 リリース及び 展開管理 インシデント 管理 XXX管理 変更管理 CMDB ェア 文書 ソフトウ ハード セ ウェア ライ ンス 一見、簡単そうに思えますが、運用の世界では簡単そうなことが、実際にやって みると、すごく難しいということがよくあります。構成管理もその一つです。 他のプロセスにデータを供給すると言っても、プロセス毎に供給すべきデータの 持つ意味が異なります。表 1 は構成管理がプロセスに供給する代表的なデータの 例です。 プロセス名 構成管理からの供給データ 問題管理 IT サービスの情報、既知のエラー情報 変更管理 変更のインパクト解析 リリース管理 ソースコード、場所、ソフトウェアの版 サービスレベル管理 IT サービスに関連する契約文書、合意文書（例： インシデント管理 問題を分析・解析するための詳細データ SLA：Service Level Agreement など）。 財務管理 サービスの利用についての情報（例：PC の所有者） サー ビ ス 継 続 及 び 可 用性管理 IT サービスに貢献する IT システムのハードウェア、 ソフトウェアを含む詳細情報 容量・能力管理 IT サービスの最適化に必要なデータ 表 1：構成管理のプロセスへの提供データ例 2 JIP-ITSMS122-1.0 構 成 管 理 で は 、 プ ロ セ ス へ 提 供 す る デ ー タ を 格 納 す る も の と し て CMDB （Configuration Management Data Base：構成管理データベース 以下 CMDB とす る）を用意します。名前はデータベースですが、必ずしもデータベースソフトが必須 というわけではありません。理論的にはスプレッドシートの代表である Excel、あるい は Access といったツールを利用して構築することも可能です。 では、明示的に CMDB を持たないと構成管理が機能しなくて、IT サービスの運 用管理の提供が出来なくなってしまうのでしょうか？ 答えは、“No”です。明確な CMDB が無い状態でも、IT サービスの運用管理を 提供しているケースは珍しくありません。運用の現場においては、構成管理のプロ セスとしての仕組み、とりわけ CMDB に相当する部分は、構成管理以外のプロセス が持つ手順書等の文書類に埋め込まれるか、あるいは外部ベンダーによってデー タが提供されていることで補完されているからです。 例えば、IT インフラストラクチャで考えると、IT システム、ネットワーク、ストレージ などの基幹部分における機器の構成情報と管理はベンダー任せになりがちです。 各ベンダーは、サービス提供者からの依頼に応じて、機器構成図、構成機器のフ ァームウェア情報などを、ファイルあるいは共有情報といった形で提供します。ソフ トウェアに関しても、同様の構図が考えられます。全体としては、仮想的な構造で、 CMDB の一部が実現されていると考えることも可能かもしれません。しかしながら、 この状態では、IT サービスの提供に効果的な構成管理のプロセスが存在し、 CMDB が存在しているとは言えません。 構成管理の下で制御される CMDB は、単なるデータベース以上の特徴を兼ね 備えていて、IT サービスの運用管理を強力に下支えすることが可能なのです。詳 細は専門書に譲るとして、ここでは、構成管理 CMDB の代表的な特徴の一つであ る、“関係（relationship）”を押さえておきましょう。 IT サービスを構成する要素の間で、どのような依存性があるかを表現するのが、 “関係（relationship）”です。例えば、ある A システムはメールサービスという IT サ ービスを構成する一部であることを、“関係（relationship）”として表現します。同じ 3 JIP-ITSMS122-1.0 ようにソフトウェアも、“関係（relationship）”でメールサービスに紐づけることが出 来ます。仮に、メールサービス全体の“関係（relationship）”として、図 1 のような関 係が CMDB 内に構築できたとします。これは運用管理のプロセスに対して多くの利 点を提供します。たとえば、ソフトウェアにパッチをあてる必要がある時には、CMDB 内のデータを参照することで、影響を受ける利用者や IT サービスの識別、さらには、 パッチを充てることで、どのようなリスクが存在するかまでを論理的に知ることが可能 になります。 現実においては、図 1 のような単純にモデル化した IT サービスなど存在しませ ん。多くの企業では、複数のシステム上で膨大な数のソフトウェアが稼働し、複雑 に構成されたネットワークを通じて、社内外の利用者に IT サービスを提供していま す 。 IT サ ー ビ ス と 複 雑 に 入 り 組 ん だ ハ ー ド ウ ェ ア や ソ フ ト ウ ェ ア を “ 関 係 （relationship）”の観点から整理して、モデル化することは、容易ではありません。 しかしながら、良くできた構成管理と CMDB が、運用管理のプロセス群にもたらし てくれる有益な情報は、効率的な IT サービスの提供に貢献するだけでなく、ひい ては運用管理の見える化と効率化につながってゆくことは容易に想像できるでしょ う。 図 1：関係（Relationship）の概念 4 2. 失敗から学ぼう構成管理 JIP-ITSMS122-1.0 2-1 ケース 1:どこに、何があるのかわからない クラウドの勢いに押される形で A 社も社内向けにクラウドサービスを導入するこ とになった。S 部長は、クラウドを導入する前に社内システムの仮想化を推進 すべきだと考えた。手始めに、システム運用を委託している B 社へ、クラウドで 置き換える予定のレガシーシステムの調査を依頼した。しかし、数週間たって も、担当者から返事がない。 S 部長： どうしたんだね。ずいぶん前にレガシーシステムの現状を教え て欲しいとお願いしたはずだが？ 運用担当者： すいません、まだ、調査中なのです。 S 部長： どれくらいの期間が必要なのかね。たかだか、数システムの構 成を調べるだけだろ。一体、そんなに時間をかけて、何を調査 しているんだ。 運用担当者： 実は、企画時の情報しか残ってないのです。このシステムはカ ットオーバーの後に、利用者数が大幅に増えてしまったため に、アプリケーションも何度か手直しをしています。その際にメ モリーや CPU ボードを追加して対策しています。現状でシステ ムがどのような状態にあるのか、よくわかってないのです。 S 部長： どこに何があるのかわからないで、運用・保守をしているのか ね。困ったものだ。 5 JIP-ITSMS122-1.0 ？ ？？ う～ん、何が入って いるんだったかなぁ？ IT サービスマネジメントの世界では、IT サービスの提供者が管理すべき要素を 構成品目（CI：Configuration Item 以下 CI とする）と呼びます。CI をどのように決め て、管理するかは、IT サービス提供者に委ねられます。理想的には、構成管理の プロセス設計時に CI の仕様を決めておくことが望ましいのですが、現実の運用管 理においては、実際に提供しているサービスに関連する CI さえも明確になってい ない事もめずらしいことではありません。 CI として何を対象とするかについては、絶対的なルールがあるわけではありませ ん。IT サービスマネジメントは、人、プロセス、製品をバランス良く組み合わせて顧 客にサービスを提供します。サービス提供者が管理すべきと考えるなら、人、プロ セス、製品に含まれている要素の中で、IT サービスに関連するものすべてを CI とし て扱うことができます。 一般的に、CI として扱う例としては、次のようなものが考えられます。サービス提 供に利用している IT インフラ、ネットワーク、サービス利用者の PC、システム上で稼 働中の OS、業務アプリ、ミドルウェアなどが CI の代表的なものです。変わったところ では、マニュアルや手順書などの、さまざまな文書類も CI として扱うことが可能で す。 6 2-2 CI を定義しよう JIP-ITSMS122-1.0 A 社のケースを考えてみましょう。サービスを提供している状態にありながら、い ざ調査となると満足な構成情報が無いようです。運用を委託されている B 社には構 成管理のプロセスが存在するかどうかも怪しい気さえしてきます。 CI を定義すること自体は、そう難しいことではありません。大雑把な表現をすれば、 変更管理で扱う対象を CI とすれば、ほとんどのプロセスにとって必要な情報は提 供できます。ISO/IEC 20000 の構成管理プロセスでは CI の定義について次のよう に規定しています。 CIの種類ごとの定義について文書化しなければならない。各CIについて記録し た情報は，効果的な管理を確実にし，少なくとも次を含まなければならない。 ・CIについての記述 ・場所 出典:JIS Q 20000-1:2012（項目は一部を抜粋） 各 CI の種類の定義とは、カテゴリーにより分類することを意味します。CI の種類、 すなわちカテゴリーの代表的な例としては、ハードウェア、文書、ソフトウェアなどが あります。分類することにより、カテゴリー毎の CI の特徴を表すことが可能になりま す。CI は大雑把に言えば CMDB の中にある一つの記録単位です。CI に記録する 内容を属性と呼びます。CI の種類により、属性として記録する情報が異なる事は、 容易に想像できるでしょう。例えば、ソフトウェアのライセンス情報はソフトウェアカテ ゴリーに属する CI には必要となりますが、ハードウェアのカテゴリーに属する CI に は属性として必要はないでしょう。 CI にはカテゴリーに関係なく、共通事項として備えておくべき属性情報がありま す。規格では特に、“場所”として明示しています。これは、CI が設置あるいは保管 されている場所を意味しています。また、CI は同じものが二つ存在してはいけませ ん。ID を属性情報として持つなどして、一意に特定できるようにする必要がありま す。 7 JIP-ITSMS122-1.0 ケース 1 のように、どこに何があるかわからない状態では、構成管理に着手する にしても、何から手をつけて良いのか迷うことでしょう。まずは、何をどういう状態で 所有しているのかを、論理的、物理的に調べることで、構成管理の第一歩を踏み 出すことが可能になります。 8 2-3 ケース 2：そのシステムが止まるとどうなるの？ JIP-ITSMS122-1.0 S 部長： クラウドへの置き換えもいろいろ大変なことがあったが、少しず つ先が見えてきたな。 運用担当者： はい。一時はどうなることかと思いましたが、レガシーシステム の全体像もわかって、クラウドに置き換える機能も決まりました からね。 S 部長： そうだな。部分的にではあるが、これがうまくいけばコストも少し 削減できるな。大きな障害が発生しなければいいが。 運用担当者： レガシーシステムの構成も改めて調査しましたからね。大丈夫 ですよ。 S 部長： 君のその楽観的なところは見習いたいものだ。 運用担当者： 部長、大変です！ S 部長： （悪い予感がするな・・・）何があった？ 運用担当者： レガシーシステムからクラウドへの置き換えを行ったのです が・・・ S 部長： 知ってるよ。うまくいったのだろう？ 運用担当者： はい。置き換える機能自体の移行はうまくいきました。 S 部長： 何が大変なんだ？ 運用担当者： ＜しばらくしてクラウドへの置き換えが行われた・・・＞ それが、置き換える機能を提供していたハードウェアを、古くな っていたこともあり、ほかに使い途もないだろうということで、廃 棄処分したんですが・・・ そのハードウェアの上で、実は業務管理システムの重要なアプ リケーションが動いていたみたいなんです。 レガシーシステムの構成上では、ほかに何も提供していない、 ということだったので安心していたのですが・・・ S 部長： ほかに影響がないか、すぐに調べて対応したまえ。 9 JIP-ITSMS122-1.0 システムは、その利用者、開発者、運用者それぞれの要望などによって、改善さ れていくものです。また、システムでいろいろできるようになったことに伴い、複数の システムが連携して一つまたはいくつかの業務機能を提供していることも多いでし ょう。そのような環境において、あるハードウェアが複数のシステム（または機能、サ ービスといってもよいでしょう）に関連することも多いと思われます。 どうしよう、 廃棄しちゃった。 継続的に変化するシステム環境、ハードウェア環境、ソフトウェア・アプリケーショ ン環境などの所在や関連性を正確に把握していないと、前述したようなことが発生 してしまいます。 構築時は正確に記録されていても、継続して文書類のメンテナンスがなされてい ないことも往々にしてあります。あるいは、メンテナンスはされているものの、記録さ れている情報の正確性に疑問が出てくることもあります。そのような事態の発生を 防ぎ、常に正確かつ最新の情報として維持するために、ISO/IEC 20000 の構成管 理プロセスでは次のような要求事項があります。 CIは一意に特定し，CMDBに記録しなければならない。CMDBは更新アクセスの 制御を含め，その信頼性及び正確性を確実にするために管理しなければなら ない。 CIの版を記録，制御及び追跡するための文書化された手順をもたなければなら 10 JIP-ITSMS122-1.0 ない。制御の程度は，サービスの要求事項及びCIに関連するリスクを考慮して， サービス及びサービスコンポーネントの完全性を維持するものでなければならな い。 出典: JIS Q 20000-1:2012 書かれていることは一見当たり前のように感じられますが、この要求事項の実行 と維持が難しいことは明らかでしょう。本書を読んでいる方も、構成管理を手掛けた 方は、実感としてお持ちかも知れません。実際のところ、この要求事項を実装する には ISO/IEC 20000 Part2 や関連書籍の実装上の手引を参考にする必要がある でしょう。 また、上記の要求事項は、日々の運用上で CI に関する情報を正確に維持する ためのものですが、それだけではなかなかうまくいかないのも世の常です。そのた め、ISO/IEC 20000 では、定期的に構成情報の正確性を確認する“引き締め効 果”を狙ったような要求事項もあります。 サービス提供者は，あらかじめ定めた間隔で，CMDBに保管されている記録を監 査しなければならない。欠陥がある場合には，サービス提供者は必要な処置を とり，とった処置について報告しなければならない。 出典: JIS Q 20000-1:2012 日常的に正確な情報を記録するための手順を作って運用し、定期的にその情 報の正確性を確認する、という当たり前だと思われることも ISO/IEC 20000 の構成 管理プロセスには記載されています。 11 JIP-ITSMS122-1.0 2-4 ケース 3：こっちの変更があっちに影響 S 部長： 今朝から販売システムで、ある商品コードが正しく表示されな いというクレームが来てるぞ。 開発担当者： え、そうなんですか。すぐに原因を調査します。 S 部長： 急いでくれ。それにしても、昨日新しくリリースした在庫管理シ ステムの影響じゃないだろうな。 開発担当者： いいえ、それはないと思います。在庫管理システムの RFC に関 する他への影響の評価はちゃんとやりましたから。 S 部長： ところで、CMDB のデータは正しいのだろうな。 開発担当者： だと思いますが．．．。担当者に聞いてみます。 ＜暫くして＞ 開発担当者： 部長、CMDB の担当者に確認しました。CI 情報の更新をサボっ ていたみたいです。そのせいで、在庫管理システムの商品コー ドモジュールの変更が、販売システムにも影響を与えることが わからなかったみたいです。 S 部長： いったい、何をしているんだ！ CMDB のデータは常に最新で ないと役に立たないだろう。担当者を呼んで来い！ 販売システム 在庫管理システム やっとリリース 出来たぞ。 12 ？ あれれ、 うまく動かないぞ。 どうしたんだろ？ JIP-ITSMS122-1.0 IT 環境が最初に構築されたままの状態で維持されるということはなく、常に何ら かの変更が施されることになります。変更は IT 環境の修復や改善を目的としたもの ですが、その変更によって予期しない悪影響が発生しないように注意する必要が あります。変更を実施するためには、変更要求（RFC）が提出されますが、かならず その変更の影響について評価しなければいけません。変更が失敗した場合の影 響を評価したり、あるいは、変更により他の IT サービス、システムなどの CI に与える 影響を評価することになります。 変更を評価する際には、CMDB に記録されている CI に関する情報が使用されま す。したがって、CI に関する情報として、変更の評価を行うために必要な情報が記 録されている必要があります。 ISO/IEC 20000 の構成管理プロセスには、次の要求事項があり、CI に関する情 報として何を定義し、何を記録するべきかを規定しています。 CIの種類ごとの定義について文書化しなければならない。各CIについて記録し た情報は，効果的な管理を確実にし，少なくとも次を含まなければならない。 a) CIについての記述 b) CIと他のCIとの関係 c) CIとサービスコンポーネントとの関係 d) 状態 e) 版 f) 場所 g) ひも（紐）付けされた変更要求 h) ひも（紐）付けされた問題及び既知の誤り 出典: JIS Q 20000-1:2012 CI は、IT サービスを提供するために管理しなければいけない、あらゆる要素で す。各 CI に関する情報は、構成管理データベース（CMDB）によって管理され、そ のライフサイクルを通して、正確で完全な状態で維持される必要があります。一般 に CI には、IT サービス、ハードウェア、ソフトウェア、文書、およびサポート・スタッフ を含むサービス全体またはシステム全体が含まれます。 構成管理プロセスは、変更管理やリリース及び展開管理が変更やリリースを許可 13 JIP-ITSMS122-1.0 したり、問題管理やインシデント管理が問題やインシデントを解決したりするときに、 CI に関する正確な情報をそれらのプロセスに提供する必要があります。それによっ て、関係者が迅速に正しい判断を下せるようになり、効果的かつ効率的な IT サー ビスマネジメント・プロセスを実施することができます。 ISO/IEC 20000 の構成管理プロセスにおける、次の要求事項を実践することで、IT サービスマネジメントの他のプロセスに CI に関する正確な情報を提供することがで きます。 CMDBからの情報は，変更要求のアセスメントを支援するために，変更管理プロ セスに提供しなければならない。 CIの変更は，CI及びCMDBにあるデータの完全性を確実にするため，追跡可能 かつ監査可能でなければならない。 出典: JIS Q 20000-1:2012 14 ～ まとめ ～ JIP-ITSMS122-1.0 今回は、ISO/IEC 20000 の構成管理のプロセスを取り上げました。 IT サービスマネジメントで実践されるプロセス群は、活動のインプットとして、構 成管理で管理し、制御されているデータを必要とします。構成管理のプロセスでは CI を定義し、CMDB を構築して、その内容を運用管理することで、IT サービスマネ ジメントを支えます。 IT サービスマネジメントの実装をインシデントから始めて、問題管理、変更管理と 進めてゆくと、必ず、構成管理に近い仕組みが必要となります。システムのハードウ ェア、ソフトウェアの情報だけを構成情報とすることで、部分的に構成管理を実践し、 残りのプロセスを導入してゆくこともできないことではありません。しかし、不十分な 構成管理では、かえって手間が多くなることも認識しておくべきです。各プロセスと 構成管理のインターフェースや CI 間の“関係（relationship）”といった利点を享受 するには、しっかりとした構成管理計画に基づいたプロセスを構築することが必要 なのです。 次回はサービス継続及び可用性管理をお届けする予定です。 ITSMS 適合性評価制度技術専門部会 一般財団法人日本情報経済社会推進協会 15 JIP-ITSMS122-1.0 本書及び ITSMS ユーザーズガイドのダウンロード提供及び ITSMS 適合性評価制 度に関する FAQ、認証機関/認証取得組織情報の参照などを次のサイトからご利 用いただけます。 URL http://www.isms.jipdec.or.jp/itsms.html JIP-ITSMS122-1.0 ―禁 無 断 転 載― 2012 年 9 月発行 発行者：一般財団法人日本情報経済社会推進協会 〒106-0032 東京都港区六本木 1-9-9 六本木ファーストビル TEL 03-5860-7570 FAX 03-5573-0564 URL http://www.isms.jipdec.or.jp/ JIP-ITSMS122-1.0 一般財団法人日本情報経済社会推進協会 〒106-0032 東京都港区六本木１丁目９番９号 六本木ファーストビル内 TEL 03-5860-7570 FAX 03-5573-0564 URL http://www.isms.jipdec.or.jp/